... 대규모 조직, 일반적으로 후원하는 기업 또는 회사의 조잭 내에는, 경쟁력 있는 비용과 일정 벤치마크를 충족하는 대규모 소프트웨어 시스템 (코드 2만 5천줄 이상)을 만들 수 있는 소규모 조직이 필요하다.
이 패턴은 조직의 적절한 규모 조정이 프로젝트의 건전성과 직원의 생산성에 얼마나 중요한지 보여준다.
✥ ✥ ✥
대규모 소프트웨어 프로젝트 (코드 2만 5천줄 이상)는 개발팀이 너무 크거나 너무 작을 때 시간과 예산 내에서 거의 배포되지(delivered) 못한다.
이 결론을 내린 두 가지 주장이 있다.
- 효과적으로 작업할 수 있는 소프트웨어 개발팀의 규모에는 제한이 있다. 팀은 개인이 할 수 있는 것보다 더 큰 문제를 다를 수 있다. (Beyer Holtzblatt 1998], p. 4).
- 프로젝트에 늦게 사람을 추가하는 것이 시간과 예산 내에서 프로젝트를 완료하는데 거의 도움이 되지 않는다.
1. 소프트웨어 개발팀이 너무 크면 수익이 크게 감소하는 지점에 도달할 수 있다. 조직의 규모가 결과물에 비선형적으로 영향을 미친다는 사실을 경험적으로 확인했다. 커뮤니케이션 오버헤드는 크기의 제곱으로 증가한다. 즉, 조직의 "마력(horsepower)"은 선형으로만 증가하는 반면, 조직은 크기의 제곱만큼 응집력이 떨어진다.
게다가, 조직이 너무 작으면 팀이 크리티컬 메스를 가지지 못하고 생산성이 저하될 것이다. 2만 5천줄보다 큰 프로젝트는 OrgPatterns/Solo Virtuoso로 거의 수행할 수 없으며, 지나치게 작은 조직은 부적절한 관성을 가지고 쉽게 불안정해질 수 있다.
그러나, 경험에 따르면 적절하게 선정되고 육성된 10명 정도의 소규모 팀은 31개월에 150만 라인 프로젝트, 15개월에 20만 라인 프로젝트, 또는 8개월에 6만 라인 프로젝트를 개발할 수 있는 적절한 크리티컬 메스를 제공할 수 있다.
조직을 작게 유지하면 모든 사람이 프로젝트 작동 방식에 대한 지식을 가질 수 있다. ("글로벌 지식"). 우리는 프로젝트에서 대부분의 역할이 약 6~7개의 다른 역할과의 상호작용을 처리할 수 있음을 경험적으로 발견했다. 10명으로 전체 글로벌 커뮤니케이션을 거의 관리할 수 있다 (그리고 완전 연결 네트워크가 필요하지 않을 것이다.)
잘 적응하는 프로젝트는, 적응하는 프로세스를 가지고 있고, 프로세스는 광범위한 동의와 혜택이 있을 때만 잘 적응한다. 동의와 이익을 위해 필요한 대화는 소규모 조직에만 발생할 수 있다.
TomDeMarco는 프로세스의 혜택을 받는 모든 사람이 프로세스 작업 및 프로세스 의사 결정에 참여해야 한다고 언급했다.
추가 연구에서는, 이 패턴과 ChristopherAlexander의 TheDistributionOfTowns 및 관련 패턴간의 관계를 평가할 수 있다. 여기서 우리는 사회 조직이 작아야 한다고 규정한다; 이것은 SubcultureBundary와 IdentifiableNeighborhood 를 반영한다. ChristopherAlexander는 광범위의 아키텍처적인 맥락 - 생태에 대한 지원과 큰 마을이 제공할 수 있는 규모의 경제와 조화를 이루면서도, 인간 본성이 외지인을 꺼리는 경향을 지원하는 - 을 강조했다. 여기에 구축되는 것과 같은 소규모 조직은 격리(isolation)되어 있는 경우가 거의 없고, 더 광범위한 지원 조직의 맥락에서 존재한다. 더 큰 조직과의 이러한 관계는 OrgPatterns/Patron Role를 불러일으킨다.
2. 프로젝트에 늦게 사람을 추가하는 것이 시간과 예산 내에서 프로젝트를 완료하는데 거의 도움이 되지 않는다.
한 관리자는 이렇게 썼다. "한 프로젝트에서, 나는 10명에서 시작하여 새로운 사람들과 함께 20명으로 성장하여 고객 계약을 체결했다. [나는] 새로운 사람들이 조직에 '흡수'되는 과정 때문에 3개월 늦게 마감했다."
많은 소프트웨어 개발 문화는 최대 약 10명의 기술 관리자 그룹을 지원한다. 더 많은 사람을 추가하면 그룹 분할이 발생하여 생산성이 크게 저하되고 다른 모든 사항은 동일하다. 우리는 또한 단일 팀이 하위 팀 모음보다 낫다는 것을 발견했다. 팀이 더 큰 팀의 책임보다 자신의 책임에 대해 걱정하는 하위 팀으로 더 빨리 분리될수록 기업 전체의 효율성이 떨어진다.
따라서:
기본적으로, 약 10명을 선택하여, 대규모 소프트웨어 시스템 개발에서 크리티컬 메스를 수립하고 게임 후반에 개인을 추가하거나 완료 날짜로부터 역방향 작업을 시도하지 않게 하라.
전문가의 정확한 수는 조금씩 다르다; 숫자 10에는 약간의 전통이 얽혀있지만, 6이나 7같은 숫자보다는 조금 더 보편적이다. 2는 너무 작고, 13은 너무 크다.
✥ ✥ ✥
대규모 프로젝트를 시작할 때 10명의 사람을 두는 것은 과도할 수 있지만, 나중에 더 많은 사람을 추가하는데 드는 비용과 오버헤드를 방지한다. 그러나 핵심 팀이 정체성을 확립하면, OrgPatterns/Phasing it In이나 OrgPatterns/Apprenticeship을 사용하여 우아하게 성장할 수 있다. 조직은 프로토타입을 만들고 던져버리는 것을 통해 초기에 지식을 생성(generate)할 수 있다. (OrgPatterns/Build Prototypes를 보라.) 초기 조직에 채용할 사람을 결정하려면, OrgPatterns/Domain Expertise in Roles 및 OrgPatterns/Architecture Team과 같은 패턴을 사용한다. OrgPatterns/Small Writing Team ([Bramble 2002, p. 31])은 유스케이스를 작성하는데 보통 2-3명을 제안한다; 다른 사람들은 다른 역할을 한다.
예리한 독자들은 이 패턴에 대해 생각하며 이렇게 말할 수도 있다, "대규모 프로젝트를 구성하는 것에 대해 이상한 생각을 가지고 있군요! 이것이 30-40명으로, 그리고 아마도 수만 라인의 코드를 생산하는 프로젝트에서는 동작할 수도 있겠습니다. 그러나 정말로 거대한 프로젝트에서는요?"
첫째로, 수십 명 이상의 실제 소프트웨어 개발팀이 매우 적다는 것을 이해하는 것이 중요하다; 더 큰 프로젝트는 거의 항상 하위 커뮤니티로 자체 구성된다 (OrgPatterns/Divide and Conquer). 그러나 가장 큰 프로젝트조차도 아이디어에서 시작하고, 아이디어는 개인 또는 소규모 그룹에서 시작된다. 이 패턴은 소수의 사람들이 가능한 한 다른 스텝들이 적극적으로 참여하기 전에 프로젝트에 착수해야 한다고 말한다. 물론 시드 팀의 수익 감소 지점을 예상하고 필요할 때 사용할 수 있고 준비할 수 있도록 충분히 일찍 사람들을 찾아야 한다. 그리고 물론 사람들은 점진적으로 참여해야 한다 (OrgPatterns/Phasing it In, OrgPatterns/Day Care 등을 보라.) 그러나, 작게 시작하고, 가능한 한 오랫동안 가능한 작게 유지하라. 대규모 시스템은 작동하는 작은 시스템에서 성장한다.
둘째로, OrgPatterns/Few Roles을 갖는 것이 필수적임을 기억하라. 10명이면 6개 정도의 역할을 정의하고 그 역할을 채우기가 쉽다. 그러나 초기 팀이 많으면 사람들은 처음에는 과제를 받을 때까지 무엇을 해야 할지에 대해 길을 잃을 것이다 (그리고 모든 사람에게 한 번에 과제를 줄 수도 없을 것이다) 그래서 그들은 할 일을 찾을 것이고, 그들 스스로 역할들을 발명해내는 경향이 있다. 이것은 데드비트(deadbeat. 게으름뱅이? 낙오자?) 역할을 만들기에 딱 좋다.
Joe Walters said that a project shouldn’t grow larger than the size of the auditorium of the building where the project is centered. Staff sizing complete, the project can SIZE THE SCHEDULE (4.1.2).
Joe Walters는 프로젝트가, 프로젝트가 중심이 되는 건물의 강당 크기보다 커지면 안된다고 말했다. 스탭 크기 조정이 완료되면, 프로젝트는 OrgPatterns/Size the Schedule을 할 수 있다.