#acl +All:read

AlistairCockburn이 지은 책.

<<TableOfContents(3)>>

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

 * 다른 작고 성공적인 프로젝트 팀들은 뭘 했길래 성공했을까?
 * 그들은 어떤 프랙티스를 사용할까?


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

 * 사람들이 함께 가깝게 앉게 하라. 자주 좋은 의지(goodwill)를 가지고 소통하게 하라.
 * 조직(bureaucracy)을 최대한 활용하고 설계하게 하라.
 * 실제 유저가 직접 개입하게 하라.
 * 좋은 자동화 회귀 테스트 집합을 마련하라.
 * 배포(shipping) 가능한 기능을 일찍, 그리고 자주 생산하라.

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

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

   리드 디자이너, 그리고 2~7명의 다른 개발자들이 큰 방 혹은 인접한 방에 있고, 정보 방열기 - 화이트보드나 플립 차트 같은 것이 벽에 걸려 있고, 핵심 사용자에게 접근하며, 방해(distractions)를 멀리 하고, 동작하고 테스트 되었고 유용한 코드를 매 한두달 (뭐, 최대한 세달까지)마다 한번씩 전달하고, 그들의 일하는 스타일을 주기적으로 회고(reflect)하고 조정한다.

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

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

 * 경제적 협력 게임 모델
 * 선별된 우선순위들
 * 선별된 속성들
 * 선별된 원칙들
 * 선별된 예시 테크닉들
 * 프로젝트 예시들

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

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

 * 프로젝트 결과물의 ''안전성''
 * 개발의 ''효율성''
 * 관습의 ''Habitability'' (개발자들이 그렇게 살기에 알맞은)

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

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

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개월 동안, 30분, 1시간 또는 반나절 동안, 한 번 이상 모여서 노트를 비교하고, 회고하고, 그룹의 작업 습관을 논의하고, 무엇이 속도를 높이는지, 속도를 낮추는지, 개선하기 위해 뭘 할 수 있는지 논의한 적이 있는가?



=== 속성 3. Osmotic Communication ===

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

    우리는 4명이 페어 프로그래밍을 했다. 상사가 들어와서 내 동료에게 질문을 했다. 나는 대답하기 시작했지만, 모듈의 이름을 잘못 불렀다. 닐과 함께 프로그래밍하던 낸시가 그것을 정정해주었고, 닐은 그녀가 말했다는 것도, 답변된 질문이 있었다는 것도 몰랐다.
    
삼투적 의사소통이 자리를 잡으면, 질문과 답변이 자연스럽게 흐르고, 팀 안에 방해는 놀랍게도 매우 적다.

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

    질문에 답할 수 있는 사람의 눈이나 귀에 질문을 전달하는데 30초 이내로 걸리는가? 적어도 며칠에 한번씩은 다른 팀원들과의 대화에서 뭔가 관련이 있는 것을 엿듣는(overhear)가?


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

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

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

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

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

삼투적 커뮤니케이션은 단점도 있는데, 가장 공통적으로는 소음, 그리고 팀의 가장 전문가 개발자에게 질문이 쏟아진다는 것이다. 일반적으로 이런 현상은 자정되고, 잡담은 덜 하거나, 상대방의 생각할 시간을 존중하게 된다.

리드 설계자를 독립 사무실에 둬서 '보호'하려는 시도는 대개 역효과를 낳는다. 실제로는 그 사람은 개발 팀의 한 가운데 앉을 필요가 있다. 리드 설계자는 종종 기술 전문가, 도메인 전문가, 최고의 프로그래머라서 요청받을 일이 많다. 그가 자리를 비우면, 어린 개발자들은 좋은 개발 습관을 발전시킬 기회를 잃는 것이고, 도메인과 기술 역량을 성장시킬 기회를 잃는 것이고, 함께 있었다면 빠르게 고쳐졌을 실수들을 만들게 된다. 그 비용은 결국 리드 설계자의 조용한 시간이라는 이점보다 더 크게 된다. 리드 설계자를 팀의 나머지 사람들과 같은 방에 두는 것은, ''Expert in Earshot'' (전문가를 가까운 데 두기) 전략이고, 삼투적 커뮤니케이션의 특별한 활용 예다. Andrews는 20여명의 사람들이 그렇게 앉을 수 있는 공간을 만드는 것에 대한 블로그 글을 썼다. (근데 정작 그 URL은 안나와있네...)

많은 성공적인 속성들조차도 어떤 환경 하에서는 적합하지 않은 경우가 있다. 삼투적 커뮤니케이션 역시 예외가 아니다. 만약 리드 설계자가 너무 부하가 많고 너무 자주 방해를 받아서 어떤 일에도 진도가 나가기 어려운 정도라면, 그 리드 설계자는 전혀 방해받지 않는 공간이 필요하고, 팀과 극도로 제한된 커뮤니케이션이 필요하다. 내가 ''Cone of Silence'' (침묵의 깔때기)라고 부르는 것이다. 많은 리드 설계자들은 저녁 6시부터 새벽 2시까지의 시간을 그들의 침묵의 깔때기 시간으로 활용한다. 하지만 가능하다면 일과시간 중에 침묵의 깔때기 시간을 만드는게 좋다.


=== 속성 4. 개인적 안전감 ===

개인적 안전감은, 뭔가 신경쓰이는게 있을때, 보복에 대한 두려움 없이 말할 수 있는 것을 말한다. 매니저에게 스케쥴이 비현실적이라고 말하는 것, 동료에게 그의 설계에 개선이 필요하다는 것, 동료에게 샤워를 좀 더 자주 하라고 알려주는 것 등 말이다. 개인적 안전감은 중요하다. 개인적 안전감으로, 팀은 자신의 약점을 발견하고 고칠 수 있다. 개인적 안전감 없이는, 사람들은 말하지 않고, 약점은 계속 팀에 피해를 줄 것이다.

개인적 안전감은 ''신뢰''를 향한 첫 발걸음이다. 신뢰는, 다른 사람에게 자신에 대한 권한을 부여하는 것인데, 개인적인 손상을 동반하는 것이고, is the extent to which one is comfortable with handing that person the power. 어떤 사람들은 기본적으로 다른 사람들을 신뢰하고, 신뢰를 철회하기 전에 상처받기를 기다린다. 다른 사람들은 다른 사람을 신뢰하는 것을 싫어하고, 신뢰를 주기 전에, 상처를 입지 않을 것이라는 증거를 볼 때까지 기다린다. 신뢰의 존재는 팀 퍼포먼스와 양의 상관관계를 가진다.

상처를 입을 수 있는 다양한 방식은 서로 다른 형태의 신뢰와 불신으로 이어진다. 솔직하지 않은 사람은 거짓말을 하거나 숨길 수 있다. 행동이 일치성이 없는 사람은 일관성이 없다. 능력이나 신뢰성이 부족한 사람은 과제를 완료하지 못한다. 타인에 대한 관심이 없는 사람은 민감한 정보를 제공하는 등 다른 사람에게 피해를 입힐 수 있다.

