Các cách để giảm thiểu ảnh hưởng của Tháng người đàn ông huyền thoại là gì?

Luật của Brooks: Thêm nhân lực vào một dự án phần mềm muộn sẽ khiến nó muộn hơn.

Trong cuốn sách No Silver Bullet - Tinh hoa và Tai nạn của Kỹ thuật phần mềm Frederick Brooks định nghĩa khái niệm Tháng của Người đàn ông Huyền thoại :

Giả định của Brooks là các dự án lập trình phức tạp không thể được phân chia hoàn hảo thành các nhiệm vụ riêng biệt có thể được thực hiện mà không cần giao tiếp giữa các công nhân và không thiết lập một mối quan hệ tương tác phức tạp giữa các nhiệm vụ và công nhân thực hiện chúng .

Từ năm 1982, chúng tôi chắc chắn đã tiến lên phía trước và thu thập thêm một số kinh nghiệm trong việc giảm thiểu vấn đề này. Một số giải pháp mà bạn đã áp dụng thành công trong công việc của mình là gì để thêm tài nguyên vào một dự án mà không tạo ra nhiều vấn đề hơn.

MMM là gì

Đầu tiên tôi muốn giải thích bối cảnh cho Luật Brook. Giả định nào đã khiến ông tạo ra nó vào năm 1975?

Man-tháng là một đơn vị công việc giả định đại diện cho công việc được thực hiện bởi một người trong một tháng; Luật của Brooks nói rằng không thể đo lường công việc hữu ích trong vài tháng.

