Quá nhiều tiền bối trong một đội? [đóng cửa]

Có thể có quá nhiều lập trình viên cao cấp trong một đội hóa ra lại là một điều xấu?

Có thể nói, 4-5 lập trình viên cao cấp trong một nhóm 6-7 người. Số / tỷ lệ tối ưu trong các loại tình huống là gì?

Điều này có thể dẫn đến quá nhiều triết lý và tranh luận về ý tưởng?

Có ai có kinh nghiệm như vậy, có thể chia sẻ nó với tôi không?

Nếu tôi có thể chọn tôi sẽ có 6-7 người cao niên trong một nhóm (giả sử dự án cần rất nhiều).

Lần duy nhất tôi có thể thấy đây là một vấn đề là nếu người cao niên chỉ cao cấp trong nhận thức bản thân và không làm việc đạo đức.

Không có gì tốt hơn là làm việc với một nhóm người đánh giá cao rằng mọi phần phát triển phần mềm đều quan trọng - tài liệu, kế hoạch, mã, cà phê, tất cả đều quan trọng và cần các nhà phát triển trưởng thành (thực sự cao cấp) phải "ở trên không có gì "và hoàn thành công việc đúng cách

EDIT : Nhiều câu trả lời khác đã nói rằng quá nhiều nhà lãnh đạo là một vấn đề - nhưng tại sao có một nhận thức rằng một cấp cao phải lãnh đạo? Một cấp cao nên đủ trưởng thành để chọn một nhà lãnh đạo và làm theo. Đây là dự án quan trọng - chọn / nhận một vai trò và đá nó ngớ ngẩn!

Vấn đề lớn nhất tôi thấy khi tải lên một nhóm với các lập trình viên cao cấp là nó có thể làm suy yếu các nhóm khác. Nếu bạn có các nhà phát triển cơ sở trong các nhóm khác cần tư vấn và hướng dẫn, thì bạn có thể cần phải thay đổi mọi người xung quanh.

Điều này có thể dẫn đến quá nhiều triết lý và tranh luận về ý tưởng?

Chắc chắn nó có thể , nhưng họ cần được trưởng thành, đủ để biết những gì khác biệt quan trọng và những gì những người chỉ cần không. Nếu bạn đã chỉ định một người lãnh đạo nhóm được kính trọng, những loại lập luận triết học này nên được giữ ở mức tối thiểu với ít nỗ lực.

Có thể có quá nhiều lập trình viên cao cấp trong một đội hóa ra lại là một điều xấu?

Chắc chắn rồi.

Tôi là một người ủng hộ lớn cho mô hình nhóm phẫu thuật của Fred Brooks .

Và như đã nói, nếu những người cao niên trong nhóm phát triển không biết ai là "bác sĩ phẫu thuật chính", thì họ sẽ đụng độ với các quyết định kiến ​​trúc quan trọng và sẽ kéo theo những hướng khác nhau đến sự bất lợi của đội.

Tái bút: Một nhóm phát triển cần một "bác sĩ phẫu thuật trưởng" tương tự như nhu cầu của một dàn nhạc. Trong cả hai trường hợp, bạn có thể sẽ có nhiều cựu chiến binh; nhưng bạn sẽ có một mớ hỗn độn mà không có ai chịu trách nhiệm.

Nó phụ thuộc vào cách phân phối responsibilites. Nếu TẤT CẢ các Dev được cho là có thiết kế wrt trách nhiệm như nhau, xem xét mã, v.v ... thì nó có thể trở thành một vấn đề. Nếu họ được giao những trách nhiệm khác nhau để họ có thể làm việc mà không phải tranh giành quyền kiểm soát đối với các lĩnh vực của nhau, thì đó không phải là vấn đề - ví dụ, một Senior Dev chịu trách nhiệm chính về thiết kế dự án, một người khác chịu trách nhiệm chính thiết lập và duy trì kho lưu trữ nguồn, một người khác chịu trách nhiệm kiểm tra đơn vị, v.v ...

Có thể có quá nhiều lập trình viên cao cấp trong một đội hóa ra lại là một điều xấu?

Không cần thiết. Tôi đã làm việc trong các nhóm nhỏ các nhà phát triển cao cấp có năng suất cao. Mức độ diễn ngôn rất cao, và không có rancor.

