1 개요

2 보다 나은 쥐덫 만들기

3 60분 프로젝트

4 규칙

5 Extreme Hour

5.1 사용자 스토리와 아키텍처 스파이크(10분)

5.2 우선순위와 범위 추정하기(10분)

5.3 초기 일정 공약(10분)

5.4 이터레이션 #1(10분)

5.5 수정 일정 공약(10분)

5.6 이터레이션 #2(10분)

5.7 릴리즈!

6 한마디!

ExtremeHour는 샘플 프로젝트에 청중이 참여하여 XP를 시연하는 한 시간 분량의 presentation이다. 기본적으로, 청중은 PairProgramming 같은 XP의 원칙들을 사용하여 완벽하게 개발된(그리고 테스트 된!) 산출물을 한 시간에 얻는다.

우린 체계적으로 XP를 소개해왔다. 우린 몇몇의 개발자가 짝을 이루고, 몇몇의 이해당사자들은 사용자 스토리를 만들고, 한 프로젝트에 automated test framework을 사용하고, 다른 프로젝트에서는 CommitmentSchedule"일정약속"(지금은 Release Plan"릴리즈 계획"으로 바뀜)을 적용하기도 했다. Kent의 책과 "PeopleWare"가 우리들 사이에서 두루 읽혔고, 많은 프랙티스들을 알게 되었다.

하지만 우린 충분히 실험적이고 모험적이지 않았다. 각 프랙티스들은 따로 놀았다. 직속 상관은 필요한 툴을 내가 구입하도록 승인해주었고 XP를 신속히 도입하기 바랐다. 그런데 도대체 어떻게 도입해야 하는가?

매니저들을 위해 여러 발표자료를 잘 계획해 준비했고, 몇몇 매니저들은 큰 관심을 보이며 자리에서 일어나 XP가 어떻게 그들에게 이익을 가져다주는지 보았으며 감탄했다. 하지만 그 날은 쉽지 않은 날이었으니, 앉은 자리도 편치 않은데다 기대와 달리 XP에 대해 잘못 이해하고 있는 매니저들로 인해 엉망이 되고 있었다. 난 그 모든 프랙티스를 하나로 통합하여 일관된 절차로 보여주지 못하고 있었다.

하지만, 마지막 한 시간이 그 날의 분위기를 역전시켰으니, 그 한 시간짜리 세션은 정말 효과적이고 재미있었기에 다른 분들도 시도해 볼 수 있도록 그 내용을 여기에 기록한다. 그 날 사용했던 발표자료에서 일부분은 삭제하였다.http://www.xpsd.org/xhour.ppt:

• 우리의 새 제품은 잘 확립된 쥐덫 시장의 공동 부분을 장악해야 한다.
  
• 첫 릴리즈를 계획, 일정 수립, 개발, 품질 보증한다.
  
• 프로젝트 시간 : 한 시간!
  
  

• 10 분 동안 사용자 스토리 & 아키텍처 스파이크
  
• 10 분 동안 우선순위와 범위 추정
  
• 10 분 동안 초기 일정 공약
  
• 10 분 동안 이터레이션 1
  
• 10 분 동안 수정 일정 공약
  
• 10 분 동안 이터레이션 2
  
• 릴리즈!
  
  • 이 시간 틀을 변경할 수 없음을 공지하라.
    
    

• 화이트 보드에 그려지지 않은 것은 전달된 게 아니다.
  
  • 이게 의미하는 것은, 개발자들은 코딩하는 게 아니라 그림을 그린다는 것이다. pictionary (단어를 그림으로 표현하여 맞추는 게임)처럼 생각하지만 눈에 보이는 말장난은 없다. 정말로 좋은 눈에 보이는 말장난이 없어도 충분하다.
    
• 냅킨에 쓰여지지 않은 것은 사용자 스토리/기능 테스트가 아니다.
  
  • 이해당사자들은 하나의 문장으로 사용자 스토리를 화이트보드에 표현한다(냅킨에 적혀있어도). QA는 그들의 기능 테스트들을 냅킨에 적는다. 예를 들어 우리는 “눈이 멀어도 사용 할 수 있어야 한다."라는 사용자스토리를 정할 수 있다. 이것은 애매모호한 요구사항으로부터 좋은 토론을 이끌어 낼 수 있다. -눈 먼 쥐? QA를 위한 예로, 다음과 같은 테스트가 있다: "We blindfold Mark. Can he figure out whether the trap is full without getting hurt?"
    
• 발표자는 코치를 한다.
  
• 청중에서 9명을 선별한다.
  
  • 기록자(Tracker) 1명은 타이머(stopwatch)와 SCM 노트를 지닌다.
    
    • SCM 노트에 개발자가 지운 것을 그린다. 예를 들어, "고양이". 개발자가 고양이를 다시 필요로 할 때 "고양이"라고만 적을 수 있고, SCM은 이미 고양이를 그렸다는 것을 증명할 것이다.
      
  • 개발자 4명
    
  • QA 2명
    
  • 이해당사자 2명
    
• QA는 개발자가 작성 마감 10분 전까지 그것을 볼 수 없다.
  
• 개발자는 QA나 이해당사자가 쓴 것을 마감 10분 전까지 알지 못한다.
  
  • 두 그룹은 이터레이션이 끝날 때까지 완전히 서로를 볼 수 없다.
    
