Our workflow
Our company is developing a system for managing agile projects TargetProcess . For several years of development, we tried a lot of different practices, and came to our own process, which we have been successfully following and have not been changing much for six months already.
Since every process has boundaries of application, let's start with the context.
The whole process is long and tedious to describe, so here are the most important practices.
')
Cycle
At first we used iterations, but abandoned them a year and a half ago. When a product gains a certain weight, it is much better to be able to release a release at any time when at least one new feature is ready. So everyone switched to Kanban . Now we can release any bacfiks during the day. New public builds come out about once a week.
Ratings
We do not appreciate the features and user story. Previously, we carried out planning poker and evaluated stories in abstract points, but now we try to just focus on the most important things. If the thing is the most important, the assessment is not so important, although the product owner sometimes wants to know when this new and important feature will finally be released.
Rallies .
Once we had a lot of rallies: retrospective, release planning, iteration planning, daily standup. Now only daily remains from the regular ones, all other meetings are held solely as needed to solve specific problems. For example, when starting work on features, developers, testers, and the product owner are going to discuss all the details of this feature. That is going to all who will deal with it.
Working hours
Previously, we tracked all the time spent, now we stopped doing it. People work as much as they want. There is only one rule left: you need to be at work no later than 11, at this time a daily rally is held.
Mini teams .
To solve each problem, a separate mini-team is formed. It usually consists of 3-4 people and works together from 1 to 6 months (depending on the complexity of the task). People from the mini-team sit together (so that moves from one room to another happen). This allows people to focus on one task and remove multitasking almost completely.
Pair programming .
There was a time when everyone programmed alone. There was a time when everyone programmed strictly in pairs. None of these extreme approaches has taken root. Pair programming is used at will and for solving complex problems. All workplaces have two monitors and a wide table at which it is convenient to sit together.
Version control .
We develop each feature and fix each bug in a separate brunch. For version control, Git is used. The wizard is always ready for release.
Automatic tests .
We are violently using TDD, and more recently, BDD . Regression / functional tests are less jealously automated. To do this, use the core mix of Selenium and the self-written framework on .NET. The test coverage is not bad, and to speed up their work, 12 virtual servers are used, which run the tests in parallel. And yes, the developers themselves write all the tests.
We are pleased to share other features of our process. Just ask.
By the way, in Minsk we really need 2 .NET developers , 2 javascript developers , and a cool tester.
Since every process has boundaries of application, let's start with the context.
Context
- Development of one large web application by 10-20 people;
- The product is already 6 years old;
- Used technologies: #, ASP.NET, NHibernate, ExtJS;
The whole process is long and tedious to describe, so here are the most important practices.
')
Not very technical practices
Cycle
At first we used iterations, but abandoned them a year and a half ago. When a product gains a certain weight, it is much better to be able to release a release at any time when at least one new feature is ready. So everyone switched to Kanban . Now we can release any bacfiks during the day. New public builds come out about once a week.
Ratings
We do not appreciate the features and user story. Previously, we carried out planning poker and evaluated stories in abstract points, but now we try to just focus on the most important things. If the thing is the most important, the assessment is not so important, although the product owner sometimes wants to know when this new and important feature will finally be released.
Rallies .
Once we had a lot of rallies: retrospective, release planning, iteration planning, daily standup. Now only daily remains from the regular ones, all other meetings are held solely as needed to solve specific problems. For example, when starting work on features, developers, testers, and the product owner are going to discuss all the details of this feature. That is going to all who will deal with it.
Working hours
Previously, we tracked all the time spent, now we stopped doing it. People work as much as they want. There is only one rule left: you need to be at work no later than 11, at this time a daily rally is held.
Mini teams .
To solve each problem, a separate mini-team is formed. It usually consists of 3-4 people and works together from 1 to 6 months (depending on the complexity of the task). People from the mini-team sit together (so that moves from one room to another happen). This allows people to focus on one task and remove multitasking almost completely.
Technical Practices
Pair programming .
There was a time when everyone programmed alone. There was a time when everyone programmed strictly in pairs. None of these extreme approaches has taken root. Pair programming is used at will and for solving complex problems. All workplaces have two monitors and a wide table at which it is convenient to sit together.
Version control .
We develop each feature and fix each bug in a separate brunch. For version control, Git is used. The wizard is always ready for release.
Automatic tests .
We are violently using TDD, and more recently, BDD . Regression / functional tests are less jealously automated. To do this, use the core mix of Selenium and the self-written framework on .NET. The test coverage is not bad, and to speed up their work, 12 virtual servers are used, which run the tests in parallel. And yes, the developers themselves write all the tests.
We are pleased to share other features of our process. Just ask.
By the way, in Minsk we really need 2 .NET developers , 2 javascript developers , and a cool tester.
Source: https://habr.com/ru/post/112854/
All Articles