Với TDD, có rất ít các cam kết lớn đối với kiến ​​trúc phần mềm, do đó, không cần phải tranh luận về chúng. Các quyết định thiết kế có thể được giải quyết bằng cách đơn giản thực hiện cả hai cách tiếp cận và xem cái nào phù hợp nhất. Vì các nhà phát triển rất nhanh, chi phí cho các thử nghiệm này rất thấp.

Vâng, có thể có vấn đề về việc có quá nhiều đầu bếp trong bếp cho một phép ẩn dụ có thể áp dụng. Nó cũng có thể khá tốn kém nếu tất cả họ đều mong đợi mức lương cao. Lưu ý rằng đây chỉ là xác minh sự tồn tại của một trường hợp xấu và không nói gì về xác suất của nó.

Tối ưu phụ thuộc vào một số biến mà bạn không tiết lộ. Số liệu nào bạn muốn sử dụng nhận ra rằng có một cơ hội tốt để chơi game hệ thống ở đây. Tương tự, những hạn chế nào bạn có trong thế giới của mình có thể làm cho nó khác với những gì Google hoặc Microsoft có thể có tương phản.

Quá nhiều nhà phát triển cao cấp có thể gặp phải vấn đề không có quy ước hoặc quá nhiều quy ước tôi nghĩ. Trong khi một số nhà phát triển cao cấp có thể giỏi thích nghi, nếu không ai trong số họ có khả năng giới thiệu một quy ước, một nhóm sẽ bắt đầu từ đâu? Ngược lại, có thể có một số nhà phát triển cấp cao là những người hâm mộ khó tính của một số công ước có thể yêu cầu một số giải quyết xung đột để giải quyết.

Tôi nghĩ rằng nó phụ thuộc vào tính cách của người cao niên. Nếu họ kiêu ngạo và hay cãi, thì đó có thể là một điều xấu. Nhưng nếu tất cả họ đều tôn trọng, cởi mở với các quan điểm khác và sẵn sàng học hỏi lẫn nhau, thì bạn có một đội ngũ tuyệt vời.

Tôi hiện đang làm việc trong một nhóm 8 người, trong đó 5 hoặc 6 người cao cấp và nó hoạt động rất tốt cho chúng tôi. Chúng tôi rất hợp nhau, học hỏi lẫn nhau và đó là một môi trường cố vấn tuyệt vời cho những người mới hơn chúng tôi có.

Tôi đã làm việc trong một nhóm có 1 nhà phát triển chính, 4 nhà phát triển cao cấp và 1 nhà phát triển trung bình. Và vì lý do một thành viên "cao cấp" trong nhóm không phải là một người thực sự trưởng thành (dù là nhà phát triển giỏi), hóa ra đó là một cơn ác mộng. Anh ta cố gắng chứng minh tất cả thời gian (ngầm hoặc rõ ràng) rằng các thành viên khác trong nhóm không đủ thâm niên. Ngoài ra, anh ta đã không hiểu được các nguyên tắc cơ bản về phát triển phần mềm và các chi tiết cụ thể của sản phẩm của chúng tôi, và do đó, đã cố gắng kiêu ngạo và bướng bỉnh để chứng minh rằng mình đúng. Kết quả là, nó ảnh hưởng nghiêm trọng đến hiệu quả của đội. Điều đáng buồn là nó thậm chí không có quá nhiều tranh luận về ý tưởng / giải pháp - đó là tranh luận về không có gì . Ví dụ:

• người đã phá vỡ công trình (phần lớn thời gian là màu xanh lá cây và về mặt kỹ thuật, không bị hỏng. Đó là giao diện người dùng không hoạt động thường xuyên do các giải pháp kiến ​​trúc kém)
• tại sao có hồi quy (các mô-đun không được bao gồm trong các bài kiểm tra đơn vị mà chúng tôi không có quyền truy cập để đóng góp)
• tranh cãi về giải pháp kiến ​​trúc trong mô-đun, đó là trách nhiệm của người khác mà không biết gì về các yêu cầu và chi tiết cụ thể của mô-đun.
• ...

Nhưng tôi thừa nhận nó là một ngoại lệ. Tôi muốn tin rằng người cao niên cư xử đúng mực hầu hết thời gian :)