Một vài suy ngẫm về "The Mythical Man-Month" - cuốn sách Triết Học kinh điển dành cho cư dân ngành CNTT.

The Mythical Man-Month: Essays on Software Engineering is a book on software engineering and project management by Fred Brooks first published in 1975, with subsequent editions in 1982 and 1995

Giới thiệu sách “The Mythical Man-Month” của Frederick Phillips Brooks, Jr. Một 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.

Năm 1995, trong lời bạt cho lần tái bản kỉ niệm 20 năm xuất bản “The Mythical Man-Month”, tác giả Fred Brooks khẳng định những nhận định cơ bản trong cuốn sách vẫn còn nguyên tính thời sự. Hơn một thập kỉ sau, Mary Poppendieck nhắc lại “Một cuốn sách kinh điển đã trụ vững qua thời gian. Điều đó cho thấy có rất ít thay đổi trong suốt 30 năm qua”. Có lẽ đó là lời gợi mở hữu ích để chúng ta lật giở những trang sách đáng quý, và suy ngẫm xem liệu những nhà quản trị dự án có đang đi lại những vết xe đổ đã được chỉ ra từ hàng thập kỉ trước hay không.

Sách gồm 17 chương, trong đó có 4 chương mới được viết thêm vào 1995 nhân kỷ niệm 20 năm xuất bản. Sách này chính là khởi nguồn cho định luật Brooks cũng khá nổi tiếng là “Adding manpower to a late software project makes it later” (Đưa thêm người vào 1 dự án đang trễ, sẽ chỉ khiến nó càng trễ hơn).

Ngoài hai chương này ra, thì các chương khác bàn về documentation, manual cũng rất hay. Có hai khái niệm khác được đề cập và đến nay thấy hữu ích là “Conceptual Integrity” (yêu cầu cho thiết kế hệ thống) và “Second-System Effect” (các bạn startup sẽ thấy chương này hữu dụng vì nó chỉ ra hiệu ứng second-system, khiến cho việc bạn xây dựng những hệ thống quá phức tạp, ảnh hưởng đến thời gian release dự án bởi vì bạn…quá giỏi giang trước đó – thành công của First system).

Sách bao gồm những bài luận ngắn, riêng lẻ về các đề tài xoay quanh việc quản lý dự án phần mềm như về tài nguyên hệ thống, phần cứng, đội nhóm, nhân sự, dự án, tài liệu nội bộ, manual cho người dùng, sự thay đổi trong cấu trúc tổ chức, cũng như những khó khăn trong xây dựng phần mềm mà sẽ không có phương pháp triệt để nào giải quyết dứt điểm.

Thú vị nhất là Chương 2 (The Mythical Man-Month, cũng là tựa sách) và chương 16 (No Silver Bullet – Essence and Accident in Software Engineering). Chương 2 là khởi nguồn cho định lý Brooks, liên quan đến việc phân tích sự liên hệ giữa nhân sự và thời gian (Man-month) và chỉ ra những trường hợp nào thì việc tăng người mới hiệu quả và cũng giải thích tại sao không hiệu quả trong những trường hợp khác. Chương 16 bàn về khó khăn khi triển khai cũng đưa ra nhiều góc nhìn và quan điểm khiến cho việc phát triển phần mềm sẽ luôn gặp khó khăn bởi có nhiều vấn đề là không thể thay đổi hay có giải pháp tối ưu để giải quyết.

Ngoài hai chương này ra, thì các chương khác bàn về documentation, manual cũng rất hay. Có hai khái niệm khác được đề cập và đến nay thấy hữu ích là “Conceptual Integrity” (yêu cầu cho thiết kế hệ thống) và “Second-System Effect” (các bạn startup sẽ thấy chương này hữu dụng vì nó chỉ ra hiệu ứng second-system, khiến cho việc bạn xây dựng những hệ thống quá phức tạp, ảnh hưởng đến thời gian release dự án bởi vì bạn…quá giỏi giang trước đó – thành công của First system).

