This chapter mainly discusses the relationship between process and engineering. Because my experience is shallow, and has not actually contacted the project, therefore to some truth in the book indefinitely. A picture of the communication problem at the beginning of the article is sufficient to illustrate the center of the first two sections. From the customer's hand to receive a project, although according to the classic model of the project into a process, and then to different people to complete. This does not seem unreasonable. The second section, however, points out the problems that arise in practical applications: it is that every worker in the process is just going through the motions and not trying to do the job well, just mechanically those excellent models without understanding the essence behind the models.
People who work for engineering are lost in the project. Just as developers get lost in the details of a technology. The person who focuses on the difference between RUP or RAD can draw a flowchart of each process, but it is also tied to each of these processes, and there is no effort to struggle.
The title of the third section is very straightforward-the realization is the goal. The authors point out very directly that the majority of software workers are trifles, blindly pursuing various models, but ignoring the most central purpose, but also the most original purpose-to achieve the purpose of the customer.
Section four--the process is not a dead model, it is a profound explanation of this point of view. It is not a mistake to divide a complex project into a small one, and it is very correct. But the current situation is that software engineering staff have been thinking rigid enough to only mechanically these models, but forget the core purpose. A good model is originally experienced companies or teams in the actual work of the slowly summed up, to help us to better complete the work, but now the software engineering personnel mechanically led to the original to help us the excellent model has become the shackles of our bondage, become the process of our heavy burden.
The five and sixth sections mainly talk about the relationship between "empty shelves" and "substance". This I do not understand how to read, but about know the author's meaning should be said, in the project in the end to use which model, must be in understanding the essence of the various models and the essence of the basis, combined with the actual situation to choose a reasonable solution. should not only for an empty shell, showy and blindly pursuit of a model that does not meet the time, but lost the most important essence
Engineering is not done, it is organized. This metaphor is very easy to understand. This section is about what a good project manager should do--a rational allocation of organizational work so that a team can pull together to complete the project.
Therefore, we certainly cannot "do" projects, but "organize" projects. The project manager's job is to organize the various roles in the project, so that the division of labor is clear, unison and common to complete the project
The fifth chapter of the Road to Jane