- 인덱스카드작성

- 사용자 스토리 : 유스케이스이름만

- 시간이나 날자가 아닌 추정치

- 프로그래밍을 위한 완벽한 하루에 맞춰

- 너무 추정치가 큰 스토리는 쪼개고, 너무 작은 스토리는 합친다.

- 사나흘 걸리는 스토리나, 반나절이 안걸리는 스토리는 없도록

- 최초탐사작업 마지막 이틀이나 사흘정도 흥미있는 스토리 두세개를 간략히 구현

- man-day 당 할 수 있는 점수(추정치) 를 잡는다.

- 만일 인하루당 반점을 한다면 5명이 두주짜리 반복에 25점 분량을 할 수 있다. 이 숫자를 최초 속도로 삼는다.

- 릴리즈하나는 보통 반복주기 여섯개, 즉 세달정도이다.

- 속도가 25라면 총 150점까지 할 수 있다.

- 고객이 점수 합이 150점이 될때까지 원하는 스토리를 고른다.

- 각 반복주기 첫날 스토리점수 25점까지 고른다. 이때 비즈니스 가치가 높고 비용이 싼 스토리를 먼저 고른다.

- 스토리를 태스트로 쪼갠다. 4인시간~10인시간정도 개발자 한명이 맡아서 할 수 있는

- 고객은 스토리의 세부내용을 말해서 테스크 쪼개는 것을 돕는다. 스토리에서 중요한점에 대한 Trade off 를 한다. 2~3시간 걸린다.

- 개발자가 사인을 해서 태스크를 맡으면 작업의 추정치를 구한 다음 자기 시간에서 추정치를 뺸다. 자기 몫의 시간이 0이 될때 까지 조정하여 태스크가 남았다면 25점을 할수 없다고 하고 스토리를 뺸다.

- 20점으로 확정했다면 다음주 월요일에는 10점 분량의 일이 완료되어야 함. 모든 스토리가 절반 완료가 아닌 절반스토리가 완료된 상태

- 진행상태에 따라 스토리를 더 빼거나 더 추가

- 진행한 점수만큼 다음 주기에 스토리를 고름

- 짝프로그래밍 : 컴퓨터 한대 앞에 두사람이 함께 앉아 작업. 두 프로그래머 모두 완전히 코드 작성에 참여

- 인수테스트 : 개발자들이 인수테스트를 받으면, 그때서야 그들이 가진 스토리와 작업이 반드시 무엇을 이루어야 하는지 진정으로 알게 된다. 이들은 이 인수테스트들을 개발과정내내 끊임없이 돌려서 전에 통과한 것들이 다시 실패하지 않는지 확인해야 한다. 이렇게 되면 바람직한 반복주기의 끝은 흥분되는 클라이막스가 아니라 오히려 그 반대가 된다. 모든 인수 테스트가 조용히 통과되고, 모든 사람이 금요일 오후에 일찍 집에 가기 때문이다. 인수테스트용 프레임웍이나 도구를 이용(fitnesse.org)

- 단위테스트 : test-first 기법. 성공못할 테스트를 먼저 만들어놓고 코드를 작성. 성공할 만큼만 작성하여 테스트. 몇분전에 모든 테스트를 완벽하게 통과한 코드. 모든 프로그래밍작업의 예제 모음처럼 사용할 수 있음. 테스트는 뜻이 모호하지않고, 정확하고, 컴파일할 수 도 있으며 실행할수도 있는 문서의 종류

- 리팩토링 : 작성한 코드를 다시보고 개선한다. 단위테스트와 인수테스트의 지원을 받는 한, 우리는 두려움 없이 원하는 대로 무엇이든 변경할 수 있다. 하루 일을 마칠 때 나쁜 코드는 남기지 않는 것을 규칙으로 삼는다.

- 개방된 작업 공간

- 끊임없는 통합 작업 : nonblocking 소스 콘트롤. 나중에 체크인하는 사람이 코드를 합침. 빨리 자주 체크인해야 한다는 압력이 생김. 단 체크인 전에 모든 단위테스트와 인수테스트를 통과함을 보임.