Pragmatic Development Process in “non-book” terms
Good day.
I want to share some ideas that help me in the Holy War of Chaos in the software development process. For definiteness, I will add a few details: I am a project manager, a medium-sized company (~ 40 brains) is engaged in offshore programming , a mixed team (15% seniors, 35% developers, 35 juniors, 15% trainees, and there is also a division in specialization - development quality, infrastructure).
The sources of creating chaos are more than enough - a long chain of communication with the customer, heterogeneous and in general, a young team, a “Slavic mentality” (eccentric creativity and frequent meditations;)), communication problems, political sales-people games (Sales - those who are “ sell ") etc.
')
In the chaos to work properly. It is the primary source of delays, loss of quality, inconsistency of the osprey with the customer. It is necessary to build a process or life cycle of software development. There are a lot of books about this subject, and they are by no means useless, but I unfortunately did not find a direct way to * our * case. Again, this is * my * experience. It is quite possible that some of you, my friends, succeeded in introducing, say, Scrum according to the book. I, unfortunately, failed. The more conventions the process demanded, the faster he left for the Valley of Unattached Processes.
Trial and error has led to some pragmatic approach that works (knocking on wood). The process looks like this:
This is an iterative Agile process. Requirements are presented in short user stories. The specification is in the form of Test Cases . Here we have taken a lot from Scrum. We have a Product Owner, he is usually American, his task is to communicate tightly with the customer and form a consistent idea about the project in his head, you can also add to his portrait that he was or is a programmer and is able to assess the technical side of the problem. At the beginning of the iteration meeting, we discuss the tasks that go to the iteration. As a rule, at this moment we have a list of User Stories (task names). In the future, QA engineer (quality engineer) writes short specifications for each story in the format of Test Cases.
The first iteration is architectural, during which the layers of the future system are built, and prototypes of dark places are written. All iterations starting from the second are functional. The length of the iteration is 3-4 weeks.
A Gantt chart is used to present the project evaluation plan (all iterations). It allows you to simulate the development process based on the composition of the team. The evaluation plan is used to agree on a project budget or a separate phase.
Backlog is used to monitor a single iteration.
This is how the plan of functional iteration with 2 backlogs looks like:
The first backlog traditionally contains User Stories and coordinated with the customer Change Requests (or, in general, in a simple way, features), the second - the bugs related to this iteration. The first backlog we call Sprint, as in Scrum.
And the progress of a feature or bug is obtained in an interesting way. There is one problem - programmers do not like to write reports. Also, sometimes it takes a lot of time to realize that it’s time for someone to ask a question. There is a modern approach that allows you to perfectly cope with such problems. This is a microblogging. An example of a microblog is Twitter. Imagine an online tool in which a programmer can go into his task and write a short post like: “I’m a little stuck with a task, I’ll have to change the type of connection between two entities in the model: User and Training. And in the cooler the water is over. Complete mess. Percentage completion - 47 ". Then this online tool will display the last progress value of the task entered by the programmer on the overall Gantte iteration.
Simple microposts and their frequency speak much more about the work of a programmer than a formal daily report.
As the above-mentioned online tool we use our development. However, in order not to be accused of spam, I will not indicate the link in this post. Probably I will describe it later in the blog “I am promoting”. However, to work with Gantt and microblogging, you can use another popular tool - dotProject . We have used the logging functionality under the tasks in this tool for some time.
We have long failed to pass the phases and projects on time in acceptable quality. The main problem was the "tails" of functional tasks in the form of a tedious list of bugs.
Outwardly, it looked as if the entire skip seemed to be completed, but the project cannot be given in such a quality, since a step to the right or left of the presentation path leads to exceptions that are covered or uncovered by beards.
It is also worth adding that the estimates for the tasks we initially received from the developers, so this situation was not a pressing effect.
In fact, the problem was a different understanding of the “feature made” situation among programmers and QA-players. Due to short iterations, testing was done after the integration of all unfinished features in the last week. And the nightmare was coming. It was a holiday of chaos.
How was the problem solved? We introduced a rule - the programmer did not have the right to set 100% according to his task. His last micropost should look something like this: “I did everything. Hear? EVERYTHING! Progress - 99%. Then came the micropost of the lead or the manager: “Well done! Checking Eugene. Progress - 99%. Zhenya is a QA-box. In most cases, he found 1-2 implementation bugs, 1-2 lost areas from the Test Case, 1-2 usability of the blemish and wrote the following task under the task: “there are bugs [here is their list with links to the bug tracker]. Progress - 60%. Then the task is finalized ...
These 100% - 60% = 40% is the tail of the problem. The described approach, we have learned to chop off.
Do not think that in this way we drove all the bugs into features. There are still integration errors, logical speck errors, architectural constraints and much more. These bugs fall into the second backlog, prioritized, evaluated, included, excluded from the iteration and repaired.
On this note, I finish the post, and so it turned out longer than I expected. All you can not describe. It is likely that I will try to write another 1-2 posts in this direction in close time.
Good luck.
I want to share some ideas that help me in the Holy War of Chaos in the software development process. For definiteness, I will add a few details: I am a project manager, a medium-sized company (~ 40 brains) is engaged in offshore programming , a mixed team (15% seniors, 35% developers, 35 juniors, 15% trainees, and there is also a division in specialization - development quality, infrastructure).
Process
The sources of creating chaos are more than enough - a long chain of communication with the customer, heterogeneous and in general, a young team, a “Slavic mentality” (eccentric creativity and frequent meditations;)), communication problems, political sales-people games (Sales - those who are “ sell ") etc.
')
In the chaos to work properly. It is the primary source of delays, loss of quality, inconsistency of the osprey with the customer. It is necessary to build a process or life cycle of software development. There are a lot of books about this subject, and they are by no means useless, but I unfortunately did not find a direct way to * our * case. Again, this is * my * experience. It is quite possible that some of you, my friends, succeeded in introducing, say, Scrum according to the book. I, unfortunately, failed. The more conventions the process demanded, the faster he left for the Valley of Unattached Processes.
Trial and error has led to some pragmatic approach that works (knocking on wood). The process looks like this:
This is an iterative Agile process. Requirements are presented in short user stories. The specification is in the form of Test Cases . Here we have taken a lot from Scrum. We have a Product Owner, he is usually American, his task is to communicate tightly with the customer and form a consistent idea about the project in his head, you can also add to his portrait that he was or is a programmer and is able to assess the technical side of the problem. At the beginning of the iteration meeting, we discuss the tasks that go to the iteration. As a rule, at this moment we have a list of User Stories (task names). In the future, QA engineer (quality engineer) writes short specifications for each story in the format of Test Cases.
The first iteration is architectural, during which the layers of the future system are built, and prototypes of dark places are written. All iterations starting from the second are functional. The length of the iteration is 3-4 weeks.
A Gantt chart is used to present the project evaluation plan (all iterations). It allows you to simulate the development process based on the composition of the team. The evaluation plan is used to agree on a project budget or a separate phase.
Backlog is used to monitor a single iteration.
This is how the plan of functional iteration with 2 backlogs looks like:
The first backlog traditionally contains User Stories and coordinated with the customer Change Requests (or, in general, in a simple way, features), the second - the bugs related to this iteration. The first backlog we call Sprint, as in Scrum.
And the progress of a feature or bug is obtained in an interesting way. There is one problem - programmers do not like to write reports. Also, sometimes it takes a lot of time to realize that it’s time for someone to ask a question. There is a modern approach that allows you to perfectly cope with such problems. This is a microblogging. An example of a microblog is Twitter. Imagine an online tool in which a programmer can go into his task and write a short post like: “I’m a little stuck with a task, I’ll have to change the type of connection between two entities in the model: User and Training. And in the cooler the water is over. Complete mess. Percentage completion - 47 ". Then this online tool will display the last progress value of the task entered by the programmer on the overall Gantte iteration.
Simple microposts and their frequency speak much more about the work of a programmer than a formal daily report.
As the above-mentioned online tool we use our development. However, in order not to be accused of spam, I will not indicate the link in this post. Probably I will describe it later in the blog “I am promoting”. However, to work with Gantt and microblogging, you can use another popular tool - dotProject . We have used the logging functionality under the tasks in this tool for some time.
We chop off tails to tasks or where the feature ends.
We have long failed to pass the phases and projects on time in acceptable quality. The main problem was the "tails" of functional tasks in the form of a tedious list of bugs.
Outwardly, it looked as if the entire skip seemed to be completed, but the project cannot be given in such a quality, since a step to the right or left of the presentation path leads to exceptions that are covered or uncovered by beards.
It is also worth adding that the estimates for the tasks we initially received from the developers, so this situation was not a pressing effect.
In fact, the problem was a different understanding of the “feature made” situation among programmers and QA-players. Due to short iterations, testing was done after the integration of all unfinished features in the last week. And the nightmare was coming. It was a holiday of chaos.
How was the problem solved? We introduced a rule - the programmer did not have the right to set 100% according to his task. His last micropost should look something like this: “I did everything. Hear? EVERYTHING! Progress - 99%. Then came the micropost of the lead or the manager: “Well done! Checking Eugene. Progress - 99%. Zhenya is a QA-box. In most cases, he found 1-2 implementation bugs, 1-2 lost areas from the Test Case, 1-2 usability of the blemish and wrote the following task under the task: “there are bugs [here is their list with links to the bug tracker]. Progress - 60%. Then the task is finalized ...
These 100% - 60% = 40% is the tail of the problem. The described approach, we have learned to chop off.
Do not think that in this way we drove all the bugs into features. There are still integration errors, logical speck errors, architectural constraints and much more. These bugs fall into the second backlog, prioritized, evaluated, included, excluded from the iteration and repaired.
On this note, I finish the post, and so it turned out longer than I expected. All you can not describe. It is likely that I will try to write another 1-2 posts in this direction in close time.
Good luck.
Source: https://habr.com/ru/post/81077/
All Articles