Alistair Cockburn이 지은 책.

이 책은 이 질문에 대해 답한다.

십여년 동안 성공적인 작은 팀들을 디브리핑하면, 대부분 같은 메세지를 답했다:

이 모든 것을 하고, 대부분의 상세한 프로세스는 will take care of themselves.

Crystal Clear는 간단하게 이렇게 묘사할 수 있다.

이 간단한 제안은 경험과 이론 모두에서 뒷받침한다. 소프트웨어 개발의 특징은 경제적으로 제약된 개발과 커뮤니케이션의 협력 게임(CooperativeGame)이라는 점이다.

Crystal의 유전 코드는 아래와 같은 것들로 만들어진다:

경제적 협력 게임 모델은, 소프트웨어 개발은 일련의 '게임'이라고 말한다. 어떤 게임이냐면, 발명하기와 의사소통하기 외에는 아무 것도 없는, 전형적인 자원 제한 상태인 게임이다. 일련의 게임 안에 있는 각 게임은 리소스를 두고 경쟁하는 두 가지 목표가 있는데: 이 게임에서 소프트웨어를 완성하기와, 다음 게임을 위해 준비하는 것이다. 각 게임은 반복되지 않으므로, 매 프로젝트에서는 이전의 모든 게임들과 약간 다른 전략을 필요로 한다. 경제 협력 게임 모델은, 사람들이 자신의 작업에 대해 매우 구체적이고 집중적이며 효과적인 방식으로 생각하도록 유도한다.

Crystal 패밀리에서 공통되는 우선순위는

Crystal은 7가지 안전 속성을 지향하며, 그 중 첫 3개가 Crystal의 핵심이다.

Crystal의 원칙들은 책/AgileSoftwareDevelopmentTheCooperativeGame에 자세하게 설명되어 있다. 그 중 몇 가지 핵심 아이디어는:

Crystal Clear는 팀이 같은 방이나 인접한 사무실에 앉아 있는 2~8명으로 구성된 경우 적용할 수 있는 Crystal의 최적화이다. 긴밀한 의사소통의 속성은 삼투 커뮤니케이션으로 강화되는데, 이는 사람들이 매일 프로젝트 우선순위, 상태, 요구사항 및 설계에 대해 서로 논의하는 것을 의미한다. 이 향상된 의사 소통을 통해 팀은 다른 방법으로 가능한 것보다 암묵적인 의사 소통과 작은 노트에서 더 많은 작업을 할 수 있다.

Chapter 2. Applied (The Seven Properties)

Crystal Clear를 읽으면 두 가지 질문이 생긴다:

이 쳅터에서는 최고의 팀들에 의해 설정된 7가지 속성(properties)들을 설명한다. CrystalClear는 첫 세 가지가 필요하다. 더 나은 팀은 나머지 4가지를 안전지대로 더 멀리 가기 위해 사용한다. 삼투적 커뮤니케이션을 제외한 모든 속성은 모든 규모의 프로젝트에 적용된다.

나는 최근에야 최고의 컨설턴트들이, 따르는 절차보다는 프로젝트에 속성에 대한 메모를 거래한다는 사실을 깨달았다. 그들은 프로젝트의 건강 후에 질문한다(?): 사명 선언문과 프로젝트 계획이 있나요? 그들은 자주 배포하나요? 스폰서와 다양한 전문가 사용자가 팀과 긴밀하게 접촉하고 있나요?

결과적으로, 방법론이 일반적으로 설명되는 방식에서 벗어나서, 나는 CrystalClear 팀에게 프로젝트의 주요 '속성'을 목표로 하도록 종용한다. 'CrystalClear 하기'는, 절차를 따르기보다는 이 속성들을 달성하는 것이다. 두 가지 동기가 절차에서 속성으로의 이러한 전환을 유도한다:

Crystal 패밀리는 세 가지 속성에 집중한다: 잦은 전달(frequent delivery), 긴밀한 의사소통, 반성적 개선 - 모든 프로젝트에서 이것들이 발견되어야 한다. CrystalClear는 팀의 규모가 작다고 근접하다는 이점을 활용하여, 긴밀한 의사소통을 더 강력한 삼투적 의사소통으로 강화한다. 그 하나의 변화를 제외하고는, 숙련된 개발자는 이 쳅터에서 설명하는 모든 속성들이 소규모 팀 프로젝트 뿐 아니라 모든 프로젝트에 적용된다는 것을 알아차릴 것이다.

