Agile development practices 2: planning and design (large R & D team, learning team, 139 team, mentoring system, design review, predicate statement, joint estimation, and playing card estimation)

This article is the second article in the "loose Pair programming" series. (One, two, three, four, five, six, seven, and eight, the ninth and later articles in this series can be found in the topic catalog .)

In fact, newcomers are rarely lazy, because on the one hand, they are at the peak of entry-level learning, and on the other hand, they need to be recognized by enterprises and teams for a short time. But why are they always ineffective?

The real problem for new users is that they do not have the right to do anything wrong or do something wrong with good intentions.

Unintentional mistakes include failing to learn some good methods, failing to know that the enterprise already has some available code or libraries, and failing to understand the business.

Good intentions include thinking about better functions than leaders, and over-thinking about reusability and maintainability.

I have experienced both issues (as a new person and an old man). "avoiding" is the best way, rather than making corrections afterwards, this requires advance prevention from both technical and management aspects in the design and planning phases.

--------------------------

Technology: Lightweight Design

If you want to assign a task to an "Uneasy person", there are two ways to ensure the success: the master gives the design to the apprentice, however, it is difficult to grasp the details of the "design document". When I write less, I cannot do it. When I write more, I have made a lot of content, and I am redundant, however, it takes a lot of time for the master, especially if the Apprentice "actually" (unfortunately only God knows) is fully qualified for this task.

There are two solutions.

1. Lightweight Design in advance: predicate (a metaphor)

The predicate statement is a method that Microsoft used a long time ago. Anyone (not just an apprentice) has any design and does not need to write it down because it is too time-consuming and may be discarded, let's talk about it. You will give comments and comments to ensure their correctness. Then this person implements this method. If it succeeds, it will be recognized, and you will simply write it down for future reference. Because the system already exists, the design of this simple writing can be really simple.

There are two similar practices in "loosely coupled programming.

One is that the master tells his thoughts to the apprentice (generally using a whiteboard or blank paper), and the apprentice asks the teacher to answer questions, almost until now.

On the contrary, the apprentice told the master about the question and guidance of the master.

Do not create a permanent document in advance, but write a simple document record after it is proved feasible (that is, after encoding. Text/images other than any code that can help you understand what you did at that time can be called documents with no limit on words. It would be better to put it together with a user story, a description of what is done, and a description of how to do it.

2. Front checkpoint

It is a temporary Pair programming at the beginning of something. Generally, when a function is just started, the details will be detailed in the subsequent "daily activity.

Management: Joint Plan (joint estimation, playing card estimation)

Although the pre-Statement and pre-check point are lightweight, if the master and apprentice have just understood the requirements (user stories) and cannot give a clear idea, for example, how can I quickly know whether the apprentice understands the requirements and has a general idea of implementation at the scrum program meeting? That is, joint estimation (playing card estimation is the best form of joint estimation ).

1. Joint Estimation

The principle and practice of joint estimation are still very complicated. Here we will just give a brief introduction, and I will discuss it in detail in later articles.

The common estimation is based on the same information (usually when I listen to the PO at the Planning Meeting to finish the story), how long does it take for the master and apprentice to finish the story. The basic principle is: if two people have the same idea about the construction period of a thing, their implementation methods will be different.

In order to prevent others from moving towards the cloud, the anonymous method is generally required, and the poker card estimation achieves efficient and effective co-Anonymous estimation (this article also details ).

2. Acceptance Criteria

In order to establish a Joint Estimation Based on the same goal, and to prevent the requirement from gold plating or the final software from meeting the requirement, the master and apprentice should establish a common understanding of the requirement.

The simple method is to join the estimation meeting with the two (in fact, the master and multiple apprentices) and listen to the PO to explain the story. However, it is best to establish a "documented" acceptance standard after that. For example, in a story card/Excel table ...... Write "integration required; no performance requirement ......" (See the next article on acceptance criteria under the Agile Development classification of this blog ).

The common estimation + acceptance criteria allow masters and apprentices (who are promoted as masters and beginners) to use roughly the same method and do roughly the same thing. Estimation together is both a work process and a learning process, because while understanding what to do and how to do it, the apprentice also learned something from the master.

--------------------------------------------

The description here is basically a preliminary work method. Based on the non-theorem (as long as something can go wrong, it will definitely go wrong), it is not enough to prevent it in advance, in daily work, the master still needs to work with the apprentice. The details will be described in another article.

 

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