How to overcome traditional problems in the implementation of Agile
Read the post " Problems in the implementation of Agile " habrapuser adnotum , I wanted to offer several solutions to the problems described. Since the solutions are quite universal, I decided to issue them as a separate post.
Most of the problems described appear because Scrum is a flexible framework, not a complete methodology. This is its disadvantage and advantage at the same time. Vanilla or Kosher Scrum is described briefly in the official authoritative guide from Sutherland and Schwabber. “Kosher” Scrum is when you do everything according to the rules, but it turns out not very tasty, and the process itself is not a pleasure. Such a spherical Scrum will work only on an ideal vacuum, but it can and should be adapted, which is actually good for this framework.
The product backlog is actually the main artifact in Scrum, but it does appear almost magically: “divide the requirements into small user stories, arrange them in priority” and everyone will be happy. In reality, we have two options: either according to the project it is necessary to carry out a full-fledged collection of requirements or there is a large and confusing TK document (TK = HZ).
In both cases, it is necessary to analyze the requirements, for which it is very convenient to use the following practices:
The person analysis practice came to product management from User Experience practices. It consists in describing the users of the created product as a real character with specific values ​​and goals.
And storymapping is a very convenient way to visualize the functionality for checking the completeness and validation of requirements. The visualization takes place on the board and begins with the high-level activities of the identified persons.
Activities are divided into tasks, which in turn are decomposed into subtasks.
The top layer of subtasks is the simplest possible implementation of the functional and is usually included in the first release. The subtasks below are an implementation of additional features. The lower we go down the subtasks, the less important they are.
After (and during) storimapping, you can already do a full backlog and plan releases. More details can be found at filippov in his presentation .
The problem lies in the fact that each developer knows his own part of the code and usually has a techlide who has this knowledge as deep as possible. Usually the solution is to increase cross-functionality between individual team members.
The simplest tools here can be the following engineering practices that will help spread knowledge among team members:
Again, it is worthwhile to approach this issue with a head: first of all, the cross functionality of the team, and not its individual members, is important to us.
Developers tend to deviate from the required functionality to ensure a higher quality system from their point of view. In this case, the quality criteria of developers may not coincide with those of the users or the customer.
As far as I understand the description of the problem, it is necessary to make the criteria of completeness for user stories (definition of done), in which to prescribe (prescribe, not prescribe), formal quality parameters: passing tests of acceptance and modular tests, percentage test coverage, compliance with code standards, passing a formal code inspection / writing code in a pair, etc.
')
Developer productivity is really different ... The worst thing is that it may differ not by times, but by orders of magnitude. If you briefly comment on this issue, you can offer the following solutions to the problem of organizing work and motivating stars (although I think this is not such a big problem):
Note: I do not pretend to be the ultimate truth.
Most of the problems described appear because Scrum is a flexible framework, not a complete methodology. This is its disadvantage and advantage at the same time. Vanilla or Kosher Scrum is described briefly in the official authoritative guide from Sutherland and Schwabber. “Kosher” Scrum is when you do everything according to the rules, but it turns out not very tasty, and the process itself is not a pleasure. Such a spherical Scrum will work only on an ideal vacuum, but it can and should be adapted, which is actually good for this framework.
Where does backlog come from
The product backlog is actually the main artifact in Scrum, but it does appear almost magically: “divide the requirements into small user stories, arrange them in priority” and everyone will be happy. In reality, we have two options: either according to the project it is necessary to carry out a full-fledged collection of requirements or there is a large and confusing TK document (TK = HZ).
In both cases, it is necessary to analyze the requirements, for which it is very convenient to use the following practices:
- Person Analysis ("Personas")
- Storemapping
The person analysis practice came to product management from User Experience practices. It consists in describing the users of the created product as a real character with specific values ​​and goals.
And storymapping is a very convenient way to visualize the functionality for checking the completeness and validation of requirements. The visualization takes place on the board and begins with the high-level activities of the identified persons.
Activities are divided into tasks, which in turn are decomposed into subtasks.
The top layer of subtasks is the simplest possible implementation of the functional and is usually included in the first release. The subtasks below are an implementation of additional features. The lower we go down the subtasks, the less important they are.
After (and during) storimapping, you can already do a full backlog and plan releases. More details can be found at filippov in his presentation .
How to plan for changes in legacy code
The problem lies in the fact that each developer knows his own part of the code and usually has a techlide who has this knowledge as deep as possible. Usually the solution is to increase cross-functionality between individual team members.
The simplest tools here can be the following engineering practices that will help spread knowledge among team members:
- Coding Standards
- Code sharing
- Pair Programming / Formal Code Inspections
Again, it is worthwhile to approach this issue with a head: first of all, the cross functionality of the team, and not its individual members, is important to us.
What is good"
Developers tend to deviate from the required functionality to ensure a higher quality system from their point of view. In this case, the quality criteria of developers may not coincide with those of the users or the customer.
As far as I understand the description of the problem, it is necessary to make the criteria of completeness for user stories (definition of done), in which to prescribe (prescribe, not prescribe), formal quality parameters: passing tests of acceptance and modular tests, percentage test coverage, compliance with code standards, passing a formal code inspection / writing code in a pair, etc.
')
First among equals
Developer productivity is really different ... The worst thing is that it may differ not by times, but by orders of magnitude. If you briefly comment on this issue, you can offer the following solutions to the problem of organizing work and motivating stars (although I think this is not such a big problem):
- Career advancement
- Colleagues training: from mentoring to performance at domestic events
- Attending and speaking at conferences
- Ambitious tasks (by deadlines, by scope of work, by complexity, by flexibility)
Note: I do not pretend to be the ultimate truth.
Source: https://habr.com/ru/post/134886/
All Articles