• 기록자는 종료 5분 전과 종료 1분 전을 알려준다.
  
  

• 2명의 이해당사자가 사용자 스토리를 작성한다.
  
  • 품질과 연관된 양을 정하는 것을 잊지 말 것!
    
• 2명의 개발자들은 아키텍처 스파이크를 작성한다.
  
  • 개발 환경의 원형을 만드는 것을 잊지 말 것!
    
• 진행중에 모두의 용기를 북돋거나 주위를 돌아다니며 제안을 하라.조심스럽게 지적하여 흐름에 영향을 주라.
  
  

• 이해당사자는 스토리를 3가지로 구분한다:
  
  • 반드시 해야하는 것
    
  • 없으면 희생이 따르는 것
    
  • 있으면 좋은 것
    
• 이해당사자는 각 분류 안에서 상대적인 순위를 결정한다.
  
• 그동안 4명의 개발자는 스파이크 경험에 기초해 스토리에 필요한 이상적인 시간(분)을 결정한다.
  
  • 하나의 스토리는 최대 10분을 소요해야 한다. 그렇지 않다면 이해당사자들은 스토리를 나누거나 명확하게 해야 한다.
    
  • 낙관적으로 하되, 리스크를 기록하라.
    
    

• 2번의 이터레이션에 들어갈 스토리에 대해 일정을 세운다.
  
• 우선순위와 리스크를 우선으로 일정을 세운다.
  
• 초기 속도로 3을 사용한다.
  
  • 4*10 = 40분(실제 시간)은 40/3 = 13분(이상적인 시간)이란 것을 의미한다.
    
    

• QA는 각 스토리마다 기능 테스트를 작성한다.
  
• QA는 이터레이션이 끝날 때까지 개발자가 그린 것을 볼 수 없다.
  
• QA가 테스트를 실행하고, 버그를 기록한다.
  
  • ''버그를 가진 어떤한 스토리도 불완전하다. 그 후의 부하율(Load Factor)에 영향을 미친다.'.
    
    
• 그동안 개발자는 기술적인 작업을 정의한다.
  
  • 개발자가 만족하는 사용자스토리를 그리는 것에 대해 대화하는 것을 말한다. 일반적으로 개발자들은 그리기 10초전에 계획을 세운다.
    
• 개발자는 해법(solution)을 그린다.
  
• 만약 다른 개발자가 이해할 수 없다면, 단위 테스트에 실패한 것이다.
  
• 개발자는 할 수 있다면 리팩터링한다.
  
• 기록자는 모든 삭제된 것을 기록한다.
  
  
• 이해당사자는 몰래 새로운 스토리와 정말 나쁜 것을 생각한다.
  
  

• 기록자 혹은 코치는 실제 부하요인을 파악하고 두 번째 이터레이션을 위해 속도를 수정한다.
  
  • Presenter, practice beforehand so you can do this quickly! Use Load Factor = 40 Real Minutes / Ideal Minutes of stories that passed QA in first iteration (9 in our example => Load factor 40/9 = 4.4); Ideal Minutes for the second Iteration then = Real Minutes / Load Factor ( 40 /4.4 => 9 in our example )
    
  • Hrm. Actually I was silly here. Of course if they got through 9 ideal minutes in the first iteration then that's the size of the second iteration. Unless they decide to include more developers, in which case you need that LoadFactor calculation after all.
    
  • Note... using simple velocity instead of load factor should make this much simpler/easier
    
• Turn QA bugs into Stories
  
• 이해당사자는 새로운 스토리를 제시한다.
  
• 스토리 전부의 우선순위와 범위(scope)
  
• 적당한 스토리를 스케쥴에 대입, 혹은 이전 것으로 대체한다.
  
• 개발자를 더 쓸 수 있는가? 아니면 부하가 걸리는가?
  
• 인간공학(ergonomics)은 부하에 영향을 주는가?
  
  

(이터레이션 #1과 동일하다)

• QA는 각 스토리마다 기능 테스트를 작성한다.
  
• QA는 이터레이션이 끝날 때까지 개발자가 그린 것을 볼 수 없다.
  
• QA가 테스트를 실행하고, 버그를 기록한다.
  
  
• 그동안 개발자는 기술적인 작업을 정의한다.
  
• 개발자는 해법(solution)을 그린다.
  
• 만약 다른 개발자가 이해할 수 없다면, 단위 테스트에 실패한 것이다.
  
• 개발자는 할 수 있다면 리팩터링한다.
  
• 기록자는 모든 삭제된 것을 기록한다. (SCM)
  
  
• 이해당사자는 몰래 새로운 스토리와 정말 나쁜 것을 생각한다.
  
  

• 이해당사자들은 해당 릴리즈가 시장성이 있는지 판단한다.
  
• 만약 당신이 지치지 않았다면(전력을 다하지 않았다면), 이 릴리즈와 다르게 스토리를 재계획하라...
  
  

• 와~ 어느새 번역이 거의다.... 대단하십니다. : ) --GyehongPark
  
• 막상 처음에 시작하려니 어렵더군요;;;; 80%정도를 아샬님께서 해주셔서 정말 감사함을 느끼고 있습니다 ^^; --김경헌