Extreme Programming

ExtremeProgramming 은 경량개발방법론으로서, RUP 등의 방법론에 비해 그 프로세스가 간단하다. XP 에서의 몇몇 개념들은 일반적인 프로그래밍에서도 유용하게 쓰일 수 있다. 특히 TestDrivenDevelopment(TestFirstProgramming) 의 개념과 Refactoring, UnitTest는 초기 공부할때 혼자서도 실습을 해볼 수 있는 내용이다. 개인 또는 소그룹의 훈련으로도 이용할 수 있을 것이다.

[GIF external image]

전체 주기 ¶

초기 Customer 요구분석시에는 UserStory를 작성한다. UserStory는 추후 Test Scenario를 생각하여 AcceptanceTest 부분을 작성하는데 이용한다. UserStory는 개발자들에 의해서 해당 기간 (Story-Point)을 예측(estimate) 하게 되는데, estimate가 명확하지 않을 경우에는 명확하지 않은 부분에 대해서 SpikeSolution 을 해본뒤 estimate을 하게 된다. UserStory는 다시

EngineeringTask로 나누어지고,

EngineeringTask부분에 대한 estimate를 거친뒤 Task-Point를 할당한다. 해당 Point 의 기준은 deadline 의 기준이 아닌, programminer's ideal day (즉, 아무런 방해를 받지 않는 상태에서 프로그래머가 최적의 효율을 진행한다고 했을 경우의 기준) 으로 계산한다.

그 다음, 최종적으로 Customer 에게 해당 UserStory 의 우선순위를 매기게 함으로서 구현할 UserStory의 순서를 정하게 한다. 그러면 UserStory에 대한 해당

EnginneringTask를 분담하여 개발자들은 작업을 하게 된다. 해당 Task-Point는 Iteration 마다 다시 계산을 하여 다음 Iteration 의 estimate 에 적용된다. (해당 개발자가 해당 기간내에 처리 할 수 있는 Task-Point 와 Story-Point 에 대한 estimate) (Load Factor = 실제 수행한 날 / developer's estimated 'ideal' day. 2.5 ~ 3 이 평균) Iteration 중 매번 estimate 하며 작업속도를 체크한뒤, Customer 와 해당 UserStory 에 대한 협상을 하게 된다. 다음 Iteration 에서는 이전 Iteration 에서 수행한 Task Point 만큼의 일을 할당한다.

Iteration 중에는 매일 StandUpMeeting 을 통해 해당 프로그램의 전반적인 디자인과 Pair, Task 수행정도에 대한 회의를 하게 된다. 디자인에는 CRCCard 과 UML 등을 이용한다. 초기 디자인에서는 세부적인 부분까지 디자인하지 않는다. XP에서의 디자인은 유연한 부분이며, 초반의 과도한 Upfront Design 을 지양한다. 디자인은 해당 프로그래밍 과정에서 그 결론을 짓는다. XP의 Design 은 CRCCard, TestFirstProgramming 과 Refactoring, 그리고 StandUpMeeting 나 PairProgramming 중 개발자들간의 대화를 통해 지속적으로 유도되어지며 디자인되어진다.

개발시에는 PairProgramming 을 한다. 프로그래밍은 TestFirstProgramming(TestDrivenDevelopment) 으로서, UnitTest Code를 먼저 작성한 뒤 메인 코드를 작성하는 방식을 취한다. UnitTest Code -> Coding -> Refactoring 을 반복적으로 한다. 이때 Customer 는 스스로 또는 개발자와 같이 AcceptanceTest 를 작성한다. UnitTest 와 AcceptanceTest 로서 해당 모듈의 테스트를 하며, 해당 Task를 완료되고, UnitTest들을 모두 통과하면 Integration (ContinuousIntegration) 을, AcceptanceTest 를 통과하면 Release를 하게 된다. Refactoring 과 UnitTest, CodingStandard 는 CollectiveOwnership 을 가능하게 한다.

그리하여 각

EngineeringTask들이 구현되고, 궁극적으로 UserStory 의 Story들이 모두 진행되면 Mission Complete. (아.. 어제 Avalon 의 영향인가. --;)

XP 의 주요 개념들 ¶

On-site customer: 같은 작업실 내에서 프로그래머와 커스터머가 언제든지 대화할 수 있도록 보장한다.
UserStory: 사용자 관점에서 시스템의 행위에 대한 간략한 서술
AcceptanceTest: 사용자 관점에서 해당 작업산출물이 제대로 돌아가는지 확인할 수 있는 테스트.
ThePlanningGame: 개발자는 UserStory들에 대해서 구현, 예측, 지시들에 대해 토론한다.
UnitTest: 모든 클래스들에 대한 자동화된 테스트 코드들.
TestDrivenDevelopment : Programming By Intention. 프로그래머의 의도를 표현하는 테스트코드를 먼저 작성한다. 그렇게 함으로서 단순한 디자인이 유도되어진다. (with Refactoring)
Refactoring : 코드를 향상시키기 위한 프로세스
SimpleDesign
PairProgramming: 프로그램코드는 두명 (driver, partner)이 하나의 컴퓨터에서 작성한다.
SpikeSolution: 주어진 문제에 대한 구현의 난이도를 예측하기 위한 작은 실험 프로그래밍.
CollectiveOwnership: 누구든지 어떠한 오브젝트건 고칠 수 있는 권리를 가진다.
CodingStandard: CollectiveOwnership 을 위한. 누구나 이해하기 쉽도록 코딩스타일 표준의 설정.
ContinuousIntegration: 매일 또는 수시로 전체 시스템에 대한 building 과 testing을 수행한다.
Metaphor : Object Naming 과 프로그램의 해당 수행에 대한 커뮤니케이션의 가이드 역할을 해줄 개념의 정의.
Forty-hour week: 지친 심신은 실수를 만들어낸다. 가능하면 초과근무를 피한다.

전체 주기 ¶

XP 의 주요 개념들 ¶

관련 사이트 ¶