Tôi cần em bé này trong một tháng - gửi cho tôi chín phụ nữ!

Trong trường hợp nào - nếu có - việc thêm lập trình viên vào nhóm thực sự tăng tốc độ phát triển của một dự án đã trễ?

Các trường hợp chính xác rõ ràng là rất cụ thể cho dự án của bạn (ví dụ: nhóm phát triển, phong cách quản lý, quá trình trưởng thành, khó khăn của vấn đề, v.v.). Để phạm vi điều này tốt hơn một chút để chúng ta có thể nói về nó trong bất cứ điều gì ngoại trừ quét quá mức, tôi sẽ giới thiệu lại câu hỏi của bạn:

Trong trường hợp nào, nếu có, có thể thêm các thành viên nhóm vào dự án phát triển phần mềm đang bị trễ dẫn đến giảm ngày tàu thực tế với mức chất lượng tương đương nếu nhóm hiện tại được phép làm việc cho đến khi hoàn thành?

Có một số điều mà tôi nghĩ là cần thiết , nhưng không đủ, để điều này xảy ra (không theo thứ tự cụ thể):

• Các cá nhân được đề xuất để thêm vào dự án phải có:
  • Ít nhất là một sự hiểu biết hợp lý về lĩnh vực vấn đề của dự án
  • Thành thạo ngôn ngữ của dự án và các công nghệ cụ thể mà họ sẽ sử dụng cho các nhiệm vụ họ sẽ được giao
  • Sự thành thạo của họ phải / không / ít hơn nhiều hoặc lớn hơn nhiều so với thành viên yếu nhất hoặc mạnh nhất hiện có. Các thành viên yếu sẽ làm cạn kiệt nhân viên hiện tại của bạn với các vấn đề cấp ba trong khi một người mới quá mạnh sẽ làm gián đoạn nhóm với cách mọi thứ họ đã làm và đang làm là sai.
  • Có kỹ năng giao tiếp tốt
  • Có động lực cao (ví dụ: có thể làm việc độc lập mà không cần prodding)
• Các thành viên trong nhóm hiện có phải có:
  • Kỹ năng giao tiếp tuyệt vời
  • Kỹ năng quản lý thời gian tuyệt vời
• Trưởng / quản lý dự án phải có:
  • Ưu tiên tốt và khả năng phân bổ nguồn lực
  • Mức độ tôn trọng cao từ các thành viên trong nhóm hiện có
  • Kỹ năng giao tiếp tuyệt vời
• Dự án phải có:
  • Một đặc tả thiết kế phần mềm tốt, hoàn thành và được ghi lại
  • Tài liệu tốt về những điều đã được thực hiện
  • Một thiết kế mô-đun để cho phép các khối trách nhiệm rõ ràng được khắc ra
  • Có đủ các quy trình tự động để đảm bảo chất lượng cho mức độ lỗi cần thiết Chúng có thể bao gồm những thứ như: kiểm tra đơn vị, kiểm tra hồi quy, triển khai xây dựng tự động, v.v.)
  • Một hệ thống theo dõi lỗi / tính năng hiện đang được nhóm sử dụng và sử dụng (ví dụ: trac, SourceForge, FogBugz, v.v.).

Một trong những điều đầu tiên nên được thảo luận là liệu ngày tàu có thể bị trượt hay không, liệu các tính năng có thể bị cắt hay không và nếu một số kết hợp của cả hai sẽ cho phép bạn thỏa mãn việc phát hành với nhân viên hiện tại của mình. Nhiều lần, một số tính năng thực sự ăn cắp tài nguyên của nhóm sẽ không mang lại giá trị bằng với khoản đầu tư. Vì vậy, hãy ưu tiên cho dự án của bạn trước khi có bất cứ điều gì khác.

Nếu kết quả của đoạn trên không đủ, hãy truy cập danh sách trên. Nếu bạn bắt gặp phiếu trượt sớm, việc bổ sung đúng thành viên trong nhóm vào đúng thời điểm có thể tiết kiệm được bản phát hành. Thật không may, bạn càng đến gần ngày tàu dự kiến, càng có nhiều điều có thể sai khi thêm người. Tại một thời điểm, bạn sẽ vượt qua "điểm không trở lại" nơi không có số lượng thay đổi nào (ngoài việc vận chuyển chi nhánh phát triển hiện tại) có thể lưu bản phát hành của bạn.

