Tại sao việc thêm nhiều người vào một dự án muộn sẽ khiến nó muộn hơn?

Đây là một câu ngạn ngữ khá phổ biến rằng việc thêm nhiều lập trình viên vào một dự án muộn sẽ làm cho vấn đề tồi tệ hơn. Tại sao lại thế này?

Giới thiệu trên cao

Mỗi nhà phát triển mới phải được giới thiệu về cơ sở mã và quy trình phát triển, không chỉ mất thời gian của người mới mà còn cần sự trợ giúp từ [một] nhà phát triển cấp cao (hướng dẫn họ qua quy trình xây dựng, giải thích quy trình thử nghiệm, giúp họ với những cạm bẫy trong cơ sở mã, đánh giá mã chi tiết hơn nhiều, v.v.) .

Do đó, càng nhiều nhà phát triển mới mà bạn thêm vào dự án thì càng phải dành nhiều thời gian để đưa họ đến một điểm mà họ thực sự có thể đóng góp cho dự án.

Ngoài các câu trả lời khác: Một yếu tố khác cần xem xét là giao tiếp.

Trường hợp xấu nhất đối với số lượng kênh liên lạc trong một nhóm (không phổ biến), là một biểu đồ hoàn chỉnh . Như bạn có thể tưởng tượng, thêm vào chỉ 1 nhà phát triển có thể tăng các kênh liên lạc lên rất nhiều. Với các phương thức truyền thông được sắp xếp hợp lý hơn, tác động sẽ ít hơn ... nhưng nó vẫn tăng lên.

Vấn đề được trích dẫn trong cuốn sách ban đầu ban hành luật này, Tháng huyền thoại , là giao tiếp. Anh ấy bắt đầu bằng cách nói:

Đàn ông và tháng là hàng hóa có thể hoán đổi cho nhau chỉ khi một nhiệm vụ có thể được phân chia giữa nhiều công nhân mà không có giao tiếp giữa họ. Điều này đúng với việc gặt lúa mì hoặc hái bông; nó thậm chí không đúng với lập trình hệ thống.

Ông không đề cập đến đào tạo như là một phần của vấn đề:

Gánh nặng thêm của truyền thông được tạo thành từ hai phần: đào tạo và giao tiếp. Mỗi công nhân phải được đào tạo về công nghệ, mục tiêu của nỗ lực, chiến lược tổng thể và kế hoạch làm việc. Đào tạo này không thể được phân vùng, vì vậy phần này của công việc thay đổi tuyến tính với số lượng công nhân.

... nhưng lưu ý rằng giao tiếp là yếu tố lớn hơn :

Vì việc xây dựng phần mềm vốn dĩ là một nỗ lực của hệ thống - một bài tập trong các mối quan hệ tương tác phức tạp - nỗ lực giao tiếp là rất lớn và nó nhanh chóng chi phối việc giảm thời gian nhiệm vụ cá nhân do phân vùng mang lại. Thêm nhiều người đàn ông kéo dài, không rút ngắn, lịch trình.

Cũng đáng lưu ý rằng Fred Brooks (tác giả) có nền tảng để biết anh ấy đang nói về điều gì. Hầu hết cuốn sách dựa trên kinh nghiệm của anh ấy khi quản lý dự án OS / 360 của IBM. Mặc dù nhiều thập kỷ của các đệ rao giảng tất cả các cách thức của "cải thiện" phương pháp quản lý, và một số thậm chí đến với tên mát mẻ (eXtreme, Agile, Scrum, vv) khi bạn nhận được xuống để nó, ít chất ¹ dường như đã thay đổi kể từ đó.

¹ Đối với định nghĩa về "bản chất", xem cùng tác giả của "Không Silver Bullet: Essence và tai nạn trong Công Nghệ Phần Mềm", bao gồm trong 20 ^ngày Anniversary Edition của The Mythical Man-Month .

Nó không chỉ đơn thuần là câu ngạn ngữ; nó có thể kiểm chứng được. Hãy xem Tháng huyền thoại của Brooks .

Dưới đây là một số suy nghĩ về vấn đề này ...

• Cần sử dụng các tài nguyên hiện tại để đưa các tài nguyên mới tăng tốc theo những gì đang diễn ra với dự án.
• Tài nguyên mới có thể không quen thuộc với cơ sở mã, do đó cần thêm thời gian để làm quen với mã.