이러한 다양한 잠재적 상처에 대한 노출을 받아들이는 것은, 다양한 형태의 신뢰를 사용하는 것이다. 프로젝트에 참여하는 모든 사람에게 모든 형태로 서로를 신뢰하도록 요청하는 것은 현실적이지도 필요하지도 않다. 사람들이 자유롭게 말하고 행동할 수 있는 것이 중요하다. 그들은 해로운 행동과 배신과 관련하여 서로를 신뢰해야 한다.

배신이나 피해의 증거가 없으면, 사람들은 정보를 더 자유롭게 공개하고, 이는 프로젝트 속도를 높일 수 있다. 따라서 개인의 안전은 달성해야 할 중요한(critical) 재산이다.

    상사에게 50% 이상 잘못 평가받았다고 이야기하거나, 매력적인 구인 제안을 받았다고 말할 수 있는가? 팀 회의 일정에 대해 상사와 의견이 일치하지 않을 수 있는가? 사람들이 서로의 설계에 대한 오랜 논쟁을 우호적인 불일치로 끝낼 수 있는가?

--

신뢰를 구축하는 것은 그러한 위험 중 하나가 존재하는 상황에 있고 다른 사람들이 당신을 해치지 않는 것을 보는 것을 포함한다. 즉, 신뢰를 쌓기 위해서는, 노출이 있어야 한다.

소프트웨어 개발에는 세 가지 특정 노출이 관련된다:

 * 자신의 무지를 드러낸다
 * 실수를 드러낸다
 * 과제에 대한 자신의 무능력을 드러낸다

숙련된 리더는 팀원(및 자기 자신!)을 이러한 상황에 일찍 노출한 다음, 피해가 발생하지 않을 뿐 아니라 리더와 팀 전체가 그 사람을 지원하기 위해 행동할 것임을 신속하고 진정성 있게 보여준다.

    한 프로젝트 리더는, 팀에 새로운 사람이 합류하면 그 사람을 개인적으로 방문하여 그의 작업과 진행 상황에 대해 논의하고, 그가 하지 않았거나 하지 않았음을 인정해야 하는 피할 수 없는 순간을 기다린다고 말했다.
    .
    이것은 리더에게 중요한 순간이었다. 왜냐하면 그가 약점을 드러내기 전까지는, 리더가 그를 보호해주거나 도움을 줄 수 있다는 것을 보여줄 수 없었기 때문이다. 리더는 그가 약점이나 실수를 드러내면 실제로 도움을 받을 수 있다는 것을 제대로 이해하기 전까지는 신뢰할 수 있는 정보와 완전한 협력 모두를 얻지 못할 것임을 알았다. 리더가 말하길, 어떤 사람들은 처음 방문에서 메세지를 받았지만, 다른 어떤 사람들은 (마음을?) 열기 전에 여러번의 시연이 필요했다고 말했다.

또 다른 프로젝트 리더는 그들이 직면하고 있는 어려운 문제를 해결하기 위해 그룹이 함께 일하게 함으로써 팀의 결속력과 안전을 구축한다고 말했다. 함께 문제를 해결하면서 그들은 몇 가지를 배웠다:

첫째, 무지를 인정해도, 그 분야가 자신의 영역일지라도, 다치지 않을 것이다.

둘째, 격렬한 논쟁에서도 서로의 매너리즘을 위협적이지 않은 것으로 해석하는 방법을 배웠다.

마지막으로, 그들은 혼자서 해결할 수 없는 것들을 함께 해결할 수 있다는 것을 배웠다.

잦은 전달로 신뢰가 향상된다. 소프트웨어가 제공될 때 사람들은 누가 자신의 작업을 맡았고 누가 회피했는지, 누가 진실을 말했는지, 누가 누구에게 손상을 입히거나 보호했는지, 피상적인 태도에도 불구하고 누가 어떤 차원에서 신뢰할 수 있는지 인식한다. 개인의 안전을 가지고 그들은 성찰적 개선 세션동안 마음에서 우러나와 말한다.

개인의 안전은 우호, 선의로 기꺼이 경청하려는 의지와 밀접한 관련이 있다. 프로젝트는 팀의 한 사람이 호의로 듣기를 중단하거나 중요한 정보를 전달하려는 성향을 잃을 때 어려움을 겪는다. 개인적인 기술 외에도 프로젝트의 진전은 사람들 간의 정보 이동 속도 ('분당 meme 거리')에만 의존한다.

일반적으로 팀의 한 사람이 우호성을 주도한다. 더 큰 프로젝트에서는 종종 프로젝트 관리자가 결정적인 역할을 한다. CrystalClear 프로젝트에서는, 그것은 팀의 모든 구성원이 될 수 있다. 이에 반대하는 특별한 이유가 없는 한 우호성은 빠르게 확산되고, 팀이 정보를 신속하게 교환하기 편안하게 만든다. 개인의 안전과 우호성은 함께 조직 경계를 넘어 협력하고 프로젝트의 글로벌 라이프 라인을 구축하는데 도움이 된다. 나는 우호성을 프로젝트의 중요한 관리 요소로, 부분적으로는 개인 안전의 증거로 설정했다.

개인의 안전과 우호성이 확립되면 유용하고 유쾌한 역동성이 나타날 수 있다. 사람들은 서로 경쟁을 벌일 수 있다. 그들은 큰 소리로 논쟁할 수 있다. 싸우기 직전까지, 개인적으로 받아들이지 않고. 누군가가 그것을 개인적으로 받아들이는 경우, 그들은 그것을 분류하고 다시 일들을 정돈한다 (they sort it out and set things straight again).

하지만 개인의 안전과 예의를 혼동하지 않도록 주의하라. 일부 팀은 개인의 안전을 확보한 것처럼 보이지만 실제로는 의견이 일치하지 않기 때문에 예의를 갖추었다. 그들의 불일치를 예의와 화해로 덮으면서 존재하는 실수를 감지하거나 고치지 않는다. 이는 Agile Software Development에 설명된 과장된 가능성의 경우처럼 결국 프로젝트를 손상시킨다.


=== 속성 5. 집중 ===


=== 속성 6. 핵심 사용자에 대한 쉬운 접근 ===


=== 속성 7. 기술적 환경 ===


=== 증거: 조직 경계를 넘나드는 협업 ===

개인 안전, 팀 내 우호성 및 전문 사용자에 대한 쉬운 접근에 대한 부작용이 있다: 다른 이해관계자들도 프로젝트에 포함시키는 것이 자연스러워진다.

프랑스 우편 서비스와 협력하여 프랑스 북부로 들어오고 나가는 모든 우편물을 처리하는 새로운 시설을 운영하는 소프트웨어를 구축하는 Gery Derbier는 Crystal을 사용했다고 보고했다. 그는 25명의 사람들과 함께, 그는 CrystalYellow 분류에 속한 프로젝트에 있었다. 그러나 그는 Crystal 방법론 제품군의 원칙, 특히 '적합한 확장' 원칙을 알고 있었기 때문에 가능하면 CrystalClear를 더 큰 설정으로 확장하기로 결정했다.