Thú thật, cho tới giờ tôi vẫn thấy rất khó chịu khi phải làm việc với những trang dự án bắt buộc phải ước tính ra bao nhiêu Man-Month (hay dùng đơn vị khác là “ngày-công”), mặc dù biết rất rõ những ước lượng kiểu này chỉ để mà … ước lượng. Còn đây là lời của Brooks hơn 40 năm trước: “Man và Month (hay con người và thời gian) không để hoán đổi, cẩn thận với khái niệm Man-Month. Thêm người vào dự án chậm tiến độ chỉ làm chậm tiến độ thêm mà thôi”. Thời điểm đó có thể có người còn chưa đồng ý, nhưng ngày nay thì cái được biết đến với tên “Định luật Brooks” này đã được khá nhiều nhà quản trị dự án quán triệt rất kĩ.

Mặc dù tập trung vào những vấn đề liên quan tới con người trong việc quản lí dự án phần mềm, Brooks đã đi xa hơn rất nhiều để thảo luận kĩ về những vấn đề liên quan đến công cụ, phương pháp, quy trình hay tổ chức để tìm kiếm một sự hiểu biết thấu đáo và đầy đủ trong lĩnh vực quản trị dự án và phát triển phần mềm. “The Mythical Man-Month” trở thành kinh điển có lẽ bởi người đọc nó không chỉ có được một cái nhìn toàn cảnh, mà còn là cái nhìn rất sâu sắc vượt thời gian của một người giàu kinh nghiệm trong ngành. Mỗi một lần đọc lại, tư duy của người đọc như một lần được làm mới.

Đối với những người thực hành Agile, đây là một cuốn sách tham khảo hết sức quan trọng. Từ trước thập kỉ của Agile rất lâu, Brooks đã dùng tư biện để đưa ra những nhận định không khác gì so với những gì được thể hiện trong Manifesto (tuyên ngôn) và các nguyên lí của Agile:

  • Con người quyết định tất cả, công cụ chỉ là cái phục vụ cho con người thực hiện tốt hơn công việc của mình (Agile Manifesto nói: cá nhân và tương tác hơn là quy trình và công cụ”)
  • Man và Month (hay con người và thời gian) không để hoán đổi, cần cẩn thận trong việc dùng Man-Month làm độ đo để ước tính và lập kế hoạch (Agile tránh ước lượng ra MM một cách cứng nhắc, mà tập trung vào các kĩ thuật thích ứng – adaptive - trong lập kế hoạch).
  • Conceptual Integrity: tính toàn vẹn khái niệm là trung tâm của vấn đề chất lượng (Agile và Lean gọi nó là chất-lượng-tự-thân, hay là “toàn vẹn tự thân”)
  • No Silver Bullet: không một quy trình tuyệt hảo nào có thể gia tăng ngay lập tức năng suất lao động của lập trình viên (Agile đề cao tính linh hoạt, thích ứng và tùy biến để phù hợp với các điều kiện thực tế, năng suất của nhóm được cải thiện thông qua quá trình thích ứng, học tập và cải tiến liên tục)
  • Incremental Build (xây dựng tăng trưởng) thì tốt hơn (Agile: tăng trưởng và lặp)
  • Trao quyền và phi tập trung hóa (Agile gọi cơ chế này bằng những khái niệm nhóm tự-tổ-chức và liên-chức-năng)
  • Mô hình Waterfall sai rồi! (chỉ rõ Man-Month là mythical, thì hệ quả tất yếu là mệnh đề này)

Đặc điểm dở nhất của cuốn sách có lẽ là nó đã lùi hơi xa vào quá khứ, khi mà nền công nghệ thông tin khác khá xa so với ngày nay, những vấn đề kĩ thuật cụ thể có thể đã không còn gần gũi với bạn đọc của thế kỉ XXI. Có vẻ nó hơi khó đọc. Nhưng như thế lại càng làm nổi bật rõ những chân lý xuyên thời gian, không phụ thuộc bối cảnh hay nền tảng công nghệ, qua đó ta có thể rút ra được những bài học bổ ích. Vì vậy mà một cuốn sách gần 40 tuổi này không chỉ là tập tài liệu đọc thêm bắt buộc của sinh viên ngành Software Engineering, mà còn được những nhà quản trị dự án phần mềm chọn làm sách gối đầu giường.

Tổng hợp và tham khảo:

  • Dương Trọng Tấn (https://hanoiscrum.net)
  • Võ Duy Tuấn (https://www.bloghoctap.com)
Category