Agile development smart agility Series 6: One ~ Summary of Chapter 5

This is the sixth article about agile development and smart agility. (One, two, three, four, five, six)

When I write too much, I find that a few of the previous articles have fallen into a chapter, that is, some common practices except for "looking at what to do". Here we will summarize them.

The so-called common practice is to prevent you from looking at it. The methods you can refer to in advance can be used as a starting point, but they may not be exactly the right one. It is more difficult to always fit, so it is not the end point.

For ease of reading, I also added it in the original article. Here I will only summarize it.

Common practices of "writing without writing documents"

Although there are many common documents, the following dimensions almost always exist. A specific document has different processing methods through analysis of several dimensions:

Documents with long-term or short-term information

Long-term effectiveness, such as competitor analysis documents, architecture design documents, requirement management documents (user stories), product roadmap ......

Long-term documents are suitable for detailed descriptions. the term should be complete (that is, the way word is written), and even graphic and modeling tools can be used.

Short-term effectiveness, such as problems found during review and the content explained by the Po at the Planning Meeting.

Short-term documents are suitable for rough descriptions. Typical examples are to use paper or word to describe key content in disorder. They do not need to be saved for a long time and are useless at the end of the month.

Documents that cannot/can be replaced by "executable software"

In the document above, competitors, architecture design, user stories, and Roadmap cannot be seen from the code, which is suitable for docalization. In addition, some scientific formulas and complex designs also fall into this column.

The interface design, database table structure design, flowcharts, and pseudo code are easy to see in the runable software once the software is ready.

If you feel that the latter is in an embarrassing situation where "no software is available, but the software is useless", you should adopt a lightweight design.

General Practice of "Write-free Architecture Design"

The three original articles have been written.

Common practices of "Every Hitachi conference"

1 ~ 4-member team

A team of this scale gives priority to the use of the 139 team structure and loose Pair programming methods, that is, the master (group leader) communicates closely with the disciples. This involves communication management, time management, over-communication, and effective productivity. It is not a problem to go into detail in the series of blogs that are linked.

Teams of this scale should not open meetings, but communicate more closely. It runs more like XP than scrum.

5 ~ 9-person team

Teams of this scale are prioritized by 2 ~ In three groups, each team is still running in a loosely paired programming method.

As there are too many people and it is difficult to communicate between groups, it is necessary to initiate a stand-up meeting. The main purpose is to communicate progress between groups, so there will be no technical communication (this is a matter in the group ), therefore, it is impossible to time out.

The group leader should be sure how to communicate and communicate with the other group.

Larger teams

For larger teams, we recommend that the group leader and the group leader participate in the super meeting, and the team members do not participate.

This type of meeting is also a progress communication meeting, so it does not involve technical communication.

Why not let the scrum masters have a meeting? Because the full-time scrum master is not responsible for the technology, progress, quality, and so on, it is really familiar with these, is the team leader and core backbone.

The latter two kinds of meetings are like "scrum of XPS", rather than "scrum of scrums". The former has stronger communication.

Common practices for "indefinite processes and templates"

Agile development process and template

Most enterprises conduct agile development training and consulting for the purpose of forming a relatively stable and unified agile development process. Therefore, the Process and template should be there. Otherwise, even the scrum master does not know what the order should be maintained.

However, when using the process and template, you should not be persistent, but flexible.

Dynamic usage principles

I don't know if you have found a rule, that is, every product will appear, rise, flourish, and decline ...... In this process, what beats them is often another emerging but simpler product. The reason is that at the early stage, due to the constant requirements of old customers, new product functions will continue to increase; new products with new functions will become more competitive, and thus become more popular; however, the product complexity has reached a certain level, and the threshold for using this product is getting higher and higher. New users are increasingly reluctant to accept this product, and the market is stolen by simple products. (For details, refer to product 6: http://blog.csdn.net/cheny_com/article/details/5872882)

The same is true for the process and template. For the old team, it is constantly improving and refining, while the threshold for the new team is rising, which eventually causes many obstacles to the promotion of the entire company.

Therefore, the organization should deploy the process and template in a hierarchical and phased manner, and the scrum master should maintain order at random.

This is highly demanding for the scrum master, because"Random Response" is not passive, that is, to push and push upon what can be promoted, but to take the initiative, that is, to find out what problems the team has, you will know what content in the process and template is used to solve this problem.