Diff for "책/CrystalClear"

Alistair Cockburn이 지은 책.

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

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

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

• 사람들이 함께 가깝게 앉게 하라. 자주 좋은 의지(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일; 편안하고; 이렇게 일찍 관여하게 되어 기쁩니다"였다.

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. 기술적 환경; 자동화된 테스팅, 형상 관리, 잦은 통합

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