Làm việc trong một nhóm lập trình lớn là gì?

Tôi luôn cảm thấy may mắn khi được làm việc trong một nhóm lập trình nhỏ. Tôi nghĩ rằng nhiều nhất tôi đã làm việc với là 11 lập trình viên. Nó giống như làm việc trên một dự án với hàng trăm nhà phát triển như thế nào? Hàng ngàn? Quy mô và những gì không?

EDIT: Cảm ơn tất cả các câu trả lời! Dường như có rất ít mặt tích cực:

• có thể làm việc trên các cơ sở mã lớn
• phát triển sự nghiệp nội bộ tốt hơn
• bảo vệ nhân viên chống lại quản lý lạm dụng (điều này nhiều hơn nhỏ hơn + đã lớn)

Có bất kỳ lợi ích khác cho các đội lớn?

Tôi thấy quy mô quan liêu thực sự tốt.

Khác hơn thế, không phải là rất nhiều. Các dự án lớn có các nhóm lớn vì không có cách nào khác, không phải vì nó hiệu quả hơn (theo nhà phát triển). Bạn phải trả một khoản chi phí ngay khi bạn thêm người thứ hai vào hỗn hợp về mặt không hiệu quả (tức là chuyển giao kiến ​​thức và giao tiếp).

Dự án lớn nhất mà tôi đã làm việc có khoảng 70 develoeprs trên 5 trang web khác nhau. Ngay cả một thay đổi một dòng cũng mất tối thiểu một ngày mặc dù điều đó một phần là do việc xây dựng mất hơn 45 phút qua liên kết mạng từ Zurich đến London và bắt đầu ứng dụng mất thêm 45 phút. Đăng ký mất khoảng 5 phút cho mỗi tệp. Tôi không đùa. Các nhà phát triển London có thể làm điều này trong một phần nhỏ thời gian.

Dù sao, những gì bạn có xu hướng tìm thấy là trong các dự án lớn, bạn sẽ có một nhóm các thành viên trong nhóm mà bạn không tương tác với tất cả. Nó giống như một bộ sưu tập các dự án nhỏ liên kết lỏng lẻo. Tôi đã từng đọc rằng sự phát triển của Microsoft có xu hướng chia nhỏ các dự án thành các nhóm gồm 5-7 nhà phát triển, ngay cả đối với các dự án lớn như Microsoft Office.

Một phần của sự khác biệt cũng là sự khác biệt giữa các công ty nhỏ và lớn: những công ty lớn hơn có xu hướng có nhiều quy trình hơn, nhiều quy tắc hơn, kém linh hoạt hơn, v.v. Nhưng điều đó không có nghĩa là được đảm bảo.

Nó có thể tốt cho sự phát triển nghề nghiệp mặc dù. Trong một công ty nhỏ, ai đó phải rời đi hoặc chết trước khi bạn có thể được thăng chức (hoặc công ty phải phát triển để nhóm mở rộng và bạn tiến lên) trong khi ở các bộ phận phát triển lớn hơn, bạn có thể di chuyển giữa các nhóm, v.v.

Ngoài ra, đôi khi bạn có thể tìm thấy một số người thực sự thông minh để gắn kết và học hỏi. Trong các công ty nhỏ bị cô lập và tự chủ có thể có lợi cho các lập trình viên hơi "lạ", giống như một ẩn sĩ.

Giao tiếp là những gì tôi thấy là điều lớn nhất bắt đầu xuống cấp khi quy mô của đội phát triển. Việc truyền thông ra ngoài trở nên khó khăn hơn và khó hơn để đảm bảo rằng mọi người vẫn ở trên cùng một trang. Tôi làm việc gián tiếp trên một nhóm gồm khoảng 75 nhà phát triển, chúng tôi sử dụng một cơ sở mã chung, nhưng nhiều trong số 75 người chia thành các nhóm nhỏ hơn cho các "hoạt động" riêng lẻ. Đối với chúng tôi, giao tiếp chỉ là một cơn ác mộng hoàn toàn.

