Extreme agile - everyone dances!
Hello! Throughout the year we develop the Elba service. In our project, we have introduced Agile practices for the whole team: for analysts, interfaceologists, engineering psychologists, documentaries, testers and promoters, and not just for developers. It seems to be good, and we want to share this experience.
Kent Beck, during a training in Contour, told us how he invented extreme programming. By that time, several good practices were known: programming in pairs, testing code with modular tests, continuous integration, work with iterations, etc. Kent’s know-how was that he suggested using all these practices at the same time and not doing it on a case-by-case basis, but always. That is, the word “extreme” in this case comes from “extremum” and not from “extremism”.
Our situation at the beginning of the project was somewhat similar: the developers knew the practices of the Ajaila and used them, but all the other people in the team were several times more than the developers. Then the idea arose to try to extend these practices to all the people involved in the work. So our agile became “extreme” :)
Elba is a replacement for an accountant for small companies: it forms bills and acts, considers taxes, prepares reports, suggests when and what report to submit - well done, in one word.
The specifics of our project:
Total: 21 people who must achieve a common result. The practices we use for this are below.
')
This is the easiest pattern, the benefits of it are felt immediately. At first we sat on different floors, communicated by mail and spent a lot of time on it. As soon as they moved to one room, they immediately felt the effect: they stopped writing long letters and generally began to write less. Questions are now resolved much faster, more successfully and more positively.
Why do we plan?
So, on the first day of the iteration, the whole team meets at the planning board. Tasks for the current iteration are planned in detail. We also plan several next iterations, but approximately, without decomposing the problem. If to simplify greatly, then planning looks like this:
Thus, the task "pops up" to the release date.
In fact, not every task goes such a long way to development. Rather, it happens with large and complex tasks. In exceptional cases, we thrust the task directly into the iteration of the developers. For example, when the idea to make promotional codes for partners arose, everyone felt the importance of this task so much that they otrelizili it the next day. In general, in life the planning board looks a little more complicated .
After the overall planning is completed, the groups disperse at the corners and evaluate the tasks gathered in the iteration. Not everyone is doing this - only developers, interfaceologists and analysts: the activities of the other groups are poorly planned. To assess the tasks we play in the planning poker . If, after evaluation, it turns out that the tasks do not fit into the iteration, we decide what to throw away.
At first, we prepared a long detailed TK (out of habit), but the developers do not like to read at all, and our developers are no exception. In addition, during the iteration there is no time for reading, especially for a pair (and the developers almost always sit in pairs), therefore the TOR was rightly renamed HZ.
How to work on HZ? Like this:
Programmers do not look at the text, but at the interface prototypes developed by the designers. Prototypes do not need to be read - it is immediately clear from them what to do, but for formulas and formats, programmers still go to the TOR.
As soon as analysts are working on another topic (for example, reporting to the Pension Fund), they arrange a presentation for the whole team. After the presentation, everyone, at least in general terms, imagines what's what.
We are sitting side by side, so when a question arises, there is no desire to look for an answer in the TK — you simply ask the analyst. In general, we communicate a lot and feel the benefits of it (even analysts :).
Both TZ and interface prototypes are not prepared entirely for the whole system: there is no time for this, and there is no point in it - even if it turns out to design a detailed interface prototype a year in advance - it will become obsolete in a month. We are preparing analytics and we are designing only what is being developed in the near future.
We do not have a dedicated person who would distribute tasks to everyone, self-organization plays a big role. For it to work, it is necessary to coordinate with others - everyone should be aware of what the others are doing and are going to do. Daily volunteers solve this problem: everyone gathers at the same time every day at the iteration board.
The iteration board contains the tasks that we have planned to do in the current iteration (the task leaflets at the beginning of the iteration are glued from the planning board to this board).
We go from the top down - each group reports what has been done in a day, what it plans to do tomorrow and outweighs the tasks.
At the fly you can immediately see if someone does not do the task that someone else considers very important, or that the solution of the task is delayed.
All this takes about 20 minutes.
The demonstration takes place at the end of the iteration. On it, the directions show and discuss what has been done during the iteration. This is another way to spread information across all project participants.
In retrospect, the whole team reflects on what was good and what was bad in the last iteration. Everyone can tell what he cares - during the iteration there is not always time for it.
As a result of the retrospective, a plan of what needs to be done in the next iteration is obtained, so that everyone can get better. Usually these are non-functional tasks: for example, take a layout maker on a team, or take a picture with popcorn for Twitter.
This is how the development process under the conditions of “Extreme Ajaila ™” looks in general terms. Later we would like to introduce you to some aspects in more detail, as well as we are ready to answer your questions in the comments. So that the process of answering your questions does not turn into a flea market behind my workplace it would be great if someone shared invites with the authors of the article and the main ideologues of the Ajail in our team - Zhenya Kobzev and Semyon Molotkov (I will give you addresses in a personal).
Continued here: habrahabr.ru/blogs/agile/113419
Why extreme?
Kent Beck, during a training in Contour, told us how he invented extreme programming. By that time, several good practices were known: programming in pairs, testing code with modular tests, continuous integration, work with iterations, etc. Kent’s know-how was that he suggested using all these practices at the same time and not doing it on a case-by-case basis, but always. That is, the word “extreme” in this case comes from “extremum” and not from “extremism”.
Our situation at the beginning of the project was somewhat similar: the developers knew the practices of the Ajaila and used them, but all the other people in the team were several times more than the developers. Then the idea arose to try to extend these practices to all the people involved in the work. So our agile became “extreme” :)
But in fact, we just wanted to call the article more loudly so that everyone would immediately become interested. Well, to mention the training of Kent Beck in Contour, to increase your weight among the public.
about the project
Elba is a replacement for an accountant for small companies: it forms bills and acts, considers taxes, prepares reports, suggests when and what report to submit - well done, in one word.
The specifics of our project:
- The project does not have a specific customer who will kindly explain what he needs, and then also pay for this holiday of life. We only in a rather general way represent what we want to do, so a significant portion of the time is spent on user research.
- Reporting is not so simple: the legislation is confusing, the rules change from time to time, and even contradict each other, so another, no less significant, part of the time needs to be spent on translating regulatory documents from bird language into human.
- Our users are not familiar with accounting, and we need a very clear interface that will relieve them of the nightmares of legislation, and a good interface cannot be done with a swoop, so before starting development we need to spend another significant amount of time on designing the prototype interface and usability testing.
Total: 21 people who must achieve a common result. The practices we use for this are below.
')
All in one room
This is the easiest pattern, the benefits of it are felt immediately. At first we sat on different floors, communicated by mail and spent a lot of time on it. As soon as they moved to one room, they immediately felt the effect: they stopped writing long letters and generally began to write less. Questions are now resolved much faster, more successfully and more positively.
Planning
Why do we plan?
- Plans set the pace and motivate the team. We try to do all the tasks taken in the iteration, and this keeps us in good shape.
- As we have already written, in our case it is impossible to simply start and program: the task must be processed by different groups - analysts, interfaceologists, and psychologists. Planning synchronizes our actions.
So, on the first day of the iteration, the whole team meets at the planning board. Tasks for the current iteration are planned in detail. We also plan several next iterations, but approximately, without decomposing the problem. If to simplify greatly, then planning looks like this:
Thus, the task "pops up" to the release date.
In fact, not every task goes such a long way to development. Rather, it happens with large and complex tasks. In exceptional cases, we thrust the task directly into the iteration of the developers. For example, when the idea to make promotional codes for partners arose, everyone felt the importance of this task so much that they otrelizili it the next day. In general, in life the planning board looks a little more complicated .
After the overall planning is completed, the groups disperse at the corners and evaluate the tasks gathered in the iteration. Not everyone is doing this - only developers, interfaceologists and analysts: the activities of the other groups are poorly planned. To assess the tasks we play in the planning poker . If, after evaluation, it turns out that the tasks do not fit into the iteration, we decide what to throw away.
TK = HZ
At first, we prepared a long detailed TK (out of habit), but the developers do not like to read at all, and our developers are no exception. In addition, during the iteration there is no time for reading, especially for a pair (and the developers almost always sit in pairs), therefore the TOR was rightly renamed HZ.
How to work on HZ? Like this:
Interface prototype - the best TK
Programmers do not look at the text, but at the interface prototypes developed by the designers. Prototypes do not need to be read - it is immediately clear from them what to do, but for formulas and formats, programmers still go to the TOR.
Analyst Presentations
As soon as analysts are working on another topic (for example, reporting to the Pension Fund), they arrange a presentation for the whole team. After the presentation, everyone, at least in general terms, imagines what's what.
Do not know - ask
We are sitting side by side, so when a question arises, there is no desire to look for an answer in the TK — you simply ask the analyst. In general, we communicate a lot and feel the benefits of it (even analysts :).
Design by pieces
Both TZ and interface prototypes are not prepared entirely for the whole system: there is no time for this, and there is no point in it - even if it turns out to design a detailed interface prototype a year in advance - it will become obsolete in a month. We are preparing analytics and we are designing only what is being developed in the near future.
Daily flyers
We do not have a dedicated person who would distribute tasks to everyone, self-organization plays a big role. For it to work, it is necessary to coordinate with others - everyone should be aware of what the others are doing and are going to do. Daily volunteers solve this problem: everyone gathers at the same time every day at the iteration board.
The iteration board contains the tasks that we have planned to do in the current iteration (the task leaflets at the beginning of the iteration are glued from the planning board to this board).
We go from the top down - each group reports what has been done in a day, what it plans to do tomorrow and outweighs the tasks.
At the fly you can immediately see if someone does not do the task that someone else considers very important, or that the solution of the task is delayed.
All this takes about 20 minutes.
Demonstration
The demonstration takes place at the end of the iteration. On it, the directions show and discuss what has been done during the iteration. This is another way to spread information across all project participants.
- Developers show the system. Not always, by the end of the iteration, everything works beautifully and correctly, but there is always something to show.
- Designers show prototypes. Explain the subtleties that are not visible from the prototype. Often, developers take this prototype to the next iteration into development, so the demonstration is especially useful for them.
- Graphic designer shows banners, flyers and graphic design of new sections of the system.
- The documentaries show reference videos.
- Analysts, psychologists and promotion usually do not show anything, the results of their work are not so visual.
Retrospective
In retrospect, the whole team reflects on what was good and what was bad in the last iteration. Everyone can tell what he cares - during the iteration there is not always time for it.
As a result of the retrospective, a plan of what needs to be done in the next iteration is obtained, so that everyone can get better. Usually these are non-functional tasks: for example, take a layout maker on a team, or take a picture with popcorn for Twitter.
This is how the development process under the conditions of “Extreme Ajaila ™” looks in general terms. Later we would like to introduce you to some aspects in more detail, as well as we are ready to answer your questions in the comments. So that the process of answering your questions does not turn into a flea market behind my workplace it would be great if someone shared invites with the authors of the article and the main ideologues of the Ajail in our team - Zhenya Kobzev and Semyon Molotkov (I will give you addresses in a personal).
Continued here: habrahabr.ru/blogs/agile/113419
Source: https://habr.com/ru/post/105008/
All Articles