Clear message

Part 1. History and Introduction

Chapter 1. An Overview of Patterns and Organizational Patterns

1.1 What are Patterns?

1.2 What are Pattern Languages?

1.3 Organizational Pattern Languages

1.3.1 The Structure of Social Systems

1.3.2 The Multiple Structures of Social Systems

1.3.3 Pattern Languages and Sequences

Chapter 2. How the Patterns Came to Us

2.1 Gathering Organizational Data

2.1.1 Introspection In and Analysis of Organizations

2.1.2 Shortcomings of State of the Art

2.1.3 The CRC-Card Methodology

2.1.4 Analyzing Roles and Relationships

2.2 Creating Sequences

2.2.1 시퀀스가 중요한 이유

이 책에 있는 패턴 언어 자체는 정적이다. 조직은 항상 변화하고 있으며, 변화하는 방식을 항상 예측할 수 있지는 않다.

역동(dynamics)은 어디에서 왔는가?

역동은 패턴의 적용에서 온다. 그리고 패턴을 적용하는 순서에서 온다. 그렇다면, 올바른 순서는 무엇인가? 누군가는 패턴 사이의 구조적 관계를 따른다고 추측할 수 있다. 하지만 항상 그렇게 작동하는 것은 아니다.

ChristopherAlexander 는 모든 시스템의 질서는 근본적으로 시스템을 구축하는데 사용되는 프로세스에 달려 있다고 믿는다. 이것이 근본적인 프로세스(fundamental process)가 중요한 이유이다. (/PIECEMEAL GROWTH 참조)

각 단계의 구조를 유지하고, 점차적으로 지역적인 대칭을 추가하는 것이 중요하며, 조직은 시간이 지남에 따라 펼쳐진다. 피드백을 통한 step-by-step 적응이다. 패턴 언어를 따르는 것만으로는 피드백을 처리하는 방법에 대한 단서가 제공되지 않는다. 이것이 바로 근본 프로세스가 존재하는 이유이다. 설계 프로세스에 완전한 자유를 부여하여 시스템의 가장 취약한 부분을 공격할 수 있다.

그러나, 근본 프로세스는, 반드시 구축되어야 하는 몇 가지 센터들을 예견할 수 있는, 경험에 기반을 둔 어떠한 종류의 인지적인 가이드 없이는, 휴먼 스케일로는 동작할 수 없다. 그것이 바로 패턴이다.: 필수적인 중심들이다.

펼쳐짐이 중요하다면, 펼쳐지는 순서를 어떻게 알 수 있는가? 순서(sequence)는 중요하다. 아마도 부드럽고 구조적인 펼쳐짐을 원할 것이다. '조직 설계'처럼 느껴서는 안된다.

따라서, 시퀀스가 하는 일은:

• 구조를 보존한다;
• 한 번에 한 가지 일을 계속한다;
• 각 단계에서 전체 조직을 고려한다;
• 수만번 반복될 수 있다.

시퀀스는 항상 전체 조직의 맥락에서, 예측할 수 없고, 피드백을 통해 다루어야 하는 상황으로 당신을 데려간다.

시퀀스는 생성(generativity)이 시작되는 곳이다.

2.2.2 우리의 시퀀스들

우리는 여기에 각 패턴 언어에 대한 시퀀스를 만들었다. 이러한 각 시퀀스는 각 패턴 언어에 대해 가정할 수 있는 수백만 개의 시퀀스 중 하나이다. 패턴 언어 그래프에는 의미 있는 경로가 많이 있다.

시퀀스는 스토리로서 펼쳐지고, 이것이 우리가 시퀀스를 제시하는 방법이다. 이러한 "스토리"는 그것들이 참조하는 패턴 집합에 대한 온전성 검사이다. 이 패턴들이 정말로 함께 속한다면, 우리는 패턴들을 타고 흐르는 "스토리"를 생각해낼 수 있어야 한다. (그리고 이것이 꼭 패턴을 통과하는 시간적인 흐름일 필요는 없다는 것을 기억하라) 패턴이 있는 곳에 잘 맞지 않거나, 그룹에 전혀 맞지 않는 패턴을 지적할 수 있다. 책의 이야기를 패턴이 함께 작동하는 방식을 설명하는데 사용할 수도 있다. 책에서 다음 순서를 보라.

