Mythical man-month-Revelation of man-month

Adding manpower to projects with low progress will only make the progress more backward. -Brooks Law

Revelation of man-month

 

Progress is one of the most important issues in IT project management. In chapter 2, the mythical man-month begins to talk about progress. The feasibility and controllability of the Progress come from the scientific nature of the project plan. The accuracy of the Project Plan's progress forecast comes from the accuracy of the estimation, and whether the estimation is accurate also involves the project scale, the workload can be obtained based on the scale, and the final progress can be obtained based on the workload and human resource input and task dependency constraints. When the scale of software products increases, the complexity increases exponentially, leading to a non-linear relationship between these elements, which is one of the revelations of the mythical man-month; at the same time, due to the lifecycle model and process task restrictions of software projects, there is a minimum construction period for software product R & D of a certain scale, regardless of the amount of resources invested, it is useless to invest more resources in this shortest period.

We are still talking about the issue of estimation at the beginning. we can introduce the cocomoii estimation model to estimate the workload and progress for the estimation assumption that the person-month can be exchanged, estimation of Small and Medium-sized products and projects still requires expert experience, and certain methods and estimation models must be followed for large projects. Therefore, large projects still emphasize that the first thing to do is to estimate the scale of software products. The scale can work with productivity, and the workload can work with schedule and related models to get the project cycle. Based on this idea, we will consciously accumulate raw data such as productivity, review efficiency, and defect density.

The estimation is based on user requirements, but we often blindly estimate the user requirements if they are unclear. For enterprise information-related software systems, estimation of newly launched and developed products is often the most inaccurate, because of the lack of relevant historical data and experience accumulation, estimation participants also lack in-depth understanding of their business and needs. Promotion of the PSP individual software process is conducive to improving the estimation capability, because it allows developers to more accurately recognize their own development productivity. The improvement of technical architecture and accumulation of technology are conducive to improving the estimation level, because the more technologies are improved, the less technical research tasks are in the future, and technical research is often a task of high uncertainty. A developer's in-depth understanding of the business field helps improve the estimation level. The greatest impact on the scale and workload of any requirement function is the complexity of business rules, instead of the UI interface and basic process involved in this requirement.

Optimism

Optimism assumes that everything works well without any risks or problems. The actual situation is that a difficult problem may be delayed for several days or a week in actual development. Although we have identified and analyzed the risks, we still cannot avoid the emergence of various unexpected problems. Using the PERT Program Review Technique and three-point estimation, we can see that if we fully estimate based on the optimistic method, the probability of normal completion by progress is usually 0%, if we estimate the most pessimistic approach, it is difficult to ensure that 100% can be completed on schedule. If we expect that the probability of reaching 80% can be completed on schedule based on the most likely estimation, it means that the progress deviation is controlled within the range of 20%, 20% may be the scope of progress control that we can tolerate.

Creative Activities include three stages: conception, implementation, and communication. The first idea would have taken time, and the time that developers actually think about during development activities (thinking is an analysis and design activity) there is often more time than actually typing code lines. The second idea is incomplete, and the ideas should be verified and modified continuously in implementation, this kind of continuous reciprocating will take time, for example, starting to assume that some code implementation method does not work, and it is necessary to completely design new algorithms for implementation. There are also large systems that perform multi-layer WBS decomposition, and there is a complex association dependency between tasks. The extension of any task on the path aggregation point will lead to the extension of subsequent tasks.

Mythical man-month

The use of a month to measure the size of a job is a dangerous and deceptive myth, because it implies that the number and time of people can be replaced by each other. (Note: man-month is used to measure the workload. The scale is measured by function points or code lines. After dividing the scale by the individual productivity, the man-month data can be obtained ). Here we will further describe the reason why tasks cannot be exchanged between people and months. The first is whether tasks can be split, whether there are mutual dependencies and constraints in a timely manner, and whether or not the corresponding communication will be added after the decomposition, as well as the additional workload such as decomposition and post-integration introduced due to decomposition tasks.

