Differences between revisions 27 and 73 (spanning 46 versions)
⇤ ← Revision 27 as of 2020-09-17 03:03:46 →
Size: 30810
Editor: 정수
Comment:
← Revision 73 as of 2021-01-12 06:16:11 → ⇥
Size: 32829
Editor: 정수
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
#acl +All:read

JimCoplien 이 쓴 책.

<<TableOfContents(3)>>
Line 31: Line 37:
{{{#!wiki multi-columns
Line 39: Line 47:
ChristopherAlexander 는 모든 시스템의 질서는 근본적으로 시스템을 구축하는데 사용되는 프로세스에 달려 있다고 믿는다. 이것이 근본적인 프로세스(fundamental process)가 중요한 이유이다. ([[/PIECEMEAL GROWTH]] 참조) ChristopherAlexander 는 모든 시스템의 질서는 근본적으로 시스템을 구축하는데 사용되는 프로세스에 달려 있다고 믿는다. 이것이 근본적인 프로세스(fundamental process)가 중요한 이유이다. ([[OrgPatterns/PIECEMEAL GROWTH]] 참조)
Line 72: Line 80:
}}}
Line 104: Line 114:
 * 4.1.1 [[/Community of Trust]]: {{attachment:orgpattern-management.PNG}}

{{{#!wiki multi-columns
 * 4.1.1 [[OrgPatterns/Community of Trust]]:
Line 106: Line 119:
  * If you are building any human organization, Then: you must have a foundation of trust and respect for effective communication at levels deep enough to sustain growth.
 * 4.1.2 [[/Size the Schedule]]:		  * 4.1.2 [[OrgPatterns/Size the Schedule]]:
Line 109: Line 121:
  * If the schedule is too long, developers become complacent; but if it is too short, they become overtaxed. Therefore: reward meeting the schedule, and keep two sets of books.
 * 4.1.3 [[/Get on With It]]:		  * 4.1.3 [[OrgPatterns/Get on With It]]:
Line 112: Line 123:
  * If you are starting a project and have enough information to get started on parts of it, Then: don’t wait until you have a complete schedule before starting to do parts of the project.
 * 4.1.4 [[/Named Stable Bases]]:		  * 4.1.4 [[OrgPatterns/Named Stable Bases]]:
Line 115: Line 125:
  * If you want to balance stability with progress, Then: have a hierarchy of named stable bases that people can work against.
 * 4.1.5 [[/Incremental Integration]]:		  * 4.1.5 [[OrgPatterns/Incremental Integration]]:
Line 118: Line 127:
  * If you want developers to be able to test changes before publishing them, Then: allow developers to build the entire product code independently to allow testing with the very latest base (not the latest Named Stable Base).
 * 4.1.6 [[/Private World]]:		  * 4.1.6 [[OrgPatterns/Private World]]:
Line 121: Line 129:
  * If you want to isolate developers from the effects of changes, Then: allow developers to have private work spaces containing the entire build environment.
 * 4.1.7 [[/Build Prototypes]]:		  * 4.1.7 [[OrgPatterns/Build Prototypes]]:
Line 124: Line 131:
  * If early acquired requirements are difficult to validate without testing, Then: build a prototype, whose purpose is to understand requirements.
 * 4.1.8 [[/Surrogate Customer]]
 * 4.1.9 [[/Take No Small Slips]]:		  * 4.1.8 [[OrgPatterns/Surrogate Customer]]
 * 4.1.9 [[OrgPatterns/Take No Small Slips]]:
Line 128: Line 134:
  * If you are getting behind schedule and need additional time resources, Then: take one large planned slip instead of allowing yourself to nickel and dime yourself to death with small, unanticipated slips.
 * 4.1.10 [[/Completion Headroom]]:
  * 일련의 중요한 일정들에 대해 작업이 진행중이라면: 가장 큰 작업의 완료 날짜와 중요한 배포 일자 사이에 [[/Completion Headroom]]이 있는지 확인하라.
  * If work is progressing against a set of hard dates, Then: make sure there is COMPLETION HEADROOM (4.1.10) between the completion dates of the largest task and the hard delivery dates.
 * 4.1.11 [[/Work Split]]:
  * 문제에 너무 가까이에 있는 사람들이 "돼지 통" 문제나 선의의 문제로 문제를 확대하는 경우: 작업을 긴급 및 지연된 구성 요소로 나누고, 긴급한 작업에 개발 작업의 절반 미만이 투입되도록 하라.
  * If people too close to the problem are escalating their problems, either as a “pork barrel” issue or as something well-intentioned, Then: split work into an urgent and deferred component, with less than half of development work in the urgent half.
 * 4.1.12 [[/Recommitment Meeting]]:
  * If: the schedule can’t be met with simple adjustments to the work queue and staffing, Then: assemble developers and interested managers to recommit to a new strategy based on doing the minimal amount of work to reach a satisfactory conclusion
 * 4.1.13 [[/Work Queue]]:
  * If deliverables are ill-defined, you need to allow time to do everything. Therefore: produce a schedule with less output than you have input. Use the list of IMPLIED REQUIREMENTS (4.1.16) (really just names) as a starting point and order them into a likely implementation order favoring the more urgent or higher priority items.
 * 4.1.14 [[/Informal Labor Plan]]:
  * If developers need to do the most important thing now, Then: let developers negotiate among themselves or “just figure out the right thing to do” as regards short term plans, instead of master planning.
 * 4.1.15 [[/Development Episode]]:
  * If we overemphasize individual contributor skills, work suffers. Therefore: approach all development as a group activity as if no one had anything else to do.
 * 4.1.16 [[/Implied Requirements]]:
  * If you need a way to nail down the functionality that needs to be covered, Then: make a list of functional areas and domains instead of breaking it down into traditional requirements.
 * 4.1.17 [[/Developer Controls Process]]:
  * If you need to orchestrate the activities of a given location or feature, Then: put the Developer role in control of the succession of activities.
 * 4.1.18 [[/Work Flows Inward]]:
  * If you want information to flow to the producing roles in an organization, Then: put the developer at the center and see that information flows toward the center, not from the center.
 * 4.1.19 [[/Programming Episode]]:
  * If you need to split up work across time, Then: do the work in discrete episodes with mind share to commit to concrete deliverables.
 * 4.1.20 [[/Someone Always Makes Progress]]:
  * If Distractions constantly interrupt your team’s progress, Then: whatever happens, ensure someone keeps moving toward your primary goal.
 * 4.1.21 [[/Team per Task]]:
  * If a big diversion hits your team, Then: let a sub-team handle the diversion, the main team keeps going.
 * 4.1.22 [[/Sacrifice One Person]]:
  * If a smaller diversion hits your team, Then: assign just one person to it until it gets handled.
 * 4.1.23 [[/Day Care]]:
  * If your experts are spending all their time mentoring novices, Then: put one expert in charge of all the novices, let the others develop the system.
 * 4.1.24 [[/Mercenary Analyst]]:
  * If you want to keep documentation from being a critical path roadblock for developers, Then: hire a MERCENARY ANALYST.
 * 4.1.25 [[/Interrupts Unjam Blocking]]:
  * If you need to schedule urgent development activities according to some reasonable priority scheme, Then: use an interrupt scheme to keep individual problems from blocking the entire project.
 * 4.1.26 [[/Don't Interrupt an Interrupt]]:
  * If you’re in the middle of handling an interrupt to keep the project from getting stuck, and a new urgent need arises, Then: continue handling the current issue before moving on to the new one.		  * 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]]:
  * 프로젝트가 중단되는 것을 방지하기 위해 인터럽트를 처리하는 중이고, 새로운 긴급한 요구가 발생했다면: 새로운 문제로 이동하기 전에 현재의 이슈를 계속하여 처리한다.
}}}
Line 168: Line 172:
 * 4.2.1 [[/Community of Trust]]
 * 4.2.2 [[/Size the Organization]]:
  * If an organization is too large, communications break down, and if it is too small, it can’t achieve its goals or easily overcome the difficulties of adding more people. Therefore: start projects with a critical mass of about 10 people.
 * 4.2.3 [[/Phasing it in]]:
  * If you can’t always get the experts you need, Then: grow new experts from new hires.
 * 4.2.4 [[/Apprenticeship]]:
  * If you have difficulty retaining expertise, Then: grow expertise internally from existing employees or even new hires.
 * 4.2.5 [[/Solo Virtuoso]]:
  * If a project is intellectually small, then overstaffing it is a waste of time and money. Therefore: staff small projects with SOLO VIRTUOSOS.
 * 4.2.6 [[/Engage Customers]]:
  * If you want to manage an incremental process that accommodates customer input, and if you want the customer to feel loved, Then: engage customers after Quality Assurance and project management are prepared to serve them.
 * 4.2.7 [[/Surrogate Customer]]:
  * If you need answers from your customer, but no customer is available to answer your questions, Then: create a surrogate customer role in your organization to play advocate for the customer.
 * 4.2.8 [[/Scenarios Define Problem]]:
  * If you want a good characterization of customer needs, Then: use scenarios to define the problem.
 * 4.2.9 [[/Fire Walls]]:
  * If you want to keep your developers from being interrupted by extraneous influences and special interest groups, Then: impose a Fire Wall, such as a manager, who “keeps the pests away.”
 * 4.2.10 [[/Gate Keeper]]:
  * If you need to keep from being inbred, Then: use a GATE KEEPER (4.2.10) role to tie together development with other projects, with research, and the outside world.
 * 4.2.11 [[/Self Selecting Team]]:
  * If you appoint people to a team, it doesn’t come together as a team. But people with outside interests and who wish to joint a team make the best team members. Therefore: teams should be largely self-selecting with limited screening on the basis of track record and outside interests.
 * 4.2.12 [[/Unity of Purpose]]:
  * If a team is beginning to work together, Then: make sure all members agree on the purpose of the team.
 * 4.2.13 [[/Team Pride]]:
  * If a team needs to perform above and beyond the call of duty, Then: instill a well-grounded sense of elitism in its members.
 * 4.2.14 [[/Skunk Works]]:
  * If a project innovates too much, then it increases its risk; yet there is a place for innovation. Therefore: give innovation an organizational space and time.
 * 4.2.15 [[/Patron Role]]:
  * If you need to insulate Developers so DEVELOPER CONTROLS PROCESS (4.1.17) and provide some organizational inertia at the strategic level, Then: identify a patron to whom the project has access, who can champion the cause of the project.
 * 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]]:		 {{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]]:
  * 장기적으로 하위 시스템을 구성해야 할 필요가 있다면: 기술에 따라 하위 시스템을 나눈다.