우리는 그의 프로젝트에 대해 논의했고, 한 시점에서 30km 떨어진 통합 테스트 팀과 프랑스 우편 서비스에서 일하는 비즈니스 및 사용자 전문가와의 프로젝트 연결을 다루었다. 나는 "그 사람이 얼마자 자주 방문했나요? 그에 대해 어떻게 느꼈나요? 그의 매니저는 그가 자주 오는 것에 대해 어떻게 느꼈나요?"와 같은 질문을 했다. Gery의 대답은, 두 외부 그룹 모두에게: "주 1일; 편안하고; 이렇게 일찍 관여하게 되어 기쁩니다"였다.

토론 이후, 나는 Gery가 조직 경계를 넘어 그의 프로젝트에 협업의 추가 안전을 구축했음을 깨달았다. 그의 프로젝트는 고객과 통합 환경 모두에 각 팀의 동료와 함께 행복하게 연결되어 있다. La Poste의 계약은 몇달마다 통합 테스트 결과에 따라 측정되고 지불되었다. (잦은 배포). La Poste 경영진은 소프트웨어를 점점 더 많이 제공받았고, 그에 따라 지불했다. 증분 배포에 대한 경험이 없었던 Gery의 상사들도, 정기 배포가 정기 결제로 바뀌는 것을 보았기 때문에 기뻐했다. Gery는 모든 면에 지지 구조를 가지고 있었다.

조직 경계를 넘는 협업은 어떤 프로젝트에서도 주어진 결과가 아니다. 그것은 팀 내부와 외부에서 정직한 우호와 성실성을 가지고 일한 결과이다. 팀 자체가 개인의 안전을 갖추지 못하고 덜 자주 배포되는 경우 달성되기 어렵다. 나는 조직 경계를 넘어 훌륭한 협업이 존재한다는 것을, 상위 7개의 안전성 속성 중 일부가 달성되고 있다는 부분적인 증거라고 생각한다.


=== 속성에 대한 성찰 ===

나는 프로젝트가 매번 안전 지역에 안착할 수 있도록 보장할 수 있는 규정된 절차가 있다고 생각하지 않는다. 또한 점진적 개발을 제외하고는 내가 좋아하는 규칙이 있더라도, 어느 밀접히 연관된 규칙들이 있다고도 생각하지 않는다. (?) 이것이 CrystalClear가, 절차의 사양이 아닌 핵심적인 속성들을 중심으로 만들어진 이유이다.

Crystal 팀은 상황에 맞는 그룹 규칙, 기술 및 표준을 사용하여 일곱 가지 속성을 제자리에 설정하기 위해 노력한다. 컨벤션은 프로젝트나 시간에 따라 다를 수 있다. 새로운 기술은 각각의 새로운 기술과 함께 고안된다. (일반적으로 몇년 후 다시 스타일이 사라진다). 반면에 이 7가지 속성은, 수십년 동안 좋은 프로젝트들에 적용되어 왔다.

Crystal에 대한 나의 의도는, 가능한 경우 프로젝트에서 개인의 자연스러운 작업을 침범하지 않고, 다양한 팀에 걸쳐 가능한 최대한의 변형을 허용하는 동시에, 다양한 프로젝트를 안전 영역으로 가져오는 것이다. 변형을 허용하려면 제약조건을 제거해야 한다. 제약을 제거한다는 것은 안전망을 제공하는 더 광범위한 메커니즘을 찾는 것을 의미한다. 내가 선택한 것은 다음과 같다:

 * 사람들은 본질적으로 주변을 둘러보고 소통하는데 능숙하다.
 * 정보가 제공되면 주도권을 잡는다.
 * 그들은 개인 및 정서적 안전과 특히 인신 공격으로부터의 자유와 관련하여 안전한 환경에서 더 잘 한다.
 * 그들은 기여, 성취, 일에 대한 자부심에 대한 욕구를 충족시킬 수 있다면 최선을 다한다.

CrystalClear 안전망은 이러한 것들을 기반으로 한다. 개인의 안전은 사람들이 발견한 것을 공유할 수 있는 개인적인 용기를 준다. 삼투적 커뮤니케이션은 서로에게서 중요한 정보를 발견할 수 있는 가장 큰 기회를 제공하며 통신 비용이 매우 낮다. 성찰적 개선은 작업 프로세스에 피드백을 적용할 수 있는 채널을 제공한다. 전문적 사용자에게 쉽게 접근할 수 있으므로 사용자로부터 관련 정보를 빠르게 찾을 수 있다. 잦은 배포는 시스템의 요구사항 및 개발 프로세스에 대한 피드백을 생성한다. 자동화된 테스트, 구성 관리 등 빈번한 통합을 포함한 기술 개발 환경을 통해 사람들은 안전하게 시스템을 변경하고 동시에 움직이는 여러 마음을 동기화하며 시스템의 중간 단계에 대한 피드백을 빠르게 얻을 수 있다. 집중을 통해 팀은 가장 중요한 일에 에너지를 잘 사용할 수 있다.

RonJeffries 는 언젠가 CrystalClear의 특징을 두고 말하길, "몇 명의 개발자를 평화, 사랑과 조화로 모으고, 격월로 코드를 배포하면 좋은 소프트웨어가 나타날 것이다"라고 했다. 거의 비슷하다.

아마 이 시점에서 궁금증이 생길 것이다. "하지만 이 모든 것들이 작은 규모의 프로젝트에서 무엇이 특별한가? 모든 팀들이 이러한 속성을 제대로 자리잡아야 하지 않나?"라고.

그 대답은, "물론이다." 소규모 팀 프로젝트를 성공적으로 만드는 속성은 모든 프로젝트를 성공적으로 만드는 것과 매우 유사하지만, 소규모 프로젝트 상황에 맞게 최적화되어야 한다.

첫 번째 메모는 소규모 프로젝트에서 속성에 도달하기가 더 쉽다는 것이다. 사람들이 서로 더 자주 상호작용하고 서로를 더 빨리 알게 되기 때문에 개인의 안전이 더 쉽다. 피드백 루프는 훨씬 더 작고, 나머지 속성은 그에 따라간다.

두 번째 메모는 배경으로 듣기와 시선을 따라 의사소통하는 삼투적 커뮤니케이션은 실제로 소규모 팀에서만 작동한다는 것이다. 더 큰 팀은 하위 팀에서 삼투적 커뮤니케이션을 이루고, 하위 팀간에 긴밀한 의사소통을 한다.


== Chapter 6. 오해 (자주 하는 실수들) ==

당신은, CrystalClear를 사용하고 있는데, 프로젝트가 동작하지 않는다고 생각할 수 있다. 무엇이 잘못되었는가? CrystalClear는 실패할 수 있다. 하지만 우선은 당신이 정말로 CrystalClear를 하고 있는지 다시 한번 확인해보자. 이 쳅터는 예제 프로젝트 상황을 제공한다. 그 중 일부는 CrystalClear의 의도를 충족하고, 다른 일부는 의도를 위반한다. 여기서의 목적은 개인적인 경고 시스템을 제공하여 Clear의 의도에 부합하는지 아닌지를 판단할 수 있게 하는 것이다.


=== 우리는 함께 자리잡고 있고, 2주짜리 이터레이션을 돌리고 있는데, 왜 실패했나? ===

