The Mythical Man-Month

The Mythical Man-Month: Essays on Software Engineering là một cuốn sách về quản trị dự án phần mềm được viết bởi Fred Brooks, tập trung ở đó là phát biểu "Thêm người vào một dự án đang bị trễ sẽ làm cho nó trễ hơn." Ý tưởng này được biết đến như là luật của Brooks, and is presented along with the second-system effect and advocacy of prototyping. Lần đầu tiên xuất bản năm 1975, sau đó được tái bản như là phiên bản kỷ niệm vào năm 1995 (ISBN 0-201-83595-9) với tiểu luận "No Silver Bullet" và lời chú của tác giả.

The Mythical Man-Month
Thông tin sách
Tác giả	Fred Brooks
Chủ đề	Quản trị dự án phần mềm
Nhà xuất bản	Addison-Wesley
Ngày phát hành	1975, 1995
ISBN	ISBN 0-201-83595-9 (1995 ed.)
Cuốn sau	No Silver Bullet

Những quan sát của Brooks dựa trên kinh nghiệm làm việc của ông tại IBM khi quản lý dự án phát triển Hệ điều hành OS/360. Ông đã có một sai lầm khi thêm nhân lực vào một dự án đang bị trễ so với kế hoạch. Ông còn mắc phải một sai lầm khi đánh giá một dự án viết một ngôn ngữ lập trình tên là Algol sẽ cần sáu tháng mà không chú ý đến số lượng nhân lực sẽ tham gia. Khuynh hướng những quản trị dự án lặp lại những sai lầm tương tự khiến Brooks đặt tên cuốn sách là "Thánh kinh của phát triển phần mềm" bởi vì "Mọi người đều đọc nó nhưng không ai làm tương tự"

Ý tưởng

The Mythical Man-Month

Phân công thêm nhiều lập trình viên vào một dự án đang bị trễ tiến độ sẽ làm cho nó trễ hơn, do thời gian cần thiết để một lập trình viên mới học về dự án, cũng như làm quá tải sự trao đổi thông tin trong nội bộ nhóm. Khi N người phải giao tiếp với nhau, khi N tăng, output M của họ giảm và có thể trở thành âm (<0)(ví dụ: tổng khối lượng công việc còn lại vào cuối ngày lớn hơn tổng khối lượng công việc vào đầu ngày hôm đó, cụ thể là khi nhiều lỗi được tạo ra)

• Công thức tính khối lượng thông tin trao đổi trong nhóm: $n(n-1)/2$
• Ví dụ: 50 lập trình viên -> $50(50-1)/2=1225$ kênh giao tiếp thông tin

The Second-system Effect

The second system an engineer designs is the most dangerous system he will ever design, since he will tend to incorporate all of the additions he originated but did not add (due to the inherent time constraints) to the first system. Thus, when embarking upon a second system an engineer should be mindful that he is susceptible to over-engineering it.

Progress Tracking

Question: How does a large software project get to be one year late? Answer: One day at a time! Incremental slippages on many fronts eventually accumulate to produce a large overall delay. Continued attention to meeting small individual milestones is required at each level of management.

Conceptual Integrity

To make a user-friendly system, the system must have conceptual integrity, which can only be achieved by separating architecture from implementation. A single chief architect (or a small number of architects), acting on the user's behalf, decides what goes in the system and what stays out. A "super cool" idea by someone may not be included if it does not fit seamlessly with the overall system design. In fact, to ensure a user-friendly system, a system may deliberately provide fewer features than it is capable of. The point is that if a system is too complicated to use, then many of its features will go unused because no one has the time to learn how to use them.

The Manual

What the chief architect produces are written specifications for the system in the form of the manual. It should describe the external specifications of the system in detail, i.e., everything that the user sees. The manual should be altered as feedback comes in from the implementation teams and the users.

The Pilot System

When designing a new kind of system, a team will design a throw-away system (whether it intends to or not). This system acts as a pilot plant that reveals techniques that will subsequently cause a complete redesign of the system. This second smarter system should be the one delivered to the customer, since delivery of the pilot system would cause nothing but agony to the customer, and possibly ruin the system's reputation and maybe even the company's.

Formal Documents

Every project manager should create a small core set of formal documents which acts as the roadmap as to what the project objectives are, how they are to be achieved, who is going to achieve them, when they are going to be achieved, and how much they are going to cost. These documents may also reveal inconsistencies that are otherwise hard to see.

Project Estimation

When estimating project times, it should be remembered that programming products (which can be sold to paying customers) and programming systems are both three times as hard to write as in-house programs. It should be kept in mind how much of the work-week will actually be spent on technical issues, as opposed to administrative or other non-technical tasks, such as meetings.

Communication

To avoid disaster, all the teams working on a project should remain in contact with each other in as many ways as possible (e-mail, phone, meetings, memos etc.) Instead of assuming something, the implementer should instead ask the architects to clarify their intent on a feature he is implementing, before proceeding with an assumption that might very well be completely incorrect.

The Surgical Team

Much as a surgical team during surgery is led by one surgeon performing the most critical work himself while directing his team to assist with or overtake less critical parts, it seems reasonable to have a "good" programmer develop critical system components while the rest of a team provides what is needed at the right time. Additionally, Brooks muses that "good" programmers are generally 5-10 times as productive as mediocre ones. See also Organization and Team Patterns.

Code Freeze and System Versioning

Software is invisible. Therefore, many things only become apparent once a certain amount of work has been done on a new system, allowing a user to experience it. This experience will yield insights, which will change a user's needs or the perception of the user's needs. The system should, therefore, be changed to fulfill the changed requirements of the user. This can only occur up to a certain point, otherwise the system may never be completed. At a certain date, no more changes would be allowed to the system and the code would be frozen. All requests for changes should be delayed until the next version of the system.

Specialized Tools

Instead of every programmer having his own special set of tools, each team should have a designated tool-maker who may create tools that are highly customized for the job that team is doing, e.g., a code generator tool that spits out code based on a specification. In addition, system-wide tools should be built by a common tools team, overseen by the project manager.

Giảm chi phí phát triển

Có hai cách để làm giảm chi phí phát triển phần mềm được Brooks mô tả như sau:

• Việc phát triển có thể thuê sau khi kiến trúc hệ thống thực sự hoàn thành (một bước có thể tốn nhiều tháng, trong thời gian này, việc thuê trước lập trình viên có thể không có gì để làm).
• Một cách khác được Brooks đề cập đến là không nên cố phát triển một phần mềm khi mà có thể mua nó.

Các tham khảo khác

• A review by Tal Cohen
• Frederick P. Brooks, Jr. Homepage
• Preface to 20th Anniversary Edition, as found on Safari.Informit.com
• Organization and Team Patterns