A living example of applying a flexible approach to software development in a Russian startup

Hi, habradrug. Do you think that waterfall ( cascade ) in software development is the only racially correct approach? Yes or no - rush under the cat.

For example, we use scrum with technical practices of eXteme Programming inside to develop our own SmartNut web service. How else would we be able to deliver business value to customers every 2 weeks (release cycle). I think that we can be attributed to the guys doing Lean Startup.



Scrum c XP was used in my last team, but here we develop the topic more productively.

I will try to briefly tell you the basic scrum and XP techniques that we have managed to implement, support, change and improve to increase efficiency.

0. Our team

Product owner (PO), team, scrum master, all as in the book. PO is the product owner responsible for the history and prioritization of tasks. Our team that implements PO requirements includes developers and testers. Scrum master is a member of the team and in addition to the functions of the scum master, it is also the product developer.

')

1. Iterations

Until recently, the iterations were weekly, and we updated the application once every two weeks.

There was a feeling that the main motivation for the task was exactly releases, not iteration. Therefore, often the tasks went from iteration to iteration, if it did not interfere with the release of the release.

Now we have tied the iterations to the release cycle in order to experience how comfortable it is, whether we can reduce the overhead, and whether more long tasks can fit into a two-week iteration.



How flexible are we at each stage of the project?

2. Planning

We have a product vision, based on it, plans for release are periodically created. Release is a set of functions that can be implemented for some finite time, and having the highest priority for delivery to customers at the moment.

Planning such releases allows you to see the "general line" of the development of our product. Not all the tasks from this release will be implemented, the main thing is this direction.



Microreleases are released every 2 weeks.

The product owner writes stories to the beginning of the iteration. In order for them to be smooth and silky, PO must devote a certain amount of time to discussing stories with the team in the previous iteration, which he does. Some productions are accepted, some are modified, and some are postponed until there is a real need to perform them.

For example, there are two tasks: the first adds new functionality, and the second develops it or improves usability.

If we doubt that the first task will “shoot”, i.e. will bring some tangible benefits to our customers, then we can postpone the second task - until we collect statistics and receive feedback.

2.5 Evaluation

We were convinced by our own experience and we know that the individual assessment in days and hours is very inaccurate. Therefore, we rate points and scores using Planning Poker to ensure independence of ratings. This, by the way, is also fun!

From interesting: earlier we always tried to come to a uniform assessment. But Jeff Sutherland (pictured) offers a solution with the arithmetic mean calculation if all the players have thrown away the cards that go in a row in the Fibonacci series.

3. Working conditions

For our team a separate large and bright room is allocated. Nothing prevents us from discussing tasks, holding meetings, looking for and eliminating obstacles. Every morning at 11-30 we hold a stand-up rally, which lasts 15 minutes in the best traditions. We consider speed and try to keep it growing all the time, not counting growth as an end in itself.

Sitting next to a programming colleague is not considered a crime. Assistance in solving infrastructure problems and problems with the environment is considered an honorable job.

4. System design

The most difficult thing is to conduct development in such a way that the system is simple and understandable both for the end user and for all the programmers of the team. If the feature is not obvious, if 2 people from the corridor cannot sit down at a computer, get to the bottom of what the PO or the developers intended, then something needs to be changed. We, as a team, move in the direction of simplicity, it does not always work, but we try.

The same applies to the functions, the needs for which the market has not yet shown. I really want to add them, it seems that this is just and necessary, but who will use them?

5. Under development

If you have questions about the productions, then the Product owner sitting in our office can answer all of them.

We have standards for writing code, which allows us to look at someone else's code as if it were our own without unnecessary emotions.

TDD we do not use. Tests are written after writing the code, as well as the errors found.

We use Jenkins for the Continuous integration process. If Jenkins receives a signal that the code in svn has been updated, then the project automatically builds. Run tests, run a static code analyzer. Negative results, if they have a place to be, are notified to people whose changes fell into the assembly.

Due to the lack of pair programming explicitly, we are conducting a code review procedure. Conducting CR is a criterion for task readiness

Everyone has the right to make changes to all parts of the system, which increases responsibility and reduces the likelihood of missing defects.

In addition to unit tests, we also have acceptance tests for the main functions of the system, which also pass after updating the code in the repository.



Another criterion for the readiness of a task is testing and checking for compliance with the formulation before the commit. When the developer believes that the task is ready, he gives it for testing. The tester checks the task and only after he is satisfied with the quality and completeness, the task can be considered completed. This saves time on switching between tasks and uploading the code to the repository already in a tested form.

This procedure does not exclude acceptance testing before rolling out the release by the tester and the product owner after completing each story, which may consist of several tasks.



In order to achieve maximum productivity, the development team should use the maximum number of XP practices to which we aspire. But we should not forget about the full set of practices of the Scrum command framework.

Scrum says that one of the tasks of a scrum master is to figure out and eliminate obstacles. Until recently, we had little thought about a radical improvement in the process. Although in the scrum techniques, there is a special rally - a retrospective on which to look back, look for obstacles and reinforce the good practices used. Now we carry out a retrospective of each iteration and use sheets A3 (and three) to identify bottlenecks in the process.



In addition, at the end of each iteration we conduct a demo, boast to others, colleagues from other departments, what we did for the iteration. We get a bunch of useful and not very suggestions, as well as, sometimes, we find previously unnoticed bugs.



In general, with each iteration we get feedback from our customers, and we can safely say that with the help of SmartNut we make the world around a little bit better. Every two weeks.



If your goal is to be on the crest of a wave and enjoy only real waterfalls, deliver updates to the client as often as possible. And this will help you scrum and xp.





PS If you, Habradrug, still think that what we do ideologically incorrectly, or vice versa, you want to praise, then welcome to the comments.