Quản lý các nhóm lớn hơn cũng khó hơn, vì trong hầu hết các môi trường sau 8-12 người, các thành viên quản lý bổ sung tham gia, thật đáng buồn, điều này chỉ phóng đại vấn đề giao tiếp vì nó thường tạo ra một môi trường kiểu "silo" nơi các tập hợp con riêng lẻ bắt đầu thoát khỏi nhóm lớn và cố gắng giữ kiến ​​thức trong nhóm của họ.

Quay lại khi tôi làm phần mềm cho các hệ thống vũ khí, chúng tôi có các nhóm phát triển phần mềm LỚN. Vì không ai có thể quấn đầu xung quanh các yêu cầu (một số trong số đó đã được phân loại), tất cả là về các đội và cách các đội tương tác với nhau.

1. Quản lý cấu hình - quá trình xây dựng hàng đêm - là một vấn đề rất lớn. Trong những ngày đó, phải mất một cụm máy tính phân tán lớn để biên dịch lại thế giới mỗi đêm.

2. Ủy quyền công việc - và tính thời gian của bạn vào chi tiết đơn hàng chính xác trong lịch trình tổng thể của dự án - là một nỗi đau lớn ở cổ. Xuống đến 0,1 giờ. gia tăng.

Nhưng thỏa thuận lớn nhất là thông báo thay đổi. Đặc biệt thay đổi giao diện.

Điều này rất quan trọng, họ đã phát minh ra quy trình hai lớp điên rồ này. Hầu hết các nỗ lực đã đảm bảo rằng Yêu cầu thông báo thay đổi giao diện (không phải chính thông báo, mà là yêu cầu thông báo) có phần mềm hỗ trợ phức tạp với cơ sở dữ liệu và báo cáo và không.

Sau khi yêu cầu được chấp thuận, thông báo thực tế ít nhiều sẽ không được nói. Có nghĩa là nó thực sự là một quá trình một lớp và yêu cầu có hiệu quả là thông báo. Nhưng khi bạn đang thực hiện phát triển thác nước, mọi thứ phải được suy nghĩ rất lâu trước khi bất kỳ nhà phát triển nào xuất hiện.

Với rất nhiều người làm việc song song, đã có Bảng điều khiển cấu hình. Tất cả các nhà quản lý nhóm khác nhau, cộng với nhóm người làm việc chỉ đơn giản là phối hợp các thay đổi.

Công việc lập trình "thực sự" đầu tiên của tôi là làm việc với một đội quân khác để phát triển hệ thống kiểm soát không lưu quốc tế. Đó là một nỗ lực rất thành công và chúng tôi được coi là môi trường Cấp độ Mô hình trưởng thành 5. Kể từ đó, tôi đã ở trong các cửa hàng vừa và nhỏ. Vì vậy, đó là nơi tốt nhất để được? Cá nhân tôi sẽ có một cửa hàng nhỏ hơn một cửa hàng lớn mỗi ngày. Trong khi một số người có thể coi Cấp 5 là Chén Thánh, đối với tôi, nó thật ngột ngạt. Mọi thứ phải được ghi lại, phê duyệt, ký tắt, v.v. Đừng hiểu sai ý tôi, tôi chắc chắn thấy giá trị của nó, đặc biệt đối với các hệ thống quan trọng như kiểm soát không lưu, nhưng câu hỏi là bạn muốn chi tiêu như thế nào ngày? Bạn có muốn tự do có thể mơ mọi thứ và sau đó thực hiện chúng, hoặc bạn muốn viết theo yêu cầu? Có lẽ nếu tôi ở lại lâu hơn với hệ thống ATC, tôi có thể đã tăng đến mức có thể thiết kế cũng như phát triển, nhưng thậm chí điều đó đòi hỏi số năm X, số lần phê duyệt Y, số lần khuyến mãi Z - tất cả đều được quy định tốt không có cơ hội sai lệch. Thật ngột ngạt.

Một điều cuối cùng, nói chung tôi thấy chất lượng của các nhà phát triển cao hơn nhiều ở các công ty nhỏ hơn đơn giản chỉ vì họ không thể che giấu. Không khó để trở nên tầm thường trong một công ty rất lớn, nhưng nó trở nên rõ ràng một cách đau đớn trong một công ty nhỏ và họ thường không tồn tại lâu.

