Shulou(Shulou.com)06/03 Report--

This article is the second in a series of "loose knot programming".

In fact, newcomers seldom slack off, because on the one hand, they are in the peak period of entry learning, on the other hand, they do not work long hours and need to be recognized by enterprises and teams. But why don't they always work well?

The real problem for newcomers is that they do wrong things unintentionally and well-intentionally.

Inadvertently doing something wrong includes not learning a good method, not knowing that the enterprise already has some available code or libraries, not knowing the business, and so on.

Doing wrong things with good intentions includes wanting to do a better function than the leader thinks, thinking too much about reusability maintainability and so on.

The author has experienced both of these problems (as a newcomer and the elderly), "avoiding" is the best way, rather than correcting it afterwards, which needs to be prevented in advance from both technical and management aspects in the design stage and the planning stage.

-

Technology: lightweight design

If you want to assign a task to a "worried person", there are two ways to ensure success: the master gives the design to the apprentice, but it is difficult to grasp the level of detail of the "design document". If you write too much, you can't do it. If you write too much, a lot of content will be superfluous. The master and apprentice program in pairs, but it takes up the master's time, especially if the apprentice is "actually" (unfortunately only God knows) can do the task.

There are two solutions.

1. Lightweight design in advance: envisioned statement (somewhat metaphorical)

Envisioned statement is a method used by Microsoft a long time ago. Anyone (not just an apprentice) has a design that does not have to be written down because it is too time-consuming and may be abandoned. People will give comments and opinions to ensure their correctness. Then the person realizes it in this way, and if it succeeds and is recognized, simply write it down for future reference. Since the system already exists, this simple written design can be really simple.

There are two similar practices in "loose knot pair programming".

One is that the master tells his apprentice what he thinks (usually with a whiteboard or a blank piece of paper), and the apprentice asks the master to answer, so far.

On the contrary, the apprentice told the master, and the master questioned and instructed him, so far.

Neither should form a permanent document in advance, but write a simple document record after it has been proved to be feasible (that is, after the coding is complete). Any text / picture outside the code that can help understand what was done at that time can be called a document, and there is no word limit. It would be better to put it with a user story, a description of what was done and a description of how it was done.

two。 Front checkpoint

Is to do temporary pair programming at the beginning of something. It usually happens at the beginning of a function, and the details will be described in detail in the Daily activities section later.

Management: joint planning (joint estimation, poker estimation)

Anticipated statements and pre-checkpoints are already very lightweight, but if both the master and the apprentice have just understood the requirements (user stories) and can't give a very clear train of thought, such as at the Scrum planning meeting, how to quickly know whether the apprentice understands the needs and whether there is a general way to implement them? That is co-estimation (poker estimation is one of the best forms of co-estimation).

1. Joint estimation

The principle and practice of joint estimation is still very complicated, which is only briefly discussed here, and will be described in detail in the future.

The common estimate is that the master and the apprentice, based on the same information (usually after listening to PO tell the story at the planning meeting), together say how long they think it will take to finish the task. The basic principle is: if two people have the same understanding of the duration of something, then their implementation methods are the same, either way.

In order to prevent others from following others, it is generally necessary to use anonymous methods, and playing card estimation achieves efficient and effective common anonymous estimation (detailed in another article).

two。 Acceptance standard

In order to establish a common estimate based on the same goal, and to prevent the requirements from being gilded or eventually the software cannot meet the requirements, the master and apprentice need to establish a common understanding of the requirements.

The simple way is for both of them (actually the master and several apprentices) to attend the estimation meeting and listen to PO explain the story together. But it is best to establish a "documented" acceptance standard after that. For example, in a story card / Excel form. It says "need to be integrated; no performance requirements." The simplest description (please refer to the next article on acceptance criteria in the Agile Development category of this blog).

Joint estimation + acceptance criteria enable masters and apprentices (promoted as experts and beginners) to use roughly the same method and do roughly the same thing. Joint estimation is not only a process of work, but also a process of learning, because while understanding what to do and how to do it, the apprentice also learns from the master.

-

Basically, what is described here is the way of pre-work. Based on Murphy's theorem (as long as things can go wrong, they will certainly go wrong), it is not enough to prevent them in advance. In daily work, it is still necessary for master and apprentice to cooperate with each other. The details will be described in another article.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.