Assume that people and months can be exchanged, more people need to be invested to reduce the cycle, and tasks need to be subdivided to make more people have something to do, subdivided tasks naturally increase the workload of System Decomposition and later integration. Unavoidable dependencies and associations between subdivided tasks naturally increase the communication cost and workload. In addition, due to task segmentation, heavyweight communication tools such as documents need to be introduced. The original requirement information is in the requirement, design, development, it is difficult to guarantee the conceptual integrity that we need to pass through multiple steps such as testing.

If a system is estimated to have 200 Function Points by function point, it is calculated by a function point of 50 thousand-lines of code. The entire system is about lines of code. This is a small and medium-sized project or system. If the total productivity is 80 rows/day, the total workload is about 20 months. Based on the nonlinear relationship, we can estimate the ideal situation or the most cost-effective situation is to invest 5 people and 4 months to complete the process. When the number of people doubles, the progress can only be compressed to three months. When the number of people increases to 15 again, the progress will be reduced to 2 months. At this time, it will be useless to add more people. For systems of this scale, 2 months may be the progress limit.

 

System Test

When the scale increases, the workload is not non-linear growth, and the cycle is not non-linear shortening. The increase in workload has already been discussed above. The first focus has been on system analysis design. complex systems need to be decomposed. The second is integration and testing in the future, various functional modules need to be integrated and assembled. When the product scale increases, the workload for the detailed design and coding phases can be linearly increased, the increased workload of some non-linear indexes reflects the Analytical Design and integration and testing at the early stage.

 

When we assume it is linear, we reduce the workload of both ends. How to reduce the workload of system analysis and overall design may lead to instability of the entire product structure. The consequence is that the entire product is often re-launched. If the workload of integration and testing is reduced, it is inevitable that the project will be postponed. Optimizers like to assume that we are developing a zero-defect system, but for complex software systems, this is just a myth.

For large projects, the book shows the recommended workload distribution (Plan 1/3, code 1/6, unit testing and integration testing 1/4, 1/4 system testing ). Few projects allocate half of the test cycle and time, and few projects only allocate 1/6 of the coding time. Based on my actual software project development experience, the approximate empirical data is (requirement 1/4, design implementation 1/2, test 1/4 ). It is already a relatively large value for Small and Medium-sized Projects to allocate 1/4 of the testing workload, which means that a team of about 10 people needs to configure two dedicated testers ).

Progress disaster

Simply and arbitrarily repeat the Brooks rule: Adding manpower to projects with low progress will only make the progress more backward. (Adding manpower to a late software project makes it later ). This is The Mythical man-month. The project time depends on the order limit, and the number of people depends on the number of individual subtasks. The two values can be used to calculate the progress schedule. This table has fewer personnel and takes a long time (the only risk is that the product may become obsolete ). On the contrary, if more people are assigned and a short schedule is planned, a feasible schedule cannot be obtained. In short, among the many software projects, the lack of reasonable time schedule is the main cause of Project lag, which is more influential than all other factors.

When there is a serious problem with the progress, the most effective method is to reduce the task. Instead of delivering 10 unavailable feature points, it is better to deliver 5 high-priority feature points. Second, when the progress lags behind, blind overtime often does not help. According to the time management methodology, the more busy you are, the more time you should stop and reflect on where the slowness is and where the bottlenecks and root causes are, only when the root cause of the problem is discovered and solved can the efficiency and acceleration be improved.

We can consider the root cause of backward progress as follows.

1. The demand itself changes frequently and is not controlled. Frequent changes and rework during development are all ineffective work.

2. developer skills, low development efficiency, or insufficient understanding of business needs.

3. Do developers have an attitude and sense of responsibility that can stimulate their potential to create passion.

4. There is no quiet and focused environment, which is often interrupted by various irrelevant meetings, phone calls, and trivial matters.

I just listed several common problem scenarios. No matter which type of problem, it will eventually come down to the improvement process and more teams and people.