- 참고문헌 : 로버트 C 마틴, "UML 실전에서는 이것만 쓴다", 이용원, 정지호 역, (인사이트, 2010), 7장
## 반복적인 개발
- dX의 실천 방법 가운데 핵심은 ‘모든 것’을 ‘짧은’ 주기로 반복하는 것이다. 내가 말 한 모든 것에는 요구사항, 분석, 설계, 구현, 테스팅, 문서화 등 정말 ‘모든 것’이 다 포함된다. 그리고 짧은 주기는 한 주 또는 두 주를 의미한다. 우리는 모든 것을 한 주나 두 주를 주기로 해야 한다
- 최초의 탐사 작업
- 첫 번째 주기는 종료할 때 코드가 없어도 되며 유일하게 두 주보다 짧아도 된다
- 먼저 요구사항과 일의 우선순위에 대한 책임을 질 누군가가 필요하다. 이 사람을 ‘고객’이라고 부르자
- 우리는 이 카드를 ‘사용자 스토리(user story)’라고 부른다 이 카드에는 유스케이스의 자세한 내용은 빼고 유스케이스의 이름만 적는다
- 각 기능의 추정치 잡기
- 오직 다른 스토리와 크기를 비교할 수 있는 상대적인 크기에만 주의를 기울인다. 즉, 추정치가 8인 스토리는 추정치가 4인 스토리보다 시간이 두 배 걸릴 것이다.
- 만약 여러분이 발판으로 삼을 수 있는 이전 스토리가 없다면, 프로그래밍을 위한 완벽한 하루라는 개념을 써서 추정해 보는 방법도 있다
- 이런 날이 며칠이면 그 스토리를 완수할 수 있을까? 여러분이 생각하는 날 수를 적어라. 하지만 이 날 수와 현실에서의 날 수가 어떤 관계가 있을 것이라는 생각은 잊어버려라. 현실은 그렇지 않기 때문이다
- 스파이크
- 다섯 명으로 구성된 팀이 두 주짜리 반복을 하나 수행할 때 작업할 수 있는 시간은 50 인-하루다.우리가 측정한 바에 따르면 이 팀은 이런 주기 한 번에 25점 분량 의 일을 할 수 있다. 이 숫자를 이 팀의 최초 ‘속도’로 삼는다
```
(내 생각)
> 책에서 user-story를 '1'잡은 기준은?
>> man/day
> man/hour로 잡으면?
>> 고민해보자. story-point를 쪼개야하므로 man/day가 계산하기 편할 듯
> user-story는 상대적 크기여야 한다?
>> 그렇더라도 기준은 있어야 할 것.
```
## 계획 짜기
### 릴리즈 계획하기
- 첫 릴리즈 계획하기 : 2 weeks x 6 반복주기
- man/day로 계산하면 : 5명 x 2 weeks(10days) = 50 story
- 이겠지만, 현실적으로 25 story 정도 나온다. (man/day 로 50% 정도?)
- 25 story x 6 반복주기 = 150 story
### 반복 주기를 계획하기
- 각 반복 주기의 첫날에는 그 주기의 계획을 세운다. 최초 속도가 25이므로, 고객은 앞서 세운 릴리스 계획의 스토리들에서 점수의 합이 25점이 될 때까지 스토리를 고른다.
- 비즈니스 가치가 낮고 비싼 스토리보다 비즈니스 가치가 높고 비용이 싼 스토리를 먼저 골라야 한다
- 그 다음에는 고객이 고른 스토리를 여러 태스크(task)로 쪼갠다. 태스크는 스토리보다 훨씬 작다. 태스크는 대략 크기가 4 인-시간(man-hoim)에서 10 인-시간 정도 되는 일의 단위로, 개발자 한 명이 책임을 맡을 수 있는 크기를 나타내는 단위다
- 개발자는 자기 몫의 시간이 0이 될 때 까지 태스크에 사인을 할 수 있다
### 중간 지점
- 2주 중 첫째주가 지나고 둘째주 월요일에,
- 지금까지 완료된 스토리 점수는 끝마친 스토리의 추정치만 모두 더해서 계산한다. 이렇게 함으로써 모든 스토리를 절반씩만 하는 일을 방지할 수 있다.
- 이 점수를 가지고 일을 더 빨리 진행해야할 지 story point를 조정해야 할지 고객과 조정한다.
### 결과를 속도에 반영하기
- 금요일 오후에는 모든 스토리를 다 끝마쳤든 아니든 이번 주기를 멈춰야 한다. 그런 다음 속도를 다시 계산한다. 만약 스토리 점수 23점을 끝마쳤다면, 새로운 개발 속도는 주기당 23점이 된다. 다음주 월요일에 다음 주기의 계획을 짤 때 고객은 스토리 점수로 23점까지만 스토리를 골라야 한다
## 반복 주기를 관리 단계로 조직하기
- 통합공정(Unified Process)
- 도입 단계(Inception phase) : 시스템이 실행될 수 있는지, 어떤 비즈니스 사례인지 결정하기 위해 노력한다.
- 정련 단계(Elaboration phase) : 시스템의 아키텍처를 결정하고 믿을 수 있는 구현 계획을 작성한다..
- 구축 단계(Construction phase) : 시스템을 구축한다.
- 전이 단계(Transition phase) : 시스템을 설치하고 사용자와 협력해서 시스템을 조율한다.
- 통합 공정의 단계마다 반복 주기가 하나 이상 있으며, 주기마다 실제로 작동하는 코드가 결과물로 나온다.
- 스토리를 찾아내고, 찾아낸 스토리의 작업량을 추정하고, 어떤 스토리를 구현할지 선택하고, 그것을 구현하는 것이다.
## 반복 주기에서 일어나는일
- 이번 주기에 하기로 선택한 '스토리'들만 진행한다. 다른 스토리들을 고려하지 않는다.
### 짝을 이뤄 개발하기
- 한 사람이 사인한 작업을 구현할 때라도 컴퓨터 한 대 앞에 두 사람이 함께 앉아서 작업한다.
- 작업 소유자의 시간이 절반으로 줄었는데 생산성이 떨어지는 것이 아닌가?
- (하지만) 생산성은 하락하지 않는 것 같다 (라고 책에 적혀있지만 해봐야 알 것 같다)
### 인수 테스트
- 자동화할 수 있는 고수준의 테스트용 언어로 작성한다.
- http://fitnesse.org
### 단위 테스트
- 그냥 작성하는 것이 아니라 대단히 많이 작성한다. (테스트코드)
### 리팩터링
- 시스템의 동작에는 변화 없이 프로그램의 구조만 개선하는 행동
- '하루 일을 마칠 때 나쁜 코드를 남기지 않는 것'을 규칙으로 삼는다.
### 개방된 작업 공간
- 가운데 책상을 두고 짝 프로그래밍을 할 수 있도록 배치한다.
- 고객도 포함해서 한 방에서 일한다.
- 다른 사람의 코드를 볼 수도 있는 한 팀으로 함께 일한다.
### 끊임없는 통합 작업
- 락을 걸지 않는 소스 컨트롤 시스템을 사용한다.
- 나중에 체크인한 사람이 먼저 한 사람의 코드와 합쳐야 한다.
- 단, 체크인전 단위 테스트와 인수 테스트를 통과해야한다.
댓글
댓글 쓰기