The Mythical Man-Month

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	0-201-83595-9 (1995 ed.)
Cuốn sau	No Silver Bullet

The Mythical Man-Month: Essays on Software Engineering (Chuyện tưởng tượng về Man-Month: Thử nghiệm trong kỹ thuật phần mềm) 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, có mặt cùng với hiệu ứng "hệ thống thứ hai" và sự ủng hộ tích cực của Mẫu đầu tiên của phần mềm. 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ả.

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ư tưởng

Chuyện tưởng tượng về 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

Hiệu ứng Hệ thống thứ hai

Hệ thống thứ hai hay Hiệu ứng hệ thống thứ hai mà một kỹ sư thiết kế ra là hệ thống nguy hiểm nhất mà kỹ sư đó đã từng thiết kế, khi kỹ sư đó hướng tới việc tích hợp chặt chẽ tất cả những tính năng cộng thêm anh ta đã tạo ra nhưng lại không thêm vào hệ thống đầu tiên (do sự giới hạn thời gian). Vậy thì, khi bắt đầu thực hiện hệ thống thứ hai, một kỹ sư nên luôn ghi nhớ rằng anh ta nên nhạy cảm với việc tăng cường nhiều tính năng kỹ thuật.

Quản lý tiến trình

Câu hỏi: Một dự án lớn sẽ trở thành trễ một năm như thế nào? Câu trả lời: Một ngày tại một thời điểm! Việc không giữ đúng thời hạn tăng dần cuối cùng sẽ dồn lại và phát sinh sự chậm trễ lớn. Tiếp tục chú ý để đạt các mốc nhỏ rất cần thiết tại mỗi cấp quản lý.

Nhận thức về tính toàn vẹn của hệ thống

Để tạo một hệ thống thân thiện với người dùng, một hệ thống phải có một nhận thức toàn vẹn, điều chỉ có thể đạt được bằng cách tách biệt kiến trúc khỏi việc thực thi. Một kiến trúc sư trưởng (hoặc một nhóm nhỏ kiến trúc sư), sẽ hành động như là một user, quyết định cái gì sẽ được để vào và cái gì sẽ được bỏ ra khỏi hệ thống. Một "ý tưởng siêu hạng" bởi một người sẽ không được thêm vào nếu nó không phù hợp với toàn bộ thiết kế hệ thống. Thực tế, để đảm bảo một hệ thống thân thiện với người dùng, một hệ thống có thể có ít hơn những tính năng mà nó có thể có nhưng những tính năng đó đều được cân nhắc thận trọng. Nếu một hệ thống sử dụng quá phức tạp, nhiều tính năng sẽ trở thành vô dụng vì không ai có thời gian để học hỏi nó.

Tài liệu sử dụng

Kiến trúc sư trưởng là người sẽ tạo ra tài liệu kỹ thuật của hệ thống dưới hình thức tài liệu hướng dẫn sử dụng. Tài liệu nên mô tả đặc điểm kỹ thuật của hệ thống một cách chi tiết, ví dụ: tất cả những gì mà người dùng thấy được. Tài liệu nên được chỉnh sửa theo phản hồi từ nhóm phát triển và người dùng.

Hệ thống Pilot

Khi thiết kế một hệ thống mới, nhóm sẽ thiết kế một hệ thống "vứt đi" (cho dù nó có mục đích hay không). Hệ thống này là một "kế hoạch thử nghiệm" để biểu diễn những kỹ thuật để sau đó thiết kế lại toàn bộ hệ thống. Hệ thống thứ 2 "thông minh hơn" nên được chuyển một lần đến khách hàng, từ khi việc gửi hệ thống pilot, dù hệ thống pilot không gây ra vấn đề gì nhưng có thể gây lo âu cho khách hàng, và cuối cùng là hủy hoại danh tiếng của hệ thống, có khi là cả của công ty.

Tài liệu chính thức

Mỗi quản trị dự án nên tạo một tập các tài liệu gọi là tài liệu chính thức có vai trò định hướng cho mục tiêu của dự án, cách thức đạt được những mục tiêu đó, ai sẽ là người đạt đến những mục tiêu đó, khi nào thì sẽ đạt được những mục tiêu đó, và giá trị của những mục tiêu đó. Những tài liệu này có thể sẽ làm xuất hiện sự mâu thuẫn và có thể chỉ ra rằng khó mà đạt được những mục tiêu đó.

Đánh giá dự án

Khi đánh giá thời gian của một dự án, nên nhớ rằng, để lập trình một sản phẩm (có thể bán cho khách hàng) và hệ điều hành thì sẽ khó gấp ba lần để viết một ứng dụng. Nên luôn giữ trong đầu về thời gian sẽ phải bỏ ra để giải quyết những vấn đề kỹ thuật, những phản đối với việc quản trị hay những nhiệm vụ không thuộc về kỹ thuật, ví dụ như họp hành.

Trao đổi thông tin

Để tránh những thảm họa, tất cả những cá nhân trong một dự án nên giao tiếp với các thành viên trong nhóm bằng nhiều cách nhất có thể (e-mail, điện thoại, họp, ghi chú v.v...). Thay vì phải giả định điều gì, lập trình viên đó nên hỏi kiến trúc sư của dự án để làm rõ mục đích của một tính năng mà mình sẽ hiện thực, trước khi thực hiện với một giả định mà nó có thể dẫn tới việc hoàn toàn sai.

Nhóm phẫu thuật

Như nhiều nhóm phẫu thuật trong khi phẫu thuật, có một phẫu thuật viên là người dẫn đầu, sẽ tự mình thực hiện những công việc nguy cấp nhất trong khi chỉ đạo nhóm của anh ta giúp đỡ mình hoặc thực hiện những phần việc đơn giản hơn. Tương tự, sẽ có một "lập trình viên giỏi" thực hiện những phần việc khẩn cấp trong khi cả nhóm cung cấp những gì cần thiết một cách kịp thời. Ngoài ra, Brooks cho rằng một lập trình viên giỏi sẽ nhanh hơn gấp 5-10 lần so với một lập trình viên bình thường. Tham khảo Organization and Team Patterns.

Ổn định mã nguồn và đặt phiên bản hệ thống

Phần mềm thì không thể thấy được. Bởi vậy, nhiều thứ chỉ có thể xuất hiện một khi một khối lượng công việc cho hệ thống mới đã hoàn tất và cho phép người dùng có thể sử dụng nó. 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.

Tool chuyên dụng

Cho dù mỗi lập trình viên đều có riêng cho mình một số tool đặc biệt, mỗi một nhóm cũng nên chỉ định một người tạo tool, người đó sẽ tạo những tools được thiết kế đặc biệt cho công việc mà nhóm đang làm. ví dụ, một tool sinh mã nguồn tự động dựa trên yêu cầu của khách hàng. Ngoài ra, một hệ thống tool lớn nên được thực hiện bởi một nhóm chuyên viết tool, được quản lý bởi quản trị dự án.

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 ngoài

• A review by Tal Cohen
• Frederick P. Brooks, Jr. Homepage
• Preface to 20th Anniversary Edition, as found on Safari.Informit.com Lưu trữ 2008-12-08 tại Wayback Machine
• Organization and Team Patterns