eXtreme Programming - 1

eXtreme Programming의 1부를 요약, 정리한 글.

1. XP란 무엇인가?

• 의사소통, 피드백, 단순성, 용기, 존중에 바탕을 둔 개발철학.
• ‘개발’을 개선하는데 쓸모 있다고 증명된 실천 방법들의 집합.
• 상호보완적 원칙들, 가치를 실천 방법으로 옮기는 지적 기법들의 집합.
• 가치를 공유하고, 동일한 실천 방법들 중 상당수를 공유하는 공동체.

1. 방법론?

1. XP의 방법론이란?
   • 모호한 요구사항이나 빠르게 변하는 요구사항에 직면한 중소규모의 개발팀을 위한 가벼운 방법론.
   • 인간성과 생산성을 조화시키고 공유한다.
   • 기술적 탁월함을 추구한다.
     • 정확한 추정값과 좋은 품질의 제품, 빠른 피드백이 이루어지는 순환구조를 의미한다.
   • 언제나 100%를 쏟아붓고, 결과에 승복한다.
   • 의사소통을 명확하게 한다.
2. 여타 방법론과 무엇이 다른가?
   • 짧은 개발 주기.
   • 점진적 계획 접근법. 전반적인 계획을 빨리 만들고 시작한 다음, 프로젝트의 생애 내내 그 계획이 진화해 가리라 생각한다.
   • 기능 구현 일정을 유연하게 세워 자주 바뀌는 비즈니스 요구에 대응한다.
   • 자동화된 테스트에 의존한다.
   • 구두 전달, 테스트, 소스 코드에 의존하여 시스템 구조와 시스템의 의도를 전달한다.
   • 평범하지만 열정적인 다수가 긴밀히 협력한다.
   • 팀 구성원들의 단기적 본능과 프로젝트의 장기적 이해관계 둘 다에 적용될 수 있는 실천 방법들에 의존한다.

2. 위험에 대처하기

1. 일정 밀림
   • XP에서는 아무리 길어도 몇 달인 정도로 릴리즈 주기가 짧아야 한다.
   • 일주일 단위의 반복을 이용해 작은 피드백을 주고받는다.
   • 가장 우선순위가 높은 기능부터 구현한다.
2. 프로젝트 취소
   • 비즈니스 쪽 구성원들에게 가장 중요하면서도 가장 작은 릴리즈를 선택하기를 요구한다.
3. 시스템 이상
   • 포괄적인 자동화 test suite를 만들고 유지한다.
   • 이 테스트들은 시스템의 변화가 생길 때마다 실행한다.
4. 결함 비율
   • 함수 단위, 기능 단위의 테스트를 한다.
5. 비즈니스에 대한 오해
   • 비즈니스 쪽의 사람들도 팀의 일원이 된다.
6. 비즈니스의 변화
   • 릴리즈 주기를 짧게 가져가면 고객이 새로운 기능 개발을 요청하는 간격이 짧아질 수 있다.
7. 이름뿐인 기능
   • 오직 우선순위가 가장 높은 작업만을 다룬다.
8. 직원 교체
   • 프로그래머들이 자기 일을 추정하고 완료하는 책임을 받아들인다.
   • 팀 내부에서 인간적인 접촉을 장려하고, 새로운 인원이 유입된 경우 기존 프로그래머들이 도움을 준다.

3. 결론

• 효과적인 새로운 습관을 선택한다.
• 오늘의 노력에 대해 자신을 인정한다.
• 내일 더 잘하기 위해 노력한다.
• 팀 전체의 목표에 내가 얼마나 기여했는가로 자신을 평가한다.
• 제품을 개발하는 와중에도 인간적인 욕구를 채우기 위해 요구하는 것을 뜻한다.

2. 운전하는 법 배우기

• 깨어있고 적응하며, 변화한다.
• 변화가 문제가 아니라, 변화를 극복하지 못하는 것이 문제다.
• 고객은 시스템의 방향을, 개발팀은 그것을 구현하는 프로세스를 결정한다.

3. 가치, 원칙, 실천 방법

• 가치를 명시하지 않는다면, 실천 방법은 의미 없는 기계적 활동이 되어버린다.
  • 아무런 목적이 없는 TDD 같은 것이 좋은 예시이다.
• 가치는 실천 방법에 목적을 부여하고, 실천 방법은 가치에 책임을 부여한다.
• 가치는 보편적이고 잘 변하지 않지만, 실천 방법은 상황에 따라 유연하게 변화한다.
• 원칙은 가치와 실천 방법을 이어준다. 원칙은 특정 영역에서의 영원한 지침이 된다.
• 결국, 직접 XP 스타일로 일하고, 공유해야만 XP에 숙달된다.

