Diff for "OrgPatterns/Size the Organization"

... 대규모 조직, 일반적으로 후원하는 기업 또는 회사의 조잭 내에는, 경쟁력 있는 비용과 일정 벤치마크를 충족하는 대규모 소프트웨어 시스템 (코드 2만 5천줄 이상)을 만들 수 있는 소규모 조직이 필요하다.

이 패턴은 조직의 적절한 규모 조정이 프로젝트의 건전성과 직원의 생산성에 얼마나 중요한지 보여준다.

✥ ✥ ✥

대규모 소프트웨어 프로젝트 (코드 2만 5천줄 이상)는 개발팀이 너무 크거나 너무 작을 때 시간과 예산 내에서 거의 배포되지(delivered) 못한다.

이 결론을 내린 두 가지 주장이 있다.

1. 효과적으로 작업할 수 있는 소프트웨어 개발팀의 규모에는 제한이 있다. 팀은 개인이 할 수 있는 것보다 더 큰 문제를 다를 수 있다. (Beyer Holtzblatt 1998], p. 4).
2. 프로젝트에 늦게 사람을 추가하는 것이 시간과 예산 내에서 프로젝트를 완료하는데 거의 도움이 되지 않는다.

1. 소프트웨어 개발팀이 너무 크면 수익이 크게 감소하는 지점에 도달할 수 있다. 조직의 규모가 결과물에 비선형적으로 영향을 미친다는 사실을 경험적으로 확인했다. 커뮤니케이션 오버헤드는 크기의 제곱으로 증가한다. 즉, 조직의 "마력(horsepower)"은 선형으로만 증가하는 반면, 조직은 크기의 제곱만큼 응집력이 떨어진다.

게다가, 조직이 너무 작으면 팀이 크리티컬 메스를 가지지 못하고 생산성이 저하될 것이다. 2만 5천줄보다 큰 프로젝트는 OrgPattern/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은 너무 크다.

✥ ✥ ✥

Having 10 people at the start of a large project can be overkill, but it avoids the expense and overhead of adding more people later. However, once a core team establishes an identity, it can grow graciously by PHASING IT IN (4.2.3) or using APPRENTICESHIP (4.2.4). The organization can generate knowledge early on by building and throwing away a prototype (see BUILD PROTOTYPES (4.1.7)). To decide whom to hire into the nascent organization, use patterns like DOMAIN EXPERTISE IN ROLES (4.2.22) and ARCHITECTURE TEAM (5.2.4). SMALL WRITING TEAM (10.5.27) [Bramble2002, p. 31] suggests that two or three people be used to write the use cases; others will be in other roles.

Astute readers might consider this pattern and remark, “You have a strange idea of what constitutes a large project! I can see this working for projects that will grow to thirty or forty people and maybe a few tens of thousands of lines of code. But how about for really large projects?”

First, it’s important to understand that there are few real software development teams that are larger than a few dozen people; larger projects almost always self-organize into subcommunities (DIVIDE AND CONQUER (5.1.6)). But even the largest projects start with an idea, and an idea starts with an individual or a small group of people. This pattern says that a small group should take the project as far as they can before other staff are actively engaged. One of course must anticipate the point of diminishing returns for the seed team and seek people early enough so they will be available and ready when they are needed. And of course people should be brought on gradually (see PHASING IT IN, DAY CARE (4.1.23), etc.) But start small, and stay as small as possible as long as possible. Large systems grow from small systems that work.

Second, remember that it is imperative to have FEW ROLES (5.1.2). With ten people, it is easy to define and fill half a dozen or so roles. But with a large initial team, people will at first be at a loss as to what to do, until they receive assignments (and you can’t give everyone an assignment all at once.) So they will find something to do, and will tend to invent roles for themselves. It’s a good way to create deadbeat roles.

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).