Quick review các nghịch lý kinh điển của sách “The Mythical Man-Month” của Frederick P. Brooks
Published on: March 11, 2023
Last updated: March 12, 2024 Xem trên toàn màn hình
Last updated: March 12, 2024 Xem trên toàn màn hình
Recommended for you
- 04 Mar 2020
Kinh nghiệm lập dự toán chi phí dự án phần mềm theo phương pháp Man-Month 2142 - 01 Jul 2023 Phương pháp Shuhari - Làm sao học ít hiểu nhiều? 587
- 01 Aug 2022 "Sponsored Content" là gì? Khác nhau giữa Sponsored Content và Native Advertising? 521
- 01 Feb 2022 Thách thức với doanh nghiệp chuyển đổi số trong thời đại VUCA 495
- 15 Apr 2023 Nghịch lý từ câu chuyện “một chén gạo dưỡng ơn, một đấu gạo gây thù” 440
- 09 Aug 2022 Hiệu ứng “rắn hổ mang” (Cobra effect): Khi giải pháp trở thành vấn đề, tưởng vui lại hóa xui 347
- 15 Apr 2020 Phần mềm BPM là gì? So sánh với ERP và các phần mềm Workflows 329
- 03 Feb 2020 Sản phẩm OEM và ODM là gì? 320
- 18 Jul 2020 Lợi ích cận biên (Marginal Utility) là gì? Qui luật lợi ích cận biên giảm dần 317
- 14 Aug 2022 Khác biệt giữa tiêu chí hoàn thành DOD (Definition of Done) với tiêu chí nghiệm thu (Acceptance Criteria) 267
- 12 May 2021 Các yêu cầu thay đổi (Change Requests) - nỗi ám ảnh của team dự án phần mềm 267
- 22 May 2022 Tư duy ngoài hộp (Thinking out of box) là gì? Tại sao quan trọng với sự phát triển của doanh nghiệp? 255
- 04 Jan 2023 Đánh giá nhân sự theo chuẩn người Nhật 220
- 17 Aug 2020 Mục tiêu dự án là gì? Làm thế nào để xác định mục tiêu? 180
- 01 Sep 2023 Định luật Goodhart và định luật Campbell - Nghịch lý về thành tích 164
- 12 Sep 2021 Túi càn khôn của lập trình viên Agile cần trang bị những gì? 162
- 03 Sep 2020 Hiệu ứng rắn hổ mang, Luật Goodhart, Campbell & Chuyện thi cử 162
- 10 Sep 2024 Tại sao những thứ chúng ta muốn lại ít khi có được? 152
- 08 Mar 2022 Mô hình nguồn mở hoạt động ra sao? 151
- 14 May 2024 Chiến lược răng lược là gì? Làm thế nào để tận dụng chiến lược răng lược trong kinh doanh? 147
- 08 Mar 2020 Vì sao doanh nghiệp cần phải tạo Web bán hàng? 143
- 02 Oct 2023 Ngôi Chùa Trăm Năm và Viên Gạch Vỡ: Bài Học Thấm Thía Về Lỗi Nhỏ Trong Bức Tranh Lớn 137
- 01 May 2023 [Tư vấn CNTT] Quản lý ngân sách CNTT cho doanh nghiệp 132
- 01 Apr 2022 Chi phí nhà thầu phụ chiếm bao nhiêu phần trăm gói thầu? 130
- 01 Sep 2020 Co-founder là gì? Vai trò của các Co-Founder khi lập nghiệp. 129
- 19 Aug 2020 Lift & Shift - Phương pháp tối ưu dịch chuyển hệ thống phần mềm qua đám mây 129
- 17 Feb 2018 Hệ luỵ khi sử dụng Web Hosting từ nhà cung cấp kém chất lượng 118
- 11 Sep 2020 Nghịch lý kinh doanh tại Mỹ: Chăm sóc khách hàng không tốt, nhưng công ty lại lãi lớn 117
- 16 Feb 2024 Nghịch lý của sự hoàn hảo: AI có thể quá tốt để sử dụng? 117
- 09 Jan 2025 10 Nghịch Lý Cuộc Sống Từ Phim Upstream (nghịch hành nhân sinh): Đối Mặt Rủi Ro Trong Thời Đại VUCA 115
- 18 Mar 2018 Dịch vụ Hosting cho Website là gì? Các lời khuyên chọn Hosting tốt nhất 110
- 09 Feb 2021 Tầm nhìn là gì? Tí dụ minh họa cụ thể về tầm nhìn 103
- 03 Oct 2021 Khác biệt giữa thiết kế phần mềm và thiết kế công trình xây dựng 98
- 25 Apr 2018 Bảo hộ bản quyền phần mềm dưới khía cạnh sở hữu trí tuệ như thế nào? 86
- 15 Mar 2024 Tê liệt vì suy nghĩ quá nhiều (Analysis Paralysis) là gì? 82
Sách “The Mythical Man-Month” của Frederick Phillips Brooks, Jr là cuốn sách nền tảng gối đầu cho tất cả kỹ sư CNTT trên toàn thế giới, nó kinh điển đến mức được ví như là sách Triết Học của ngành CNTT. Các định luật trong sách vẫn đúng cho đến tận 40 năm sau.
| Nhiều dự án lập trình trở nên tồi tệ vì thiếu thời gian theo lịch hơn là vì tất cả các nguyên nhân khác cộng lại. | More programming projects have gone awry for lack of calendar time than for all other causes combined. |
| Nấu ăn ngon cần có thời gian; một số nhiệm vụ không thể vội vàng nếu không muốn làm hỏng kết quả. | Good cooking takes time; some tasks cannot be hurried without spoiling the result. |
| Tất cả các lập trình viên đều là những người lạc quan: “Mọi việc rồi sẽ diễn ra tốt đẹp thôi.” |
All programmers are optimists: “All will go well.” |
| Bởi vì lập trình viên xây dựng bằng tư duy thuần túy, nên chúng ta mong đợi sẽ gặp ít khó khăn khi triển khai. (đây thực chất là một nghịch lý). | Because the programmer builds with pure thought-stuff, we expect few difficulties in implementation. |
| Nhưng bản thân ý tưởng của chúng ta lại có lỗi nên chúng ta có lỗi (đầu vào thế nào thì đấu ra thế đó). | But our ideas themselves are faulty, so we have bugs (garbage in, garbage out). |
| Kỹ thuật dự tính của chúng ta, được xây dựng dựa trên mô hình kế toán chi phí, đã gây ra nhầm lẫn giữa 2 khái niệm nỗ lực (công) và tiến độ. Dựa vào man-month là một sai lầm và nguy hiểm, vì nó ngụ ý rằng nhân lực và thời gian có thể thay thế cho nhau. | Our estimating techniques, built around cost-accounting, confuse effort and progress. The man-month is a fallacious and dangerous myth, for it implies that men and months are interchangeable. |
| Việc phân chia một nhiệm vụ giữa nhiều người tạo ra thêm công sức đào tạo và tương tác trong nhóm, cũng như giao tiếp chéo giữa nhiều nhóm nhỏ. | Partitioning a task among multiple people occasions extra communication effort-training and intercommunication. |
| Nguyên tắc là: 1/3 lịch biểu của dự án là dành cho thiết kế, 1/6 dành cho viết code, 1/4 dành cho kiểm thử riêng rẽ và 1/4 dành cho kiểm thử tích hợp toàn hệ thống. | My rule of thumb is 1/3 of the schedule for design, 1/6 for coding, 1/4 for component testing, and 1/4 for system testing. |
| Về mặt nguyên tắc, chúng ta thiếu số liệu để xác định khoảng dự tính cho công việc/dự án. | As a discipline, we lack estimating data. |
| Bởi vì chúng ta không chắc chắn về dự tính kế hoạch của mình nên chúng ta thường thiếu can đảm để bảo vệ chúng một cách mạnh mẽ trước áp lực của ban quản lý và khách hàng. | Because we are uncertain about our scheduling estimates, we often lack the courage to defend them stubbornly against management and customer pressure. |
| Định luật Brooks: Việc bổ sung nhân lực vào một dự án phần mềm muộn sẽ chỉ khiến dự án đó bị chậm trễ. | Brooks’s Law: Adding manpower to a late software project makes it later. |
| Việc thêm người vào một dự án phần mềm sẽ làm tăng tổng công (effort) theo ba cách: bản thân công việc và sự gián đoạn của việc sau khi khoanh vùng lại công việc, đào tạo người mới và gia tăng thời gian giao tiếp, trao đổi, họp hành. | Adding people to a software project increases the total effort necessary in three ways: the work and disruption of repartitioning itself, training the new people, and added intercommunication. |
[{"displaySettingInfo":"[{\"isFullLayout\":false,\"layoutWidthRatio\":\"\",\"showBlogMetadata\":true,\"includeSuggestedAndRelatedBlogs\":true,\"enableLazyLoad\":true,\"quoteStyle\":\"1\",\"bigHeadingFontStyle\":\"1\",\"postPictureFrameStyle\":\"2\",\"isFaqLayout\":false,\"isIncludedCaption\":false,\"faqLayoutTheme\":\"1\",\"isSliderLayout\":false}]"},{"articleSourceInfo":"[{\"sourceName\":\"\",\"sourceValue\":\"\"}]"},{"privacyInfo":"[{\"isOutsideVietnam\":false}]"},{"tocInfo":"[{\"isEnabledTOC\":true,\"isAutoNumbering\":false,\"isShowKeyHeadingWithIcon\":false}]"},{"bannerInfo":"[{\"isBannerBrightnessAdjust\":false,\"bannerBrightnessLevel\":\"\",\"isRandomBannerDisplay\":true}]"}]
Nguồn
{content}
Khám phá thêm các chủ đề sau
Guest Blogging: The Definitive Guide
Các chủ đề được quan tâm nhiều nhất
CHIA SẺ BÀI VIẾT