Tôi có thể đi và về nhưng tôi nghĩ tôi đã đạt được những điểm chính. Ngoài dự án và về sự nghiệp, thành công trong tương lai của công ty, v.v., một trong những điều bạn chắc chắn nên làm là tìm ra lý do tại sao bạn đến trễ, nếu có bất cứ điều gì có thể được thực hiện cảnh báo bạn sớm hơn và những biện pháp bạn cần để thực hiện để ngăn chặn nó trong tương lai. Một dự án muộn thường xảy ra bởi vì bạn là:

• Đã trễ trước khi bạn bắt đầu (nhiều thứ hơn thời gian) và / hoặc
• trượt 1 giờ, 1 ngày tại thời điểm.

Mong rằng sẽ giúp!

Nó chỉ giúp nếu bạn có một dự án dựa trên tài nguyên.

Ví dụ, hãy xem xét điều này:

Bạn cần vẽ một poster lớn, nói 4 x 6 mét. Một tấm áp phích lớn, có lẽ bạn có thể đặt hai hoặc ba người trước nó và vẽ chúng song song. Tuy nhiên, đặt 20 người trước nó sẽ không hoạt động. Ngoài ra, bạn sẽ cần những người có kỹ năng, trừ khi bạn muốn có một poster nhảm nhí.

Tuy nhiên, nếu dự án của bạn là nhét phong bì bằng các chữ cái in sẵn (như You MIGHT đã giành chiến thắng! ) Thì bạn càng thêm nhiều người, nó sẽ càng nhanh hơn. Có một số chi phí lớn trong việc sắp xếp công việc, vì vậy bạn không thể nhận được lợi ích cho đến khi bạn có một người pr. phong bì, nhưng bạn có thể nhận được lợi ích từ nhiều hơn chỉ 2 hoặc 3 người.

Vì vậy, nếu dự án của bạn có thể dễ dàng được chia thành các phần nhỏ và nếu các thành viên trong nhóm có thể tăng tốc nhanh chóng (như ... ngay lập tức), thì việc thêm nhiều người sẽ giúp nó đi nhanh hơn, đến một điểm.

Đáng buồn thay, không có nhiều dự án như thế trong thế giới của chúng ta, đó là lý do tại sao lời khuyên của docgnome về cuốn sách Tháng huyền thoại là một lời khuyên thực sự tốt.

Có thể nếu áp dụng các điều kiện sau:

1. Các lập trình viên mới đã hiểu dự án và không cần bất kỳ thời gian tăng tốc nào.
2. Các lập trình viên mới đã thành thạo với môi trường phát triển.
3. Không có thời gian quản trị là cần thiết để thêm các nhà phát triển vào nhóm.
4. Hầu như không có giao tiếp được yêu cầu giữa các thành viên trong nhóm.

Tôi sẽ cho bạn biết lần đầu tiên tôi thấy tất cả những thứ này cùng một lúc.

Theo Tháng huyền thoại, lý do chính khiến việc thêm người vào một dự án muộn khiến cho sau này là chi phí liên lạc O (n ^ 2).

Tôi đã trải qua một ngoại lệ chính cho điều này: nếu chỉ có một người trong một dự án, thì hầu như luôn luôn phải chịu số phận. Thêm một cái thứ hai tăng tốc nó gần như mọi lúc. Đó là bởi vì giao tiếp không phải là chi phí trong trường hợp đó - đó là một cơ hội hữu ích để làm rõ suy nghĩ của bạn và ít mắc lỗi ngu ngốc hơn.

Ngoài ra, như bạn rõ ràng đã biết khi bạn đăng câu hỏi của mình, lời khuyên từ Tháng huyền thoại chỉ áp dụng cho các dự án muộn . Nếu dự án của bạn chưa bị trễ, thì việc thêm người sẽ không thực hiện được sau này. Giả sử bạn làm điều đó đúng, tất nhiên.

Nếu các lập trình viên hiện tại hoàn toàn không đủ năng lực, thì việc thêm các lập trình viên có năng lực có thể giúp ích.

Tôi có thể tưởng tượng một tình huống trong đó bạn có một hệ thống rất mô-đun và (các) lập trình viên hiện tại thậm chí đã không bắt đầu trên một mô-đun rất cô lập. Trong trường hợp đó, chỉ định phần đó của dự án cho một lập trình viên mới có thể giúp ích.

Về cơ bản các tài liệu tham khảo Tháng người đàn ông thần thoại là chính xác, ngoại trừ trong các trường hợp giả định như trường hợp tôi tạo ra. Ông Brooks đã thực hiện nghiên cứu vững chắc để chứng minh rằng sau một thời điểm nhất định, chi phí kết nối và kết nối mạng khi thêm lập trình viên mới vào dự án sẽ vượt xa bất kỳ lợi ích nào bạn có được từ năng suất của họ.

