The Mythical Man-month

Tản mạn về Man-month – Phần Mở Đầu

Lần đầu tiên biết đến cuốn sách này là lúc đọc được 1 bài viết về những cuốn sách gối đầu giường của programmer and project manager (tập sự). Trong đó có rất nhiều cuốn sách kinh điển như Pracmatic Programmer, Code Complete, Clean Code, Design Pattern GOF, Peopleware, và tất nhiên là The Mythical Man-month. Những cuốn đầu là dành cho các lập trình viên để luyện nội công nhập môn. Riêng 2 cuốn sau là dành cho các đàn anh chị để quản lý các bạn lập trình viên kia.

Tò mò, mình cũng download cả 2 cuốn về đọc thử (không có điều kiện mua sách gốc), và bị shock ngay những trang đầu tiên. Cái shock thứ nhất là từ ngữ quá khó nhằn, có lẽ bản thân cái title cũng đủ nói lên độ “dai” của nó, và cũng có thể là do bản chất của nghệ thuật quản lý, phải viết giông dài triết lý (nghe mấy ông manager nói chuyện là đủ hiểu) chứ không thực dụng như các bí kíp nhập môn khác. Mình đành từ bỏ cuốn Peopleware, vì nội công chưa đủ để lĩnh hội, nên đành cố đấm ăn xôi lấy cuốn còn lại, đọc đi đọc lại mấy lần (toàn là bỏ dở giữa chừng, xong phải start lại) mà vẫn không thẩm thấu hết tinh túy của cuốn sách.

Mythical_man-month_(book_cover)(The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) – Frederick P. Brooks Jr.)

Lần này quyết định “yêu thêm lần nữa” em nó xem có mò mẫm được gì thêm không. Một điểm mới của lần này là mình sẽ đưa lên blog bản dịch bằng tiếng Việt do mình đọc hiểu và diễn giải lại theo ý của mình để mọi người cùng tham khảo.
Tâm sự chút vậy thôi, mình nên đi vào phần lăng-xê em nó 1 tí để lên dây cót nào.

Man-month. Chắc ai cũng biết, đó là đơn vị tính trong quản lý dự án, còn gọi là “ngày công”. Ví dụ nói dự án này cần 5 người làm trong 3 tháng thì khối lượng của dự án sẽ là 15 man-months. 1 ví dụ khác, công ty nhận được 1 dự án từ 1 khách hàng nói là phải hoàn thành trong 1 năm, sau khi ước tính 1 hồi thì ông manager nói dự án này tốn khoảng 120 man-months, vậy cho ổng 10 người để làm.
Mythical. Tra từ điển thì ra là thần thoại. Ráp với Man-month thì nghĩa là gì. Khó hiểu quá. English dictionary thì có định nghĩa: “idealized, especially with reference to the past”.

Thôi ai muốn hiểu sao thì hiểu, mình thì gọi là “Tản mạn về Man-month” (Nghe lúa vl). Bản thân mình luôn thích sự đơn giản và luôn hướng đến việc giải thích bất cứ việc gì bằng từ ngữ đơn giản nhất có thể. Các ý tưởng trong loạt bài viết được dựa trên ấn bản “The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) – Frederick P. Brooks Jr.” được viết lại theo cách dễ hiểu và gần gũi nhất với người Việt.

Do chưa hiểu hết nội dung cuốn sách nên mình đành mượn review trên mạng về để lừa tình. Sau này nếu có hiểu biết thêm thì sẽ chỉnh sửa lại, hi vọng lúc đó các bạn cũng có thể góp ý cho phần mở đầu về câu chuyện kể về ngày công này.

Xin được trích nguyên văn bài viết “Sao vẫn còn mãi dùng Man-Month?” của tác giả Dương Trọng Tấn trên HanoiScrum


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.


Các bạn có thể tìm đọc, hoặc mua sách gốc trên Amazon.com

Danh mục bài viết:

The Mythical Man-month Phần 1: Vũng lầy

edwardthienhoang.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s