The practice of Scrum&kanban in mobile development team (i)

Now most teams are talking about agile development, and it seems that agile is a silver bullet for software development. Just need to practice some of the agile development model can be how, in fact, I think whether it is agile development or the traditional waterfall flow development has their market, depending on the composition of the team, depends on the attributes of your products, the market competition environment. The ultimate goal is to achieve the desired requirements in the quickest way and at the highest quality.

My recent two teams are mobile research and development teams, one for enterprise-class software in relatively large foreign companies, and one for entrepreneurial teams for consumer-grade applications. The first team evolved from the traditional waterfall flow development model to scrum, and the second team I dominated the entire research and development team, combining scrum and Kanban, with a hybrid development model.

Scrum practices

The basic concept of scrum I will not go into the details, I hope to quickly understand the person can step to this.

Let me talk about how we operate:

1. Team Role Assignment: product, research and development, program Manager. The product provides the business requirement description, Mockui. Research and development includes scrum Master, Developer, QA, and software development testing. Program Manager is responsible for the progress control of the whole project and the communication and coordination of the external team.

2. Tools used: VersionOne for the entire Scrum development project management, later we replaced Jira Agile, mainly because we also use Jira to do bug track, decentralized in different systems management is also quite complex. Code management GitHub, document management confluence, test case Testlink.

3. Process:

We have one months as a release cycle, 15th per month to 15th next month, the release of the general in the next month, 15th, the Friday. One months are divided into 3 dev sprints and 1 release sprints.

Release planning Stage

Release Kickoff Meeting: At the beginning of the cycle, the product team is responsible for explaining the functions of a release to be done in the future. Usually the product team is maintaining epic and breaking it down into a backlog (specific needs) and prioritizing the backlog.

Engineer Backlog Discuss meeting: When you get the backlog, the research and development team needs to analyze the backlog, understand the requirements, and be able to break down into tasks and estimate the workload of each task. There are two ways to estimate the workload, the traditional one, or the poker Points.

People's way is easier to operate, familiar with the better understanding, but this way is no way to measure a team's productivity change situation. For a fixed number of teams, the number of days that can be produced within a fixed time is fixed.

Poker Point's approach is to select a task as a benchmark, such as 1 points, and then evaluate the other tasks with the reference to always give the corresponding score. This time actually need to pay attention to avoid yiyantang, so most of the time is through the way of playing cards to achieve the whole team of the same, you can pass more rounds of cards, it must be the entire team to agree on this score. The evaluation method using point is relatively difficult to operate, but the benefits are obvious, and the number of each release point gives a very clear understanding of the changes in team productivity.

This phase usually takes 1-2 days to complete, and a good planning is critical to the success of the entire release! Well begun to think that the success of half!

At the end of plan we will fill in all the data in the Versionone/jira Agile system:

Epic	Backlog	Task	Effort	Developer
EP1	Feature1	Taska	1	Membera
		Taskb	3	Memberb
	Feature2	Taskc	8	Membera
Ep	Feature3	Taskd	5	Memberb
	Feature4	Taske	3	Membera

Development Sprint

Daily Scrum meeting: Many teams use this, daily Scrum stand-up meetings, usually each member introduces himself to yesterday's work, today's plan and what problems it encounters. This meeting must emphasize efficiency, resolved within 15 minutes, so the team of more than 10 people suggested splitting the meeting separately. The Scrum master needs to play a timed job at this meeting, to ensure that the rhythm of the meeting is controlled, and if complex issues are to be discussed later, don't get bogged down in endless discussions.

Everyone must keep track of the tasks they do, how much they have done, and how much remains. This can produce a very useful diagram, Burndown chart. This chart makes it easy to see where the project is progressing.

Throughout the Dev Sprint, the Test team worked closely with the development team, and the test should be involved at the very beginning of the entire development cycle, discussing requirements, evaluating together, writing test cases, testing for new functionality, and iterative testing. Ideally, during the 3-week development cycle, development and testing have been synchronized, development completed within 3 weeks, and new functional testing is almost complete.

Release Sprint

This phase is designed to stabilize product quality and prepare for release. We use standard git flow to manage the code base.

At the beginning of the release sprint, we will checkout out the release branch from the develop branch. The release branch only accepts a commit of the bug fix, the develop branch can still submit new functionality, but the new feature submitted is not released until the next release cycle.

Published standards:

1. No high-priority issues

2. No regression problem is that the previous version is good and the new version causes

When publishing, the code for the release branch is simultaneously merge to the develop and master branches and labeled on the Master branch.

At the end of each release, retrospective meeting is also required, and we can summarize and make continuous improvements.

Scrum is a relatively well-developed project development model, and various tools are also well-established. I think there are several points to note:

1. Fixed release cycle: This can lead to a good development iteration periodicity, but also easy to evaluate the efficiency of each cycle.

2. Product team and research and development team time is not the same, the general product team to work 1-2 weeks in advance, to ensure that the research and development team will not be due to the uncertainty of the need to affect efficiency.

3. Avoid changes in requirements, regardless of the development model, changes in requirements are always unavoidable, so it is best to shorten the cycle so that the product team can tolerate the need to delay time to achieve these changes.

4. To reserve a certain buffer, after all, the programmer is also a person, there will be no caller time, also need to learn to share knowledge, so do not fill the time completely, leaving everyone time to adjust.

The practice of Scrum&kanban in mobile development team (i)