• 프로젝트 관리에 대한 이야기 (4.1 프로젝트 관리 패턴 언어)
• 점진적 성장에 대한 이야기 (4.2 점진적 성장 패턴 언어)
• 조직 스타일에 대한 이야기 (5.1 조직 스타일 패턴 언어)
• 사람과 코드에 대한 이야기 (5.2 사람과 코드 패턴 언어)

이러한 시퀀스는 실제이다; 그것들은 우리의 경험에서 비롯되었으며, 우리는 패턴이 서로를 형성하는 풍부한 방식과, 언어가 살아남는 방식을 대표한다고 생각했다. 물론 각각의 케이스 스터디들은 그것을 위해 작성된 시퀀스를 가질 수도 있다. 각 시퀀스는 자체적으로 작은 언어를 형성하는 패턴을 선택한다. 이 언어는 조직의 문화를 설명한다.

2.3 History and Related Work

Chapter 3. How to Use This Book

3.1 Reading the Patterns

3.1.1 The Form

3.1.2 Understanding the Models Behind the Patterns

3.1.3 Stories and Pictures in the Patterns

3.1.4 Finding your Way

3.2 Applying the Patterns

3.2.1 Sequences

3.2.2 Which Patterns?

3.2.3 Human Concerns

3.3 Updating the Patterns

3.4 Who Should Use This Book?

Part 2. The Pattern Languages

Chapter 4. Organization Design Patterns

4.1 Project Management Pattern Language

• 4.1.1 /Community of Trust:

  • 인간 조직을 구축하고 있다면: 성장을 지속할 수 있을 만큼 깊은 수준에서 효과적인 의사 소통에 대한 신뢰와 존중의 기초를 가져야 한다.

• 4.1.2 /Size the Schedule:

  • 일정이 너무 길면 개발자는 안주하게 된다; 그러나 너무 짧으면 과도한 부담이 된다. 따라서 일정을 맞추고 보상을 받고, 두 세트의 책을 보관하라.

• 4.1.3 /Get on With It:

  • 프로젝트를 시작하고 일부를 시작하기에 충분한 정보가 있는 경우: 프로젝트의 일부를 시작하기 전에 완전한 일정이 될 때까지 기다리지 말라.

• 4.1.4 /Named Stable Bases:

  • 안정성과 진보의 균형을 맞추고 싶다면: 사람들이 작업할 수 있는, 명명된 안정된 기반의 계층 구조를 만들라.

• 4.1.5 /Incremental Integration:

  • 개발자가 변경사항을 게시하기 전에 테스트할 수 있도록 하려면: 개발자가 전체 제품 코드를 독립적으로 빌드하여 최신 베이스(최신의 명명된 안정 베이스가 아닌)로 테스트할 수 있도록 허용하라.

• 4.1.6 /Private World:

  • 개발자를 변경의 영향으로부터 격리하려면: 개발자가 전체 빌드 환경을 포함하는 개인 작업 공간을 가지도록 허용하라.

• 4.1.7 /Build Prototypes:

  • 초기에 획득한 요구사항을 테스트 없이 검증하기 어렵다면: 요구사항을 이해하는 것이 목적인 프로토타입을 만들라.

• 4.1.8 /Surrogate Customer

• 4.1.9 /Take No Small Slips:

  • 일정이 늦춰지고 추가 시간 자원이 필요하다면: 작고 예기치 못한 여러 지연들로 당신을 하찮게 만들어 죽음에 이르게 하는 대신, 하나의 크고 계획된 일정지연(slip)을 가져라.

• 4.1.10 /Completion Headroom:

  • 일련의 중요한 일정들에 대해 작업이 진행중이라면: 가장 큰 작업의 완료 날짜와 중요한 배포 일자 사이에 /Completion Headroom이 있는지 확인하라.

• 4.1.11 /Work Split:

  • 문제에 너무 가까이에 있는 사람들이 그들의 문제 - "돼지 통" 문제나 선의의 문제 등 - 를 확대하고 있다면: 작업을 긴급 및 지연된 구성 요소로 나누고, 긴급한 작업에 개발 작업의 절반 미만이 투입되도록 하라.

