I see scrum (1)

I got scrum Agile Software Development on Wednesday afternoon. After reading the last chapter at on Friday, I think of my project experience and can't help but feel a lot, I agree with most of my views with deep understanding, and some disagree. I think of the article "Why scrum is not good" Translated by Chen Hao at the front-end time. Here, I systematically talk about my views on scrum and agility. It is also a book review of this book. Unless otherwise stated, the following examples are based on your own experiences.

Four Dimensions of Software Development: people, processes, products, and technologies.

1. People

The most famous book about people is man piece. We are familiar with such a sentence: the Productivity Difference between developers with different depth and breadth can be more. However, another statistic cannot be ignored: The productivity differences between developers with the same level of experience can also reach.

Human factors include motivation, organizational structure, selection of team members, teamwork and training.

It is clear that human parts greatly affect production efficiency and should be considered before processes, products, and technologies. However, this only indicates that individual abilities, individual incentives, team competencies, and team incentives play a greater role than other factors, it doesn't mean that a team can achieve incentives as long as they have T-shirts, free carbonated drinks, Windows offices, game consoles, and beautiful test mm. This is only necessary, not sufficient. The real incentive comes from the ongoing project.

Ii. Process

The process consists of two parts: management and technology. It includes project planning (one of which is the project lifecycle model and iterative development), tracking, measurement, quality assurance, and risk management.

Some people think that focusing on the process will make the work dull and inefficient. However, the most common phenomenon of process abuse is the neglect process.

Iii. Products

About products, including product scale (demand scope) and product features (non-functional requirements, performance, stability, and reliability ).

The attention paid to the product scale and features represents a huge opportunity to shorten development time. Reasonable Reduction of product functions can shorten the product development cycle. The 2/8 principle exists here.

Iv. Technology

The basic principles of technology include requirement management, system design, system construction, and configuration management. The specific content includes the selection of technology stacks, development languages, development platforms, frameworks, and development tools.

First look at people

I. Personnel roles

The SCRUM team has two important roles: the coach (iteration manager) and the product manager. One is internal and the other is internal. As a coach, he is responsible for providing a good and uninterrupted working environment for the team and promoting continuous improvement of the team. Everyone understands that the most important thing is that his power cannot exceed the scope of the development process, and he cannot cross the process to make decisions for the team.

In the two projects I 've experienced, iterative managers from technical backgrounds have the habit of making decisions for programmers. One iteration manager reviews the design of each programmer, and the other iteration manager spends a lot of time discussing the specific details of story implementation with the programmer every day and putting forward his or her own opinions.

The actions that iterative managers make decisions actually express their distrust of the team, which is inevitable. No matter what kind of good wishes they initially have, they will ultimately influence the team's enthusiasm. In the next project, some programmers even stood up and handed the keyboard and said to the iteration manager, okay, let's do it.

The iteration manager cannot cross the border. It does not mean that he cannot exert an influence. Its impact should be indirect.

As for the product owner, the most important thing to remove the product requirements is to ensure that only one person can make decisions on the product direction and requirements.

In my previous company, there were four shareholders who had to discuss and make decisions collectively. When my wife heard about the organizational structure of our company for the first time, she smiled and said that your company is destined to be a small company.

In one of my previous projects, the customer's product manager and the customer's O & M team have been arguing over the demand. There is no consistent and unified product development direction, leading to a lot of waste.

2. team size

In the classic management books, there are no more than five people who can directly and effectively manage a person. Of course, with the standardization of the process, this number has been greatly expanded. In the development team dominated by informal communication, the standard of five people is still applicable. A small team of five to seven people is suitable. The advantage of a small team is to reduce communication and coordination and promote cohesion.

In the later stage of a project, when the number of people expanded from the first eight to 14, the time for The Daily website meeting was greatly extended. Everyone did not know what others were talking about, too many people speak, and the focus is lost.

But just as one person cannot complete the Apollo moon landing, the problem with the small team is that, despite the increase in productivity, the overall output is not enough. For many projects, a large team is inevitable. The key is to split a large team into many small teams. There are multiple methods for coordination between these teams, the lowest cost is the appropriate decomposition of the system. For example, the current Sina Weibo platform, third-party plug-in developers and Sina Weibo teams are completely decoupled, the purpose of system decomposition is to minimize interaction between small teams. Management methods include System Integration Teams and personnel flow between teams.

3. Feature team or component team

Scrum advocates feature teams, but what I feel most deeply is feature-driven development.

In the development of a workflow product, I used hierarchical development. At first, the team focused on developing the workflow engine, the development tasks of the Management Console, integrated components, and designer are placed after the engine is complete. As a result, the project was canceled due to the delay in providing the demo version to the company to reflect the progress and the company's capital shortage. It is a pity that everyone in the team, because it is a proud engine that supports all 21 workflow modes.

If possible, a feature team should be set up, rather than a component team. This is my point of view in the book. My point of view is somewhat different from this. My point of view is that if it is at the project level, there is no doubt that we should set up a feature team, but it should go up to the company level, component Accumulation and accumulation are required.

As a positive example, in a company, because of the existence of the collaborative office business platform, basically all collaborative office projects were implemented for about three months. Of course, this platform is abstracted and accumulated based on many projects of the company. The platform team also participates in project development.

As a back-to-back example, team members in another company are arguing over technical issues, and even a paging component must be rewritten twice, resulting in a lot of waste. The company did not notice the accumulation of public technology. One important principle in lean-standardization was intentionally ignored.

4. team collaboration

5. full-featured team

6. Do not use distributed teams

Process

I. Estimation

Ii. Plan

Iii. Documentation

Iv. Iterative project lifecycle

V. Quality

Vi. Risks

Product

1. Project simplification is the only way out for success

2. Multiple teams and one task list

Technology

I. Test-driven development

2. Reconstruction

Iii. Collective Ownership

Iv. Continuous Integration

V. pairing

Vi. Simple Design and over-design