Khác biệt giữa bản sửa đổi của “The Mythical Man-Month”
Nội dung được xóa Nội dung được thêm vào
Không có tóm lược sửa đổi |
Không có tóm lược sửa đổi |
||
Dòng 14:
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ự"
==
====Huyền thoại 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)
Dòng 25:
====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ó.
====
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.
====
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ùng 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.
====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.
| |||