• 4.1.12 /Recommitment Meeting:

  • 작업 대기열과 인력을 간단하게 조정하여 일정을 충족할 수 없다면: 개발자와 관심있는 관리자를 모아서, 최소한의 작업을 수행하면서 만족스러운 결론에 도달할 수 있는 새로운 전략에 다시 집중(헌신)하게 하라.

• 4.1.13 /Work Queue:

  • 산출물이 잘못 정의된 경우, 모든 것을 할 시간을 허용해야 한다. 따라서: 당신이 입력한 것보다 더 적은 출력을 내도록 일정을 만들라. /Implied Requirements 목록을 시작점으로 사용하고, 더 긴급하거나 우선순위가 높은 항목을 선호하는, 가능한 구현 순서로 정렬하라.

• 4.1.14 /Informal Labor Plan:

  • 개발자가 지금 가장 중요한 작업을 수행해야 한다면: 개발자들 스스로가 서로 협상하거나, 마스터 플랜 대신에 "해야 할 올바른 일들을 파악"하여 단기 계획을 세운다.

• 4.1.15 /Development Episode:

  • 우리가 개별 기여자들의 기술을 지나치게 강조하면, 업무가 (안좋은) 영향을 받는다. 따라서: 모든 개발을 그룹 활동으로 접근하여, 아무도 할 일이 없는 것처럼 하라.

• 4.1.16 /Implied Requirements:

  • 다루어야 할 기능을 상세하게 파악할 방법이 필요하다면: 전통적인 요구사항 분석으로 쪼개어 들어가는 대신, 기능적인 분야와 도메인의 목록을 만들라.

• 4.1.17 /Developer Controls Process:

  • 주어진 위치나 기능에 대한 활동들을 조율할 필요가 있다면: 개발자에게 일련의 활동들에 대한 결정권을 맡겨라.

• 4.1.18 /Work Flows Inward:

  • 정보가 조직 안에서 흘러서 생산하는 역할들에 전달되기를 원한다면: 개발자를 중심에 두고, 정보가, 중심으로부터가 아니라, 중심을 항하여 흐르는지 살펴보라.

• 4.1.19 /Programming Episode:

  • 시간이 흐름에 따라 작업을 분할해야 할 필요가 있다면: 마인드 셰어가 된 개별의 구체적인 에피소드에서 작업을 수행하여 구체적인 결과물에 전념하라.

• 4.1.20 /Someone Always Makes Progress:

  • 산만함이 팀의 진행을 지속적으로 방해한다면: 어떤 일이 발생하더라도, 누군가는 계속해서 기본 목표를 향해 나아가도록 하라.

• 4.1.21 /Team per Task:

  • 큰 전환이 팀을 강타한다면: 하위 팀이 전환을 처리하도록 하여, 메인 팀은 계속하여 진행한다.

• 4.1.22 /Sacrifice One Person:

  • 조금 더 작은 소규모 전환이 팀을 강타한다면: 그것에 한 사람만 할당하여 처리하게 하라.

• 4.1.23 /Day Care:

  • 전문가가 초보자를 멘토링하는데 모든 시간을 할애하고 있다면: 모든 초보자를 담당하는 전문가 한 명을 두고, 다른 사람들은 시스템을 개발하게 하라.

• 4.1.24 /Mercenary Analyst:

  • 문서가 개발자에게 치명적인 경로 장애물이 되지 않기를 원한다면: /Mercenary Analyst를 고용하라.

• 4.1.25 /Interrupts Unjam Blocking:

  • 어떤 합당한 우선 순위 체계에 의해서 긴급한 개발 활동을 잡아야 한다면: 인터럽트 스킴을 사용해서 개별 문제가 전체 프로젝트를 인터럽트하지 않게 한다.

• 4.1.26 /Don't Interrupt an Interrupt:

  • 프로젝트가 중단되는 것을 방지하기 위해 인터럽트를 처리하는 중이고, 새로운 긴급한 요구가 발생했다면: 새로운 문제로 이동하기 전에 현재의 이슈를 계속하여 처리한다.

4.2 Piecemeal Growth Pattern Language

• 4.2.1 /Community of Trust

