"No change during iteration" and Research and development psychology (commitment Management, Moscow method) _ Agile development

Author: Chen

Source: blog.csdn.net/cheny_com

There are no changes during the iteration. Support Faction said: Yes, if often change, how do we develop AH.

The opposition said: No, agile development can not come up to confirm the demand, to be in the development of gradually understand the needs, how may not change it.

Only at the development level, there is no solution to this problem. Let's stand at the height of research and development psychology to see this problem.

Let's see what adverse psychological changes the team will have if changed.

1. Let's not start with the commitment to do it, once the change commitment is lost

2. Since it's always changing, every time we set aside a few estimates.

3. Don't worry, you can not finish the work, to the last day you will change

4 .....

Looking at product Owner, the change initiator has also changed:

1. In the future, I will not attend the plan, so that they can choose some important needs to do first

2. In the future can change, this plan will be the first to do these several needs, do half I see what to cut off

3 .....

These changes make us inclined to not make changes during the iteration.

But if it must be changed.

In the product version planning (see "No change during the iteration" and product version planning) We should outline the product roadmap and the content to be developed for each version, and if this is done, the actual changes that we might actually take are:

1. This function was originally due to technical dependence, the need for early development

2. This function is not like this

3. A better alternative function was found

4 .....

Developers are more receptive to 1 of such technical issues, and they even offer to do so.

For 2, 3 of these problems, it is the value of the product itself has increased, is the common pursuit (if the development team is still trapped in the "completion of the Sprint backlog function" rather than "delivery of customer value" is too primitive), At this time should be cut off some of the functions to achieve the implementation of the change and commitment to achieve a win.

There are several key points to this operation:

1. Even in an iterative backlog, there should be priority, the most common is the MOSCOV classification:

Must: This iteration must be done

Should: What this iteration is supposed to do

Could: This iteration can be done (is the last to do, so ready to cut off)

Would not: This iteration does not do (just do a cautionary show to prevent someone from gilded)

2. A vision for each iteration

such as "This iteration we want to make a quick and easy display of electronic program set-top box software."

One vision is to allow developers to embrace change psychologically by placing their eyes on the backlog tasks of value rather than the image.

Download the Free Agile Development textbook: "The Martian Agile Development Handbook"