• Nếu những người mới tập trung vào thử nghiệm
• Nếu bạn có thể cô lập các tính năng độc lập không tạo ra các phụ thuộc mới
• Nếu bạn có thể trực giao một số khía cạnh của dự án (đặc biệt là các tác vụ không mã hóa như thiết kế / bố trí trực quan, điều chỉnh / lập chỉ mục cơ sở dữ liệu hoặc thiết lập máy chủ / cấu hình mạng) để một người có thể làm việc trong khi những người khác thực hiện với mã ứng dụng
• Nếu mọi người biết nhau, công nghệ và các yêu cầu kinh doanh và thiết kế, đủ để có thể làm mọi việc với kiến ​​thức khi họ sẽ giẫm lên chân nhau và làm thế nào để tránh làm điều đó (điều này, tất nhiên, khá khó để sắp xếp nếu không phải như vậy)

Chỉ khi bạn có ở giai đoạn cuối đó, một số nhiệm vụ độc lập (gần như 0% với các phần khác của dự án) chưa được xử lý bởi bất kỳ ai và bạn có thể đưa vào nhóm một người nào đó là chuyên gia trong miền đó. Việc bổ sung một thành viên trong nhóm phải giảm thiểu sự gián đoạn cho phần còn lại của đội.

Thay vì thêm các lập trình viên, người ta có thể nghĩ về việc thêm trợ giúp quản trị. Bất cứ điều gì sẽ loại bỏ phiền nhiễu, cải thiện sự tập trung hoặc cải thiện động lực có thể hữu ích. Điều này bao gồm cả hệ thống và quản trị, cũng như những thứ bình thường hơn như ăn trưa.

Rõ ràng mỗi dự án là khác nhau nhưng hầu hết các công việc phát triển có thể được đảm bảo để có một số lượng hợp tác nhất định giữa các nhà phát triển. Đây là trường hợp kinh nghiệm của tôi là tài nguyên mới thực sự có thể vô tình làm chậm những người mà họ đang dựa vào để tăng tốc và trong một số trường hợp, đây có thể là người chủ chốt của bạn (tình cờ thường là 'người chủ chốt' sẽ lấy thời gian để giáo dục một newb). Khi họ đạt được tốc độ, không có gì đảm bảo rằng công việc của họ sẽ phù hợp với 'quy tắc' hoặc 'văn hóa làm việc' được thiết lập với phần còn lại của nhóm. Vì vậy, một lần nữa, nó có thể làm hại nhiều hơn tốt. Vì vậy, bên cạnh đó, đây là những trường hợp có thể có lợi:

1) Tài nguyên mới có một nhiệm vụ chặt chẽ đòi hỏi tối thiểu tương tác với các nhà phát triển khác và một bộ kỹ năng đã được thể hiện. (ví dụ: chuyển mã hiện có sang một nền tảng mới, tái cấu trúc bên ngoài một mô-đun chết hiện đang bị khóa trong cơ sở mã hiện có).

2) Dự án được quản lý theo cách có thể chia sẻ thời gian của các thành viên nhóm cao cấp khác để hỗ trợ đưa newb tăng tốc và tư vấn cho họ trên đường đi để đảm bảo công việc của họ tương thích với những gì đã hoàn thành.

3) Các thành viên khác trong nhóm rất kiên nhẫn.

Tôi cho rằng việc thêm người vào cuối tác phẩm có thể tăng tốc mọi thứ nếu:

1. Công việc có thể được thực hiện song song.

2. Số tiền được tiết kiệm bởi các tài nguyên được thêm vào nhiều hơn số lượng thời gian bị mất do những người có kinh nghiệm với dự án giải thích những điều thiếu kinh nghiệm.

EDIT: Tôi quên đề cập, loại chuyện này không xảy ra quá thường xuyên. Thông thường nó là một công cụ khá đơn giản, như màn hình quản trị thực hiện CRUD đơn giản cho một bảng. Ngày nay, các loại công cụ này có thể được tự động tạo ra.

Hãy cẩn thận với các nhà quản lý ngân hàng về loại công việc này để xử lý mặc dù. Nghe có vẻ hay, nhưng thực tế thường không đủ để cắt bớt thời gian đáng kể của dự án.