• 4.2.2 /Size the Organization:

  • 조직이 너무 크면, 커뮤니케이션이 무너지고, 너무 작으면, 목표를 달성하지 못하거나, 더 많은 사람들을 추가하는 어려움을 쉽게 극복하지 못한다. 따라서: 약 10명 정도의 크리티컬 매스로 프로젝트를 시작하라.

• 4.2.3 /Phasing it in:

  • 필요한 전문가를 항상 확보할 수 없다면: 신입 사원으로부터 새로운 전문가를 키우라.

• 4.2.4 /Apprenticeship:

  • 전문성을 유지하는데 어려움이 있다면: 기존 직원 또는 신입 직원으로부터 내부적으로 전문성을 키우라.

• 4.2.5 /Solo Virtuoso:

  • 프로젝트가 지적으로 작다면, 인력을 과도하게 투입하는 것은 시간과 돈을 낭비하는 것이다. 따라서: /Solo Virtuoso로 소규모 프로젝트에 인력을 배치하라.

• 4.2.6 /Engage Customers:

  • 고객의 의견을 수용하는 점진적 프로세스를 관리하고 고객이 사랑받고 있다고 느끼기를 원한다면: QA와 프로젝트 관리가 고객에게 서비스를 제공할 준비가 된 후, 고객을 참여시키라.

• 4.2.7 /Surrogate Customer:

  • 고객의 답변이 필요하지만 질문에 답변할 수 있는 고객이 없다면: 조직에서 대리 고객 역할을 만들어 고객을 대변한다.

• 4.2.8 /Scenarios Define Problem:

  • 고객 요구를 잘 특성화하기를 원한다면: 시나리오를 사용하여 문제를 정의하라.

• 4.2.9 /Fire Walls:

  • 개발자가 외부의 영향과 특별한 이해 집단의 방해를 받지 않게 하고 싶다면: "해충을 제거"하는, 관리자와 같은 방화벽을 도입하라.

• 4.2.10 /Gate Keeper:

  • 근친 교배(? being inbred)를 유지해야 할 필요가 있다면: /Gate Keeper 역할을 사용하여 개발을 다른 프로젝트, 리서치, 바깥 세상과 함께 묶는다.

• 4.2.11 /Self Selecting Team:

  • 팀에 사람을 임명한다고 해서, 하나의 팀이 되지 않는다. 그러나 외부 이해 관계가 있고 팀을 하나로 연결하기를 원하는 사람들은 최고의 팀 멤버를 만든다. 따라서: 팀은 실적 및 외부 관심사를 기반으로, 제한된 선별(screening)을 통해 대부분 자체 선택해야 한다.

• 4.2.12 /Unity of Purpose:

  • 팀이 함께 일하기 시작하고 있다면: 모든 구성원이 팀의 목적에 동의하는지 확인하라.

• 4.2.13 /Team Pride:

  • 팀이 임무를 넘어서, 그 이상으로 수행할 필요가 있다면: 팀의 구성원들에게 잘 기반된 엘리트주의를 심어라.

• 4.2.14 /Skunk Works:

  • 프로젝트가 너무 많이 혁신하면, 위험이 증가한다; 그래서 적절한 혁신의 정도가 있다. 따라서: 혁신에 조직적인 공간과 시간을 제공하라.

• 4.2.15 /Patron Role:

  • /Developer Controls Process를 보호하고 전략적 수준에서 조직적 타당성을 제공해야 할 필요가 있다면: 프로젝트가 접근할 수 있는, 그리고 프로젝트의 이유를 옹호할 수 있는 후원자(patron)를 파악하라.

• 4.2.16 /Diverse Groups:

  • 모든 사람이 비슷한 견해를 가지고 있다면, 좋은 팀을 가지고 있는 것이다. 하지만 너무 많은 정규화는 중요한 문제 영역들이 조명되지 않은 채 남겨둔다.
  • If everyone has similar views, you have a good team, but too much normalization leaves important problem areas unaddressed. Therefore: assemble a diverse team, based on different experiences, cultures, and genders.

• 4.2.17 /Public Character:

  • If you need a catalyst to bring people together, Then: recognize some roles as PUBLIC CHARACTERS.

• 4.2.18 /Matron Role:

  • If your team needs ongoing care and feeding, Then: include a Matron in the team who will naturally take care of social needs of the team.

