Quick Software Development

This book has a high score on Douban and has a good rating. After a variety of confusions, I finally decided to read this book, although this book is the thickest.

This book is basically written from the perspective of a manager, but it does not limit the perspective to a fixed management position, which means that this book does not discuss specific practices.

I found the following problems:

1. Risk management

Everything is risky, and any decision-making is risky. Software development is no exception. Software Engineering is a very complicated process, and the "risks" in it are difficult to quantitatively assess and control. Even if it is difficult to quantify and control, it should be evaluated as accurately as possible and effectively controlled. Otherwise, a software project is almost impossible to succeed. A common risk identification method is a schedule risk. In the risk analysis process, the loss size should be taken into account to assess the probability of loss. In addition, different risks have different priorities, which can be avoided and eliminated through monitoring. The term risk management was my first contact. The Team Project in our group does not involve risk management, so I am not very familiar with it.

2. Incentive Mechanism

The incentive mechanism is too important! I am PM in the team project. How can I encourage everyone to write happily and efficiently?CodeI spent a lot of time thinking. The book mentions the five most important incentives: a sense of accomplishment, a development opportunity, a pleasure in work, a personal life, and an opportunity to become a technical supervisor. I feel that these five incentive factors are far away from us. They are too professional. We are still students. It seems that it is more effective to eat and eat together... Everyone is not familiar with the problem at the dinner table, and many problems are solved at the dinner table. Everyone wants to eat, but it is better to eat together. Another point is to encourage everyone to share. Because our group of students have similar tasks and almost parallel tasks, other people may encounter problems. When a person solves a technical problem, we encourage him to share his methods, which also inspires everyone's enthusiasm for development.

3. customer-oriented development

I am deeply touched by this. The book mentions the importance of customers for rapid development. It can improve efficiency, reduce rework, reduce risks, and eliminate conflicts. In practice, we also deeply understand the importance of the customer, because in any case, your software will eventually be used by the customer. The users we imagine in our minds are usually very different from real users. Many feature features we want to implement are useless to users. For example, if a user wants to create an activity, he will not do this on his mobile phone at first, and the complex action will be completed on his computer. Besides, it takes a lot of time to implement this feature, which is basically not used by anyone. In the end, we decided not to use this feature.

4. Team Structure

The team structure problem involves both human and complex issues. The book mentions many interesting team models, such as "drama team", "Search and Rescue Team", "professional Athlete Team", and "MainProgramTeam members, etc. A professional team must have a clear division of labor and smooth communication. To be honest, there are many problems with the team structure of our team. For example, if we didn't learn design, what we did was ugly. We didn't have a dedicated tester and everyone developed it, everyone also tests and our PM also needs to write code (PM prefers to write code), which should be avoided by professional teams as much as possible.

5. Why is it "Fast Software Development"

The first chapter of the book specifically introduces what is "quick" and provides many suggestions. But is it just quick? Obviously not. The second part of the book describes effective development. It can be seen that fast development is not based on the sacrifice of quality. In the startup field, there is a very famous saying: "iterate fast and release often", and I think it is quite consistent. The demand is changing, the user is changing, and the market is changing. If it cannot be fast, it will soon be eliminated.

Tao Yu