CrystalClear를 속성의 집합으로 설명함으로써, 나는 프로젝트의 느낌에 도달하고 싶다. 대부분의 방법론 설명은 성공적인 팀과 실패한 팀을 분리하는 결정적인 느낌을 좋친다. CrystalClear 팀은, 전달하는 속도만큼이나 팀의 분위기와 커뮤니케이션 패턴으로 상태를 측정한다. 속성에 이름을 붙이는 것은 또한 팀이 그들의 상황을: "우리는 한동안 '반성적 개선'을 하지 않았어", "우리가 좀 더 전문가 사용자에게 쉽게 접근할 수 있을까?" 라며 측정할 수 있게 한다. 속성 이름은 그 자체로 사람들이 현재 상태를 고치기 위해서 진단하고 논의하는 데 도움이 된다.

속성 1. Frequent Delivery

어느 프로젝트에서건, 크던, 작던, 애자일하던 아니던, 단 하나의 가장 중요한 것은, 동작하고, 테스트된 코드를 실제 사용자들에게 매 수개월마다 전달하는 것이다. 그 이점은 상당히 많은데,

이러한 모든 이점은, 단 하나의 속성: 잦은 배포에서 비롯된다. 인터뷰들을 하면서, 나는 4개월을 넘기면서 이 안전성을 제공하는 것을 보지 못했다. 2개월이 더 안전하다. 웹에 배포하는 팀은 매주마다 배포할 수도 있다.

지난 6개월 동안, 동작하고, 테스트되고, 사용 가능한 코드를 당신의 사용자 커뮤니티에 최소한 2번 이상 전달했는가?

그러면, '배포(delivery)'란 무엇을 뜻하는가?

때로는 그것은 소프트웨어가 각 이터레이션의 끝에, 프로덕션 사용을 위해서 모든 사용자들에게 전달되는 것을 뜻한다. 이것은 웹 배포 소프트웨어나 사용자 그룹이 상대적으로 작을 때 실용적이다.

만약 사용자들이 그렇게 잦은 소프트웨어 업데이트를 수용하기 어렵다면, 팀은 어려움에 처하게 된다. 시스템을 자주 전달하면, 사용자 커뮤니티가 짜증을 낼 것이다. 자주 제공하지 않으면 통합 또는 배포와 관련된 실제 문제를 놓칠 수 있다. 매우 늦게, 즉 시스템을 배포하는 순간에 그 문제에 직면하게 될 것이다.

이러한 경우 내가 아는 최선의 전략은, 소프트웨어를 테스트해보는 것을 귀찮아하지 않는, 그게 존중 때문이든 호기심 때문이든, 우호적인 유저를 찾는 것이다. 그 컴퓨터 하나에만 테스트용으로 배포한다. 이렇게 함으로써 팀은 배포를 연습하고 최소한 한 명의 유저로부터 유용한 피드백을 얻게 된다.

그러한 우호적인 유저를 찾을 수 없다면, 최소한, 전체 통합을 수행하고 테스트하라. 이를 통해, 잠재적인 결함이 있는 배포만 남게 된다.

통합, 이터레이션, user viewing, 릴리즈는 요즘에는 뒤섞여서 사용된다. 이들 각각은 개발에 서로 다른 영향을 주기 때문에, 구분해서 생각해야 한다.

잦은 통합은 일상이 되어야 한다. 매 시간, 매일, 최소한 매주마다 일어나는. 요즘에 더 나은 팀들은 자동화된 빌드-테스트 스크립트를 수행하며, 체크인으로부터 30분이 채 되기 전에 자동화된 테스트 결과를 얻는다.

잦은 배포는 소프트웨어를 유저에게 전달하는 것이지, 단지 이터레이션을 반복하는게 아니다. 내가 방문했던 어떤 신경질적인 프로젝트 팀은 거의 1년간 매달마다 한번씩 이터레이션을 했는데, 단 한번도 릴리즈는 하지 않았다. 사람들은 점점 신경질적이 되어갔다. 왜냐면 고객은 그들이 지난 1년간 뭘 해왔는지 보지를 못했기 때문이다. 이 조직은 잦은 배포를 위반한 것이다.

속성 2. Reflective Improvement

나를 완전히 놀라게 했던 한 발견은, 팀이 함께 모이고, 작동하는 것과 작동하지 않는 것을 나열하고, 더 잘 작동할 수 있는 것에 대해 논의하고, 다음 이터레이션에 그러한 변화들을 만들어내면, 프로젝트가 재앙적인 실패에서 성공으로 운을 되돌릴 수 있다는 것이다. 다른 말로, 회고하고 개선하라. 팀은 이 일에 대해 엄청나게 많은 시간을 쏟을 필요 없이, 몇 주나 몇달에 한번씩 한시간 정도만 투자하면 된다. 무엇이 더 잘 작동할 수 있을지 생각하기 위해 매일의 개발에 시간을 할애한다는 사실만으로도 이미 효과적이다.