• 4.2.19 /Holistic Diversity:

  • If Development of a subsystem needs many skills, but people specialize, Then: create a single team from multiple specialties.

• 4.2.20 /Legend Role:

  • If a key person will leave the organization soon, Then: train a key replacement, and have them assume a role named after the key person.

• 4.2.21 /Wise Fool:

  • If critical issues do not get aired easily, Then: nurture a Wise Fool to say the things nobody else dares say.

• 4.2.22 /Domain Experties in Roles:

  • If you need to staff all roles, it’s difficult to determine how to match people to roles to optimize communication. Therefore: match people to roles based on domain expertise, and emphasize that people play those roles in the organization.

• 4.2.23 /Subsystem by Skill:

  • If you need to organize subsystems for the long haul, Then: divide them up by skills.

• 4.2.24 /Moderate Truck Number:

  • If you can’t eliminate having a single point of failure in allocating expertise to roles, Then: spread expertise as far as possible, but not more so.

• 4.2.25 /Compensate Success:

  • If enterprises are to succeed, they must reward the behaviors that portend for success; but, these behaviors are varied, and success is difficult to measure. Therefore: establish a spectrum of reward mechanisms that reward both teams and individuals.

• 4.2.26 /Failed Project Wake:

  • If people have put their hearts and souls into a project, only to have it canceled, Then: celebrate its demise; hold a “wake” for it.

• 4.2.27 /Don't Interrupt an Interrupt

• 4.2.28 /Developing in Pairs:

  • If you want to improve the effectiveness of individual developers, Then: have people develop in pairs.

• 4.2.29 /Engage Quality Assurance:

  • If developers can’t be counted on to test beyond what they already anticipate what might go wrong, Then: engage Quality Assurance as an important function.

• 4.2.30 /Application Design is Bounded by Test Design:

  • If you want to organize the interworking between test developers and software developers, Then: organize the process so APPLICATION DESIGN IS BOUNDED BY TEST DESIGN.

• 4.2.31 /Mercenary Analyst

• 4.2.32 /Group Validation:

  • If you want to avoid being blindsided in quality assurance, Then: ENGAGE CUSTOMERS (4.2.6) and DEVELOPING IN PAIRS (4.2.28) and others to validate the system.

Chapter 5. Organization Construction Patterns

5.1 Organizational Style Pattern Language

• 5.1.1 /Community of Trust

• 5.1.2 /Few Rules:

  • If your organization has high communication overhead and latency, Then: identify the roles in the organization, and keep the number of roles to sixteen or fewer.

• 5.1.3 /Producer Roles:

  • If your organization has too many roles, but does not know which to eliminate, Then: identify roles as Producers, Supporters, or Deadbeats; eliminate the Deadbeats, and combine some of the Supporters.

• 5.1.4 /Producers in the Middle:

  • If your developers are somewhat lost, Then: make sure the producer roles are at the center of all communication.

• 5.1.5 /Stable Roles:

  • If you have to deal with project disruptions, Then: keep people in their primary roles, and deal with disruptions as temporary tasks.

• 5.1.6 /Divide and Conquer:

  • If an organization is getting too large for communications to be effective any more, Then: try partitioning it along lines of mutual interest and coupling, forming a separate organization and process.

• 5.1.7 /Conway's Law:

  • If organization structuring concerns are torn between geography, expertise, politics, and other factors, Then: align the primary organizational structuring with the structure of the business domains, the structure that will be reflected in the product architecture.

• 5.1.8 /Organization Follows Location:

  • If you need to distribute work geographically, communications suffer, but you can limit the damage if work is partitionable. Therefore: organize work at locations so groups of people that work together are at the same location.

• 5.1.9 /Organization Follows Market:

  • If there is no clear organizational accountability to a market, Then: make some organization accountable for the market to assure that the market’s needs will be met.

• 5.1.10 /Face to Face Before Working Remotely:

  • If a project is divided geographically, Then: begin the project with a meeting of everyone in a single place.

• 5.1.11 /Form Follows Function:

  • If there is little specialization, and people don’t know where to turn for answers to technical questions, Then: Create domains of expertise called roles that cluster around artifacts or specialization.