4. 가치

1. 의사소통
2. 단순성
   • 불필요한 복잡성을 제거하는 쪽으로 고민한다.
   • 상황에 따라 의미가 달라진다.
   • 의사소통을 통해 불필요하거나 미룰 수 있는 요구사항을 제거할 수 있고, 이는 단순성을 달성하는 데 도움을 준다.
3. 피드백
   • 다음의 이유로, 점진적 개선을 위해 피드백을 이용하여 목표로 접근한다.
   • 최대한 빨리, 많은 피드백을 만들기 위해 노력한다. 팀의 상태를 보며 양과 속도를 조절한다.
4. 용기
5. 존중
   • 구성원들이 서로를 고려하고 존중하지 않는다면 제대로 XP를 할 수 없다.
   • 가치는 무엇을 해야 하는지 구체적으로 충고해주지 않기 때문에 원칙이 필요하다.

5. 원칙

• 원칙은 개발하는 제품에 따라 달라진다.
• XP의 원칙은 다음과 같다.

1. 인간성
   • 인간적인 욕구를 인정하지 않으면, 비인간적인 프로세스에 마모된다.
   • 기본적인 안전, 성취감, 소속감, 성장, 친밀감이 필요하다.
   • 개인과 팀 사이의 욕구 균형을 맞춘다.
2. 경제성
   • 비즈니스 가치를 지니고, 비즈니스 목표에 부합하며, 비즈니스 필요를 충족하는지 확인한다.
   • 그렇지 않으면, ‘기술적 성공’이라는 공허함만 남게 된다.
   • 돈을 빠르게 받고, 비용은 나중에 지불하는 개발이 가치 있다.
3. 상호이익
   • 모든 활동은 그 활동에 관련된 모든 사람들에게 이익이 되어야 한다.
   • 제안을 수용해주기를 원한다면, 그 제안이 야기하는 문제의 수보다 해결해주는 문제의 수가 더 많아야 한다.
   • 현재와 미래와 고객에게 이익이 되는 win-win-win 실천 방법을 찾는다.
4. Self similarity
   • 모든 상황에서 효과를 내는 원칙은 아니다.
   • 어떤 해결책이 유용하다면, 맥락과 규모가 달라도 적용해 본다.
5. 개선
   • ‘완벽’은 없지만 완벽해지기 위해 노력하는 것도 가능하다. 완벽을 기다리지 않는다.
   • XP는 개선을 통해 탁월함에 도달하는 것이다. 오늘 최선을 다하고, 내일 더 잘하기 위한 깨달음과 이해를 구한다.
6. 다양성
   • 문제 해결을 위해 협동과 대비되는 의견 모두를 존중한다.
   • 갈등 없는 팀은 없으며, 이를 생산적으로 해결해야 한다.
7. 반성
   • 어떻게, 왜 일하는지도 생각한다.
   • 실수를 감추지 않고 드러내어 거기서 배운다.
   • 일하는 방식에 대해 수시로 고민한다.
   • 실천과 반성을 뒤섞어 피드백을 최대화한다.
8. 흐름
   • 개선을 위해 가치를 조금씩 점진적으로 배치한다.
   • 피드백이 줄어들면 문제는 더욱 악화된다.
9. 기회
   • 문제를 배움과 개선의 기회로 바라본다.
10. 잉여
    • 핵심적이면서도 해결하기 어려운 문제에는 여러 가지의 해결방법을 마련해 놓는다.
    • 이러한 ‘잉여’를 만드는 비용보다 재앙을 면하는 이득이 더 크다.
    • 비용으로 인해 정당한 잉여를 제거하지 않도록 조심한다.
11. 실패
    • 어떤 것을 구현하는 세 가지 방법 중 무엇을 선택해야 할지 모르겠디면, 셋 다 해본다. 무엇을 해야 할지 모르겠다면 실패를 감수하고 성공으로 가야 한다.
    • 실패를 통해 얻는 것이 있다면 자원을 허비하는 것이 아니다.
12. 품질
    • 품질은 제어할 수 있는 변수가 아니다.
    • 낮은 품질이 개발속도를 빠르게 만들지 않고, 높은 품질이 개발 속도를 떨어뜨리지 않는다.
    • 품질이 향상될수록 생산성, 효율성 같은 속성들이 개선된다.
13. 아기 발걸음
    • 단계를 잘게 나눌 때 생기는 overhead가, 큰 변화를 시도했다가 실패하여 다시 원상태로 돌아오는 ‘낭비’보다 훨씬 작다는 사실을 인지한다.
14. Accepted responsibility
    • 구현을 책임진 사람이 설계, 구현, 테스트까지 책임진다.
    • 책임에 권위를 잘 연결한다.