Some Questions about fast software development by yiming Qian

I recently read "quick Software Development" written by Steve McConnell and put forward some of my views. You are welcome to comment on it.

1. How to understand the speed of rapid software development?
The definition of "Fast software development" in the book is as follows: it is a common term and has the same meaning as "Fast Development" or "shorter development cycle". In short, this means that you can develop software at a faster speed than you currently do. Literally speaking, the definition is not comprehensive enough compared with the effective development proposed later in the book. Many people have expressed similar views on Douban and excellence, however, I personally think that fast software development is actually a macro term, which means that our modern software development projects basically want our own projects to be fast, and the premise of fast speed is efficiency, for example, if you make many low-quality typical errors in your software products, it takes a lot of time to modify the errors? Obviously, the speed of software development involves improving the speed and shortening the cycle. Therefore, such a definition is reasonable at a deeper level!

2. How do I select a project member?

The second chapter in the book provides five principles for selecting project team members, one of which is "the greatest genius-fewer and better people". First of all, I don't think everyone in a team must be a "genius". This may be a bit exaggerated, I personally think that when selecting a project member, a basic principle is to ensure team harmony to the maximum extent and achieve team strength. Therefore, we can divide human beings into two types. One is comprehensive knowledge, that is, understanding many aspects of knowledge. For example, a person who understands both hardware and software, and the other is excellent talent, this kind of person is particularly proficient in one aspect. When the two types of person form a team, they can only do specific things, while they are responsible for communication between the players. In addition, the smaller the number of people, the better, depends on the size of the project.

3. What should I do when the software is estimated in advance or the plan conflicts with the actual progress?

The book details how to make accurate estimates and provides some instances of overly optimistic progress plans. However, it does not show readers how to make unreasonable estimates, it even seriously affects the specific feasible remedial measures in the next step. I personally think that in the actual software development process, especially new users like us, this is certainly the case.

4. Is it possible to solidify the thinking of the team members according to their guidance and plans? What are the disadvantages of the entire project?

the 5, 8, and 9 sections of this book cover the importance and necessity of the implementation of the original plan in the software development process. If this is done blindly, does it affect project innovation. For example, when software development is half done, a team member gives a new idea about software development, and the solution is better than originally planned, what measures should be taken in this case.