• 5.1.12 /Shaping Circulation Realms:

  • If you need mechanisms to facilitate the communication structures necessary for good group formation, Then: shape circulation realms.

• 5.1.13 /Distribute Work Evenly:

  • If you want to optimize utilization of human resources, Then: alleviate hot spots of overload on specific groups and individuals in your organization by Distributing Work Evenly

• 5.1.14 /Responsibilities Engage:

  • If central roles are overloaded but you don’t want to take them out of the communication loop Then: intensify communication more among non-central roles to lighten the load on the central roles

• 5.1.15 /Hallway Chatter:

  • If developers tend to huddle around the organizational core or supporting roles are inadequately engaged with each other, Then: rearrange responsibilities in a way that encourages less isolation and more interworking among roles and people.

• 5.1.16 /Decouple Stages:

  • If stages are too interleaved for the good of some high-context development where phases can be separated to increase parallelism, Then: serialize process steps, with well-defined hand-offs between steps.

• 5.1.17 /Hub Spoke and Rim:

  • If you want to DECOUPLE STAGES in a high-context development process, Then: orchestrate the process with a hub role, and minimize coupling between other roles, in a hub-spoke-and-rim geometry.

• 5.1.18 /Move Responsibilities:

  • If you want to change coupling between roles (particularly if you want to decouple roles), Then: move responsibilities from one role to another.

• 5.1.19 /Upside Down Matrix Management:

  • If the right skills and resources don’t seem to be applied to a particular aspect of the work, Then: go beyond corporate structures to leverage teams in other organizations (customer, partners, other internal organizations)

• 5.1.20 /The Water Cooler:

  • If you need more communication between institutionalized organizations, Then: leave space for everyday human activities at the workplace that can provide more complete and informal communication

• 5.1.21 /Three to Seven Helpers oer Role:

  • If you want to even out communication, Then: at least try to limit communication to THREE TO SEVEN HELPERS PER ROLE, and to pull up the outliers to the same level of engagement.

• 5.1.22 /Coupling Decreases Latency:

  • If you need a high throughput development process, Then: increase coupling between roles to decrease latency.

• 5.1.23 /Standards Linking Locations

5.2 People and Code Pattern Language

• 5.2.1 /Community of Trust

• 5.2.2 /Conway's Law

• 5.2.3 /Architect Controls Product:

  • If a project has a long life, Then: use the architect to carry the vision forward and serve as the long-term keeper of architectural style.

• 5.2.4 /Architecture Team:

  • If you are building a system too large or complex to be thoroughly understood by a single individual, Then build a team that has both the responsibility and the power to create the architecture.

• 5.2.5 /Lock'em Up Together:

  • If your team is struggling to come up with an architecture, Then: isolate them physically for several days where they can work uninterrupted.

• 5.2.6 /Smoke Filled Room:

  • If you need to make a decision quickly and there are reasons to exclude others, Then: make the decision covertly so that the rationale remains private, though the decision will be publicized.

• 5.2.7 /Stand Up Meeting:

  • If there are pockets of misinformation or people out of the loop: Then: hold short daily meetings to socialize emerging developments.

• 5.2.8 /Deploy Along the Grain:

  • If reuse is suffering from fragmentation of responsibilities for an artifact, Then: give people dedicated, long term responsibility for a management piece of the system.

• 5.2.9 /Subsystem by Skill

• 5.2.10 /Architect Also Implements:

  • If an architect is on an ivory tower, they are out of touch; yet someone needs to take the big and long view and reconcile it with practice. Therefore: the architect is materially involved in day-to-day implementation.

• 5.2.11 /Generics and Specifics:

  • If you have many new people, Then: put the experienced people on generic parts of the work, and give specific assignments to the new people.

• 5.2.12 /Standards Linking Locations:

  • If you have geographically separated development, Then: use standards to link together parts of the architecture that cross geographic boundaries.

• 5.2.13 /Code Ownership:

  • If you need responsibility for code and want to build on DOMAIN EXPERTISE IN ROLES (4.2.22), Then: give various individuals responsibility for the overall quality of the code.

• 5.2.14 /Feature Assignment:

  • If you are trying to partition work in a large project, Then: make assignments of features to people.

• 5.2.15 /Variation Behind Interface:

  • If more than one person is developing software, then changes affect not only the code, but people as well. Therefore: create interfaces around predicted points of variation.

• 5.2.16 /Private Versioning:

  • If you want to enable incremental changes without publishing them, Then: set up a mechanism for developers to version code without checking it in to a public repository.

• 5.2.17 /Loose Interfaces:

  • If you need to develop systems rapidly in an environment where communication is less than optimal, Then: limit the number of explicit, static, interfaces. Use loose interfaces like callbacks.

• 5.2.18 /Subclass per Team:

  • If subsystem teams have different Design points, Then: where two subsystems collide in one class, assign them to different layers of the class hierarchy.

• 5.2.19 /Hierarchy of Factories:

  • If you have a creational system which creates different products specified by different groups, Then: set up factories in a hierarchical arrangement, where each knows about 1 level below only.

• 5.2.20 /Parser Builder:

  • If you need you create objects based on type information in an input stream, Then: use a parser builder which reads type information from the stream and builds the appropriate objects based on this information.

• 5.2.21 /Incremental Integration

• 5.2.22 /Private World

• 5.2.23 /Named Stable Bases

Part 3. Foundations and History

Chapter 6. Organizational Principles

6.1 Priming the Organization for Change

6.1.1 Dissonance Precedes Resolution

6.1.2. Team Burnout

6.1.3 Stability and Crisis Management

6.1.4 The Open Closed Principle of Teams

6.1.5 Team Building

6.1.6 Building on the Solid Core

6.2 Piecemeal Growth

6.2.1 The Foundamental Process

6.2.2 When do I apply these patterns?

6.2.3 Writing your own patterns

6.2.4 Master Planning and the Theory of Constraints

6.2.5 Communication and Organizational Learning

6.3 Some General Rules

6.3.1 Make Love not War

6.3.2 Organizational Patterns are Inspiration Rather than Prescription

6.3.3 It Depends on Your Role in Your Organization

6.3.4 It Depends on the Context of the Organization

6.3.5 Organizational Patterns are Used by Groups Rather than Individuals

6.3.6 People are Less Predictable than Code

6.3.7 The Role of Management

Chapter 7. Anthropological Foundations

7.1 Patterns in Anthropology

7.2 Beyond Process to Structure and Values

7.2.1 The Shortcomings of Process

7.2.2 Structure

7.2.3 Values: The Human Element

7.3 Roles and Communication

=== 7.4 Social Network Analysis

=== 7.5 Distilling the Patterns

7.5.1 CRC-Cards and Roles

7.5.2 Social Network Theory Foundations

7.5.3 Scatterplots are Patterns

Part 4. Case Studies

Chapter 8. Borland Quattro Pro for Windows

Chapter 9. A Hyperproductive Telecommunications Development Team

Part 5. Appendices

Chapter 10. Summary Patlets

10.1 Project Management Patlets

10.2 Piecemeal Growth Patlets

10.3 Organizational Style Patlets

10.4 People and Code Patlets

10.5 Patlets from Other Pattern Languages

• 10.5.1 /Arranging the Furniture

• 10.5.2 /Ad-Hoc Corrections

• 10.5.3 /All At Once

• 10.5.4 /Architecture Definition Team

• 10.5.5 /Balanced Team

• 10.5.6 /Business Process Model

• 10.5.7 /Clear The Fog

• 10.5.8 /Creator-Reviewer

• 10.5.9 /Demo Prep

• 10.5.10 /Designer are Our Friends

• 10.5.11 /Early and Regular Delivery

• 10.5.12 /Establish the Business Objectives

• 10.5.13 /Get Involved Early

• 10.5.14 /Gradual Stiffening

• 10.5.15 /Guru Does All

• 10.5.16 /Market Walk-through

• 10.5.17 /Master-Journeyman

• 10.5.18 /Micro Cosm

• 10.5.19 /Owner Per Deliverable

• 10.5.20 /Participating Audience

• 10.5.21 /Peace Maker

• 10.5.22 /Product Initiative

• 10.5.23 /Proto Types

• 10.5.24 /Query Objects

• 10.5.25 /Shared Clear Vision

• 10.5.26 /Shearing Layers

• 10.5.27 /Small Writing Team

• 10.5.28 /Skill Mix

• 10.5.29 /Work Allocation