반복적인 개발
- dX의 실천 방법 가운데 핵심은 모든 것을 짧은 주기로 반복
- 요구사항, 분석, 설계, 구현, 테스팅, 문서화 모든 것을 짧은 주기 반복
- 짧은 주기는 한 주 또는 두 주를 의미
- 주기마다 계획을 짜며 시작하고 고객에게 전달할 만한 결과물을 만듦으로서 주기를 종료
최초의 탐사 작업
- 첫 번째 주기는 종료할 때 코드가 없어도 되며 유일하게 두 주보다 짧아도 된다.
- 상세한 요구사항을 포착하는 시기가 아니다.
- 단지 시스템의 범위에 대해 아이디어를 얻으려는 것뿐
- 유스케이스를 찾아낸다.
- 유스케이스를 인덱스 카드에 한장에 하나씩 적어 놓는다.
- 이 카드를 사용자 스토리라고 부른다.
- 이 카드에는 유스케이스의 자세한 내용은 빼고 유스케이스의 이름만 적는다.
- 이 탐사는 끝나지않는다. 새로운 요구나 기능을 논의하고 스토리를 기록한다.
각 기능의 추정치 잡기
- 프로그래밍을 위한 하루라는 개념을 써서 추정할 수 있다.
-
프로그래밍을 위한 완벽한 하루
- 적절한 시간에 잠자리에 들고
- 아침식사도 배불리 먹고
- 일하러 오는데 교통체증도 없었고
- 하루종일 전화도 걸려오지 않고
- 회의도 없고
- 컴퓨터가 한 번도 다운되지 않고
- 네트워크 속도는 무한에 가까울만큼 빠르고
- 직장동료는 똑똑하고 인내심 있고 잘 배려 해주는 사람들
스파이크
계획짜기
릴리스 계획하기
반복 주기를 계획하기
중간 지점
결과를 속도에 반영하기
반복 주기를 관리 단계로 조직하기
반복 주기에서는 어떤 일이 일어나는가?
짝을 이뤄 개발하기
인수 테스트
단위 테스트
- 하루에 몇 십개
- 한 주에 몇 백개
- 한달이면 몇 천개가 쌓인다.
- 특정한 API 함수를 호출하는 방법을 알고 싶다면, 그것을 테스트가 있으니 보면 된다.
리팩토링
- 시스템의 동작에는 변화 없이 프로그램의 구조만 개선하는 행동
- 하루 일을 마칠 때 나쁜 코드를 남기지 않는 것을 규칙
개방된 작업 공간
끊임없는 통합 작업
- 락을 걸지 않는 소스 컨트롤 시스템을 사용
- 체크 인도 먼저 체크 인한 사람이 임자
- 체크 인한 사람이 처음 사람의 코드를 자신의 코드와 합쳐야 한다.
- 모듈을 체크 아웃해놓은 시간이 길면 길수록 코드를 합쳐야 할 가능성도 커진다.
- 빨리 자주 체크 인해야 한다는 압력이 생기며, 이것은 좋은 현상이다.
- 체크 인을 하기 전 반드시 모든 단위 테스트와 인수 테스트를 통과함을 보여야 한다.
결론
- UML은 방법론이 아니라 표기법이다.
- 자바도 방법론이 아니라 프로그래밍 언어다.
- 이런 표기법과 언어는 필요할 때 사용하면 그만이다.
- 의무적으로 작성하는 문서는 대부분 그다지 쓸모가 없다
- 여러분에 당장 필요하고 중요한 문서만 만들어라
- UML 다이어그램 그리기가 필수는 아니라는 뜻이다.
dX 는 거꾸로 읽으면 XP 이다. 저자의 센스







덧글