Communication issues in software development-Adams Wang

In the Chapter "aristocracy, democracy, and system design", Brooks pointed out that successful software has a high degree of conceptual consistency. "Isn't the new architect expensive ?...... As for the question of aristocratic authority, you must answer "yes" or "no ". There must be only a few architects. The answer is yes ......", The architecture in man-month is more similar to the current requirement concept than the current architecture. However, in practice, the requirements and architecture should still be undertaken by a few people. Such a view may be controversial, but in my personal opinion, the software industry is actually an "elite industry ". High-quality and experienced demand analysts and architects are often the core backbone staff of software enterprises, and the relative mobility of General programmers is relatively higher.

From the perspective of personal development, it seems that being a screw is not the spirit of the times. This problem is the same as the relationship between enterprises and people. For specific project operations, the ideal situation isProgramFewer employees participate in the preliminary analysis work. Experienced colleagues are responsible for providing a frameworkCodeDegree requirement and framework product.

In earlier projects, some general programmers were uneasy about coding implementation, and were too early to be exposed to some PM jobs and other factors such as project pressure, resulting in low code quality, this reduces the degree of reuse of the framework. In another company's project, due to the company's culture, our colleagues developed in strict accordance with the division of labor, improving the quality. The latter seems to have fewer opportunities, but in the long run, we have a better understanding of the design, a deeper understanding of the process, and laid the foundation for future development.

In this chapter, Brooks also proposed "what should implementers do while waiting ?" . He believes that "First, we must set well-defined time and space targets ,...... At the same time, there are also a lot of work at the level of physical implementation ." In actual projects, there are usually a small number of employees who invest in the early stage. Generally, projects of about 15 persons and months are two to five months old ~ Three members, including requirement analysis, designers, and primary programmers. The primary programmer will have a preliminary understanding of the system, study the technologies, tools, and development skills used in system development, and build a software engineering environment and software development environment together with PM. One problem with this arrangement is the communication between programmers and analysis designers. It requires smooth and free communication, and consensus on development may be reached to reduce the loss of information.

In terms of the project communication method, Brooks explained the os360 development experience in the chapter "passing the word. For example, conferences and conferences, multiple implementations, and telephone logs. For small projects, if remote development is not considered, formal intra-group meetings can be arranged once a week, that is, weekly meetings. In addition, review meetings are arranged at milestones to adjust and revise the development progress, demand implementation, and project plan. For remote development, or the user is not local, we suggest using teleconference and other forms. Although the effect is not as good as local development, it is better than others. "Why does Babylon fail? (Why did the Tower of Babel fail ?)" I also stressed the communication issues in software development and pointed out that documents are an important way of communication. The subsequent "Outline of the documentary hypothesis" illustrates how to define a document set for a software project in an analogy. "the other side (the other face) discussed some forms of the program documentation. These points of view are also instructive for practical work. The reference document set for the software project is recommended in the reference of the requisite pro tool in the rational suite. In the practice of several projects in C ++ and Domino, it is found that the smallest collection of documents includes the Software Requirement Specification, software development plan, framework design, and design element descriptions. The project plan is not only about progress, but about Software Configuration Management, lifecycle, resource allocation, risk analysis, and training, this part of content is not limited to a single project, but is common in the same type of project. Therefore, it can be shared in different projects.

All in all, Brooks's advice on documents is "the best practice for project managers is to generate several documents immediately as their own data base, even if these mini documents are very simple. Then ,......" And "if we realized their universality and importance from the very beginning, we could utilize the document as a tool in a friendly manner without making it an annoying task. By following the document, the Project Manager can set his/her own direction more clearly and quickly ."

Http://www.mmmbook.com/review/pratice.htm