Agile development routine follow-up Series 6: Development and follow-up

This is the sixth article in the daily follow-up series of agile development. (Topic directory)

The product owner is often described as preparing a user story before the plan, explaining the story at the plan meeting and helping the development team estimate that everything will be fine, just waiting until the end of the month to receive "work software, in fact, if this is the case, problems are very likely to occur.

Demand refinement

This is a regular activity that occurs in the middle of the iteration cycle, and the product owner will be in close contact with the Team (specifically, if they can often sit together better) on the Eve or in the middle of every story development, describe the previous user stories in more detail (sometimes it is done after seeing half of the half-finished products under development ).

It is generally considered that it is undesirable for the product owner to disturb the development team during development. What is the difference between the two?

The agile development product management series, which will be compiled in the future, will mention that product owners must perform long-term R & D management to achieve "no change during iteration, it is to set the target for each iteration of each version in advance. Therefore, when we implement specific iterations, this goal is not so easy to change, but"How to achieve this goal better", It may change frequently.

The process of demand refinement is the process in which the product owner helps the team to better achieve the goal.

"What are the activities of demand refinement ?" To be exact, everything can happen if the product owner and team are put together.

Fuzzy requirements may be refined. some adjustments may be made based on semi-finished products. The background may be explained to developers ...... All in all, just try it.

There is even a fixed period of time in the iterative development of NEC (forgetting whether it is the 10th or 20th days of the month). The product owner will help the entire group to make an advance announcement of the story of the next iteration, to help the team predict what will happen in the future, so as to slightly prepare for the future. This kind of preparation involves both understanding the business aspect in advance and potential to make some limited preparations for expansion in the architecture.

Follow-up person, gradual review

If the development team has a large number of developers and only one product owner, his work will be quite busy and he will lose his mind.

The follow-up personnel system is established on the basis of the product owner team. The product owner team is a team composed of multiple people who know the product and collectively exercise the responsibility of the product owner, typical scenarios include product directors in software or embedded product R & D-product managers-product specialists, game team master planning-planning leader-planning team.

But the follow-up person isSpecify a team member of the corresponding product owner team for a user story to track the development progress of the story.

The biggest benefit of a person to follow up is that the user's story can be reviewed and improved as soon as the user story is completed.To prevent the end from discovering poor implementation of the story. One is a waste of time for rework, And the other affects the launch date (only the next iteration can be modified ).

The follow-up personnel system and progressive review are very common in the agile development of online games because online game planners are more likely to follow up and are sensitive to "Influencing online.

I personally feel that the follow-up personnel system and progressive review should also be promoted in general R & D. In any case, if the user story cannot be delivered because it is "only a little short and needs improvement", it should be extended to the next iteration, it is indeed frustrating.

Storyboard arrangement skills

The general concept of the story board is not much said. There are just a few topics: to be developed, to be developed, to be tested, to be tested, to be released, and so on.

One trick is that the column "under development" must be narrow, meaningDo not develop multiple stories at the same time. It is best to end with a few more stories.. The purpose is not to end all the stories, which leads to the final failure of delivery.

This also makes the follow-up personnel not too busy with multiple stories. They can be introduced one by one and reviewed one by one.

 

Click to download the free agile development textbook: Martian agile development manual