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 사람과 코드 패턴 언어)

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

• 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.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 및 다른 것들을 하여, 시스템을 검증하라.

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