Diff for "OrgPatterns/Size the Organization"

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

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

✥ ✥ ✥

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

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

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

1. If a software development team is too large, you can reach a point of greatly diminishing returns. We have found empirically that an organization’s size affects a deliverable non-linearly. Communication overhead goes up as the square of the size, which means that the organization becomes less cohesive as the square of the size while the “horsepower” of the organization goes up only linearly.

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

In addition, if the organization is too small, the team won’t have critical mass and productivity will suffer. Projects larger than 25KSLOC can rarely be done by a SOLO VIRTUOSO (4.2.5) and overly small organizations have inadequate inertia and can easily become unstable.

게다가, 조직이 너무 작으면 팀이 크리티컬 메스를 가지지 못하고 생산성이 저하될 것이다. 2만 5천줄보다 큰 프로젝트는 OrgPattern/Solo Virtuoso로 거의 수행할 수 없으며, 지나치게 작은 조직은 부적절한 관성을 가지고 쉽게 불안정해질 수 있다.

However, experience has shown that a suitably selected and nurtured small team of around 10 people can provide a suitable critical mass with a capacity to develop a 1,500 KSLOC project in 31 months, a 200 KSLOC project in 15 months, or a 60KSLOC project in 8 months.

그러나, 경험에 따르면 적절하게 선정되고 육성된 10명 정도의 소규모 팀은 31개월에 150만 라인 프로젝트, 15개월에 20만 라인 프로젝트, 또는 8개월에 6만 라인 프로젝트를 개발할 수 있는 적절한 크리티컬 메스를 제공할 수 있다.

Keeping the organization small makes it possible for everybody to have knowledge of how the project works (“global knowledge”). We have found empirically that most roles in a project can handle interactions with about six or seven other roles; with 10 people, you can almost manage total global communications (and a fully connected network may not be necessary).

조직을 작게 유지하면 모든 사람이 프로젝트 작동 방식에 대한 지식을 가질 수 있다. ("글로벌 지식"). 우리는 프로젝트에서 대부분의 역할이 약 6~7개의 다른 역할과의 상호작용을 처리할 수 있음을 경험적으로 발견했다. 10명으로 전체 글로벌 커뮤니케이션을 거의 관리할 수 있다 (그리고 완전 연결 네트워크가 필요하지 않을 것이다.)

Projects that do well have processes that adapt, and processes adapt well only if there is widespread buy-in and benefit. The dialogue necessary to buy-in and benefit can accrue only to small organizations.

잘 적응하는 프로젝트는, 적응하는 프로세스를 가지고 있고, 프로세스는 광범위한 동의와 혜택이 있을 때만 잘 적응한다. 동의와 이익을 위해 필요한 대화는 소규모 조직에만 발생할 수 있다.

Tom De Marco has noted that everybody who is to benefit from process should be involved in process work and process decision-making.

TomDeMarco는 프로세스의 혜택을 받는 모든 사람이 프로세스 작업 및 프로세스 의사 결정에 참여해야 한다고 언급했다.

Further study might evaluate the relationship between this pattern and Alexander’s THE DISTRIBUTION OF TOWNS ([Alexander1977], ff. 16) and related patterns. Here, we stipulate that the social organization must be small; it reflects a SUBCULTURE BOUNDARY ([Alexander1977], ff.75) and IDENTIFIABLE NEIGHBORHOOD ([Alexander1977], ff. 80). Alexander emphasizes the grander architectural context that balances support for the ecology with the economies of scale that large towns can provide, while supporting the xenophobic tendencies of human nature. Small organizations like that being built here rarely exist in isolation, but in the context of a broader supporting organization. This relationship to the larger organization invokes PATRON ROLE (4.2.15).

추가 연구에서는, 이 패턴과 ChristopherAlexander의 TheDistributionOfTowns 및 관련 패턴간의 관계를 평가할 수 있다. 여기서 우리는 사회 조직이 작아야 한다고 규정한다; 이것은 SubcultureBundary와 IdentifiableNeighborhood 를 반영한다. ChristopherAlexander는 웅장한 아키텍처적인 맥락이, 생태에 대한 지원과 큰 마을이 제공할 수 있는 규모의 경제와 조화를 이루는 것을 강조하면서도 인간 본성이 외지인을 꺼리는 경향을 지원했다.

생태에 대한 지원과 대도시가 제공할 수 있는 규모의 경제가 균형을 이루는데 더 웅장한 건축적 맥락을 강조하는 동시에 인간 본성의 외국인 혐오 경향을 지원한다.

2. Adding people late to a project rarely helps complete that project on time and within budget.

One manager writes: “On [one] project, I grew from 10 to 20 people to meet a customer contract....with new people, [I] wound up three months late because of ‘absorption’ of new folks into the organization.”

Many software development cultures support technical manager groups up to around 10 people. Adding more people would force a group split, which can cause a large decrease in productivity, all other things being equal. We have also found that a single team is better than a collection of sub-teams. The faster a team breaks up into sub-teams worrying about their own responsibilities rather than those of the larger team, the less effective the enterprise will be as a whole.

Therefore:

By default, choose about ten people to establish critical mass in the development of large software systems and avoid adding individuals late in the game, or trying to work backwards from a completion date.

Experts vary on the exact number; the number 10 has a bit of tradition associated with it, but numbers like 6 or 7 are also common. Two is too small, and 13 is too big.

✥ ✥ ✥

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