eXtreme Programming
애자일 개발방법론중에 하나인 익스트림 프로그래밍(XP)
1. 규칙
계획
- 요구사항정의
요구사항정의서 : 유저 니즈를 정리한 문서, 개발 스펙이나 방법에 대해서는 정의하지 않는다
- 릴리스 계획 세우기
유저의 요구사항을 구현하는 데 걸리는 시간 계획
전제사항, 엮인일, 잡무를 제외한 시간을 예측(단, 테스트 기간 포함)
주어진 시간내에 몇개의 요구사항을 구현할 수 있고 몇개의 요구사항 세트들이 얼마나 걸리는지?
개별 반복(Individual Iteration)마다 얼마나 많은 요구사항을 처리할 수 있는지?
릴리스 계획은 대체로 4개의 quantified된 변수에 의해 결정된다. Scope(어느 범위까지 일이 완료되어야 하는지), Resources(얼마나 많은 사람이 투입되는지), Time(얼마나 많은 시간이 걸리는지), Quality(얼마나 퀄리티가 높아야 하는지, 어느 정도의 테스트가 필요한지)
- 작은 릴리스를 자주 공개하기
고객과의 잦은 소통으로 프로젝트 방향성 잡기
개발 투명성 유지하기
- 각 프로젝트는 "반복(Iteration)"으로 쪼개어 진행한다.
관리
- 팀은 열린공간(Open work space)에서 개발한다
서서하는 미팅, 화이트보드, 열린 토론, 브레인스토밍
- 지속할 수 있는 페이스를 만든다
실현가능한 현실적인 계획을 세운다
"인간적으로 가능한"것보다 더 많은 일이 주어질 경우 Scope 또는 Timing을 조절한다
Fred Brooks는 이미 늦은 프로젝트에 대해서 더 많은 사람을 투입하는 것은 안좋은 아이디어라고 했다. 늦기전에 릴리스 플래닝을 잘 예측하라.
프로젝트를 성공적으로 끝내기위해 팀의 적절한 속도를 찾는 것이 중요하다
- 하루의 시작은 서서하는 미팅으로 한다
모든사람이 서서하는 잠깐의 미팅이 몇명의 개발자들이 앉아서 하는 것보다 효율적이다
서서하는 미팅은 시간낭비를 줄여준다
어제 무엇을 성취했는지, 오늘 무엇을 시도할 것인지, 딜레이를 초래하는 문제는 무엇인지에 대해 이야기한다.
- 프로젝트 속도(Project Velocity)를 측정한다
일정하고 예측가능한 속도(Steady Predictable Pace)를 유지하기위해 반복계획을 수정한다
- 움직이면서 일한다
사람들과 소통하면서 지식의 고립과 코딩의 병목현상을 없애도록 한다
Pair Programming을 하도록 노력한다(두명이 함께 개발/테스팅 혹은 한명이 개발 한명이 테스팅)
XP룰이 깨지면 고치도록 한다
디자인
- 간결(Simplicity)
가장 간단한 디자인으로 부터 시작한다
팀내에서 "간결"의 정의를 확실히 한다
각자 주관적 코드 평가를 한다
Testable, Understandable, Browsable, Explainable 로 퀄리티를 나눈다
Testable : Unit test와 Acceptable test를 작성할 수 있는지
Browsable : 내가 원할때 찾을 수 있는지
Understandable : (굉장히 주관적) 같이 일한 사람이 이해할 수 있는지
Explainable : 새로온 사람 또는 개발자가 아닌 사람이 이해할 수 있는지
예) 함수를 작성할때
소수점을 %로 바꿀때, cm를 m로 바꿀때 똑같이 100을 곱하는 함수를 작성하지만 convertToPercentOrMeters(x)로 작성하지 않고 converToPercent(aFraction)와 convertMetersToCentimeters(aLength)로 나누어 함수를 작성한다
스타일시트를 작성할때도 똑같다 brad-right가 아니라 small-font float-right와 같은 네이밍을 사용한다
- 시스템 메타포를 선택한다
시스템에 특별한 네이밍을 하도록 한다. 현재 완성된 프로젝트가 아니기 때문에 함수나 오브젝트의 이름을 정하기 힘들때가 있다. 이미있는 시스템 또는 사물에 비유하여 코딩을 하도록 한다.
- 스파이크 솔루션(Spike solution)을 만들어 리스크를 방지한다
기술적 한계 또는 어려움이 예상되면 잠재적인 해결가능성을 가지고 있는 코드를 작성해본다. 이 코드는 대부분 버려질 것이다.
- 기능성을 초기에 추가하지 않도록 한다
이 기능을 넣어두면 시스템이 나중에 더 좋아질거야라는 생각은 접는다
실제로 기능성 추가는 정말로 필요하지 않으며 항상 우리의 자원을 낭비한다
Turn a blind eye towards future requirements and extra flexibility. Concentrate on what is scheduled for today only.
- 무자비하게 리팩토링 한다
코드 재사용성과 유지때문에 리팩토링을 주저하지 않도록 한다. 이또한 자원낭비로 이어진다.
전체적 리팩토링은 프로젝트 생명주기를 늘리고 퀄리티를 높인다
항상 코드를 간결하게 깨끗하게 유지하여 이해하고, 수정하고, 확장하기 쉽도록 유지한다
리팩토링은 훌륭한 디자인을 전제로 한다
코딩
- 고객과 항상 대화하도록 한다
커뮤니케이션은 항상 중요하다
- 코드는 항상 합의된 코딩 표준을 따르도록 한다
집단 오너쉽을 가질수 있도록 표준을 정하고 따른다
- 코드보다 유닛 테스트를 먼저 작성한다
실제 코드보다 유닛 테스트 코드를 먼저 작성하면 코딩이 쉽다(TDD의 개념)
무엇이 완성되야하는지 확실히 보인다
완성된 스펙에 대해 오해를 피할 수 있다(커뮤니케이션도 쉽다)
즉각적인 피드백을 얻기 쉽다
나중에 테스트하기 쉽다
- 모든 프로덕션 코드는 Pair Programmed 되어야 한다
두 사람이 한 컴퓨터로 코딩한다
지식을 공유하고 온도차를 없앤다
새로운 방식을 도입하기 쉽고 "지식의 섬(Knowledge Island)"에 갇히는 것을 방지한다
가장 좋은 페어 프로그래머는 "너의 아이디어를 먼저 해보자"라고 말하는 사람이다
페어 프로그래밍은 멘토링이 아니다. 절대 "선생과 학생"의 관계가 아니다
- 순서대로 인테그레이션 한다
프로그램에 문제가 생겼을때, 각자 맡은 파트 또는 클래스가 엮여있을 경우 순서대로 해결하도록 한다. 엮여있는 팀은 앞의 팀이 문제를 해결할때까지 기다린다
모든 문제는 한 페어가 하나씩 커밋하도록 하고 최신 버전은 그 문제가 해결된 버전이어야 한다
- 자주 인테그레이트 한다
저장소에 자주 커밋하도록 한다
분기되고 조각화된 개발에서 노력을 반으로 줄여준다
자주 공유함으로써 다른 팀원들이 최신 버전으로 작업할 수 있게 한다
인테그레이션은 유닛 테스트에도 영향을 준다
호환성 문제를 미리 방지할 수 있다
- 인테그레이션 전용 컴퓨터를 설치한다
누가 언제 릴리스했는지 기록을 남겨둔다
- 집단 오너쉽(Collective Ownership)을 사용하라
모든 사람이 새로운 아이디어를 기여하고 함께 코드를 바꾸는 방식
테스팅
- 모든 코드는 유닛 테스트를 가지고 있어야 한다
- 모든 코드는 릴리스되기전에 모든 유닛 테스트를 거쳐야 한다
- 버그가 발견되면 테스트를 만들어야 한다
- Acceptance Test 는 자주 실행되어야하고 점수가 정해져야 한다
2. 용어 설명
릴리스 플래닝(Release Planning) : 요구사항정의서를 개발 언어로 바꾸는 작업, 테스팅 계획 및 리팩토링을 포함한다.
반복(Iteration) : 1~3주 정도의 개발 결과물을 보이는 기간, 개발일정을 여러개의 "반복"으로 나누어 민첩성을 높임(심장박동과 같다). 너무 먼 미래의 계획을 잡지말고 "반복 미팅"을 통해 "Just-in-time planning"을 세워라.
반복 플래닝(Iteration Planning) : 1 ~ 3일(필요하다면 1/2도 추가)동안 개발할 수 있는 단위로 쪼개서 계획을 세우는 것. 3일을 초과하는 개발은 세부적으로 쪼개도록 한다. 쪼개는 과정을 통해 Project velocity(프로젝트 진행속도)를 조절할 필요가 있다.
3. 기타
스크럼이 추구하는 가치
- 확약(Commitment)
약속한 것을 확실히 실현하는 것
Because we have great control over our own destiny, we are more committed to success.
왜냐하면 우리는 우리의 운명을 훌륭하게 컨트롤할 수 있기 때문에, 성공을 더 확신할 수 있다
- 전념(Focus)
확약한 것의 실현에 전념하는 것
Because we focus on only a few things at a time, we work well together and produce excellent work. We deliver valuable items sooner.
왜냐하면 우리는 한번에 몇가지 적은 일에 집중하기 때문에, 함께 열심히 일하고 가치있는 제품을 빨리 내놓는다
- 정직(Openness)
어떤 것이 자신에게 불리해도 숨기지 않는 것
As we work together, we express how we're doing, what's in our way, and our concerns so they can be addressed.
우리는 함께 일하기 때문에, 우리가 어떻게 일을 하고 있고, 앞으로 무엇이 예상되며, 어떻게 자리잡을 것인지에 대한 염려를 표현한다
- 존중(Respect)
자신과 다른 사람에게 경의를 표하는 것
As we work together, sharing successes and failures, we come to respect each other and to help each other become worthy of respect.
우리는 함께 일하기 때문에, 성공과 실패를 공유하고, 서로를 존중하며, 서로를 돕는 것이 존중의 가치가 된다
- 용기(Courage)
위의 사항을 언제든지 지킬 수 있는 용기
Because we work as a team, we feel supported and have more resources at our disposal. This gives us the courage to undertake greater challenges.
왜냐하면 우리는 팀으로 일하고, 서로 도움을 받으며, 우리의 재량권에 더 많은 가치를 둔다
애자일 소프트웨어 개발 선언
http://www.agilemanifesto.org/iso/ko/
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을
도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고
있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:
공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를
가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만,
우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.