요즘 소프트웨어 개발 커뮤니티는 이터레이션이라는 단어를 잘못 사용하고 있고, 사용자를 과소평가하고 있다. 문헌은 실제 사용자에게 배포하는 대신 이터레이션을 강조한다. XP는 현장 고객을 이야기하는데, 이는 칭찬할만하지만, 조직이 단순히 포기하고 실제 유저를 전혀 참여시키지 않을 정도로, 조정하기가 너무 어렵다.

CrystalClear의 속성 #1은 잦은 배포이다. 잦은 이터레이션이 아니다. 그리고 속성 #6은 전문가 유저에 대한 쉬운 접근이다.

얼마 전 XP에서 파생된 습관을 가진 한 그룹을 방문했을 때 한 이슈가 발생했따. 그들은 짝프로그래밍, TDD, 자동화된 회귀 테스트, 짧은 반복주기 및 나머지 모든 것에 대해 알고 있었다. 그들은 매우 자주 그렇듯이, 1년간 CrystalClear와 비슷한 것으로 진화했다. 이 이야기를 할 때 우리는 회고 워크샵을 하고 있었다. 방에 있는 사람들의 절반이 5개월간의 프로젝트를 마무리하고 있었다. 그들은 작동하고 좋은 테스트 세트를 가지고 있었음에도 불구하고, '단지 잘못된' 시스템 섹션을 계속 언급했다.

    우리는 작년 동안의 그들의 프랙티스에 대한 타임라인을 그렸다. 그들은 잘 알고 있는 이해관계자들로부터 요구사항을 수집했다. 3개월 후, 그들은 Web-X를 사용하여 고객 사이트에 초기 버전의 시스템을 배포하고 시스템에 대한 온라인 토론을 했다. 이 연습 배포에서는 모두 잘 진행되었다.
    .
    4개월 후, 워크샵 일주일 전, 미래의 5명의 시스템 사용자가 개발 사이트를 방문하여 개발자와 함께 시스템 사용을 연습했다. 그리고 그 때 개발자들에게 '이게 아닌데요'라고 말했다. 이로 인해 개발팀이 끝없는 충격을 받았다고 연상할 수 있다. Web-X 배포는 어떻게든 방문과 동일한 수준의 소프트웨어 세부 검사를 수행하지 않았다.
    .
    우리는 그들이 다르게 할 수 있는 일과 미래에 다르게 할 수 있는 일에 대해 논의했다. 나와 팀 모두에게 놀랍게도, 팀은 그들이 실제로 그러한 유저들은 임시 배포를 전달받아, 성장하고 있는 시스템을 조사할 수 있을만한 '우호적인 사용자'에게, 실제로 접근하지 않아왔다는 것을 발견했다. 이 팀에서는, 더욱 나쁘게도 아직도 가까운 시일 내에 언제 그것을 받을 수 있을지 알 수 없는 상황이었다.
    .
    다른 말로, 그들의 타임라인을 되돌아보면, 그들은 이 큰 놀라움을 어떻게 피할 수 있었는지 알 수 없었다.
    .
    이 이야기는 해피앤딩이었다고 말할 수 있어 기쁘다. 이는 생산적인 그룹이었고, 아직 한 달이 남아있었기 때문에, '잘못된' 부분을 추출하고 사용자의 요구를 충족시키기 위해 다시 작성했다.

이 팀은 스폰서와 사용자의 의견에 귀를 기울이고, 함께 자리잡고, 자주 통합하고, 각 반복주기 후에 회고를 했으며, 이러한 상황이 오는 것을 보지 못했다. 그들은 여전히 그것을 고칠 방법이 없었다. 그 책임은 실제 사용자가 더 많이 방문하도록 해야 하는 임원 후원자에게 있었다. 다행히 그 임원 후원자는 문제의 중요성을 인식하고 있었으며, 향후 프로젝트를 위해 문제를 개선하는데 적극적으로 참여하고 있따.

반복주기는 프로세스에 대한 피드백을 팀에 제공하고, 사기에 대한 이른 승리, 그들이 궤도를 유지하는지 확인하기 위한 조정 메커니즘을 제공한다. 그러나 그들은 업무용 소프트웨어의 적합성에 대한 end-to-end 피드백을 제공하지 않는다. 이를 위해서는 실제 사용자의 참여가 필요하다.

실제 사용자에 대한 접근 없이 2주 반복주기를 선택하거나, 짧은 반복주기를 포기하고 분기별로만 배포해야 하지만 실제 사용자가 전달 기간에 두 번 랩에 들어와서 성장하고 있는 소프트웨어를 검토하도록 하는 두 가지 선택을 해야 한다면, 나는 후자를 선택할 것이다. 이것이 작업 제품을 확인하는 일정에 대한 이유이자, 반복주기보다 배포주기를 강조하는 이유이다.


=== 우리의 첫 배포는 데이터 테이블 데모이다 ===

좋지 않다. 매 배포 싸이클은, 최소한 원칙적으로는, 동작하고 테스트된 코드를, 일부 사용자가 사용할 수 있도록 제공해야 한다.

애자일 개발로 전환하기 위해서는, 개발 과제를 end-to-end 통합이 가능한 덩어리로 나누는 방법을 배우고, 전체 개발 프로세스와 성장하는 기능에 필요한 만큼의 아키텍처를 연습해야 한다.

사용자 인터페이스 디자인이나 테이블, 또는 작은 프로토타입을 개발하고, 이를 '(어떤 종류의) 싸이클' 이라고 부르고 그 후에 회고 워크샵이 열리는 것은 위안이 되는 함정이다. 모든 요구사항을 '반복주기'로 작성하고, 요구사항 수집 프로세스를 반영한 팀에 대해 들어본 적이 있다. 이는 그들이 나머지 개발 프로세스 (즉, 전달 후)와 어떻게 조화를 이루는지 볼 때까지 요구사항을 얼마나 잘 수집하고 문서화했는지 알 수 없다는 이 두 가지 이유로 동작하지 않는다.


=== 어느 사용자도 가능하지 않다, 하지만 다음주에 테스트 엔지니어가 합류한다 ===

테스트 엔지니어는 사용자가 아니다. '한번 현상에서 일해본' 매니저도 감독자도 사용자가 아니다. 당신의 전문가 사용자는 당신의 UI 설계를 검증하고 부순다. 테스트 엔지니어는 당신의 테스트를 더블 체크해서 당신의 코드가 깨졌다는 것을 말할 수는 있다. 하지만 시스템이 사용자가 원했던 그 것인지를 말해주지는 못한다. 프로젝트 매니저들에 대한 출판된 한 연구에서, 사용자들과 직접 연결되는 경험이 있든지 없든지, 프로젝트 매니저들은 사용자와 직접 연결이 있는 프로젝트가 그렇지 않은 프로젝트보다 더 성공적이었다고 압도적으로 느꼈다. 사용자가 참석했을 때 사용자는 초기에 소프트웨어의 개념과 레이아웃에서 저지른 실수에 대해 경고하고 불필요한 기능은 줄이면서 사용자의 요구에 더 적합한 소프트웨어를 만들 수 있도록 했다.

