E D R , A S I H C RSS

Extreme Programming

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


전체 주기


초기 Customer 요구분석시에는 UserStory를 작성한다. UserStory는 추후 Test Scenario를 생각하여 AcceptanceTest 부분을 작성하는데 이용한다. UserStory는 개발자들에 의해서 해당 기간 (Story-Point)을 예측(estimate) 하게 되는데, estimate가 명확하지 않을 경우에는 명확하지 않은 부분에 대해서 SpikeSolution 을 해본뒤 estimate을 하게 된다. UserStory는 다시 Wiki:EngineeringTask로 나누어지고, Wiki:EngineeringTask부분에 대한 estimate를 거친뒤 Task-Point를 할당한다. 해당 Point 의 기준은 deadline 의 기준이 아닌, programminer's ideal day (즉, 아무런 방해를 받지 않는 상태에서 프로그래머가 최적의 효율을 진행한다고 했을 경우의 기준) 으로 계산한다.

그 다음, 최종적으로 Customer 에게 해당 UserStory 의 우선순위를 매기게 함으로서 구현할 UserStory의 순서를 정하게 한다. 그러면 UserStory에 대한 해당 Wiki: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, TestFirstProgrammingRefactoring, 그리고 StandUpMeetingPairProgramming 중 개발자들간의 대화를 통해 지속적으로 유도되어지며 디자인되어진다.

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

그리하여 각 Wiki: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: 지친 심신은 실를 만들어낸다. 가능하면 초과근무를 피한다.

관련 사이트



SE분류, 지도분류

위의 전체 그림을 한번 정리해 보고 싶어서 추가함
고치고 싶으면 마음대로 고치세요.
그리고 다른 것도 좀 올려봅시다.

DeleteMe) 질문에 대해서는 Metaphor 로 옮겼습니다. 그리고 질문을 하실때는 실명으로 로그인해주시기 바랍니다. (사람들이 203.244.197.254 님 에게 답하기엔 좀 이상하자나요~) --1002


...여기에서의 XP 와 관련된 글들의 경우도 XperDotOrg 쪽으로 옮기는건 어떨까 궁리. (Interwiki 로 옮기고, ZP 에서는 ZP 내의 토론으로 대신할 있을듯. 자료가 어디에 있느냐는 그리 중요하지 않을 것이니. XperDotOrg 가 상용사이트나 CUG 가 되는게 아닌이상) 사람들 의견은? --1002
Valid XHTML 1.0! Valid CSS! powered by MoniWiki
last modified 2021-02-07 05:23:15
Processing time 0.0225 sec