No older revisions available
No older revisions available
ExtremeProgramming 은 경량개발방법론으로서, RUP 등의 방법론에 비해 그 프로세스가 간단하다. XP 에서의 몇몇 개념들은 일반적인 프로그래밍에서도 유용하게 쓰일 수 있다. 특히 TestDrivenDevelopment(TestFirstProgramming) 의 개념과 Refactoring, UnitTest는 초기 공부할때 혼자서도 실습을 해볼 수 있는 내용이다. 개인 또는 소그룹의 훈련으로도 이용할 수 있을 것이다.
전체 주기 ¶
초기 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: 지친 심신은 실수를 만들어낸다. 가능하면 초과근무를 피한다.
관련 사이트 ¶
- http://extremeprogramming.org - 처음에 읽어볼만한 전체도.
- eXtremeProgrammingMeetsUML - 아직 읽어보지 않았음.
- http://objectmentor.com - Robert Martin 의 글들. OOP 관련 기사들도 많음.
- http://xprogramming.com - Ron Jeffries 의 글들이 많다.
- http://www.martinfowler.com/articles/newMethodology.html#N1BE - 또다른 '방법론' 이라 불리는 것들. 주로 agile 관련 이야기들.
- http://www.freemethod.org:8080/bbs/BBSView?boardrowid=3220 - 4가지 가치 (Communication, Simplicity, Feedback, Courage)
- http://www.freemethod.org:8080/bbs/BBSView?boardrowid=3111 - 4가지 변수 (Resource, Quality, Time, Scope)
위의 전체 그림을 한번 정리해 보고 싶어서 추가함
고치고 싶으면 마음대로 고치세요.
그리고 다른 것도 좀 올려봅시다.
고치고 싶으면 마음대로 고치세요.
그리고 다른 것도 좀 올려봅시다.
DeleteMe) 질문에 대해서는 Metaphor 로 옮겼습니다. 그리고 질문을 하실때는 실명으로 로그인해주시기 바랍니다. (사람들이 203.244.197.254 님 에게 답하기엔 좀 이상하자나요~) --1002
...여기에서의 XP 와 관련된 글들의 경우도 XperDotOrg 쪽으로 옮기는건 어떨까 궁리. (Interwiki 로 옮기고, ZP 에서는 ZP 내의 토론으로 대신할 수 있을듯. 자료가 어디에 있느냐는 그리 중요하지 않을 것이니. XperDotOrg 가 상용사이트나 CUG 가 되는게 아닌이상) 사람들 의견은? --1002