Line 213: Line 221:
 * 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.		  * 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]] 및 다른 것들을 하여, 시스템을 검증하라.
}}}
Line 234: Line 243:
 * 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]]		 {{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]]
}}}
Line 281: Line 294:
 * 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]]		 {{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]]
}}}
Line 415: Line 432:
 * 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]]		  * 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

JimCoplien 이 쓴 책.

Contents

  1. Part 1. History and Introduction
    1. Chapter 1. An Overview of Patterns and Organizational Patterns
      1. 1.1 What are Patterns?
      2. 1.2 What are Pattern Languages?
      3. 1.3 Organizational Pattern Languages
    2. Chapter 2. How the Patterns Came to Us
      1. 2.1 Gathering Organizational Data
      2. 2.2 Creating Sequences
      3. 2.3 History and Related Work
    3. Chapter 3. How to Use This Book
      1. 3.1 Reading the Patterns
      2. 3.2 Applying the Patterns
      3. 3.3 Updating the Patterns
      4. 3.4 Who Should Use This Book?
  2. Part 2. The Pattern Languages
    1. Chapter 4. Organization Design Patterns
      1. 4.1 Project Management Pattern Language
      2. 4.2 Piecemeal Growth Pattern Language
    2. Chapter 5. Organization Construction Patterns
      1. 5.1 Organizational Style Pattern Language
      2. 5.2 People and Code Pattern Language
  3. Part 3. Foundations and History
    1. Chapter 6. Organizational Principles
      1. 6.1 Priming the Organization for Change
      2. 6.2 Piecemeal Growth
      3. 6.3 Some General Rules
    2. Chapter 7. Anthropological Foundations
      1. 7.1 Patterns in Anthropology
      2. 7.2 Beyond Process to Structure and Values
      3. 7.3 Roles and Communication
  4. Part 4. Case Studies
    1. Chapter 8. Borland Quattro Pro for Windows
    2. Chapter 9. A Hyperproductive Telecommunications Development Team
  5. Part 5. Appendices
    1. Chapter 10. Summary Patlets
      1. 10.1 Project Management Patlets
      2. 10.2 Piecemeal Growth Patlets
      3. 10.3 Organizational Style Patlets
      4. 10.4 People and Code Patlets
      5. 10.5 Patlets from Other Pattern Languages

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)가 중요한 이유이다. (OrgPatterns/PIECEMEAL GROWTH 참조)

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

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

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

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

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

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

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

2.2.2 우리의 시퀀스들

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

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

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

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

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

orgpattern-management.PNG

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

  • 4.1.25 OrgPatterns/Interrupts Unjam Blocking:

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

  • 4.1.26 OrgPatterns/Don't Interrupt an Interrupt:

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

4.2 Piecemeal Growth Pattern Language

orgpattern-piecemeal-growth.PNG

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

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

Chapter 5. Organization Construction Patterns

5.1 Organizational Style Pattern Language

orgpattern-org-style.PNG

  • 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

orgpattern-people-and-code.PNG

  • 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

CategoryPattern

책/OrganizationPatternsOfAgileSoftwareDevelopment (last edited 2021-01-12 06:16:11 by 정수)