Chín mươi chín mươi quy tắc trong thực tế

90 phần trăm đầu tiên của mã chiếm 90 phần trăm đầu tiên của thời gian phát triển. 10 phần trăm còn lại của mã chiếm 90 phần trăm thời gian phát triển khác.

- Tom Cargill, Phòng thí nghiệm Bell

Điều đó chính xác có nghĩa là gì trong thực tế? Các lập trình viên đó làm khối lượng công việc đáng kể và họ đang cho 180% từ chính họ hay?

Hãy tưởng tượng nó như thế này: Khi bạn bắt đầu làm việc trên phần mềm, bạn có thể viết một lượng lớn mã trong thời gian tương đối ngắn. Mã mới này có thể thêm một lượng lớn chức năng mới. Vấn đề là, thông thường, chức năng đó không được "thực hiện", có thể có lỗi, thay đổi nhỏ (nhỏ trong kinh doanh nhỏ), v.v. Vì vậy, phần mềm có thể cảm thấy như đã hoàn thành (90% đã hoàn thành), vì nó hỗ trợ phần lớn các trường hợp sử dụng. Nhưng phần mềm vẫn cần làm việc. Điểm chính của quy tắc này là mặc dù phần mềm cảm thấy gần như đã hoàn thành, khối lượng công việc để đưa phần mềm đó vào trạng thái hoạt động chính xác cũng lớn như việc đạt đến trạng thái "gần như hoàn thành" đó. Đó là bởi vì sửa lỗi thường tốn thời gian nhưng không tạo ra nhiều mã.

Vấn đề là hầu hết các nhà phát triển ước tính đưa phần mềm vào trạng thái "gần như đã hoàn thành", bởi vì điều đó tương đối đơn giản so với thực tế ước tính tổng nỗ lực mà phần mềm sẽ mất.

Nó là một tham chiếu đến một kịch bản phổ biến, đáng buồn là vẫn xảy ra ngày hôm nay:

1. Nhóm được yêu cầu ước tính (tức là đoán) số lượng công việc cần thiết để viết tất cả mã,
2. Dự án tiến hành với nhiều áp lực bên trong và bên ngoài để "giữ đúng thời gian và ngân sách",
3. Vì vậy, đối với một tỷ lệ đáng kể của dự án, "về đích" được báo cáo. Điều này thường được kết hợp bằng cách chọn các nhiệm vụ dễ dàng trước để đảm bảo tiến độ tốt được thực hiện.
4. Sau đó, ở một giai đoạn nào đó, một điểm quan trọng đã đạt được khi thực tế phải được chấp nhận: dự án sẽ không được hoàn thành đúng hạn và ngày phát hành bị đẩy lùi (thường là nhiều lần).

"90%" là một con số tùy ý, nhưng nó làm cho vấn đề trở nên rõ ràng: ước tính là phỏng đoán và có thể sẽ sai (thường rất sai) và bản chất con người đảm bảo chúng ta gần như luôn luôn ước tính, vì vậy mọi thứ tràn ngập.

Tôi đã nghe một phiên bản khác của điều này (còn được gọi là "quy tắc 90-90") như sau:

Sau khi tôi đã thực hiện 90% chức năng, tôi vẫn phải thực hiện 90% còn lại .

Cả hai phiên bản đều đề cập đến khó khăn trong việc ước tính chính xác nỗ lực phát triển các sản phẩm phần mềm và những cạm bẫy phổ biến mà mọi người có xu hướng rơi vào:

• ném các số liệu thống kê ra khỏi đó khi cần ước tính và về cơ bản là đoán ("Tôi đã hoàn thành 80%")
• tập trung vào độ phức tạp thuật toán của mã được viết, với tác hại của khối lượng công việc (đánh giá thấp nỗ lực cần thiết cho các tác vụ thông thường)
• thiếu các bước ("khuất mắt, mất trí")
• đánh giá thấp nỗ lực để duy trì và thay đổi mã hiện có
• đánh giá thấp nỗ lực cần thiết cho mã soạn sẵn / "keo"

