대규모 프로그래밍 팀에서 일하는 것은 어떤가요?

저는 작은 프로그래밍 팀에서 일하는 것이 항상 운이 좋았습니다. 내가 일한 가장 많은 사람은 11 명의 프로그래머라고 생각합니다. 수백 명의 개발자와 함께 프로젝트를 진행하는 것은 어떻습니까? 수천? 확장 성 및 확장 성

편집 : 모든 답변 주셔서 감사합니다! 긍정적 인 것이 거의없는 것 같습니다.

• 초대형 코드베이스에서 작업 가능
• 더 나은 내부 경력 개발
• 욕설 관리에 대한 직원 보호 (대규모 + ve보다 작음 -ve가 더 많음)

대규모 팀에 다른 이점이 있습니까?

관료주의 규모가 정말 좋다고 생각합니다.

그 외에는 많지 않습니다. 대규모 프로젝트에는 다른 방법이 없기 때문에 규모가 큰 팀이 있습니다. 개발자마다 더 효율적이기 때문이 아닙니다. 비 효율성 (예 : 지식 이전 및 커뮤니케이션) 측면에서 두 번째 사람을 믹스에 추가하자마자 비용을 지불합니다.

내가 작업 한 가장 큰 프로젝트는 5 개의 다른 사이트에 70 명 정도의 개발자가있었습니다. 취리히에서 런던까지의 네트워크 링크를 통해 빌드가 45 분 이상 걸렸고 앱을 시작하는 데 또 45 분이 걸렸기 때문에 한 줄만 변경해도 하루가 조금 걸렸습니다. 체크인은 파일 당 약 5 분이 걸렸습니다. 농담이 아냐. 런던 개발자들은 아주 짧은 시간 안에 이것을 할 수있었습니다.

어쨌든, 당신이 찾는 경향이있는 것은 대규모 프로젝트에는 그다지 많은 팀원이 없다는 것입니다. 그것은 느슨하게 제휴 된 미니 프로젝트 모음과 같습니다. 한때 Microsoft 개발이 프로젝트를 Microsoft Office와 같은 대규모 프로젝트의 경우에도 5-7 명의 개발자 팀으로 분류하는 경향이 있음을 읽었습니다.

차이점은 소규모 기업과 대기업의 차이점이기도합니다. 대기업은 프로세스가 많고 규칙이 많으며 유연성이 떨어지는 경향이 있습니다. 그러나 이것이 결코 보장되는 것은 아닙니다.

그래도 경력 개발에 도움이 될 수 있습니다. 소규모 회사에서는 승진을하기 전에 누군가 떠나거나 죽어야합니다 (또는 팀이 확장되고 위로 올라갈 수 있도록 회사가 성장하고 있어야합니다). 반면 대규모 개발 부서에서는 팀간에 이동할 수 있습니다.

또한 당신은 때때로 자신을 연결하고 배우는 정말 똑똑한 사람들을 찾을 수 있습니다. 소기업에서 너무 고립되고 자립하는 것은 소위와 같은 다소 "이상한"프로그래머에게 도움이 될 수 있습니다.

의사 소통은 팀의 규모가 커짐에 따라 저하되기 시작한 가장 큰 것으로 밝혀졌습니다. 의사 소통을하기가 더 어려워지고 모든 사람이 같은 페이지에 있는지 확인하기가 더 어려워집니다. 저는 약 75 명의 개발자로 구성된 팀에서 간접적으로 일하고 공통 코드 기반을 사용하지만 75 개 중 다수는 개별 "활동"을 위해 더 작은 그룹으로 나뉩니다. 우리에게 커뮤니케이션은 완전히 악몽 일뿐입니다.

대부분의 환경에서 8-12 명의 추가 관리 구성원이 참여한 후 대부분의 환경에서 더 큰 그룹의 관리는 더 어렵습니다. 슬프게도 이는 일반적으로 개별 서브 세트가 그룹 내에서 지식을 유지하려고 노력하십시오.

무기 시스템 용 소프트웨어를 만들었을 때 우리는 대규모 소프트웨어 개발자 팀이있었습니다. 어떤 사람도 요구 사항을 머리로 감쌀 수 없으므로 (일부는 분류 됨) 팀과 팀이 서로 상호 작용하는 방식에 관한 것입니다.

1. 야간 빌드 프로세스 인 구성 관리는 매우 중요했습니다. 당시에는 매일 밤 세계를 다시 컴파일하기 위해 대규모 분산 컴퓨팅 클러스터가 필요했습니다.

2. 작업 승인과 마스터 전체 프로젝트 일정의 올바른 광고 항목에 시간을 청구하는 것은 목에 큰 고통이었습니다. 0.1 시간까지 증분.

그러나 가장 큰 거래는 변경 알림이었습니다. 특히 인터페이스 변경.

이것은 매우 중요했고,이 미친 2 계층 프로세스를 발명했습니다. 대부분의 노력은 인터페이스 변경 알림 요청 (알림 자체가 아니라 알림 요청)이 데이터베이스 및 보고서를 포함한 정교한 지원 소프트웨어를 갖도록하는 데있었습니다.

요청이 승인되면 실제 통지는 아무 말없이 진행되었습니다. 이는 실제로 단일 계층 프로세스였으며 요청이 효과적으로 통지되었음을 의미합니다. 그러나 폭포 개발을 할 때 개발자가 나타나기 전에 모든 것이 오랫동안 생각되어야합니다.