• Các mô-đun độc lập chưa được bắt đầu
• Thiếu các công cụ phát triển mà họ có thể tích hợp (như trình quản lý bản dựng tự động)

Chủ yếu tôi đang nghĩ về những điều cho phép họ tránh xa cách mọi người đang phát triển. Tôi đồng ý với Tháng huyền thoại, nhưng tôi cũng nghĩ có những ngoại lệ đối với mọi thứ.

Tôi nghĩ rằng việc thêm người vào một nhóm có thể tăng tốc dự án hơn là thêm họ vào chính dự án.

Tôi thường gặp phải vấn đề có quá nhiều dự án đồng thời. Bất kỳ một trong những dự án đó có thể được hoàn thành nhanh hơn nếu tôi có thể tập trung vào dự án đó một mình. Bằng cách thêm các thành viên trong nhóm, tôi có thể chuyển đổi khỏi các dự án khác.

Tất nhiên, điều này giả định rằng bạn đã thuê các nhà phát triển có khả năng, tự động viên, những người có khả năng kế thừa các dự án lớn và học độc lập. :-)

Nếu tài nguyên bổ sung bổ sung cho nhóm hiện tại của bạn, nó có thể là lý tưởng. Ví dụ: nếu bạn chuẩn bị thiết lập phần cứng sản xuất của mình và xác minh rằng cơ sở dữ liệu thực sự được điều chỉnh thay vì chỉ trả về kết quả tốt (mà nhóm của bạn biết là chuyên gia tên miền) mượn thời gian từ một dba giỏi làm việc trong dự án tiếp theo để bạn có thể tăng tốc đội lên mà không cần nhiều chi phí đào tạo

Chỉ cần đặt. Việc so sánh thời gian còn lại và năng suất bạn sẽ nhận được từ một người nào đó ngoại trừ lượng thời gian cần thiết để tăng tốc và đạt năng suất và trừ đi thời gian đầu tư vào việc dạy họ bằng các tài nguyên hiện có. Các yếu tố chính (theo thứ tự quan trọng):

1. Làm thế nào tốt tài nguyên là chọn nó. Các nhà phát triển tốt nhất có thể đi đến một trang web mới và sửa lỗi hiệu quả gần như ngay lập tức với rất ít sự trợ giúp. Kỹ năng này rất hiếm nhưng có thể học được.
2. Sự phân biệt của các nhiệm vụ. Họ cần có khả năng làm việc trên các đối tượng và chức năng mà không vấp ngã các nhà phát triển hiện có và làm chậm chúng.
3. Sự phức tạp của dự án và tài liệu có sẵn. Nếu đó là một ứng dụng ASP.Net thực hành tốt nhất và các tình huống kinh doanh được ghi chép tốt, thì một nhà phát triển giỏi có thể bị mắc kẹt ngay lập tức. Yếu tố này nhiều hơn bất kỳ yếu tố nào sẽ quyết định thời gian mà các tài nguyên hiện tại sẽ phải đầu tư vào giảng dạy và do đó tác động tiêu cực ban đầu của các tài nguyên mới.
4. Lượng thời gian còn lại. Điều này thường được ước tính sai quá. Thường thì logic sẽ là chúng ta chỉ còn x tuần nữa và sẽ mất x + 1 tuần để giúp ai đó tăng tốc. Trong thực tế, dự án IS sẽ trượt và trên thực tế, còn 2 tuần nữa để phát triển và nhận được nhiều tài nguyên hơn sớm hơn là sau này sẽ giúp ích.

Trường hợp một nhóm đã được sử dụng để ghép lập trình, sau đó thêm nhà phát triển khác đã có kỹ năng ghép nối có thể không làm chậm dự án, đặc biệt nếu việc phát triển được tiến hành theo kiểu TDD.

Nhà phát triển mới sẽ dần dần làm việc hiệu quả hơn khi họ hiểu cơ sở mã nhiều hơn và mọi hiểu lầm sẽ được phát hiện rất sớm bởi cặp của họ hoặc bởi bộ thử nghiệm được chạy trước mỗi lần đăng ký (và lý tưởng nhất là phải kiểm tra trong ít nhất mười phút một lần).

Tuy nhiên, ảnh hưởng của các chi phí truyền thông phụ cần phải được tính đến. Điều quan trọng là không pha loãng kiến ​​thức hiện có của dự án quá nhiều.

Thêm nhà phát triển có ý nghĩa khi năng suất được đóng góp bởi các nhà phát triển bổ sung vượt quá năng suất bị mất để đào tạo và quản lý các nhà phát triển đó.