Quy tắc này bổ sung cho quy tắc 80-20. Bây giờ, có nhiều cách hiểu khác nhau về quy tắc 80-20, nhưng hai cách tôi thích nhất là:

1. Việc phát triển sản phẩm 80% đầu tiên chiếm 20% nỗ lực.
2. 80% lỗi nằm trong 20% ​​mã.

Trong thực tế, điều này có nghĩa như sau: sự phát triển sẽ bắt đầu và tiếp tục cho đến khi một số điểm nhất định khi sự chậm trễ đầu tiên sẽ được chú ý. Sự chậm trễ có thể có tính chất khác nhau:

• Kiểm soát chất lượng kém, dẫn đến lỗi
• Các yêu cầu bổ sung mà khách hàng đưa ra trên đường đi (và lý do cho điều này cũng có thể là nhiều)
• Các yêu cầu không rõ ràng ngay từ đầu, dẫn đến việc bỏ đi các phần của sự phát triển trước đó (điều này cũng có thể dẫn đến lỗi hồi quy)
• Đánh giá ban đầu do phạm vi không rõ ràng, lỗi của con người hoặc trường hợp không dự đoán được. Những trường hợp không thể đoán trước này có thể là những chiếc lá ốm yếu, sự cam chịu, sự cố phần cứng hoặc trong trường hợp cực đoan, núi lửa phun trào (một khi chúng tôi phải trì hoãn một dự án vì chúng tôi không thể bay tại chỗ do núi lửa phun trào ở Iceland).

Điểm mấu chốt là việc đến gần mục tiêu sẽ dễ dàng hơn nhiều so với việc thực sự đạt được nó.

Tôi thấy Wikipedia giải thích khá ngộ:

Điều này cho biết thêm tới 180% trong một sự ám chỉ gượng gạo về sự nổi tiếng của các dự án phát triển phần mềm khi chạy quá mức lịch trình của họ (xem ước tính nỗ lực phát triển phần mềm). Nó thể hiện cả việc phân bổ thời gian thô cho các phần dễ và khó của một dự án lập trình và nguyên nhân gây ra độ trễ của nhiều dự án là do không lường trước được các phần khó. Nói cách khác, phải mất cả thời gian và mã hóa nhiều hơn dự kiến ​​để làm cho một dự án hoạt động.

Điều đó chính xác có nghĩa là gì trong thực tế? Các lập trình viên đó làm số lượng công việc không đáng kể và họ đang tự cho mình 180% hay sao?

Không, lập trình viên luôn làm cùng một lượng công việc trên một đơn vị thời gian. Báo giá là về chi phí ước tính thấp và vượt mức. 180% là số lượng thời gian và tiền bạc mà dự án kết thúc với chi phí.

Nó đại khái có nghĩa là "Bạn sẽ mất gấp đôi thời gian bạn nghĩ" và "Bạn sẽ nghĩ rằng mình đang làm tốt cho đến khi quá muộn (thời hạn đã gần kề)".

Điều này có nghĩa là trong thực tế là mọi người nói dối chính họ.

Nếu một lập trình viên nói rằng "chúng tôi đã hoàn thành 90%", điều đó có nghĩa là 90% nỗ lực xây dựng các tính năng đã được sử dụng.

Nếu một người quản lý dự án nói rằng "chúng tôi đã hoàn thành 90%, tôi chỉ cần ai đó hoàn thành nó" thì có nghĩa là họ đã hoàn thành 90% thông qua ngân sách (và có thể là 50% đã hoàn thành). Đây là một khách hàng không có tiền, kỳ vọng cao và thái độ không tốt.

Sự khác biệt là cần nhiều nỗ lực hơn các tính năng mã hóa để hoàn thành một dự án: qa, sửa lỗi, sao chép chỉnh sửa, triển khai.

Những điều đó cần phải được quản lý trong dự án, và là trách nhiệm của người quản lý dự án. Điều này thường gây ngạc nhiên cho các Thủ tướng mới, những người tìm đến "90% tính năng hoàn thành" chỉ để nhận ra rằng họ chỉ mới đi được một nửa so với "dự án đã hoàn thành".