| Many comments and discussions have been made on the book man-month myth. Probably, the author's experience-"is considered to be the father of IBM 360 systems," as a project manager for 360 systems and a manager for the design phase of 360 operating system projects ." -- Is already the best comment. Many of my friends think that the current software engineering data is more theoretical and not highly operable, so they can only understand some ideas. I am still confused about specific projects. In the entire translation process, Brooks's views and academic attitudes are often amazing. Here, I will discuss some of my experiences and practices with you. Programming systems product ). Unlike all of the above cases, the cost is as high as nine times. However, it is the only product that is truly useful and the goal of most system development ." It makes sense, at least in the face of the current views of many bosses on Management. "Management in the real world is more at the cost of human life, so that they can work harder and longer. Managers keep boasting about the overtime hours of their staff and the tricks that can extract more time from these people ." (Man piece, to be published by Tsinghua University Press, translated by chunxu And ye xiangqun for umlchina translators. In this case, the quality of development products will definitely decline, or even be terrible, because the only thing developers can control is quality. When they have to sacrifice quality, they will face their own work with great pains, when trampling on the joy of work, we can imagine that the project cost will increase significantly, and the release of the Project will often be accompanied by the collapse of a large number of programmers. Team formation
The Mythical man-month (The Mythical man-month) puts forward this argument, (blindly) "adding manpower to projects with lagging progress only makes the progress more backward ." This also involves how to set up your development team or plan development plans, divide task items, and allocate resources for a software development task. Next, in the surgical team, Brooks proposed using surgeons + deputies to organize the team to ensure the integrity of the design philosophy. It also mentions the use of "language experts" to help solve difficult problems; arrangement of tool maintenance personnel, that is to say, in the current sense, the system administrator can ensure the effective operation of the system development and management environment, while others can solve some file management tasks.
In a small C ++ project
- PM and constructor use one slave to analyze requirements and design the framework to ensure the conceptual integrity of the entire project. The output of the analysis design reaches the level of the sample code of the framework. This part of the Framework Code mainly helps the team to understand the project development and does not exist in the formal code;
- Arrange for developers to take charge of configuration management. The Configuration Management here is not limited to the management of documents and software products, but when framework-driven iterative development is used, the framework and various components need to be constantly compiled, integrated, and checked to record bugs. This developer is often the main programmer in the team (chief programmer) and has some experience in various development methods and methodologies;
- Arrange personnel to conduct pre-Research on the tool, such as understanding the STL class library. The specific personnel of this role will be adjusted at different stages. Because he/she needs to study languages, class libraries, and development skills, which often takes a lot of work time. In actual situations, the primary programmer is responsible for the early stage, and the PM is responsible for the later stage;
This arrangement can solve the consistency of product ideas and greatly improve productivity and product quality. However, it requires: 1. PM has good communication with the constructor, including the style of the analysis method and the understanding of development. inconsistency between them will directly lead to the development direction of the project; 2. Make good implementation of the analysis results. The software industry is young, vigorous, and impetuous. Some developers are far away from each other and do not pay enough attention to the code quality, affecting the stability of the framework. The risk of such arrangement is that "surgeons" may be overloaded, especially in domestic companies, who often work simultaneously on PM and system analysis. Similarly, the corresponding performance appraisal mechanism is not easily available. Another risk lies in the "one-use-one-slave" arrangement, where "Why does the tower of Babylon fail? (Why did the Tower of Babel fail ?)" The organization structure of large-scale programming projects is described in detail. However, in the domestic development environment, it seems difficult to implement it. The discount solution is to establish development and management guidelines for certain types of projects, including business types, development methods, and language types, so as to ensure conceptual integrity. In the subsequent development of a series of projects of the domino type, I tried to implement the problem. The potential voice of the above method is "software reusability ". When it comes to reusability, you may immediately think of objects, class libraries, and so on. Good, object-oriented methods and business component (class) libraries do greatly improve software reusability. However, for small and medium-sized enterprises and even a mature development team, accumulating their own large-granularity frameworks is an important measure to improve software productivity. Some of the design patterns, such as visitor and observe, can be used as software frameworks. Based on the design model, accumulating frameworks in specific business fields based on the development type is a feasible best practice. Brooks has repeatedly stressed "concept integrity" and recommends surgeons to be responsible for system development in the surgical team, it ensures that the systems generated are the results of a few people's thinking. They are often simple and pure, without the influence of many people. After the baptism of the project, they can often become a framework for reuse. On the contrary, many developers are arranged to develop together in the analysis design phase. Even though the project is completed, it will lead to the "the second-system effect" feature-"It is extremely creative, extremely complex, and efficient. But I don't know why. At the same time, I also feel rough, wasted, and not elegant, and make people feel that there must be some better way.The Reusable framework often captures the root of the problem and uses a simple and elegant solution to solve 80% of the problem. Implementation
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, rather 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 is that programmers are less involved in the preliminary analysis work, and experienced colleagues are responsible for providing framework code-level requirements and framework products. 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, you must set well-defined time and space targets ,...... At the same time, at the level of physical implementation, there are also a lot of work that can be done."In actual projects, there are usually a small number of people 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 the document is"The clever practice of the project manager is to generate several documents immediately as the data basis, 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." Change-oriented development
"Stable Production ideas are particularly unsuitable for project work. We tend to forget this: the whole purpose of a project is to let ourselves die. The only stable State in project life is stiff after death ......"(Peopeware ); "Software development is the process of reducing chaos (reducing entropy), so it is in sub-steady state. Software maintenance is a process of increasing chaos (increasing entropy). Even the most skilled software maintenance work only slows down the process of system degradation to non-steady state."--" Plan to throw one away )" Software development itself is an activity with unordered trends. When people move around and look for a pipeline method similar to computer hardware, they may think quietly, which is in itself contrary to the internal development law of development. In addition, software development is a creative activity of human thinking. Just like poetry and music, it seems that there is no attempt to streamline the above-mentioned creations in human history. From the perspective of software development products, configuration management in level 2 of CMM specifications generally includes four activities: configuration identification, version control, change control, and measurement. The configuration identifier and version control are designed to provide a stable basis for changes. Brooks described 360 machine development as"In the system/360 engineering model, the purple wiring harness is often seen inadvertently in a lot of conventional yellow-colored wires ....... These changed cables use purple wires and look like a broken thumb ." It embodies the prototype of configuration management and further proposes "... The "Purple harness" method is also required for software development. For the program code that finally becomes a product, it urgently requires strict control and in-depth attention ....... Documentation is also required."--" The whole and the parts )" In the CMM pilot project and subsequent project practices, it is easy to identify the document deliverables of the project. There are a lot of materials and templates on the Internet for reference. Version Control can use VSS or open source CVs, while the "baseline" concept that appears repeatedly in the CMM specification, in the initial stage of configuration management practices or small-scale projects, it is not mandatory. When the configuration identification and version control practices reach a certain level, it is much easier to promote baseline and change control. That is to say, for a certain type of project, you can adopt the configuration identification specification, identify the document type, determine the directory structure of this type of project, and establish a version control mechanism for initial practice, after a certain degree of maturity, implement change management. Change"Phase (quantum), regular changes ...... The quantum (phase) change method perfectly accommodates the purple harness technology: until the next scheduled release of system components, fast patching has been used. In the current release, integrate documented repair measures that have passed tests into the system platform.This method can alleviate the conflicts between project pressure, changes, and quality to a certain extent. Iterative development
In his "The Mythical man-month after 20 years", Brooks clearly proposed the concept of iterative development.Better incremental development model-progressive refinement". This development method has an inmeasurable incentive for the project. When I was at the University of North Carolina,I am often shocked by the boost effects of the first image on the screen and the first runable system on the team's morale."And in the real project of C ++, when the first executable prototype appears in front of developers under great pressure, it is exhausting and frustrating for a long time. Thus, it provides motivation for further development. Here, long-term high-load work is not promoted, but incremental development is an important means of software development dynamics. Iterative development can be implemented using the "surgical team", Oo and design patterns. The Analysis and Design Ideas of object-oriented frameworks do not have to be implemented in object-oriented languages. One of its important features is to solidify user requirements or relatively stable parts of the system to be developed, so as to get a more stable model at the cost of a certain dimension of the model. Then, the framework is constantly iterated. The surgical team is operated by experienced surgeons to host demand analysis and build iterative frameworks. A few people can ensure that the framework does not have many unnecessary non-structural features, so as to ensure the simplicity and good scalability of the framework. Iterative development is a good medicine for changing this "monster". Different iteration cycles can better accommodate changes in the phase (quantum. While changing, there is always a system that can run for debugging and testing, so as to ensure the quality of the project-quality determines the cost,"The quality far exceeds the requirements of end users is a means to achieve higher productivity."(Man piece, to be published by Tsinghua University Press, translated by the umlchina translation team chunxu And ye xiangqun ). Similarly, Brooks put forward the concept of abandon prototype in "plan to throw one away", and his opinion in "man-month myth" is: yes or not? (Propositions of the mythical man-month: true or false ?)" "Therefore, you must plan to discard it."Iterative development is to accommodate prototypes, including the discard type and the non-Discard type. Moreover, it is a good way to persuade management and users-because different iteration cycles and tasks are originally planned. In the C ++ project, I still have some regrets for abandoning the Framework Code prototype after the framework design is complete, the price is the loss of product quality and developers' confidence in the project. Another way to improve the quality of the project's products, Brooks gave expert advice in "System Integration debugging" in "the whole part (the whole and the parts)"."Use the debugged component units, build a sufficient testing platform, and add one component at a time and perform phased (quantum) and periodic changes". This is still instructive in the current practice. The current software testing level is believed to be very clear to the industry: there are very few standardized tests, white box tests are basically not done, the project pressure is too high, and the testing time is constantly reduced ....... Therefore, a careful system integration test is very necessary. Half of the os360 system test in man-month myth is already very good. Project Plan
The importance of the project plan should be clear to everyone. Brooks mentioned project planning/tracking in the article "hatching a catastrophe. In addition, the importance of plan docalization is described in many other chapters. Here, a project plan not only refers to the project progress, but also draws only the project progress using Microsoft Project. In practice, the Project Plan can be considered from the following aspects:
- Project Description: includes the project definition, name, background, goal and scope, deliverables, and acceptance criteria;
- Project Organization Structure: defines the composition of project personnel. Note: This part of content will be continuously adjusted according to the implementation of the project;
- Software life cycle: determines the appropriate cycle according to the characteristics of the project. Not all projects are applicable to the iteration cycle, nor are waterfall models useless. Some projects even need waterfall models as the backbone and add iteration features at a certain stage.
- Project management: includes customer management, progress management, cost management, risk management, and training management;
- Configuration Management: defines the project directory structure, product identification method, version control, and so on;
The project plan must be carefully considered based on the user and project features. It may be a few words, but its role is not described under the requirement specification. Project plans and requirement specifications are the most basic mandatory documents in the project documentation set. In software development, theories and practices are a constant topic. We are fortunate to have been born in the age of information sharing and can be touched by the wise thoughts of our predecessors. "This magical era is far from over, and it is still developing rapidly. More fun for the future."-- Brooks. |
