I.극한 프로그램(XP：eXtreme Programming)의 개요
가. XP의 정의
- 반복형 모델의 개발주기를 극단적으로 짧게 함으로써, 프로그래머가 설계, 구현, 시험 활동을 전체
소프트웨어 개발 기간에 걸쳐 조금씩 자주 실시하도록 하고 소프트웨어 변경의 비용을 최소화하는
애자일 기법
- SW를 개발하기 위한 가볍고, 효율적이고, 낮은 위험도를 가진, 유연하면서도 예상가능하고
과학적인데다 재미있는 방법
-의사소통(Communication), 피드백, 단순성(Simplicity), 용기(Courage) 의 4가지 가치를 기반으로
고객, 관리자, 프로그래머에 대한 역할과 권한을 중시하고, “고객에게 최고의 가치를 가장 빨리”
전달하도록하는 경량 소프트웨어 개발 방법론
-XP는‘고객이 원하는 양질의 소프트웨어를 빠른 시간 안에 전달하는 것’을 궁극적 목표
-전통적인 소프트웨어 개발 방법론과는 달리 문서를 강조하지 않고 변경을 장려하며, 개발 초기부터
테스트를 병행할 것을 강력히 권고하는 새로운 방법론
- XP는 고객이 원하는 소프트웨어를 고객이 원하는 시기에 제공하는 것을 목표로 하며, 프로젝트
막바지에도 나올 수 있는 요구사항 변경에 더욱 잘 대처할 수 있도록 한다
나.XP의 개념도
II. XP 개발의 4가지 가치
가. 의사소통(Communication)
- 고객, 개발자, 관리자들 간의 의사소통을 원활히 하면 요구사항을 명확히 식별
- 고객, 개발자, 관리자들 간의 의사소통이 중요함
- XP에서는‘현장 고객(On-site Customer)’이라는 수행법을 사용
- XP에서는 완전한 팀(Whole Team)은 고객과 개발자가 상호 신뢰하고 적극적으로 협력하는
상황에서만 가능하고, 이것이 이뤄지지 않으면 개발은 실패
-고객과 개발자, 개발자 간에 메타포어를 의사소통 수단으로 쓴다는 점
- 스탠드업 미팅(Stand-Up Meeting): 매일 정해진 짧은 시간에 진행상황, 문제점, 해결방안,
팀 초점의 수정 여부에 대해 의견을 교환
: 미팅의 결과는 프로젝트 전반에 걸친 공통의 이해를 돕고 나아가 프로젝트 진행 방향의 기준
나. 피드백(Feedback)
- 작동하는 소프트웨어를 신속하게 개발하고, 이를 고객과 함께 시험해 오류사항의 개선사항이나 신규 요구사항을
빨리 피드백
- 지속적인 테스팅하여 피드백을 얻음
- 지속적인 통합이 또 피드백을 지원
다. 단순성(Simplicity)
- 단순함은 변경 요구를 줄이고, 변경을 하더라도 적은 노력으로 변경 가능
- DTSTTCPW (Do The Simplest Thing That Could Possibly Work, 작동할 수 있는 가장 단순한 것을
해라)와 YAGNI(You Aren’t Gonna Need It, 그건 필요 없게 될 거요)를 말함
- 가장 간단한 것,단순한 것, 그러나 100% 제대로 동작하는 것을 추구하되,YAGNI로 미리 일반화하는
것, 발생하지 않은 문제를 미리 대비/해결하려는 것을 방지
- YAGNI 현재 필요치 않은 복잡성을 미리 추가하지 말라는 것으로, 필요 없는 복잡성에 반대하는 것임
라. 용기(Courage)
- 가능한 한 빨리 변경된 사항을 반영하여 고객에게 인도한다는 정신 아래 요구사항 및 기술 변경에
용감하게 대처
- 라이프사이클 후반부라도 요구사항 변경에 대해 용기있게 대처하도록 격려
- 결과적으로 남들과 소통이 잘 되고, 단순한 것에서 시작하고, 지속적인 피드백을 얻을 수 있다면
누구나 용감해질 수 있음.
III. XP에서는 12개의 실무
1.계획 게임(Planning Game)
- 고객(Customer)과의 다양한 이야기(Story)를 통한 계획/기획을 작성
- 비즈니스와 관련된 사람들은 우선순위(priority)와 범위(scope)를 정하고 기술진은 비용 견적을 계산
- 계획 게임을 매 이터레이션(iteration, 1~4주)마다 반복
- 한 이터레이션 내에서는 그 기간 동안에 구현할 것만 계획하고 구현
- 요구사항은 언제든지 변경될 수 있으며, 계획도 이에 발 빠르게 적응, 맞춰 나갈 수 있고, 현실
상황을 무시한 무리한 계획이 나올 수 없도록 하자는 논리에서 출발한것임
- 계획시 피드백도 중요한데, 이터레이션과 릴리스 주기(1~4개월)가 짧기 때문에 빠른 피드백을 얻고
이를 곧바로 다음 주기에 적용
2.리팩토링(Refactoring)
- 과감히 군더더기를 없애고 사용하지 않는 기능을 제거하고 못쓸 것을 쓸수있도록 하는 Refactoring을 통해 코드의 구조를 개선시켜나가는 과정
- 코드를 깔끔하고 명로하게 정리하게되면 이해하고,수정하고,확장하기가 용이해짐
- 외부에서 관찰 가능한 행동을 바꾸지 않으면서 내부 구조를 개선하는 것
- 회귀 테스팅(Regression Testing)이 필요.
- 리팩토링을 하기 전과 한 후에 테스트 코드가 모두 100% 만족되어야 합니다.
- 끊임없는 의사소통을 통해 심플하고 중복되지 않게 유지하며 재생산
3.단순 설계(Simple Design)
- 설계를 단순하고 명확하도록 유지
- 요구에 충족되는 가장 간단한 설계 . 미래를 위해 많은것을 투자하지 않고 비지니스적 가치에 집중
- 부가적인 기능이나, 사용되지 않는 구조, 알고리즘은 만들지 않는다.
- 시험이 쉽고 간단하도록 코드 작성
- 클래스나 함수의 수를 최소화
- 중복 코드는 모듈화
-
4.코딩 표준(Coding Standards)
-항상 깔끔하게 규칙적으로 코딩해야한다 . 이건 굳이 방법론을 거론하지 않더라도 개발자라면 당연히 지켜야할 의무이자 기본원칙
5.짝 프로그래밍(Pair Programming)
- 두 사람이 한 짝이되어 프로그래밍을 하는 것
- 한사람은 코딩을 하는 driver가 되고 한사람은 코딩을보고 조언도 해주며 도와주는 파트너가됨
- 프로그램에 대한 이해도가 높아져 궁극적으로 생산성이 높아짐
- XP 방법론에서 의견교환의 중요성을 가장 극명하게 보여주는 대목
- 오류가 훨씬줄고 코드 라인 수는 더 짧아짐
- 지식 공유, 팀웍 증진, 부차적인 현장 학습, 만족도증가 등의 장점
- driver와 partner로 구성
- driver : 실제 코딩 표준에 따라 코드를 작성하는 프로그래머
- partner : driver에게 전략과의 일치 여부 등, 모든 것을 상기시켜주는 역할을 하는 프로그래머
- driver와 partner의 역할을 바꿔가며 수행하면 코드와 시스템에 대한 이해가 높아지며, 작업이 재미있어진다.
6.코드공동 소유권 (Collective Code Ownership)
모든 코드는 모든 프로그래머들이 숙지하여 변경이 필요할 시 누구나 지체 없이 변경할 수 있어야 한다 à pair programming 의 결과
7.지속적인 통합(Continous Integration)
- 특정한 주기를 정하고 통합하는 것이 아니라 하루에도 몇번씩 통합을 하면서 테스트를 수행
- 전통적인 개발에서는 부분별 개발이 한참 진행되고 나서 각 부분을통합하는 작업이 진행되는데
이때 전혀 예상하지 못했던 문제들이 발생하는데 이를 최소화하자는 개념
- 자신이 맡은 태스크가 완료되면 그걸 바로 통합.
8.지속적인 테스팅(Continous Testing)
- 통합하기 전과 한 직후에 테스트를 실시
- 먼저 테스트를 수행하여 검증받은 코드로 작성해나간다
9.메타포어(Metaphor)
- 메타포는 고객과 프로그래머 혹은 프로그래머 간에 의사소통을 하는 공통의 언어를 형성
- 고객이건, 매니저건,프로그래머이건 간에 모두 공통의 언어로 그 시스템이 어떻게 돌아가는지
설명할 수 있어야 합니다
- 은유, 비유법을 자주 사용
10.작업에 고객 동참(On-site Customer)
- 개발 현장에 고객이 늘 상주하는 것
- 고객과 개발자들이 한 팀을 이룬다는 것을 인식하는 것이 더욱 중요
- 일반적으로 고객은 개발자들을 최대한 부려먹으려고 하고, 개발자들은 고객을 최대한 기만하려고 합함
- 개발과정에 고객을 적극적으로 개입시킨다 . 고객위주의 프로그래밍을 할것이며 그들의 의견을
적극적으로 반영
- 프로그래머가 작업을 하는데 필요한 내용들을 요구사항으로 정리
- XP에서 프로그래머와 고객의 활발한 의사 소통과 공동 작업은 프로젝트를 성공적으로
완료하도록 지원
- 개발자와의 지속적인 대화를 통하여 사용자 스토리는 더욱 구체화
11.주당 40시간 업무(40-Hour Work),
- 충분한 휴식후 맑고 건강한 상태로 최고의 효율을 발휘하여 프로그램을 작성
- 지나친 작업량은 오히려 개발을 비효율적
12.작은 릴리스(Small Releases)
- 데모수준이 아닌 실제시스템/제품릴리즈 기간을 최소화하도록 함
- 제품을 심플하게 작고 빠르게 그리고 자주 릴리즈
IV. 시스템 개발 라이프 사이클상의 XP 전략
가.XP의 특징
- 1 ~ 3 주간의 iteration을 제안
- 다른 소프트웨어개발 방법론과의 가장 큰 차이점은 테스팅을 강조
- Test Driven Development
: 개발이 들어가기전에 먼제 테스트프로그램을 개발하라.그렇게되면 자기가 개발하게될 프로그램의 기능이 명확해지고 빠른 개발이 가능해짐
- XP 는 작업자체에 대한 도큐멘테이션을 경시 .
- XP 개발자들은 고객 및 동료 개발자들과 의사소통을 잘 해야 한다.
- 개발하는 소프트웨어에 대해 개발 첫 날부터 유닛 테스트를 통해 피드백을 받는다.
- 개발 중인 시스템을 최대한 빨리 고객한테 보여줌으로써 고객들이 원하는 변경 사항을 빨리 도출할 수 있도록 한다.
-1~3주 내에 구현할 수 있는 수많은 요구사항(유저 스토리) 가운데 고객이 가장 중요하게 생각하는 것을 먼저 구현하며 시간이 모자라면 유저 스토리 가운데도 고객이 가장 중요시하는 과제를 먼저 구현
프로젝트가 예측한 시일 안에 끝날 수 있도록
1~3주마다 진행상황을 점검하고 다음 1~3주 동안 할 일을 계획한다.(주기 계획 회의). 유닛 테스트를 통해 구현된 코드가
유저 스토리를 만족한다는 것을 확인고. 유닛 테스트를 이용함으로써 틈틈이 리팩토링을 통해 코드의 질도 높인다.
※Architectural Spike:문제를 해결하거나 이해도를 높이기위해 작성하는 간단한 프로그램
※System Metaphor: 명명규칙과 같이 프로젝트 진행을 위해 팀원들이 지켜야 할 공통 규칙
※New User Story Project Velocity: 스토리 개발에 소요되는 속도. 즉, 스토리의 수/기간
유저 스토리
- 유저 스토리는 요구사항 명세서의 일종
- 고객이 원하는 시스템의 기능을 사용자 스토리로 작성
- UML의 유스 케이스와 같은 목적으로 만들어지지만 형식이 없고(informal) 고객에 의해 작성
- 기술적인 용어를 사용하지 않고 고객의 용어로 고객이 작성
- 개발일정수립 및 인수테스트의 근거자료
- 용도
: 복잡한 요구사항 명세 문서들 대신 사용
: Release planning 회의에서 시간을 측정하는데 사용
: 사용자 승인 시험에서 시험 시나리오 개발에 사용
-스토리는 가능한 작고, 자주 릴리즈 될 수 있어야 한다.
스파이크 솔루션(Architectural Spike)
- 스파이크 솔루션은 숨어 있을 수 있는 문제를 찾아내기 위한 아주 간단한 프로그램
- 유저 스토리가 만들어지면 risk에 대해 스파이크 솔루션을 작성.
- 다른 사항은 무시하고 제기된 문제만을 고려한 시스템을 구축
- 기술적 문제를 해결하거나 설계에 대한 이해도를 높이기 위해 작성
- 잠재적인 위험을 감소
- 구축해보고 해결점을 찾으면 스파이크는 삭제
시스템 메타포어(System Metaphor)
- 일관된 명명규칙을 이용해 클래스와 메소드 등을 명명
- 설명 없이 이해할 수 있고, 이름만으로 무엇을 하는지 추측이 가능해야함
- 주석이나 부수적인 문서가 없어도 시스템 설계 전반을 이해하고 코드를 재사용 하는데 매우 중요
- 설명하기 위한 많은 문서화 요구가 줄어들며, 개발 및 수정 시간을 단축
주기 계획회의(release planning)
- 회의에서 프로젝트의 전반적인 일정 수입
- 각 주기가 시작될 때마다 주기 계획 회의 실시
- 각 주기는 1~3주 정도
- 모든 참여자가 수용할 수 있는 일정을 정의
- 개발팀이 각 사용자 스토리의 개발 기간을 예측하고 연관있는 스토리를 묶어 릴리즈를 계획
- 3주를 초과할 경우 스토리를 더 작게 분할
- 1주 미만이면 너무 상세한 수준이므로 여러 스토리를 병합
- release plan: 구현할 사용자 스토리들과 릴리즈 기한이 명시된 산출물
반복 개발(iteration)
-한 iteration을 1~3주 분량으로 계획
-각 주기의 길이를 비슷하게 유지
-각각의 주기에 해야 할 일은 해당 주기가 시작될 때 주기 계획 회의를 통해 결정
- 주기에 스케줄링 불필요: 고객의 요구사항은 계속 바뀌기 때문에 미리 계획할 필요가 없음
-주기 데드라인을 엄수: 진척상황을 확인해서 데드라인을 넘길 것 같으면 주기 계획 회의를 다시 소집해서 일부 과제를 뺀다
- 고객이 선정한 가장 중요한 과제에 집중
승인 테스트
- iteration planning 회의에서 선택한 사용자 스토리에 대해 사용자 승인 시험을 실시
-고객이 참여해 구현될 코드를 검사할 시나리오 작성
-고객은 승인 테스트가 올바르게 만들어졌는지를, 그리고 실패한 테스트의 중요도를 확인
-승인 테스트를 통과해야 유저 스토리에 대한 처리가 완료
-하나의 스토리는 구현된 기능을 확인하기 위해 한 번 이상 사용자 승인 시험을 실시
-사용자 승인 시험은 자동화하여 자주 수행
Small Release
- 개발팀은 고객에게 반복적으로 시스템 개발 결과를 자주 릴리즈할 필요가 있음
- 중요 기능을 수행하는 부분을 시스템 사용자에게 더 오래 보여줄 수록, 그 부분을 수정하는데 걸리는 시간이 더 감소됨
유닛 테스트
- XP에서는 집단 코드 소유(collective code ownership)라고 하는데, 필요하면 누가 어떤 코드든지 고친다는 뜻. 이렇게 하기 위해서는 유닛 테스트(unit test)가 필요.
- 유닛 테스트는 자주 실행할 수 있도록 자동화
- 모든 모듈을 테스트할 수 있도록 만들어져야 한다
- 코드를 작성하기 전에 유닛 테스트를 작성하는 것이 좋다
가. 계획 측면
1) 목적
- 팀이 개발한 SW의 가치를 최대화
2) 전략
- 가능한 한 적게 투자, 가능한 한 빨리, 가능한 한 가장 가치 있는 기능 구현
3) 필요 도구 : 스토리 카드
4) 행위자 : 비즈니스측, 개발자측
5) 단계
- 탐색 : 새로운 기능 찾기
- 결정 : 다음 번에 구현할 요구사항 결정
- 조종 : 개발 가이드
나. 개발 측면
- 지속적 통합
- 매 수정마다 통합 및 테스트 실행
- 공동 소유
- 복잡한 코드 제거, 다른 사람의 어리석은 행동에서 방해 되지 않는다.
- 짝pair 프로그래밍
- 동시에 개발하는 두 사람간의 대화
- 어떻게 더 좋은 프로그램으로 만들 것인가를 같이 이해
다. 설계 측면
1) 테스트부터 시작
2) 설계 및 구현
3) 반복
4) 더 단순하게 만들 수 있다면 그렇게 하라
5) "가장 단순한 것"의 의미
- 시스템이 의사소통 하기를 원하는 모든 것들과 의사소통이 가능하도록 하는 것
- 중복된 코드가 없을 것
- 가능한 한 클래스들은 적게 만들 것
- 가능한 한 메소드들은 적게 만들 것
라. 테스트 측면
- 각 테스트는 다른 부분과는 관련이 없어야 한다.
- 테스트는 자동화되어야 한다.
- 테스트 프로그램 만드는 주체 : 프로그래머 함수 단위, 고객 스토리 단위
xp에서의 담당자들의 역할
|
사용자 |
사용자 스토리1)작성 릴리즈 항목2)을 결정하고, 그들 간의 우선순위를 설정 사용자 승인 시험을 정의 |
|
프로그래머 |
사용자 스토리들에 대한 난이도를 추정 분석, 설게, 시험, 프로그래밍 및 통합을 수행 |
|
프로젝트관리자 |
고객과 프로그래머의 협동을 지원 프로젝트 관리 문제점들을 해결 요원에 대한 보상활동 수행 |
※사용자 스토리 :사용자 요구사항 중 일부를 짧게 명세한 것, 개발의 단위로 사용
다른 방법론과 XP와의 관계
|
구조적 방법론 |
데이터의 흐름을 중요시 DFD,ERD등을 써서 분석과 설계를 진행 |
|
객체지향 방법론 |
객체와 그들의 역할을 찾아내는 방식 데이터의 흐름보다는 데이터와 관련되는 연산을 중요시 클래스 다이어그램, 시퀀스 다이어그램 등을 써서 분석과 설계 진행 |
|
XP 방법론 |
나선형 모델을 좀더 극단적으로 적용한 것 |
V. XP의 활용분야
- 모바일이나 쇼핑몰처럼 소비자의 변화에 따라 짧은 시간에 민첩하게 변화되어야 하는 분야
- 요구사항 등의 변화가 자주, 많이 있거나 개발자가 소규모(10명 내외)이고 같은 공간을 사용하는 경우에 높은 효과
– 유동성이 큰 프로젝트 / 단기간의 프로젝트 . ( 3~4 월 .. )
– 기술적으로 신 기술을 도입하였거나 , 경험이 없거나 , 잘모르겠거나 …
사양이 명확 하지 않거나 ,최종 모습이 애매거나 , 그때 그때 변해 갈 우려가 큰 경우
– 요구사항 등의 변화가 자주, 많이 있거나 개발자가 소규모(10명 내외)이고 같은 공간을 사용하는
경우에 높은 효과를 볼 수 있다고 알려져 있고, 다른 규모나 원거리 XP 등의 적용이 꾸준히 시도되고 있다
Do
항상 설계하라.
어떤 스토리를 어떤 순서로 만들던지 개의치 마라.
무엇을 확실히 알게 되었을 때 설계 문서를 작성하라.
항상 의사소통을 중시하라.
프로젝트의 진행상황을 자주 공표하라.
모든 사람이 설계에 참여하도록 하라.
할 수 있는 한 가장 간단한 설계를 작성하라.
오늘 코드를 간단하게 만들었다면, 내일 이것을 향상시키는 것은 쉽다.
오늘의 문제를 해결하기 위한 가장 간단한 일을 해라. 단 확실히 완성하라.
XP는 팀 기반의 작업이다. 모든 팀원은 같은 규칙에 따라 작업하여야 한다.
Do not
구현을 시작하기 전에 전체 시스템을 설계하려 하지마라.
구현을 시작하기 전에 요구사항을 고정시키려 하지마라.
사용되지 않을 문서나 산출물을 작성하지 마라.
팀을 설계자와 코더로 분리하지 마라.
'◆ 무한한 가능성 > & Programming' 카테고리의 다른 글
| [조언] 꿈꾸는 공대생 - 서울대학교 김종원 교수님 (0) | 2009.01.12 |
|---|---|
| [펌글] IT맨, 내가 사직서를 쓴 이유. (0) | 2009.01.12 |
| [펌글] SOCK_STREAM 소켓의 특성 (0) | 2009.01.12 |
| [펌글] 크리티컬섹션, 뮤텍스, 세마포어의 차이 (0) | 2009.01.12 |
| [펌글] 소스 분석 방법 (0) | 2009.01.12 |