많은 사람들이 동시에 일하면서 구성 제어 보드가있었습니다. 모든 다양한 팀 관리자와 함께 일하는 사람들 그룹은 단순히 변화를 조정하는 것이 었습니다.

저의 첫 번째 "실제"프로그래밍 작업은 다른 항공 군과 협력하여 국제 항공 교통 관제 시스템을 개발하는 것이 었습니다. 그것은 매우 성공적인 노력이었으며 우리는 역량 성숙도 모델 레벨 5 환경으로 간주되었습니다. 그 이후로 저는 중소 규모의 상점에있었습니다. 그렇다면 어느 곳이 가장 좋은가요? 개인적으로 나는 매일 큰 가게보다 작은 가게를 가져갈 것입니다. 어떤 사람들은 레벨 5를 성배로 생각할 수도 있지만, 질식하고있었습니다. 모든 것이 문서화되고, 승인되고, 서명 된 것이어야합니다. 잘못 이해하지 마십시오. 특히 항공 교통 관제만큼 중요한 시스템의 경우 그 가치를 분명히 알지만, 문제는 어떻게 지출하고 싶습니까? 일? 꿈을 꾸고 실현할 수있는 자유를 원하십니까? 또는 요구 사항을 작성 하시겠습니까? 아마도 ATC 시스템으로 더 오래 머물렀다면 디자인뿐만 아니라 개발할 수있는 수준까지 올랐을 지 모르지만 X 년, Y 승인 횟수, Z 프로모션 횟수가 모두 규정되어 있습니다. 편차의 가능성이 없습니다. 질식했다.

마지막으로, 일반적으로 소기업에서는 숨길 수 없기 때문에 개발자의 품질이 훨씬 높다는 것을 알게되었습니다. 매우 큰 회사에서는 평범한 것이 어렵지 않지만 작은 회사에서는 고통스럽게 분명해지며 종종 오래 가지 않습니다.

나는 적어도 수백 명의 개발자와 함께 조직에서 (간결하게) 일했습니다. 그러나 물론 (?), 조직은 내부적으로 분할되어 있기 때문에 단일 직원으로서 다른 모든 직원과 직접 연락 할 수 없으므로 따라하기가 매우 어렵습니다.

특정 장소에서 소프트웨어는 구성 요소로 분할되었으며 팀은 구성 요소를 중심으로 구성되었습니다. 일부 팀은 단일 (대형) 구성 요소 만 사용하는 반면, 많은 팀은 여러 개의 작은 구성 요소를 담당합니다.

물론 이것은 매우 큰 코드 기반으로 작업하는 것이하는 모든 것을 의미합니다. 구성 관리, 구축, 통합 등과 같은 작업은 전문화 된 전담 부서에서 수행하는 중요하고 큰 작업이됩니다. 모든 개발자 부서의 결과물을 수집하고 정기적으로 (일주일에 한 번 일한 경우) 실제로 작동 한 하나의 응집력있는 전체로 통합합니다.

나는 큰 팀을 위해 일한 적이 없다 프로그래머 조직의 규모가 커지면 일반적으로 더 많은 규칙이 적용됩니다. 이것이 항상 나쁜 것은 아닙니다! 모든 사람의 삶을 어렵게 만드는 규칙 외에도 직원을 보호하고 올바른 프로세스를 보장하는 규칙이 더 있습니다.

소규모 조직의 관리자가 엔터프라이즈 HR 부서에서 즉시 해지 한 사항을 피하는 것을 보았습니다.

큰 프로젝트에서 주목 한 한 가지는 사무실 정치입니다. 프로젝트가 클수록 정치가 더 지배적입니다.

학교 밖에서의 첫 프로젝트는 몇 백 명의 개발자였습니다. 학교에서 신선하고 건방진 개발자로서 나는 그럴 준비가 되지 않았습니다 . (그리고 유일한 것은 내 hiney을 저장하는 유일한 것은 지금까지 정말 당신을 보호는) 내가 만든 친구의 양이었다.

그것이 내가 배운 가장 큰 교훈입니다. 모든 사람 과 친구를 사귀십시오 . 바보들도 특히, 일을 잠시 중단하고 이전에 이야기 한 적이없는 사람과 대화를 나눌 수 있다면 그렇게하십시오.

나는 한 해에 500 명 이상의 사람들로 구성된 팀에서 일했으며, 그 중 약 200 명은 개발자였습니다. 우리는 몇 가지 다른 SOA 솔루션을 통합하여 EOA를 제공하고있었습니다.

실제로 30-50 개의 팀이 있으며 각 팀에는 다양한 수의 프로그래머 (팀의 3 명)가 있으며 각 팀은 전체 결과물의 다른 측면에 대한 책임이 있습니다.

내가 작업 한 가장 큰 팀은 약 15 명이었습니다 (이는 다른 회사에서 3 ~ 4 개월 동안 만 진행했습니다). 나는 팀의 기술 책임자 였고 오전 7시에 일을 시작했습니다. 다른 사람들이 들어 오기까지 2 시간이 걸렸을 때, 저는 제 자신의 업무를 완수 할 수있는 유일한 방법이었습니다.

8 명 또는 10 명 이상의 개발자가있는 팀에서 일하고 싶지 않습니다. 15 명은 단일 팀에 비해 너무 많았습니다. 좋은 편안한 크기 IMHO