^{nguồn: https://en.wikipedia.org/wiki/The_Mythical_Man-Month}

Trước đây, các dự án lập trình phức tạp có nghĩa là các hệ thống nguyên khối lớn. Và Brooks tuyên bố rằng những điều này không thể được phân chia hoàn hảo thành các nhiệm vụ riêng biệt có thể được thực hiện mà không cần giao tiếp giữa các nhà phát triển và không thiết lập một mối quan hệ tương tác phức tạp giữa các nhiệm vụ và những người thực hiện chúng.

Điều này rất đúng trong các phần mềm nguyên khối có tính gắn kết cao. Cho dù có thực hiện tách rời bao nhiêu, thì khối nguyên khối lớn vẫn cần có thời gian để các lập trình viên mới tìm hiểu về khối nguyên khối. Và tăng chi phí liên lạc sẽ tiêu tốn một lượng thời gian ngày càng tăng.

Nhưng nó thực sự phải theo cách này? Chúng ta có phải viết các khối nguyên khối và giữ các kênh liên lạc đến n(n − 1) / 2đâu nlà số lượng nhà phát triển không?

Chúng tôi biết có những công ty nơi hàng ngàn nhà phát triển đang làm việc cho các dự án lớn ... và nó hoạt động. Vì vậy, phải có một cái gì đó thay đổi kể từ năm 1975.

Khả năng giảm thiểu MMM

Năm 2015, PuppetLabs và IT Revolution đã công bố kết quả của Báo cáo Nhà nước DevOps 2015 . Trong báo cáo đó, họ tập trung vào sự khác biệt giữa các tổ chức hoạt động cao so với hoạt động không hiệu quả cao.

Các tổ chức hiệu suất cao cho thấy một số tính chất bất ngờ. Ví dụ, họ có hiệu suất đúng hạn dự án tốt nhất trong phát triển. Ổn định hoạt động tốt nhất và độ tin cậy trong hoạt động. Cũng như hồ sơ theo dõi bảo mật và tuân thủ tốt nhất.

Một trong những điều đáng ngạc nhiên được nêu bật trong báo cáo là số liệu triển khai mỗi ngày. Nhưng không chỉ triển khai mỗi ngày, họ còn đo lường triển khai / ngày / nhà phát triển và hiệu quả của việc thêm nhiều nhà phát triển trong các tổ chức hiệu suất cao so với hiệu suất không cao.

Đây là biểu đồ từ báo cáo đó -

Trong khi các tổ chức hoạt động thấp phù hợp với các giả định Tháng huyền thoại. Các tổ chức hiệu suất cao có thể mở rộng quy mô số lượng triển khai / ngày / dev theo số lượng nhà phát triển.

Một bài thuyết trình tuyệt vời tại DevOpsDays London 2016 của Gene Kim nói về những phát hiện này.

Làm thế nào để làm nó

Đầu tiên, làm thế nào để trở thành một tổ chức có hiệu suất cao? Có một vài cuốn sách nói về điều này, không đủ chỗ trong câu trả lời này vì vậy tôi sẽ chỉ liên kết với chúng.

• Tốt đến vĩ đại: Tại sao một số công ty tạo ra bước nhảy vọt ... Và những người khác thì không bởi Jim Collins
• Lợi thế cao: Các nhà lãnh đạo thị trường tận dụng sự xuất sắc trong hoạt động để đánh bại đối thủ cạnh tranh của Steven Spear
• Kinh tế mới cho công nghiệp, chính phủ, giáo dục của W. Edwards Deming

Đối với các tổ chức phần mềm và CNTT, một trong những yếu tố quan trọng để trở thành một tổ chức có hiệu suất cao là: tập trung vào chất lượng và tốc độ .

Ví dụ, Ward Castyham giải thích Nợ kỹ thuật vì tất cả những điều chúng tôi cho phép không bị trộn lẫn. Điều này được quản lý chấp nhận vì nó luôn đi kèm với một lời hứa rằng nó sẽ được sửa chữa khi có thời gian.

Không bao giờ có đủ thời gian, và nợ kỹ thuật ngày càng trở nên tồi tệ hơn.

Những điều này làm cho nợ kỹ thuật tăng lên là gì?

• mã kế thừa
• cấu hình thủ công của môi trường
• Kiểm tra bằng tay
• triển khai thủ công

Mã kế thừa Như được định nghĩa trong Làm việc hiệu quả với Mã kế thừa của Michael Feathers là bất kỳ mã nào không có kiểm tra tự động.

Bất kỳ phím tắt thời gian được sử dụng để có được mã để sản xuất; các hoạt động là gánh nặng với việc duy trì khoản nợ này mãi mãi. Sau đó, quá trình triển khai trở nên dài hơn và dài hơn.

Gene kể một câu chuyện trong bài trình bày của mình về một công ty có triển khai dài sáu tuần. Liên quan đến hàng chục ngàn bước cực kỳ dễ bị lỗi, buộc 400 người và họ sẽ làm điều này bốn lần mỗi năm.

Một trong những nguyên lý của DevOps là độ tin cậy đến từ việc triển khai nhỏ hơn thường xuyên hơn.

Thí dụ

• Jon Jenkins tại Velocity 2011 : Amazon đang thực hiện 15k triển khai / ngày
• Ken Exner tại AWS Summit 2015 : Amazon đang thực hiện 136k triển khai / ngày

Hai bài thuyết trình này cho thấy tất cả những điều mà Amazon đã làm để giảm thời gian họ triển khai mã để sản xuất.

Theo Gene, điều duy nhất được thay đổi theo thời gian trong các tổ chức có hiệu suất cao này là số lượng nhà phát triển. Vì vậy, từ ví dụ của Amazon, bạn có thể nói rằng trong bốn năm họ đã tăng số lần triển khai của họ lên gấp mười lần chỉ bằng cách thêm nhiều người hơn.

Điều này có nghĩa là trong những điều kiện nhất định, với kiến ​​trúc phù hợp, thực hành kỹ thuật phù hợp, chuẩn mực văn hóa phù hợp, năng suất của nhà phát triển có thể mở rộng khi số lượng nhà phát triển được tăng lên. Và DevOps chắc chắn ở giữa tất cả những điều này.

Những gì tôi đã làm (và điều này chỉ mang tính chủ quan) như sau:

Khi người quản lý nghĩ về ngày đáo hạn muốn thêm người vào nhóm của tôi để giảm thời gian cần thiết và dường như theo MMM, trước tiên tôi sẽ thảo luận với anh ấy về lý do tại sao điều này có thể xấu. Sự tương tự yêu thích của tôi cho điều này là để nhắc nhở họ rằng nếu một người phụ nữ có thể sinh con trong chín tháng, thì chín người phụ nữ sẽ không có một đứa con trong một tháng, nhưng họ sẽ có chín đứa con trong chín tháng. Thời gian không bị cắt, chỉ cần xử lý song song là tốt hơn.

Khi quyết định bắt buộc đối với nhóm của chúng tôi, chúng tôi thường cố gắng phân chia một số nhiệm vụ và khi không thể, chúng tôi thường dựa vào lập trình cặp , trong đó một lập trình viên chịu trách nhiệm gõ và người kia ra lệnh (và chuyển đổi định kỳ ).

Bản thân việc viết mã chậm hơn, nhưng có ít lỗi đánh máy / lỗi và lỗi hơn khi kiểm tra vì việc xem xét không thể tránh khỏi được thực hiện trong khi viết. Tôi cảm thấy chất lượng mã tổng thể cũng tốt hơn một chút, nhưng tôi không có số liệu nào hỗ trợ cho tuyên bố đó.

Nói riêng từ góc độ CI, việc tăng số lượng nhà phát triển làm việc trong một dự án thường chuyển thành nhiều người làm việc trong cùng một chi nhánh.

Các hệ thống CI truyền thống có một vấn đề về khả năng mở rộng về mặt này: xác suất vỡ / hồi quy / tắc nghẽn làm tăng tốc độ tích hợp và mời các nhóm nhỏ hơn thoát ra và chuyển sang các nhánh con (tức là chậm hơn nữa). Xem Làm thế nào có thể quy mô tích hợp liên tục cho các dự án / nhóm rất lớn? . Điều này chơi đúng với khái niệm Tháng huyền thoại.

Giải pháp tôi đề xuất trong câu trả lời của mình cho câu hỏi đó, một hệ thống CI có khả năng mở rộng cao sẽ cho phép di chuyển sang CI thực sự - tích hợp dựa trên một nhánh / thân cho toàn bộ các nhóm lớn hơn (ngay cả với kích thước khổng lồ).

Với tất cả mọi người trên cùng một trang, sử dụng cùng các công cụ / quy trình tự động và phần lớn các xác minh QA được tự động hóa trong chính hệ thống CI, việc chuyển đổi vai trò và tập trung giữa các thành viên trong nhóm trở nên dễ dàng hơn nhiều. Toàn bộ quá trình phát triển trở nên mượt mà hơn, dễ dự đoán hơn, thoải mái hơn.

Đưa người mới lên tàu trong một môi trường như vậy, giúp họ làm việc hiệu quả chỉ bằng cách giảm tải các nhiệm vụ ít khó khăn hơn từ các thành viên nhóm có kinh nghiệm hơn, sau đó có thể đảm nhận những nhiệm vụ khó khăn hơn, do đó dễ dàng hơn.

Tất cả những điều này có thể được nhìn thấy, tôi tin, như làm dịu các hiệu ứng khái niệm Tháng huyền thoại.