Sao vẫn còn mãi dùng Man-Month?

Giới thiệu sách “The Mythical Man-Month” của Frederick Phillips Brooks, Jr.

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.

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 (xuất bản lần đầu năm 1975) 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.

Dương Trọng Tấn.