CrystalClear 프로젝트는 디자이너가 일주일을 넘지 않는 간격으로 사용자에게 간단히 물어볼 수 있는 능력 때문에 상대적으로 비공식적인 중간 작업 제품으로 성공할 수 있다. 최고의 프로젝트에는 풀타임 사용자가 있으며, 일부는 사용자가 일주일에 여러번 아침에 방문하도록 할 수 있다. 사용자 인터뷰 또는 공유 설계 시간을 위해 최소한 매주 한 시간을 예약해야 한다.

그것은 명백한 위반이었따. 다음은 CrystalClear의 의도를 위반하거나 경계에 의문을 제기하는 일련의 질문과 상황이다.


=== 한 개발자가 그의 설계나 그의 코드에 대해 나머지 사람들과 논의하기를 거절한다 ===

전문 개발자인 Pete Mcbreen이 말했듯이, "코드가 개인적인 것이라고 주장하던 시대는 지났다." 설계에 대해 논의하고 자신의 설계나 코드에서 가능한 결함을 찾으려는 의지가 중요하다.

자신의 코드를 기꺼이 논의하려는 사람들은 개인 안전 속성의 일부이다. 프로그래머는 무엇이 좋은 설계를 구성하는지에 종종 동의하지 않으며, 그것에 대해 매우 불쾌해하곤 한다. 사람들에게 필요한 개인 안전을 제공하려면 팀이 감정적으로가 아니라 기술적으로 설계를 논의하는 방법을 배울 수 있도록 몇 명의 사람들이 앞으로 나아가 설계를 보여주어야 할 수 있다.

팀원에게 설계를 신뢰하는 것을 두려워하는 프로젝트는 CrystalClear 프로세스를 시작하지 않을 것이다. 당신이, 그리고 그들이 설계에 대한 토론을, 모욕 없이, 서로 다른 사람들이 각자의 역량 수준에서 작업하면서, 여전히 작업 시스템을 제공할 수 있도록 설계 토론을 관리하는 방법을 스스로 자문해보라.


=== 사용자가 한 번에 모든 기능이 제공되기를 원한다... ===

"(우리는) 그렇게 자주 새 버전을 인스톨하도록 해서 그들을 귀찮게 하고 싶지 않다"

이런 일은 사용자가 변화하는 시스템에 대한 많은 전달들, 특히 UI의 변화-에 방해받을 수 없는 종류의 시스템에서 발생한다. 하지만, 시스템을 보고 사용하여 기술 및 사용 설계 결정에 대한 피드백을 받을 수 있도록 사용자를 초대할 수 있어야 한다. 시스템의 해당 부분이 설계, 테스트, 검토 및 승인되면 이러한 결정에 대해 긴장을 풀고 다음 단계로 넘어갈 수 있다.

사용자의 컴퓨터에 실제로 소프트웨어를 설치하는 것이 적절하지 않은 경우, 구성되고, 테스트된 기능을 측면으로 설정하고(물론 적절하게 버전이 지정된) 다음 증분이 추가될 때까지 기다린다. 즉, 이 경우에는 하지 않았더라도, 사용자에게 기능을 전달한 것처럼 정확하게 개발할 수 있다. CrystalClear 프로세스의 핵심은 소프트웨어 뿐만 아니라 개발 및 배포 프로세스에 대한 종료와 피드백을 받는 것이다.

CrystalClear는 모든 사용자에게 시스템 업데이트를 계속 제공할 수 없을 때 사용할 수 있다. "우호적 사용자"를 찾아 프로세스를 수정하고, 해당 사용자에게만 다른 버전을 배포한다.






== Chapter 7. 질문들 ==

=== 질문 6. CrystalClear는 방법론 생태계에서 어디에 위치하는가? ===

==== Crystal Clear와 XP ====

XP는 CrystalClear와 많은 부분 닮았다. 특히 같이 앉기에 대한 관심이나, 짧은 반복주기, 잦은 배포, 스폰서들과 최종 사용자와의 밀접한 접촉. 몇몇 부분은 CrystalClear보다 더 엄격하고, 몇몇은 덜하다.

 * XP의 반복 사이클은 더 짧아야 한다: 1일에서 1개월. XP는 전달 주기가 얼마나 길어야 하는지에 대한 규칙을 만들지 않는다. 이것은, 최악의 경우에도 배포가 3개월을 넘지 않아야 하는 CrystalClear와 반대로, 반복주기가 배포만큼 길어질 수 있다. 다른 점에서 뛰어난 XP 프로젝트가, 단순히 배포에 걸리는 시간이 6개월에서 1년이었기 때문에 문제가 발생하는 것을 보았다. 이것은 분명히 잦은 배포를 암시하는 XP의 의도를 위반한 것이다. 이러한 상황을 해결하기 위해 CrystalClear는 실제 배포의 필요성을 명시한다. 내 생각에는 연간 배포에서 분기별 배포로 변경하려면 가장 크게는 조직에 정신적 변화가 필요하며, 일단 조직에 분기별 배포가 이루어지면, 반복주기 및 배포 사이클을 단축하는 목적을 확인할 수 있고, 회고 워크샵을 통해, 동작하는 세트를 찾을 수 있다.
 * XP는 짝으로 프로그래밍해야 하지만, CrystalClear는 그렇지 않다. 차이점은 근본적이다: XP는 가능한 한 가장 효과적인 방법론을 목표로 하고, 결과적으로 이러한 종류의 선택을 할 때 팀의 자유도를 감소시킨다. CrystalClear는 관용적이고 적절하게 효과적인 방법론이 되는 것을 목표로 하여, 팀이 지역 컨벤션을 구성하는데 가능한 한 많은 자유를 제공한다.
 * XP는 풍부한 자동화된 단위 테스트를 필요로 하고, 하루에도 여러번 통합하도록 한다. 첫번째는 CrystalClear의 권장 속성일 뿐이며, 통합 기간은 프로젝트마다 크게 다를 수 있다.
 * XP는 현장 고객이 필요하다. CrystalClear는 풀타임이 아닌 일주일에 최소 1시간으로 전문적 사용자에게 쉽게 접근하는 것을 요구한다. 이것은 더 많은 것이 더 좋은 상황이다; CrystalClear의 경우 프로젝트 안전 우선 순위를 충족하는 최소값을 의도적으로 찾고 있다.
 * XP를 사용하려면 팀이 일반 코딩 규칙을 결정하고 준수해야 한다. 이는 CrystalClear에서 필요하지 않거나 언급되지 않은 것이다. XP의 규칙은 프로그래머가 프로그래밍 파트너를 자주 변경하고 끊임없는 싸움과 혼란을 피하기 위해 코딩 규칙에 대한 동의를 얻어야겠다고 생각할 때 이해할 수 있게 된다.
 * XP는 개발 에피소드의 일부로 그리고 장기적으로 설계와 리팩토링의 단순성에 대해 명시적으로 이야기한다. 걸어다니는 해골과 증분 재설계 전략에서 이야기한 것처럼, 이것들은 CrystalClear에서는 단지 권고사항이다. 나 역시 단순한 설계와 지속적인 리팩토링을 선호하지만, 내 의문은 이것이다. 그게 방법론에서 표준으로 포함되어야 할까? 내 결론은 설계를 단순화하고 리팩토링하는 법을 배우는 것은 전문적 프로그래머의 정상적인 성장 경로의 일부이며, CrystalClear가 모든 프로젝트 유형과 프로그래밍 기술에 걸쳐 법률을 만들려는 것이 아니라는 것이다.
 * XP는 문서를 필요로 하지 않고, CrystalClear는 필요로 한다. 협동 게임의 두 가지 목표라는 관점에서 XP는 첫 번째 목표인, 소프트웨어 전달에 초점을 맞추고, 두 번째 목표인, 두 번째 목표를 설정하기에 대해서는 침묵한다. XP는 미래에 필요한 투자의 반쪽을 제공한다: 페어 프로그래밍 순환을 통해서, 새로운 사람이 노련한 팀에 합류했을 때, 설계와 코드 작성 속도를 매우 빠르게 높일 수 있다. 그러나 사람들이 시간이 지남에 따라 다른 프로젝트로 이동하고, 이에 따라 팀의 이해가 누출되고, 새로운 사람들이 지식이 누출되는 만큼 빨리 습득하고 내면화하지 못할 가능성이 높다. 이러한 붕괴는 거의 불가피하며, 이는 팀이 새로운 사람들의 유입을 지원하기 위해 다른 외부화된 정보 표식을 만들어야 함을 의미한다. CrystalClear는 팀에게 '욕심쟁이'와 '투자' 행동 둘 모두를 수행하여 의사소통 경로의 장기간과 단기간의 균형을 맞출 것을 요구한다.