bây giờ, việc thêm tài nguyên mới để kiểm tra có thể không phải là ý tưởng tồi ... nó có thể tăng tốc quá trình kiểm tra (nếu các trường hợp kiểm thử của bạn được viết tốt) và có sử dụng các công cụ kiểm tra cũng sẽ giúp ích.

Bởi vì lập trình không phải là dây chuyền sản xuất cơ bản. Bắt kịp tốc độ trên một dự án phần mềm cần có thời gian. Người mới cần đặt nhiều câu hỏi dẫn đến năng suất tiêu cực (tức là người mới học, người cũ dạy họ -> không có công việc thực tế nào được thực hiện).

Để đơn giản hóa nó, hãy tưởng tượng một dự án một người tương đối đơn giản, dự kiến ​​sẽ diễn ra trong 1 tuần: vào thứ năm, bạn nhận ra rằng nó sẽ không được hoàn thành đúng hạn, thay vào đó sẽ mất một lập trình viên hơn 6-7 ngày trong số 5. ​​Nếu bạn thêm một lập trình viên khác vào thời điểm đó, họ sẽ cần phải làm việc với lập trình viên1 trong ít nhất vài giờ hoặc một ngày hoặc lâu hơn, hỏi nhiều câu hỏi để tăng tốc, v.v. Bạn có thể sẽ không nhận được bất kỳ năng suất dương nào trong phần còn lại của tuần. Lập trình viên mới cũng có khả năng giới thiệu thêm một số lỗi (vì họ sẽ không biết mã hiện có cũng như lập trình viên1), do đó sẽ thổi bay chu kỳ thực hiện và thử nghiệm thêm một hoặc hai ngày nữa. Dự án sẽ dễ dàng kéo dài hai tuần làm việc đầy đủ thay vì ban đầu!

Fred Brooks đã viết toàn bộ cuốn sách "Tháng huyền thoại" trả lời câu hỏi này.

Đây là phiên bản nhanh-bẩn-bẩn:

1) Có giới hạn về số tiền bạn có thể chia một dự án thành các phần riêng biệt để gán cho nhiều lập trình viên hơn.

2) Tách một dự án ra cho nhiều người hơn sẽ tăng lượng giao tiếp cần thiết để phối hợp tất cả các phần của ứng dụng. Giao tiếp nhiều hơn = Công việc nhiều hơn.

3) Đối với mỗi người bạn thêm vào dự án, bạn thêm nhiều kênh truyền thông phải được điều hướng đến nhóm. Con số này tăng lên về mặt hình học và tăng số lượng giao tiếp phải xảy ra. Giao tiếp nhiều hơn = Công việc nhiều hơn.

4) Có "J-Curve" khi bạn thêm từng thành viên trong nhóm. Đó là, các nguồn lực sản xuất hiện tại phải dành thời gian để giúp những người mới tăng tốc mà họ có thể đã dành để làm việc trong dự án. Cuối cùng, bạn có thể tăng công suất, nhưng nó tạm thời làm chậm dự án. Càng về sau, dự án càng phải học, do đó hiệu quả càng rõ rệt.

Một yếu tố khác mà tôi chưa thấy đề cập đến là một số nhiệm vụ cần phải được thực hiện theo một thứ tự cụ thể. Bạn không thể thực hiện nhiệm vụ 4 cho đến khi nhiệm vụ 3 được thực hiện vì nó phụ thuộc vào 3. Việc thuê ai đó làm nhiệm vụ 4 không đồng thời giúp ai đó thực hiện nhiệm vụ 3. Thường thì khi kết thúc dự án , những nhiệm vụ cần những thứ khác hoàn thành trước là những nhiệm vụ còn lại.

Chúng cũng thường là một số nhiệm vụ phức tạp nhất cần thực hiện, những nhiệm vụ đòi hỏi sự hiểu biết tốt nhất về toàn bộ thiết kế để tránh phá vỡ những gì đã hoàn thành. Họ cũng thường yêu cầu kiến ​​thức lĩnh vực kinh doanh rộng lớn nhất. Tôi có thể sau khi làm việc trong dự án trong nhiều tháng có thể thực hiện nhiệm vụ trong một tuần hoặc ít hơn. Một người mới sẽ mất hơn một tuần để tăng tốc (và kéo tôi ra khỏi nhiệm vụ của mình để có thời gian tốt để trả lời câu hỏi) và có khả năng ngay cả khi cực kỳ lành nghề sẽ mất nhiều thời gian hơn để thực hiện nhiệm vụ. Không phải vì anh ta hoặc cô ta không đủ năng lực mà vì không quen thuộc với cấu trúc thực tế của dự án hoặc cơ sở dữ liệu phụ trợ.

