Successful Kanban in a small team
After reviewing the posts in which habra users describe the processes of implementation and implementation of flexible methodologies in production, I decided to share my own development experience using the Kanban methodology in a small product team.
By the time when we had a desire to try a new process organization system, we were a worked-out team leading a successful Scrum development.
I will not load the post theory and all kinds of water, on Habré enough articles about Kanban and lean production. I proceed immediately to the description of the process.
Implementing Kanban, we sought to improve the development process to the maximum and achieve a complete absence of defects in the manufactured product. Therefore, we began to introduce the methodology with an analysis of the current process, which at that time was built on Scrum. The analysis consisted in the compilation of a map of values ​​- a graph which depicted all the stages of the production process. Considering each step of the process, we excluded those steps that delayed us or caused discomfort among the participants in the production. I note that we constantly returned to the process analysis.
')
The result of the analysis was a map of our future process. Each of the stages of the process has its own column on the Kanban board, and each stage (except Pull) has two columns: In Progress and Done.
For each stage, a list of readiness criteria is defined. If at least one of the criteria does not match the feature, it cannot go to the next column.
I will dwell in detail on each of the stages.
A pull is a buffer into which the Product Owner (PO) adds new tasks from the backlog. The buffer has a limit on the number of tasks. Tasks on the board are placed in order of priority. PO at any time can change the priority of a task or replace a task at all with another one.
When a completely free developer appears in the development process, he takes the highest priority task from pull and translates the task into status analysis.
Usually, a developer who takes a feature into development becomes responsible for it. Responsible at all stages of development monitors the state of the feature, the PO can at any moment find out the current status of the feature.
At the analysis stage, a group consisting of the tester (s) and the developer (s) is assembled. They use various methods to pull out the details of the task from the PO, since the descriptions in the backlog are often not enough. In the course of such a discussion, PO often changes some features of the feature, and in some cases refuses it. During the analysis, test cases are also written out, i.e. all sorts of user behavior and the corresponding system response. All information received is recorded in the specification. If the feature assumed the creation of interfaces, then interface prototypes (sketches) are drawn, which will then allow you to draw up a subtask for the developer of interfaces.
Due to the analysis phase, the functionality exactly corresponded to the wishes of the customer and we did not spend time on rework.
After completion of the analysis, the development team begins designing the technical implementation of the task. The result of this design is the technical specifications of the architecture (class diagrams, sequence diagrams, etc.). Developers quite often hold presentations of architecture for the whole team in order to listen to criticism or make sure that the proposed solution is perfect.
Having dealt with the technical details, you can break the task into smaller subtasks (if that makes sense).
Thanks to a thoughtful and detailed design, the code began to come out with virtually no bugs.
So, the feature is fully ready for immediate implementation. Free developers sort out the tasks and outweigh their development column. Each feature is developed in a separate branch of the main repository. When coding almost all tasks, we use TDD and pair programming. Each developer conducts functional and integration testing. Much has been written about the advantages of these practices and it’s not worth focusing on them.
Having finished with the code, interfaces, database migration files and everything that includes the task, we put it on review.
Any free developer, and sometimes the entire development team, conducts review tasks. We pay considerable attention to this stage. In addition to a quick scan of the code for compliance with the code convention, the reviewer checks the functionality of the implemented feature and analyzes the written unit tests.
This stage allows to avoid minor inaccuracies in the code and allows the whole team to get acquainted with the various components of the developed system.
The last review task is queued for testing. The released tester takes the feature into circulation. It is driven through all circles of the tester hell, subjecting it to functional, load, regression testing. Testing is conducted strictly in the feature line.
After the testing process is completed, the feature is deposited on the demo server - the merge code occurs and the necessary migrations roll in. On demo server PO can view the results of work.
Successfully delayed feature is subjected to verification - integration and regression testing is carried out.
Having dealt with all stages of the production process, let's talk about the limitations. What are they needed for? And in order to focus all attention on the quality of the product. If the developers start to rivet uncontrollably features in batches, then the testing department simply will not have time to test all features by the deadline. To avoid such situations in a practical way, we select restrictions on a column or on groups of columns. Now, for example, when we have too many tasks in our review, the developer will not be able to take new features into development until we have reviewed the ready-made features. Thus, we deprive the inaccurate, hasty developers of the temptation to create code with defects.
In the process of describing the production process, I mentioned only the successful outcomes of each stage. So how exactly is this outcome necessary to strive for. However, in the course of the formation of an ideal production process, products with defects are emerging. We are forced to return the task a step (or more) back. For example, if a task has not been reviewed and tested, it returns to development and sometimes to design (this must be taken into account when placing constraints). If a similar return has occurred, this is a signal that a defect (loss) has arisen in the process and it is necessary to stop the process and analyze this defect. In practice, we rarely stopped, more often the loss is recorded in the log of returns. When enough weighty defects accumulate in the journal, we collect a rally at which the analysis of defects takes place. According to the results of the analysis, measures are taken to help avoid the repetition of the defect in the production process.
Of course, it did not immediately go smoothly and beautifully. But the continuous improvement process yielded results. After half a year, we were able to significantly speed up the development process (burndown graphics indicated an acceleration of 2.1 times), and also greatly improve the quality of the product. Testers admitted that finding bugs has become more difficult, and the situations “fixed here - broke there” disappeared altogether.
Processes
Kanban (development)
Kanban Applied Software Development: from Agile to Lean
Lean Software Engineering
Instruments
Kanban Boards Review
By the time when we had a desire to try a new process organization system, we were a worked-out team leading a successful Scrum development.
I will not load the post theory and all kinds of water, on Habré enough articles about Kanban and lean production. I proceed immediately to the description of the process.
Implementing Kanban, we sought to improve the development process to the maximum and achieve a complete absence of defects in the manufactured product. Therefore, we began to introduce the methodology with an analysis of the current process, which at that time was built on Scrum. The analysis consisted in the compilation of a map of values ​​- a graph which depicted all the stages of the production process. Considering each step of the process, we excluded those steps that delayed us or caused discomfort among the participants in the production. I note that we constantly returned to the process analysis.
')
The result of the analysis was a map of our future process. Each of the stages of the process has its own column on the Kanban board, and each stage (except Pull) has two columns: In Progress and Done.
For each stage, a list of readiness criteria is defined. If at least one of the criteria does not match the feature, it cannot go to the next column.
I will dwell in detail on each of the stages.
Pull
A pull is a buffer into which the Product Owner (PO) adds new tasks from the backlog. The buffer has a limit on the number of tasks. Tasks on the board are placed in order of priority. PO at any time can change the priority of a task or replace a task at all with another one.
Analysis
When a completely free developer appears in the development process, he takes the highest priority task from pull and translates the task into status analysis.
Usually, a developer who takes a feature into development becomes responsible for it. Responsible at all stages of development monitors the state of the feature, the PO can at any moment find out the current status of the feature.
At the analysis stage, a group consisting of the tester (s) and the developer (s) is assembled. They use various methods to pull out the details of the task from the PO, since the descriptions in the backlog are often not enough. In the course of such a discussion, PO often changes some features of the feature, and in some cases refuses it. During the analysis, test cases are also written out, i.e. all sorts of user behavior and the corresponding system response. All information received is recorded in the specification. If the feature assumed the creation of interfaces, then interface prototypes (sketches) are drawn, which will then allow you to draw up a subtask for the developer of interfaces.
Due to the analysis phase, the functionality exactly corresponded to the wishes of the customer and we did not spend time on rework.
Design
After completion of the analysis, the development team begins designing the technical implementation of the task. The result of this design is the technical specifications of the architecture (class diagrams, sequence diagrams, etc.). Developers quite often hold presentations of architecture for the whole team in order to listen to criticism or make sure that the proposed solution is perfect.
Having dealt with the technical details, you can break the task into smaller subtasks (if that makes sense).
Thanks to a thoughtful and detailed design, the code began to come out with virtually no bugs.
Development
So, the feature is fully ready for immediate implementation. Free developers sort out the tasks and outweigh their development column. Each feature is developed in a separate branch of the main repository. When coding almost all tasks, we use TDD and pair programming. Each developer conducts functional and integration testing. Much has been written about the advantages of these practices and it’s not worth focusing on them.
Having finished with the code, interfaces, database migration files and everything that includes the task, we put it on review.
Review
Any free developer, and sometimes the entire development team, conducts review tasks. We pay considerable attention to this stage. In addition to a quick scan of the code for compliance with the code convention, the reviewer checks the functionality of the implemented feature and analyzes the written unit tests.
This stage allows to avoid minor inaccuracies in the code and allows the whole team to get acquainted with the various components of the developed system.
Testing
The last review task is queued for testing. The released tester takes the feature into circulation. It is driven through all circles of the tester hell, subjecting it to functional, load, regression testing. Testing is conducted strictly in the feature line.
Deploy
After the testing process is completed, the feature is deposited on the demo server - the merge code occurs and the necessary migrations roll in. On demo server PO can view the results of work.
Verification
Successfully delayed feature is subjected to verification - integration and regression testing is carried out.
Restrictions
Having dealt with all stages of the production process, let's talk about the limitations. What are they needed for? And in order to focus all attention on the quality of the product. If the developers start to rivet uncontrollably features in batches, then the testing department simply will not have time to test all features by the deadline. To avoid such situations in a practical way, we select restrictions on a column or on groups of columns. Now, for example, when we have too many tasks in our review, the developer will not be able to take new features into development until we have reviewed the ready-made features. Thus, we deprive the inaccurate, hasty developers of the temptation to create code with defects.
Returns
In the process of describing the production process, I mentioned only the successful outcomes of each stage. So how exactly is this outcome necessary to strive for. However, in the course of the formation of an ideal production process, products with defects are emerging. We are forced to return the task a step (or more) back. For example, if a task has not been reviewed and tested, it returns to development and sometimes to design (this must be taken into account when placing constraints). If a similar return has occurred, this is a signal that a defect (loss) has arisen in the process and it is necessary to stop the process and analyze this defect. In practice, we rarely stopped, more often the loss is recorded in the log of returns. When enough weighty defects accumulate in the journal, we collect a rally at which the analysis of defects takes place. According to the results of the analysis, measures are taken to help avoid the repetition of the defect in the production process.
Result
Of course, it did not immediately go smoothly and beautifully. But the continuous improvement process yielded results. After half a year, we were able to significantly speed up the development process (burndown graphics indicated an acceleration of 2.1 times), and also greatly improve the quality of the product. Testers admitted that finding bugs has become more difficult, and the situations “fixed here - broke there” disappeared altogether.
Utility
Processes
Kanban (development)
Kanban Applied Software Development: from Agile to Lean
Lean Software Engineering
Instruments
Kanban Boards Review
Source: https://habr.com/ru/post/135037/
All Articles