이것들을 살펴보면, XP가 규제하는 곳은 더 엄격한 규칙으로 규제하고, 더 느슨한 곳은 규칙이 없기 때문에 그렇다. 이것은 두 가지 결과를 가져온다.

 * CrystalClear는 XP의 관행을 채택할 수 있다. 여기에는 현장 고객, 플래닝 게임, 짝프로그래밍, 3주 반복주기, TDD, 완전 자동화된 단위 테스트, 지속적 통합, 엄격한 코딩 컨벤션, 단순한 설계와 지속적인 리팩토링이 포함된다.
 * XP를 완전하게 사용하고 여전히 CrystalClear를 충족하려면 두 가지를 해야 한다: 반복주기 뿐만이 아니라 코드를 정기적으로 전달한다는 약속을 추가하라. 다음 게임을 준비하는데 관련된 투자 활동의 일환으로 상기하고 정보를 주는 문서화를 추가한다.

기술 관점에서, XP는 전문 개발자가 마스터할 수 있는 효과적인 기술의 풍부한 방법들을 제공한다.


==== Crystal Clear와 Scrum ====

Scrum은 밀접한 커뮤니케이션과 집중에 해당하는 세 가지 주요 실천법에 초점을 준다:

 * 타임박싱. 각 1개월의 반복주기동안 개발될 요구사항의 하위 집합은, 반복주기가 시작할 때 '반복주기 백로그'에 고정된다. 이를 통해 팀은 변경에 대한 두려움 없이 작업할 수 있는 마음의 평화(초점)를 얻을 수 있다. 스크럼은 실제 전달이 아닌, 각 타임 박스 이후에 데모 혹은 그에 준하는 것을 필요로 한다.
 * 동적인 백로그. 반복 중에 요구사항을 고정하는 것을 보상하기 위해, 남은 모든 작업에 대한 목록('제품 백로그')이 유지된다. 스폰서는 원할 때마다 원하는 방식으로 백로그를 변경할 수 있다. 개발팀과 스폰서는 새 타임 박스 기간이 시작될 때 백로그를 확인하고 타임박스에 대해 고정할 하위 집합을 선택한다. 즉, 각 반복 전에 백로그의 우선순위를 다시 지정하여 각 반복이 매달 가장 높은 우선순위 작업을 목표로 한다.
 * 일일 스탠드업. 팀은 매일 짧게 (말 그대로 일어서서) 만나서 각 사람이 어제 작업한 내용, 오늘 계획한 작업, 그를 방해하는 요소를 공유한다. 이것은 팀을 사회적, 기술적 교류로 묶고 그들이 궤도를 벗어날 때 조기 경고하는 시스템을 만든다.

이는 Crystal의 세 가지 주요 프랙티스와 잘 결부된다:

 * 잦은 배포, 단순히 시스템을 시연하는게 아니라, 실제로 사용자의 손에 - 최소한 '우호적 사용자' - 쥐어주는 것
 * 일반적인 Crystal에 대해서는 긴밀한 커뮤니케이션, CrystalClear에서는 삼투적 커뮤니케이션. 하루 중 언제든지 쉽게 질문과 대답을 할 수 있으며, 소규모 팀 환경에서 정보를 엿들을 수 있다.
 * 회고 워크샵. 프로젝트 시간 프레임 내에서 지역 조건에 신속하게 적응할 수 있도록 규칙을 조정한다.

Scrum과 Crystal은 깔끔하게 어울려서 No-Process 프로세스라고 부르는 것들을 만들어낸다. No-Process 프로세스는, 대략 말하자면, 어디서나 시작하고, 높은 의사소통과 반성적 피드백으로 짧은 주기로 작업하고, 결국에는 당신이 필요로 하는 것 (일종의 유전자 알고리즘 같은)에 귀결될 것이라고 말한다.

 * 실제 전달이 수반되는 타임 박스는 프로세스의 동력이다.
 * 주기적인 백로그 재우선순위는 장기적으로 제품이 제자리를 잡도록 한다.
 * 반복주기 후 성찰 워크샵은 팀과 프로세스가 장기적으로 제자리를 잡도록 한다.
 * 삼투적 의사소통과 일일 스탠드업은 팀이 단기적으로 제자리를 잡도록 한다.


그것이 무엇이든 상관없이, 조직의 프로세스에 No-Process 프로세스를 추가할 수 있다. 정말 멋진 유전자 알고리즘이 될 것이다. 프로젝트의 마감 기한이 4,6,10월이고, 어디서나 시작하여 최적으로 진화할 시간이 없다는 점만 빼면. 아주 가까이서 시작해야 한다.

Crystal은 그 속성, 원칙, 기술 및 예제들을 가지고 매우 가깝게 시작할 수 있도록 도와준다.


==== Crystal Clear and RUP ====

RUP(Rational Unified Process)는 구조상 Crystal 패밀리와 매우 유사하지만, XP와는 다른 점에서 그렇다.

RUP와 Crystal은 모두 "방법론 생성기"들이다. 그 자체로는 방법론이나 프로세스가 아니다. (그렇다. Rational Unified Process라고 부르는 것은 알고 있지만, 프로세스가 아니다. 어쨌든 프로세스 생성기이거나 RUP 언어의 '프로세스 프레임워크'이다). RUP와 Crystal은 모두 단일 프로세스가 모든 프로젝트에 적합하지 않다는 견해를 전제로 하고 있으므로 프로젝트 팀은 현지 상황에 맞게 방법론을 커스터마이즈해야 한다.

