Pragmatic Non-Book Development Process

    Good day.

    I want to share some ideas that help me in the Holy War with Chaos in the software development process. For definiteness pictures add a few details: I - project manager, the firm is medium in size (~ 40 brains) engaged in offshore programming , mixed team (15% of seniors, 35% of developers, 35 Junior, 15% of the trainees, and there is division on specialization - development , quality, infrastructure).

    Process


    The sources of chaos are more than enough - a long chain of communication with the customer, a heterogeneous and generally young team, a “Slavic mentality” (eccentric creativity and frequent meditation;)), communication problems, political games of sales people (Sales are those who are us “ sell "), etc.

    In chaos, working incorrectly. It is the primary source of delays, quality losses, inconsistency of ospreys with the customer. You need to build a Process or Life Cycle for software development. There are a lot of books about this subject, and they are by no means useless, but unfortunately I did not find a direct exit to * our * case. I repeat, this is * my * experience. It is possible that some of you, my friends, have managed to introduce, say, Scrum from the book. Unfortunately, I did not succeed. The more conventions a process required, the faster it would go into the valley of the Unprotected Processes.

    The trial and error method has led to some pragmatic approach that works (knock on wood). The process looks like this:

    This is an iterative Agile process. Requirements are presented as short User Stories . Specification - in the form of Test Cases. Here we took a lot from Scrum. We have a Product Owner, he is usually an American, his task is to communicate closely with the customer and form a consistent idea of ​​the project in his head, you can 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, we rally, discuss the tasks that go to the iteration. Typically, at this point we have a list of User Stories (task names). Subsequently, the QA engineer (quality engineer) writes short specifications for each story in the Test Cases format.

    The first iteration is architectural, during which layers of the future system are built, prototypes of dark places are written. All iterations starting from the second are functional. The iteration length is 3-4 weeks.

    A Gantt chart is used to represent 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 coordinate the project budget or its individual phase.

    For monitoring a single iteration used beklogi ( backlog ).

    This is how the functional iteration plan looks like with 2 backlogs:

    image

    The first backlog traditionally contains User Stories and Change Requests agreed upon with the customer (or, in general, in a simple way, features), the second - bugs related to this iteration. The first backlog we call Sprint, as in Scrum.

    Moreover, 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 understand that it is time for someone to ask a question. There is a modern approach that allows you to perfectly cope with such problems. This is a microblog. 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 bit 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 ran out. Full mess. Percentage of completion - 47. " Further this online tool will display the last value of the task progress introduced by the programmer on the general iteration gantt.

    Simple microposts and their frequency speak much more about the work of a programmer than a formal daily report.

    As the mentioned online tool, we use our own development. However, in order not to be accused of spam, I will not indicate a link in this post. I guess I will describe it later on the blog "I am PR." However, you can use another popular tool, dotProject , to work with Gantt and the microblog . We used logging functionality under tasks in this tool for some time.

    We chop off tails to tasks or where the feature ends.


    For a long time, we were unable to hand over 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 like the entire osprey was completed, but you cannot give the project as such, since a step to the right or left of the presentation path leads to covered or naked exceptions beards.

    It is also worth adding that the estimates for the tasks we initially received from the developers, so this situation was not an effect of pressure.

    In fact, the problem was a different understanding of the “feature made” situation among programmers and QA-schiki. Due to short iterations, testing was carried out 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% for his task. His last micro-post should have looked something like this: “I did everything. Do you hear? ALL! Progress is 99%. ” Next came the micropost lead or manager: “well done! Checks Zhenya. Progress is 99%. ” Zhenya is a QA-box. In most cases, he found 1-2 implementation bugs, 1-2 lost sites from the Test Case, 1-2 usability of the flaw, and wrote the following post under the task: “there are bugs [there is a list of them with links to the bug tracker]. Progress is 60%. ” Next is the completion of the task ...

    These 100% - 60% = 40% is the tail of the task. With the described approach, we learned to chop it off.

    Do not think that in this way we drove all the bugs into features. There are still integration errors, logical errors in specs, architectural restrictions, and much more. These bugs fall into the second backlog, are prioritized, evaluated, enabled, excluded from iteration, and repaired.

    On this note, I finish the post, and so it turned out longer than I expected. You can’t describe everything. It is likely that I will try to write another 1-2 posts in this direction in the near future.

    Good luck.

    Also popular now: