#acl +All:read

JimCoplien 이 쓴 책.

<<TableOfContents(3)>>

= 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 ===

{{{#!wiki multi-columns

==== 2.2.1 시퀀스가 중요한 이유 ====

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

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

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

ChristopherAlexander 는 모든 시스템의 질서는 근본적으로 시스템을 구축하는데 사용되는 프로세스에 달려 있다고 믿는다. 이것이 근본적인 프로세스(fundamental process)가 중요한 이유이다. ([[OrgPatterns/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 ===

{{attachment:orgpattern-management.PNG}}

{{{#!wiki multi-columns
 * 4.1.1 [[OrgPatterns/Community of Trust]]:
  * 인간 조직을 구축하고 있다면: 성장을 지속할 수 있을 만큼 깊은 수준에서 효과적인 의사 소통에 대한 신뢰와 존중의 기초를 가져야 한다.
 * 4.1.2 [[OrgPatterns/Size the Schedule]]:
  * 일정이 너무 길면 개발자는 안주하게 된다; 그러나 너무 짧으면 과도한 부담이 된다. 따라서 일정을 맞추고 보상을 받고, 두 세트의 책을 보관하라.
 * 4.1.3 [[OrgPatterns/Get on With It]]:
  * 프로젝트를 시작하고 일부를 시작하기에 충분한 정보가 있는 경우: 프로젝트의 일부를 시작하기 전에 완전한 일정이 될 때까지 기다리지 말라.
 * 4.1.4 [[OrgPatterns/Named Stable Bases]]:
  * 안정성과 진보의 균형을 맞추고 싶다면: 사람들이 작업할 수 있는, 명명된 안정된 기반의 계층 구조를 만들라.
 * 4.1.5 [[OrgPatterns/Incremental Integration]]:
  * 개발자가 변경사항을 게시하기 전에 테스트할 수 있도록 하려면: 개발자가 전체 제품 코드를 독립적으로 빌드하여 최신 베이스(최신의 명명된 안정 베이스가 아닌)로 테스트할 수 있도록 허용하라.
 * 4.1.6 [[OrgPatterns/Private World]]:
  * 개발자를 변경의 영향으로부터 격리하려면: 개발자가 전체 빌드 환경을 포함하는 개인 작업 공간을 가지도록 허용하라.
 * 4.1.7 [[OrgPatterns/Build Prototypes]]:
  * 초기에 획득한 요구사항을 테스트 없이 검증하기 어렵다면: 요구사항을 이해하는 것이 목적인 프로토타입을 만들라.
 * 4.1.8 [[OrgPatterns/Surrogate Customer]]
 * 4.1.9 [[OrgPatterns/Take No Small Slips]]:
  * 일정이 늦춰지고 추가 시간 자원이 필요하다면: 작고 예기치 못한 여러 지연들로 당신을 하찮게 만들어 죽음에 이르게 하는 대신, 하나의 크고 계획된 일정지연(slip)을 가져라. 
 * 4.1.10 [[OrgPatterns/Completion Headroom]]:
  * 일련의 중요한 일정들에 대해 작업이 진행중이라면: 가장 큰 작업의 완료 날짜와 중요한 배포 일자 사이에 [[OrgPatterns/Completion Headroom]]이 있는지 확인하라.
 * 4.1.11 [[OrgPatterns/Work Split]]:
  * 문제에 너무 가까이에 있는 사람들이 그들의 문제 - "돼지 통" 문제나 선의의 문제 등 - 를 확대하고 있다면: 작업을 긴급 및 지연된 구성 요소로 나누고, 긴급한 작업에 개발 작업의 절반 미만이 투입되도록 하라.
 * 4.1.12 [[OrgPatterns/Recommitment Meeting]]:
  * 작업 대기열과 인력을 간단하게 조정하여 일정을 충족할 수 없다면: 개발자와 관심있는 관리자를 모아서, 최소한의 작업을 수행하면서 만족스러운 결론에 도달할 수 있는 새로운 전략에 다시 집중(헌신)하게 하라.
 * 4.1.13 [[OrgPatterns/Work Queue]]:
  * 산출물이 잘못 정의된 경우, 모든 것을 할 시간을 허용해야 한다. 따라서: 당신이 입력한 것보다 더 적은 출력을 내도록 일정을 만들라. [[OrgPatterns/Implied Requirements]] 목록을 시작점으로 사용하고, 더 긴급하거나 우선순위가 높은 항목을 선호하는, 가능한 구현 순서로 정렬하라.
 * 4.1.14 [[OrgPatterns/Informal Labor Plan]]:
  * 개발자가 지금 가장 중요한 작업을 수행해야 한다면: 개발자들 스스로가 서로 협상하거나, 마스터 플랜 대신에 "해야 할 올바른 일들을 파악"하여 단기 계획을 세운다.
 * 4.1.15 [[OrgPatterns/Development Episode]]:
  * 우리가 개별 기여자들의 기술을 지나치게 강조하면, 업무가 (안좋은) 영향을 받는다. 따라서: 모든 개발을 그룹 활동으로 접근하여, 아무도 할 일이 없는 것처럼 하라.
 * 4.1.16 [[OrgPatterns/Implied Requirements]]:
  * 다루어야 할 기능을 상세하게 파악할 방법이 필요하다면: 전통적인 요구사항 분석으로 쪼개어 들어가는 대신, 기능적인 분야와 도메인의 목록을 만들라.
 * 4.1.17 [[OrgPatterns/Developer Controls Process]]:
  * 주어진 위치나 기능에 대한 활동들을 조율할 필요가 있다면: 개발자에게 일련의 활동들에 대한 결정권을 맡겨라.
 * 4.1.18 [[OrgPatterns/Work Flows Inward]]:
  * 정보가 조직 안에서 흘러서 생산하는 역할들에 전달되기를 원한다면: 개발자를 중심에 두고, 정보가, 중심으로부터가 아니라, 중심을 항하여 흐르는지 살펴보라.
 * 4.1.19 [[OrgPatterns/Programming Episode]]:
  * 시간이 흐름에 따라 작업을 분할해야 할 필요가 있다면: 마인드 셰어가 된 개별의 구체적인 에피소드에서 작업을 수행하여 구체적인 결과물에 전념하라.
 * 4.1.20 [[OrgPatterns/Someone Always Makes Progress]]:
  * 산만함이 팀의 진행을 지속적으로 방해한다면: 어떤 일이 발생하더라도, 누군가는 계속해서 기본 목표를 향해 나아가도록 하라.
 * 4.1.21 [[OrgPatterns/Team per Task]]:
  * 큰 전환이 팀을 강타한다면: 하위 팀이 전환을 처리하도록 하여, 메인 팀은 계속하여 진행한다.
 * 4.1.22 [[OrgPatterns/Sacrifice One Person]]:
  * 조금 더 작은 소규모 전환이 팀을 강타한다면: 그것에 한 사람만 할당하여 처리하게 하라.
 * 4.1.23 [[OrgPatterns/Day Care]]:
  * 전문가가 초보자를 멘토링하는데 모든 시간을 할애하고 있다면: 모든 초보자를 담당하는 전문가 한 명을 두고, 다른 사람들은 시스템을 개발하게 하라.
 * 4.1.24 [[OrgPatterns/Mercenary Analyst]]:
  * 문서가 개발자에게 치명적인 경로 장애물이 되지 않기를 원한다면: [[OrgPatterns/Mercenary Analyst]]를 고용하라.
 * 4.1.25 [[OrgPatterns/Interrupts Unjam Blocking]]:
  * 어떤 합당한 우선 순위 체계에 의해서 긴급한 개발 활동을 잡아야 한다면: 인터럽트 스킴을 사용해서 개별 문제가 전체 프로젝트를 인터럽트하지 않게 한다.
 * 4.1.26 [[OrgPatterns/Don't Interrupt an Interrupt]]:
  * 프로젝트가 중단되는 것을 방지하기 위해 인터럽트를 처리하는 중이고, 새로운 긴급한 요구가 발생했다면: 새로운 문제로 이동하기 전에 현재의 이슈를 계속하여 처리한다.
}}}

=== 4.2 Piecemeal Growth Pattern Language ===

{{attachment:orgpattern-piecemeal-growth.PNG}}

{{{#!wiki multi-columns
 * 4.2.1 [[OrgPatterns/Community of Trust]]
 * 4.2.2 [[OrgPatterns/Size the Organization]]:
  * 조직이 너무 크면, 커뮤니케이션이 무너지고, 너무 작으면, 목표를 달성하지 못하거나, 더 많은 사람들을 추가하는 어려움을 쉽게 극복하지 못한다. 따라서: 약 10명 정도의 크리티컬 매스로 프로젝트를 시작하라.
 * 4.2.3 [[OrgPatterns/Phasing it In]]:
  * 필요한 전문가를 항상 확보할 수 없다면: 신입 사원으로부터 새로운 전문가를 키우라.
 * 4.2.4 [[OrgPatterns/Apprenticeship]]:
  * 전문성을 유지하는데 어려움이 있다면: 기존 직원 또는 신입 직원으로부터 내부적으로 전문성을 키우라.
 * 4.2.5 [[OrgPatterns/Solo Virtuoso]]:
  * 프로젝트가 지적으로 작다면, 인력을 과도하게 투입하는 것은 시간과 돈을 낭비하는 것이다. 따라서: [[OrgPatterns/Solo Virtuoso]]로 소규모 프로젝트에 인력을 배치하라.
 * 4.2.6 [[OrgPatterns/Engage Customers]]:
  * 고객의 의견을 수용하는 점진적 프로세스를 관리하고 고객이 사랑받고 있다고 느끼기를 원한다면: QA와 프로젝트 관리가 고객에게 서비스를 제공할 준비가 된 후, 고객을 참여시키라.
 * 4.2.7 [[OrgPatterns/Surrogate Customer]]:
  * 고객의 답변이 필요하지만 질문에 답변할 수 있는 고객이 없다면: 조직에서 대리 고객 역할을 만들어 고객을 대변한다.
 * 4.2.8 [[OrgPatterns/Scenarios Define Problem]]:
  * 고객 요구를 잘 특성화하기를 원한다면: 시나리오를 사용하여 문제를 정의하라.
 * 4.2.9 [[OrgPatterns/Fire Walls]]:
  * 개발자가 외부의 영향과 특별한 이해 집단의 방해를 받지 않게 하고 싶다면: "해충을 제거"하는, 관리자와 같은 방화벽을 도입하라.
 * 4.2.10 [[OrgPatterns/Gate Keeper]]:
  * 근친 교배(? being inbred)를 유지해야 할 필요가 있다면: [[OrgPatterns/Gate Keeper]] 역할을 사용하여 개발을 다른 프로젝트, 리서치, 바깥 세상과 함께 묶는다.
 * 4.2.11 [[OrgPatterns/Self Selecting Team]]:
  * 팀에 사람을 임명한다고 해서, 하나의 팀이 되지 않는다. 그러나 외부 이해 관계가 있고 팀을 하나로 연결하기를 원하는 사람들은 최고의 팀 멤버를 만든다. 따라서: 팀은 실적 및 외부 관심사를 기반으로, 제한된 선별(screening)을 통해 대부분 자체 선택해야 한다.
 * 4.2.12 [[OrgPatterns/Unity of Purpose]]:
  * 팀이 함께 일하기 시작하고 있다면: 모든 구성원이 팀의 목적에 동의하는지 확인하라.
 * 4.2.13 [[OrgPatterns/Team Pride]]:
  * 팀이 임무를 넘어서, 그 이상으로 수행할 필요가 있다면: 팀의 구성원들에게 잘 기반된 엘리트주의를 심어라.
 * 4.2.14 [[OrgPatterns/Skunk Works]]:
  * 프로젝트가 너무 많이 혁신하면, 위험이 증가한다; 그래서 적절한 혁신의 정도가 있다. 따라서: 혁신에 조직적인 공간과 시간을 제공하라.
 * 4.2.15 [[OrgPatterns/Patron Role]]:
  * [[OrgPatterns/Developer Controls Process]]를 보호하고 전략적 수준에서 조직적 타당성을 제공해야 할 필요가 있다면: 프로젝트가 접근할 수 있는, 그리고 프로젝트의 이유를 옹호할 수 있는 후원자(patron)를 파악하라.
 * 4.2.16 [[OrgPatterns/Diverse Groups]]:
  * 모든 사람이 비슷한 견해를 가지고 있다면, 좋은 팀을 가지고 있는 것이다. 하지만 너무 많은 정규화는 중요한 문제 영역들을 조명되지 않은 채 남겨둔다. 따라서: 다양한 경험, 문화, 성별을 기반으로 다양성 있는 팀을 구성하라.
 * 4.2.17 [[OrgPatterns/Public Character]]:
  * 사람들을 한데 모으기 위한 촉매제가 필요하다면: 일부 역할을 [[OrgPatterns/Public Character]]로 인식하라.
 * 4.2.18 [[OrgPatterns/Matron Role]]:
  * 팀이 지속적인 돌봄과 공급을 필요로 한다면: 팀에 자연스럽게 팀의 사회적 요구를 돌볼 수 있는 대모를 포함시켜라.
 * 4.2.19 [[OrgPatterns/Holistic Diversity]]:
  * 하위 시스템 개발에는 많은 기술이 필요한데, 사람들이 전문화한다면: 여러 전문 분야에서 단일 팀을 만든다.
 * 4.2.20 [[OrgPatterns/Legend Role]]:
  * 핵심 인물이 곧 조직을 떠난다면: 핵심 교체를 훈련시키고, 그 핵심 인물의 이름을 딴 역할을 맡게 하라.
 * 4.2.21 [[OrgPatterns/Wise Fool]]:
  * 중요한 문제가 쉽게 회자되지 않는다면: 다른 사람들이 감히 말하지 않는 말을 할 수 있는 현명한 바보를 육성하라.
 * 4.2.22 [[OrgPatterns/Domain Experties in Roles]]:
  * 당신이 모든 역할을 담당해야 한다면, 커뮤니케이션을 최적화하기 위해 역할에 사람을 연결하는 방법을 결정하기 어렵다. 따라서: 도메인 전문 지식을 기반으로 사람들을 역할에 연결하고 사람들이 조직에서 이러한 역할을 수행한다는 것을 강조하라.
 * 4.2.23 [[OrgPatterns/Subsystem by Skill]]:
  * 장기적으로 하위 시스템을 구성해야 할 필요가 있다면: 기술에 따라 하위 시스템을 나눈다.
  * If you need to organize subsystems for the long haul, Then: divide them up by skills.
 * 4.2.24 [[OrgPatterns/Moderate Truck Number]]:
  * 전문 지식을 역할에 할당하는데 있어 단일 실패 지점을 제거할 수 없다면: 가능한 한 전문 지식을 전파하되, 그 이상은 하지 마라.
 * 4.2.25 [[OrgPatterns/Compensate Success]]:
  * 기업이 성공하려면, 성공을 나타내는 행동에 대해 보상해야 한다; 그러나, 이러한 행동은 다양하며, 성공은 측정하기 어렵다. 따라서: 팀과 개인 모두에게 보상하는 다양한 보상 메커니즘을 수립하라.
 * 4.2.26 [[OrgPatterns/Failed Project Wake]]:
  * 만약 사람들이 그들의 마음과 영혼을 프로젝트에 넣었는데, 그것이 취소되었다면: 그것의 종말을 축하하라(?);  그것을 위해 장례식을 열어라.
 * 4.2.27 [[OrgPatterns/Don't Interrupt an Interrupt]]
 * 4.2.28 [[OrgPatterns/Developing in Pairs]]:
  * 개별 개발자의 효과성을 향상시키고 싶다면: 사람들이 짝으로 개발하게 하라.
 * 4.2.29 [[OrgPatterns/Engage Quality Assurance]]:
  * 개발자가 이미 잘못될 것이라고 예상했던 것 이상으로 테스트할 수 없다면: QA를 중요한 기능으로 사용하라.
 * 4.2.30 [[OrgPatterns/Application Design is Bounded by Test Design]]:
  * 테스트 개발자와 소프트웨어 개발자간의 연관 업무를 구성하기 원한다면: 애플리케이션 디자인이 테스트 디자인과 묶이도록 프로세스를 구성한다.
 * 4.2.31 [[OrgPatterns/Mercenary Analyst]]
 * 4.2.32 [[OrgPatterns/Group Validation]]:
  * 품질 보증에서 장님이 되지 않기를 원한다면: [[OrgPatterns/Engage Customers]]를 하고 [[OrgPatterns/Developing in Pairs]] 및 다른 것들을 하여, 시스템을 검증하라.
}}}

== Chapter 5. Organization Construction Patterns ==

=== 5.1 Organizational Style Pattern Language ===

{{attachment:orgpattern-org-style.PNG}}

{{{#!wiki multi-columns
 * 5.1.1 [[OrgPatterns/Community of Trust]]
 * 5.1.2 [[OrgPatterns/Few Rules]]:
  * 조직에 높은 커뮤니케이션 오버헤드와 지연이 있다면: 조직의 역할들을 파악하고, 그 수를 16개 이하로 유지하라.
 * 5.1.3 [[OrgPatterns/Producer Roles]]:
  * 조직에 너무 많은 역할이 있지만, 어느 것을 제거해야 할지 모르겠다면: 역할을 생산자, 서포터, 데드비트(Deadbeats)로 식별하라. 데드비트들을 제거하고, 일부 서포터들을 결합하라.
 * 5.1.4 [[OrgPatterns/Producers in the Middle]]:
  * 당신의 개발자들이 무언가 길을 잃었다면: 생산자 역할이 모든 커뮤니케이션의 중심에 있는지 확인하라.
 * 5.1.5 [[OrgPatterns/Stable Roles]]:
  * 프로젝트 붕괴를 다뤄야 한다면: 사람들을 그들의 기본 역할로 유지하게 하고, 붕괴를 임시 작업으로 다룬다.
 * 5.1.6 [[OrgPatterns/Divide and Conquer]]:
  * 조직이 너무 커져서 커뮤니케이션이 더 이상 효과적이지 못한다면: 상호 관심과 결합에 따라 조직을 분할하여 별도의 조직과 프로세스를 형성하라.
 * 5.1.7 [[OrgPatterns/Conway's Law]]:
  * 지리, 전문성, 정치, 다른 기타 요인 사이에서 조직 구조화 문제가 괴롭다면: 기본 조직 구조를 비즈니스 도메인의 구조, 제품 아키텍처에 반영될 구조에 맞춘다.
 * 5.1.8 [[OrgPatterns/Organization Follows Location]]:
  * 작업을 지리적으로 분산해야 한다면, 커뮤니케이션에 고통을 겪지만, 작업을 분할할 수 있다면 피해를 제한할 수 있다. 따라서: 함께 작업하는 사람들 그룹이 같은 위치에 있도록 작업을 위치에 따라 조직하라.
 * 5.1.9 [[OrgPatterns/Organization Follows Market]]:
  * 시장에 대한 명확한 조직의 책임이 없다면: 시장의 요구가 충족될 수 있도록 일부 조직이 시장에 대한 책임을 지게 하라.
 * 5.1.10 [[OrgPatterns/Face to Face Before Working Remotely]]:
  * 프로젝트가 지리적으로 나뉘어졌다면: 한 곳에 모든 사람이 모인 회의로 프로젝트를 시작한다.
 * 5.1.11 [[OrgPatterns/Form Follows Function]]:
  * 전문화가 거의 없고 사람들이 기술 질문에 대한 답을 어디에서 찾아야 할지 모른다면: 산출물 또는 전문화를 중심으로 모이는, 역할이라는 전문 영역을 만든다.
 * 5.1.12 [[OrgPatterns/Shaping Circulation Realms]]:
  * 좋은 그룹 형성에 필요한 의사소통 구조를 촉진하는 메커니즘이 필요하다면: 순환 영역을 형성하라.
 * 5.1.13 [[OrgPatterns/Distribute Work Evenly]]:
  * 인적 자원 활용을 최적화하길 원한다면: 작업을 균등하게 분배하여 조직의 특정 그룹 및 특정 개인에 대한 과부하 핫스팟을 완화하라.
 * 5.1.14 [[OrgPatterns/Responsibilities Engage]]:
  * 중앙 역할들에 과부하가 걸리지만 그들을 커뮤니케이션 루프에서 제거하고 싶지 않다면: 중앙 역할에 대한 부담을 줄이기 위해 중앙 역할이 아닌 역할간의 커뮤니케이션을 강화한다.
 * 5.1.15 [[OrgPatterns/Hallway Chatter]]:
  * 개발자들이 조직의 핵심 주위를 둘러싸고 있는 경향이 있거나 지원 역할이 서로 부적절하게 참여하는 경향이 있다면: 역할과 사람간의 고립을 줄이고 더 많은 상호작용을 장려하는 방식으로 책임을 재정렬하라.
 * 5.1.16 [[OrgPatterns/Decouple Stages]]:
  * 병렬성을 높이기 위해 단계를 분리할 수 있는 일부 상위-컨텍트스 개발을 위해 단계가 너무 끼워졌다면: 단계간에 잘 정의된 핸드오프를 사용하여 프로세스 단계를 직렬화한다.
 * 5.1.17 [[OrgPatterns/Hub Spoke and Rim]]:
  * 컨텍스트가 높은 개발 프로세스에서 단계를 분리하려면: 허브 역할을 사용하여 프로세스를 조정하고, 허브-스포크-림 형상에서 다른 역할간의 결합을 최소화한다.
 * 5.1.18 [[OrgPatterns/Move Responsibilities]]:
  * 역할 사이의 결합을 변경하고 싶다면 (특히 역할을 분리하려는 경우): 책임을 한 역할에서 다른 역할로 옮긴다.
 * 5.1.19 [[OrgPatterns/Upside Down Matrix Management]]:
  * 적절한 기술과 리소스가 작업의 특정 측면에 적용되는 것 같지 않다면: 기업 구조를 넘어 다른 조직(고객, 파트너, 기타 내부 조직)의 팀을 활용한다.
 * 5.1.20 [[OrgPatterns/The Water Cooler]]:
  * 제도화된 조직들 간에 더 많은 의사소통이 필요하다면: 더 완전하고 비공식적인 의사소통을 제공할 수 있는 일상적인 인간 활동을 위한 공간을 직장에 남겨둔다.
 * 5.1.21 [[OrgPatterns/Three to Seven Helpers oer Role]]:
  * 의사소통을 균등하게 하려면: 최소한 역할당 3~7명의 도우미로 의사소통을 제한하고, 아웃라이어들을 동일한 수준의 참여로 끌어올리라.
 * 5.1.22 [[OrgPatterns/Coupling Decreases Latency]]:
  * 높은 처리량의 개발 프로세스가 필요하다면: 역할 간의 결합을 늘려 대기 시간을 줄이라.
 * 5.1.23 [[OrgPatterns/Standards Linking Locations]]
}}}

=== 5.2 People and Code Pattern Language ===

{{attachment:orgpattern-people-and-code.PNG}}

{{{#!wiki multi-columns
 * 5.2.1 [[OrgPatterns/Community of Trust]]
 * 5.2.2 [[OrgPatterns/Conway's Law]]
 * 5.2.3 [[OrgPatterns/Architect Controls Product]]:
  * 프로젝트의 수명이 길다면: 아키텍트를 사용하여 비전을 전진시키고 아키텍처 스타일의 장기적인 지킴이 역할을 하게 한다.
 * 5.2.4 [[OrgPatterns/Architecture Team]]:
  * 시스템을 너무 크거나 복잡하여 한 개인이 완전히 이해할 수 없다면: 아키텍처를 생성하는 책임과 권한을 모두 가진 팀을 구성하라.
 * 5.2.5 [[OrgPatterns/Lock'em Up Together]]:
  * 팀이 아키텍처를 마련하기 위해 고군분투하고 있다면: 인터럽트 없이 작업할 수 있도록 며칠 동안 물리적으로 그들을 격리한다.
 * 5.2.6 [[OrgPatterns/Smoke Filled Room]]:
  * 신속하게 결정을 내릴 필요가 있고 다른 사람들을 배제할 이유가 있다면: 결정이 공개되더라도 근거가 비공개로 유지되도록 은밀하게 결정을 내린다.
 * 5.2.7 [[OrgPatterns/Stand Up Meeting]]:
  * 잘못된 정보가 많거나 루프를 벗어난 사람들이 있다면: 매일 짧은 회의를 개최하여 최근의 개발 상황을 공유한다.
 * 5.2.8 [[OrgPatterns/Deploy Along the Grain]]:
  * 재사용이 산출물에 대한 책임의 단편화로 인해 고통을 겪고 있다면: 사람들에게 시스템의 관리 부분에 대한 헌신적이고 장기적인 책임을 부여하라.
 * 5.2.9 [[OrgPatterns/Subsystem by Skill]]
 * 5.2.10 [[OrgPatterns/Architect Also Implements]]:
  * 아키텍트가 상아탑 위에 있다면, 그들은 손 닿는 거리 밖에 있는 것이다; 그러나 누군가는 크고 긴 관점을 취하고 그것을 실제와 조화시켜야 한다. 따라서: 아키텍트는 일상적인 구현에 실질적으로 관여한다.
 * 5.2.11 [[OrgPatterns/Generics and Specifics]]:
  * 새로운 사람이 많다면: 경험이 많은 사람을 작업의 일반적인 부분에 배치하고, 새로운 사람에게 특정 임무를 부여한다.
 * 5.2.12 [[OrgPatterns/Standards Linking Locations]]:
  * 지리적으로 분리된 개발이 있다면: 표준을 사용하여 지리적 경계를 넘어서는 아키텍처의 부분들을 함께 연결한다.
 * 5.2.13 [[OrgPatterns/Code Ownership]]:
  * 코드에 대한 책임이 필요하고 [[OrgPatterns/Domain Expertise in Roles]]를 기반으로 하고 싶다면: 코드의 전반적인 품질에 대한 책임을 다양한 개인에게 부여하라.
 * 5.2.14 [[OrgPatterns/Feature Assignment]]:
  * 대규모 프로젝트에서 작업을 분할하려 한다면: 사람들에게 기능을 할당하라.
 * 5.2.15 [[OrgPatterns/Variation Behind Interface]]:
  * 둘 이상의 사람이 소프트웨어를 개발하는 경우, 변경사항은 코드 뿐 아니라 사람에게도 영향을 미친다. 따라서: 예측된 변동 지점을 중심으로 인터페이스를 만든다.
 * 5.2.16 [[OrgPatterns/Private Versioning]]:
  * 배포하지 않고 증분 변경을 활성화하길 원한다면: 공용 저장소에 체크인하지 않고 코드를 버전화할 수 있는 메커니즘을 마련하라.
 * 5.2.17 [[OrgPatterns/Loose Interfaces]]:
  * 커뮤니케이션이 최적이 아닌 환경에서 시스템을 신속하게 개발해야 한다면: 명시적, 정적 인터페이스의 수를 제한하라. 콜백과 같은 느슨한 인터페이스를 사용하라.
 * 5.2.18 [[OrgPatterns/Subclass per Team]]:
  * 하위 시스템 팀이 서로 다른 설계 중점을 가지고 있다면: 두 하위 시스템이 한 클래스에서 충돌하는 경우, 클래스 계층 구조의 다른 계층에 할당하라.
 * 5.2.19 [[OrgPatterns/Hierarchy of Factories]]:
  * 서로 다른 그룹에 의해 지정된 서로 다른 제품을 만드는 창조 시스템이 있다면: 계층적 배열로 공장을 설정하라. 여기서 각각은 1수준 아래에 대해서만 알고 있다.
 * 5.2.20 [[OrgPatterns/Parser Builder]]:
  * 입력 스트림의 유형 정보를 기반으로 객체를 생성해야 한다면: 스트림에서 유형 정보를 읽고 이 정보를 기반으로 적절한 객체를 빌드하는 파서 빌더를 사용한다.
 * 5.2.21 [[OrgPatterns/Incremental Integration]]
 * 5.2.22 [[OrgPatterns/Private World]]
 * 5.2.23 [[OrgPatterns/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 [[OrgPatterns/Arranging the Furniture]]
 * 10.5.2 [[OrgPatterns/Ad-Hoc Corrections]]
 * 10.5.3 [[OrgPatterns/All At Once]]
 * 10.5.4 [[OrgPatterns/Architecture Definition Team]]
 * 10.5.5 [[OrgPatterns/Balanced Team]]
 * 10.5.6 [[OrgPatterns/Business Process Model]]
 * 10.5.7 [[OrgPatterns/Clear The Fog]]
 * 10.5.8 [[OrgPatterns/Creator-Reviewer]]
 * 10.5.9 [[OrgPatterns/Demo Prep]]
 * 10.5.10 [[OrgPatterns/Designer are Our Friends]]
 * 10.5.11 [[OrgPatterns/Early and Regular Delivery]]
 * 10.5.12 [[OrgPatterns/Establish the Business Objectives]]
 * 10.5.13 [[OrgPatterns/Get Involved Early]]
 * 10.5.14 [[OrgPatterns/Gradual Stiffening]]
 * 10.5.15 [[OrgPatterns/Guru Does All]]
 * 10.5.16 [[OrgPatterns/Market Walk-through]]
 * 10.5.17 [[OrgPatterns/Master-Journeyman]]
 * 10.5.18 [[OrgPatterns/Micro Cosm]]
 * 10.5.19 [[OrgPatterns/Owner Per Deliverable]]
 * 10.5.20 [[OrgPatterns/Participating Audience]]
 * 10.5.21 [[OrgPatterns/Peace Maker]]
 * 10.5.22 [[OrgPatterns/Product Initiative]]
 * 10.5.23 [[OrgPatterns/Proto Types]]
 * 10.5.24 [[OrgPatterns/Query Objects]]
 * 10.5.25 [[OrgPatterns/Shared Clear Vision]]
 * 10.5.26 [[OrgPatterns/Shearing Layers]]
 * 10.5.27 [[OrgPatterns/Small Writing Team]]
 * 10.5.28 [[OrgPatterns/Skill Mix]]
 * 10.5.29 [[OrgPatterns/Work Allocation]]

----

CategoryPattern