RUP와 Crystal은 모두 조직과 프로젝트에 맞게 방법론을 맞춤화하는 방법에 대한 조언을 담고 있다. 둘 다 핵심 기술을 설명하고 작업 제품 예제 및 템플릿을 포함한다. 둘 다 반복적인 개발을 통한 시스템의 점진적인 성장, 좋은 테스팅 실천법, 사용자와의 밀접한 접촉, 위험 관리, 작동하는 코드로부터의 피드백을 권장한다.

RUP의 시작 단계는 이 책에 설명된 차터링 활동과 매우 유사하다. 프로세스 커스터마이징을 위한 RUP의 개발 사례는 Crystal에서의 방법론 형성 워크샵만큼이나 RUP의 핵심이다. (개발 사례를 통해 RUP를 회사에 맞게 조정하지 않는 것은, 방법론 형성 및 회고 워크샵을 하지 않고 Crystal을 수행하는 것만큼이나 RUP를 제대로 하지 않는 것이다.)

이 수준의 논의에서는 RUP 프로세스 생성기와 Crystal 방법론 생성기를 구분할 수 있는 것은 거의 없다.

세 가지 핵심 요소가 다르다. RUP는 아키텍처, 시각적 모델링, 도구 사용을 핵심 요소로 설정한다. Crystal은 초기 실행 가능한 아키텍처를 구축하기 위해 동일한 권장을 하지만, 아키텍처를 지엽적인(local) 문제로 간주한다. Crystal은 시각적 모델링이라는 주제에서 RUP와 크게 다르다. 첫번째는 문서화가 로컬에서 결정된 문제라는 생각을 사용하고, 두번째는 문서가 시스템의 '이론'을 전달하려고 시도해야 한다는 생각을 사용한다. 시각적 모델은 그 이론을 전달하는데 있어 아주 작은 부분일 뿐이다. 일반적으로 Crystal은 도구에 구애받지 않고, CrystalClear는 모델링 도구와 관련하여 다소 과묵하다. Crystal 프로젝트를 가장 잘 지원하는 것은, 구성 관리, 커뮤니케이션, 프로그래밍, 테스트 하네스, 테스트 코드 커버리지 및 성능 프로파일링 도구이다.

Crystal에는 RUP에 쉽게 추가될 수 있는 (그리고 반드시 추가되어야 하는) 핵심 관행 중 하나인 회고 워크샵이 포함되어 있다. RUP 인스턴스를 사용하는 모든 팀이 단순히 각 반복주기 후에 모이고 더 나은 방법에 대해 생각하는 것을 막는 것은 없다. RUP 저자는 팀에 반성적 개선을 수행하는 방법을 보여주는 기술과 작업 예제를 간단히 추가할 수 있다 (그리고 그래야 한다).

다른 차이점들이 있다. 그 중 일부는 필수적이고 일부는 방법론의 관행과 실제 '느낌'에 대한 더 정신적인 연관이다. 이러한 정신적 연관성은 방법론을 태개하는 조직에서 자체 현실을 생성하므로 무시해서는 안된다.

 * 가볍고 관대한. 각 Crystal 방법론은 핵심 가치에서 프로젝트 상황이 허용하는 한 가볍고 효율적이며 비 관료적이며 관용적이다. 그것들은 RUP의 선언된 요소가 아니다. 이는 Andrea Branca가 이메일에서 설명한 결과를 제공한다. "모든 프로세스를 민첩하게 보이게 하는 것은 가능하지만 민첩하게 느끼게 만드는 것은 어렵다"
 * 원칙을 형성하기. Crystal에는 형태를 선택하는 방법에 대한 지침을 제공하기 위한 일련의 원칙이 포함되어 있다. 이러한 원칙은 Crystal 패밀리의 일부이다. RUP는 커스터마이즈를 권장하고 마일스톤과 템플릿을 나열하지만, 모양을 선택하는 방법에 대한 이론을 제공하지 않는다.
 * 방법론 형성의 속도. Crystal은 수행할 방법론의 형성을 일반적으로 며칠 단위의 매우 짧은 순서로 요구하므로, 해당 워크샵의 비용은 프로젝트 기간 내에 새로운 효율성으로 상환된다. Crystal 방법론은 프로젝트 과정에서 발전하기 위한 것이므로 방법론 형성이 빨라야 한다. RUP를 형성하는데는 몇 달이 걸리지 않지만 종종 그렇게 되기 때문에 많은 회사가 개발 사례를 피하고 전체 패키지를 채택하는 이유가 될 수 있다 (너무 무거운 비용의 불이익과 함께 조정되지 않은 방법론의 비효율성을 얻기 때문에 두 배로 나쁘다)
 * 컷 다운 vs 빌드업. Crystal의 접근 방식은 방법론 형성 워크샵에서 제시한 모든 것, 또는 지난 시간에 사용한 모든 것에서 시작하여 경험이 문제를 드러낼 때만 방법론에 추가하는 것이다 (일반적으로 회고 워크샵 중). Crystal은 의도적으로 과소 지정되어 '누락 오류'를 범한다. 필요하지 않은 것이 있다는 것을 감지하는 것보다, 필요한 것을 놓쳤을 때 감지하는 것이 더 쉽다. 크리스탈은 의도적으로 '적합하도록 늘린다'.

반대로 RUP는 '적합하도록 축소'이다. RUP에는 작업 제품 템플릿의 백과사전이 포함되어 있다. 백과사전을 앞에서 뒤로 읽거나 The Joy of Cooking의 모든 레시피를 순차적으로 준비하지 않는 것처럼 RUP 백과사전의 모든 레시피를 순차적으로 준비하지 않는 것처럼 RUP 백과사전의 모든 템플릿을 앞에서 뒤로 채우면 아노딘다. 오히려 오늘 필요한 것에 대한 요리 책이나 백과 사전을 살펴 보는 것처럼, RUP 백과사전을 살펴보고 이 특정 프로젝트에 필요한 특정 요소를 꺼내야 한다.

RUP의 접근 방식은 전체 백과사전에서 시작하여 형성 활동 중에 물건들을 버리는 것이다. 이런 의미에서, 과도하게 지정된다.

이 두 가지는 조직마다 다른 방식으로 잘못되었다. 나는 Crystal이 시작하기에는 너무 비어 있기 때문에 그룹이 도입하는데 문제가 있을 것이라고 예상한다; 많은 사람들이 RUP에 애를 먹는데, 시작하기에 너무 꽉 차있어서 그렇다. 나는 이런 종류의 딜레마에서 벗어날 수 없다고 생각한다.

 * 비쥬얼 모델링. 앞에서 설명한 것처럼, 시각적 모델링은 RUP의 핵심 요소이며 Crystal의 선택 요소이다.
 * 도구. RUP는 도구에 의해 지원되도록 설계되었으며, Crystal은 의도적으로 도구에 대해 알지 않으며 시각적 모델링 도구에 대한 투자에는 약간 반대한다. 1992년부터 내가 권장한 것은 연결된 모양을 가장 빠르게 그릴 수 있는 도구를 구입하는 것이었다. 여기에는 연필과 종이, 화이트 보드와 카메라, PowerPoint, Visio 및 CAD-CAM 도구도 포함된다.
 * 동시 개발. Crystal은 프로젝트에 적합한 적시 요구 사항을 통합하기 위한 지침과 함께 핵심 권장 사항으로 동시 개발을 제공한다. RUP에는 시스템의 점진적 성장에 대한 권장 사항이 포함되어 있지만, 적시 요구사항 및 동시 개발을 통합하는 방법에 대한 지침은 없다.
 * 기업 지원. 마케팅, 도구 개발, 교육 및 컨설팅 부서와 함게 전담 설계 팀이 RUP를 지원한다는 차이를 피할 수 없다. 이것은 방법론 정의의 차이는 아니지만 채택에 있어 매우 큰 차이를 만든다. Crystal은 구잆할 수 없다; 두 권의 책을 사거나 웹사이트를 볼 수는 있다. 그 후에는 당신과 당신의 팀은 함께 모여 생각하고 토론하고 회고해야 한다. 이것은 책, 도구, 코스 및 컨설팅을 주문하여 조직의 문 앞에 표시하는 것과는 매우 다르다.