Tôi đã làm việc (một thời gian ngắn) trong một tổ chức có ít nhất hàng trăm nhà phát triển. Nhưng tất nhiên (?), Tổ chức được phân vùng nội bộ để bạn với tư cách là một nhân viên không tiếp xúc trực tiếp với tất cả những người khác, điều đó sẽ rất khó theo kịp.

Tại nơi cụ thể đó, phần mềm được chia thành các thành phần, với các nhóm được hình thành xung quanh các thành phần. Một số nhóm sẽ chỉ làm việc với một thành phần (lớn), trong khi nhiều nhóm có trách nhiệm đối với một loạt các thành phần (nhỏ hơn).

Tất nhiên điều này ngụ ý mọi thứ hoạt động với một cơ sở mã rất lớn làm; những thứ như quản lý cấu hình, xây dựng, tích hợp, v.v ... trở nên quan trọng, lớn lao, những thứ lần lượt được thực hiện bởi các bộ phận chuyên trách. Và bạn sợ họ, vì có thể thu thập đầu ra của tất cả các bộ phận nhà phát triển và thường xuyên (mỗi tuần một lần, nơi tôi làm việc) tích hợp tất cả lại với nhau thành một tổng thể thực sự hiệu quả.

Tôi chưa bao giờ làm việc cho một nhóm lập trình viên lớn , nhưng kết quả của một tổ chức tăng quy mô thường là nhiều quy tắc hơn. Điều này không nhất thiết luôn luôn là một điều xấu! Ngoài các quy tắc khiến cuộc sống của mọi người trở nên khó khăn, còn có nhiều quy tắc khác để bảo vệ nhân viên và đảm bảo quy trình tốt.

Tôi đã thấy các nhà quản lý trong các tổ chức nhỏ thoát khỏi những điều mà ngay lập tức họ sẽ bị chấm dứt bởi một bộ phận nhân sự doanh nghiệp.

Một điểm khác biệt tôi nhận thấy với các dự án lớn là chính trị văn phòng. Các dự án càng lớn, chính trị càng chiếm ưu thế.

Dự án đầu tiên của tôi ra khỏi trường là một vài trăm nhà phát triển. Là một nhà phát triển tự mãn và mới mẻ từ trường, tôi thực sự chưa sẵn sàng cho điều đó. Điều duy nhất mà lưu hiney của tôi (và đó là điều duy nhất mà sẽ không bao giờ thực sự bảo vệ bạn) là số lượng bạn bè tôi đã thực hiện.

Đó là bài học lớn nhất tôi học được từ đó. Cố gắng kết bạn với mọi người . Ngay cả những kẻ ngốc. Đặc biệt, nếu bạn có cơ hội dừng công việc trong một phút và nói chuyện với ai đó mà bạn chưa từng nói chuyện trước đây, hãy làm điều đó.

Tôi đã từng dành một năm làm việc trong một nhóm với hơn 500 người trên đó, khoảng 200 trong số đó là các nhà phát triển. Chúng tôi đã cung cấp một EOA, tích hợp một số giải pháp SOA khác nhau.

Trong thực tế, có khoảng 30 đến 50 đội, mỗi đội có số lượng lập trình viên khác nhau (3 người trong nhóm của chúng tôi), mỗi nhóm chịu trách nhiệm về một khía cạnh khác nhau của tổng thể phân phối.

Đội ngũ lớn nhất tôi từng làm việc là khoảng 15 người (điều này chỉ trong 3 hoặc 4 tháng, trong một công ty khác biệt). Tôi là trưởng nhóm kỹ thuật, và bắt đầu làm việc lúc 7 giờ sáng, tôi nhận được 2 tiếng đồng hồ trước khi mọi người vào, đó là cách duy nhất tôi có thể hoàn thành bất kỳ nhiệm vụ nào của mình.

Tôi không muốn làm việc trong một nhóm có hơn 8 hoặc 10 nhà phát triển, 15 người là quá nhiều cho một nhóm (nhóm có thể dễ dàng bị tách thành hai, không phải là cuộc gọi của tôi), 3 hoặc 4 dev là một kích thước thoải mái đẹp IMHO