속성 3. Osmotic Communication

삼투적 의사소통은, 정보가 팀원들의 배경 소리 속에 흘러 들어가서, 마치 삼투처럼, 그들이 연관된 정보를 길어올릴 수 있게 하는 것이다. 이것은 통상적으로 같은 방에 앉은 경우에 이루어진다. 그리고, 어떤 사람이 질문을 하면, 방에 있는 다른 사람들은 토론에 참여하거나 참여하지 않고 그들의 업무를 계속할 수 있다. 몇몇 사람들은 이 사람이 했던 것에 그들의 경험을 빗대었다:

삼투적 의사소통이 자리를 잡으면, 질문과 답변이 자연스럽게 흐르고, 팀 안에 방해는 놀랍게도 매우 적다.

삼투적 의사소통과 잦은 배포는 프로젝트가 다른 구조를 거의 사용하지 않고 작동할 수 있는 빠르고 풍부한 피드백을 촉진한다.

삼투적 의사소통은 소규모 프로젝트에서 Crystal 패밀리의 핵심 속성인 긴밀한 의사소통을 얻을 수 있는 보다 강력한 버전이다. 삼투적 의사소통은 커뮤니케이션 비용을 낮추고 피드백 속도를 높여서, 오류를 매우 빠르게 수정하고 지식을 빠르게 전파한다. 사람들은 프로젝트 우선순위와, 누가 어떤 정보를 보유하고 있는지 배운다. 그들은 새로운 프로그래밍, 설계, 테스팅, 도구 처리 트릭을 고른다. 그들은 큰 오류로 자라기 전에 작은 오류를 포착하고 수정한다.

삼투적 의사소통은 대규모 프로젝트에도 가치가 있지만, 팀 규모가 커짐에 따라 달성하기가 점점 어려워진다.

사람들이 같은 방에 있지 않다면 삼투적 의사소통을 자극하기가 어렵다. 그러나, 각각에 2-3명이 있는 인접한 방은 많은 이점을 제공한다. Herring 은 웹캠, 마이크 및 채팅 세션과 함께 고속 인트라넷을 사용하여 질문과 코드를 교환하고, 어느 정도까지 하나의 룸을 시뮬레이션한다고 보고했다. 좋은 기술을 사용하면 팀은 어떤 목적에 대해 어느 정도 긴밀한 의사소통을 달성할 수 있지만, 팀원 간의 물리적 근접성 외에는 삼투적 의사소통이 달성되는 것을 아직 보지 못했다.

삼투적 의사소통에 대한 논의는 필연적으로 사무실 배치 및 사무용 가구에 대한 논의로 이어진다.

Crystal Clear는 사람들이 유용한 정보를 엿듣고(overhear), 질문에 대한 답을 빨리 얻을 수 있도록 서로 매우 가까이 있어야 한다. 이를 수행하는 확실한 방법은 모든 사람을 단일 방(war room)에 두는 것이다. 반복적으로 매우 효과적인 것으로 나타났다.

Chapter 9. Distilled (The Short Version)

Crystal Clear의 핵심은 무엇인가?

ClystalClear는 작고 한 곳에 있는 팀을 매우 효율적으로 활용하기 위한 방법으로서, 만족스러운 결과물을 전달하는데 있어 효율성, 거주가능성(habitability: 아마도, 규범들이 실현 가능하고 지속 가능한지를 말하는듯.), 안전성을 우선으로 한다. level-3 실천가가 CrystalClear를 간단하게 설명하면 이럴 것이다:

팀 멤버들은 그들이 적절하다고 생각하는 기법들을 사용하여 아래 안전성 속성들을 수립한다. 첫 세 가지는 CrystalClear에 필수적이고, 나머지 네 개는 팀을 safety zone으로 더 깊이 들어가게 할 것이다.

  1. 잦은 전달
  2. 반성적(reflective) 개선
  3. 밀접한(close) 커뮤니케이션 (osmotic communication)
  4. 개인적 안전감 (신뢰의 첫 걸음)
  5. 초점 (집중)
  6. 전문가 유저(expert users)에게 접근하기 쉬움
  7. 기술적 환경; 자동화된 테스팅, 형상 관리, 잦은 통합