RUP 내에서 CrystalClear를 할 수 있을까? 물론 3~8명의 함께 앉는 팀을 가정할 때, CrystalClear가 RUP의 적절한 구현이 될까?

CrystalClear의 처음 세 가지 속성만 필수이다. 그 밖에 모든 것은 조언이거나 최소한 논의를 위한 것이다. 이 세 가지 속성은 개념적으로 어렵지 않다. 문제는 RUP를 수행하는 팀이 실제로 몇 달에 한 번씩 실제 사용자에게 제공할 것인지, 팀이 삼투적 커뮤니케이션을 얻기 위해 개인 사무실에서 공용 공간으로 이동할 것인지, 그리고 앉을 것인지 여부이다. 회고 워크샵 및 성찰적 개선을 달성한다. 그들이 이 세 가지 일을 할 수 있다면 아마도 나머지 일들은 CrystalClear에 속하게 될 것이다.

CrystalClear가 쓰여진 것처럼 RUP의 유효한 구현이라는 것은 분명하지 않다. 시각적 모델링이나 아키텍처가 충분하지 않거나 RUP 테스트를 통과하기 위한 명시적 위험 관리가 없을 수 있다. 수행 여부는 개발 사례가 어떻게 나오는지에 달려있다.


=== 질문 9. 왜 안전 영역만을 목표로 하는가? 더 할 수 있지 않나? ===

그렇다. 당신은 더 잘 할 수 있고, 원한다면 그렇게 하기를 권한다. 예를 들어 TDD, 순환하는 풀 타임 짝프로그래밍, 자동화된 인수 테스트는 물론 단위 테스트, 전문 사용자 및 도메인 전문가들의 풀타임 현장 상주, 지속적이고 자동화된 빌드, 반복주기를 1-2주 정도로 단축하기, 매달 배포하기.

그렇다. 가능하다면 매주 1시간 토론 그룹을 구성할 수 있다. 이 보고서를 작성한 사람들은 사람들이 서로 주제를 토론할 수 있는 신뢰, 능력 및 능력의 증가에 대해 다시 보고한다. 실용주의 프로그래머, 테스트 주도 개발에 대한 책들, 리팩토링 등 다양한 디자인 패턴 책을 포함한 여러 책을 통해 작업하라. 이 세션에서는 프로젝트의 코드 스니펫을 보여주고 토론하면서 설계-프로그래밍 기술을 분석하고 비교하는 방법을 배운다. 코드를 테스팅하는 방법에 대해 논의하라. 세션을 사용하여 새로운 언어와 도구를 시도해보라.

당신은 개인의 안전에 특별한 주의를 기울일 수 있고, 사람들 간의 신뢰를 위한 기반을 구축할 수 있고, 개인적 신뢰와 기술적 신뢰를 구축해야 한다. 팀원의 전문 교육을 위해 시간과 비용을 할당할 수 있고, 이를 통해 빠르게 변화하는 분야에 대한 최신 정보를 얻을 수 있다. 예를 들어, 나는 10년마다 프로그래밍 기술을 완전히 바꿨다. 나는 네 번째 학습주기에 있으며, 이는 프로그래밍에만 해당된다. 나는 아직 유용성이나 사용자 인터페이스 디자인을 다루지 않았고, 슬프게도 구성 관리 시스템에 대해서도 구식이다. 당신은 어떤가? 만약 당신이 설계에, 프로그래밍에, UI 디자인에, 테스팅에 대해 최근 5년이나 7년동안 습관을 크게 바꾸지 않았다면, 당신은 아마도 구식이 되었을 것이다.

내가 CrystalClear에서 요구했던 것보다 더 잘할 수 있는 방법의 목록은 길다. 그러나 이들 각각은 채택에 어려움을 더하고 전체를 관리할 수 있는 사람의 수를 줄인다.

Crystal 제품군의 방법론은 가능한 프로젝트 우선 순위의 어느 한 차원에 대해서도 '최적'을 목표로 하지 않는다. 생산성, 추적가능성, 법적 책임, 결함으로부터의 자유, 여유있는 팀, 분산된 팀, 하급 직원의 최대 사용 또는 기타 우선 순위를 위해 최적화되지 않는다.

Crystal은 프로젝트 안전, 효율성 및 거주가능성을 우선한다. 효율성 우선순위는 경제 협력 게임을 잘 플레이하여 다음 게임에 계속 주의를 기울이면서 이 게임에서 좋은 배포 속도를 허용한다. 거주가능성 우선순위는 합리적으로 살기 좋은 결과를 만들기 위해 함께 일하는 인간의 자연스러운 강점과 약점을 고려한다고 말한다. 프로젝트 안전은 소프트웨어가 공정한 시간 프레임에 나오고 프로젝트 직원이 온전하고 기꺼이 의지하는 것을 의미한다. 다시 같은 과정을 거친다.

효율성과 거주 가능성 우선순위는 우리가 소프트웨어 개발에서 주의해야 하는 많은 문제와 마찬가지로 충돌한다. 관용을 줄이면 더 효율적일 수 있다. 효율성을 낮추면 더 관대할 수 있다.

바라건대, 이 책은 팀이 프로젝트의 안전 지대에 들어갈 수 있는 충분한 엄격함과 충분한 관용도를 제공하여 프로젝트에 필요한 다음 우선순위를 추가할 수 있기를 바란다.


== Chapter 9. Distilled (The Short Version) ==

Crystal Clear의 핵심은 무엇인가?

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

 * 리드 디자이너, 그리고 2~7명의 다른 개발자들이
   * 큰 방 혹은 인접한 방에 있고,
   * 정보 방열기 - 화이트보드나 플립 차트 같은 것이 벽에 걸려 있고,
   * 핵심 사용자(expert users)에게 접근하며,
   * 방해(distractions)를 멀리 하고,
     * 동작하고 테스트 되었고 유용한 코드를
   * 매 한두달 (뭐, 최대한 세달까지)마다 한번씩 전달하고,
   * 그들의 일하는 스타일을 주기적으로 회고(reflect)하고 조정한다.

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

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

이 책의 모든 다른 내용들은 이 페이지의 내용의 확장이다.