Câu ngạn ngữ luôn có hiệu quả với tôi là bạn không thể có chín người phụ nữ để sinh con trong một tháng.

Tôi cũng đề xuất "Peopleware" của DeMarco và Lister.

Và "Hạn chót" của DeMarco trình bày điều này, và một số bệnh và quản lý dự án phần mềm khác theo cách nhẹ nhàng và rất dễ đọc.

Nó cũng đi sâu vào sự năng động của những người làm công việc dự án / nhóm và đi sâu vào một số chi tiết về việc NHƯ THẾ NÀO như giao tiếp và giới thiệu làm mất thời gian làm việc có sẵn của một nhóm.

Những cuốn sách này khá rẻ, tôi khuyên bạn nên lấy chúng (Amazon hoặc Nhà lưu trữ sách có chúng) và đọc. Các câu trả lời ngắn ở đây không thể thực sự công bằng cho câu hỏi được hỏi.

Bởi vì không ai dành thời gian để suy nghĩ kỹ, lên kế hoạch, thử nghiệm quy trình cho: tuyển dụng, đào tạo, phát triển và giám sát các lập trình viên chứ đừng nói đến việc thúc đẩy họ tăng tốc cho một dự án cụ thể.

Nếu bạn đang quản lý một nhóm các nhà phát triển, bạn nên có một số liên hệ ngay bây giờ của những người bạn muốn thuê nếu bạn có một cơ hội. Tham gia các nhóm phát triển.

Làm thế nào nhanh chóng bạn có thể có được một thiết lập máy phát triển hoàn toàn mới và sẵn sàng để đi?

Bạn đã bao giờ kiểm tra tài liệu dự án và thông số kỹ thuật của bạn bằng cách hiển thị chúng cho nhà phát triển trên một dự án khác chưa? Họ đã xem xét nó và xác định rằng họ có thể bắt đầu làm việc với dự án nếu cần thiết?

Làm thế nào để cập nhật là bất kỳ lịch trình dự án?

Tiết kiệm cho một ngày mưa bởi vì khi một dự án rơi phía sau nó giống như một cơn bão.

Ngoài vấn đề giao tiếp (mà tôi nghĩ rằng tất cả các câu trả lời khác đang nói đến), một người cũng có thể thêm vào một dự án để tạo ra lỗi, vì họ chưa biết rõ về mã.

Bất cứ khi nào tôi được thêm vào một dự án, tôi luôn cố gắng hết sức để không phá vỡ mọi thứ. Điều này có nghĩa là tôi chậm hơn nhiều trong việc sửa chữa mọi thứ lúc đầu.

Tôi muốn chỉ ra một cái gì đó hoàn toàn bị bỏ qua cho đến nay bởi các câu trả lời khác.

Vào thời điểm mọi người được thêm vào một dự án muộn, điển hình là rất nhiều lỗi đã xảy ra trong toàn tổ chức. Quản lý và khách hàng không hài lòng. Mọi người đã bị áp lực để có được với nó. Mọi thứ khá căng thẳng.

Bây giờ hãy tưởng tượng bạn đang ở trong đội đó. Rõ ràng không ai trong số này là lỗi của bạn. Lập kế hoạch (không ai trong số đó là của bạn) đã quá lạc quan. Tất cả các quyết định sai đã được thực hiện mà không hỏi ý kiến ​​bạn. Bạn đang cố gắng làm cho nó tốt nhất và đột nhiên một nhóm người mới đang bị cuốn vào. Thông điệp này truyền tải điều gì?

Những người trên lầu rõ ràng đã mất niềm tin vào bạn. Họ kêu gọi các chàng trai lớn bù đắp cho những gì bạn đã làm hỏng.

Bạn vẫn sẽ có động lực để làm cho điều này thành công? Hoặc ... bạn sẽ nản lòng hơn bao giờ hết và liệu bạn có muốn nhìn thấy toàn bộ sự việc không?

Hãy dành thời gian của bạn :-).