eXtreme Programming - 2

앞의 글에서 이어지는, eXtreme Programming의 1부를 요약, 정리한 글.

6. 실천 방법

• 가치를 통해 목적을 불어넣지 않은 실천 방법은 무의미하다.
• 실천 방법은 상황에 따라 바뀐다. 원칙은 도메인 영역에 따라 바뀐다. 단, 가치는 바뀌지 않는다.
• XP의 실천 방법은 궁극적인 방법론이 아님을 명심한다.

7. 기본 실천 방법

1. 함께 앉기
   • 개발 작업은 팀 전체가 들어갈 정도로 열린 공간에서 한다.
   • 사생활 공간과 분명한 선을 긋는다.
   • 소통이 중요하다. 무조건 얼굴을 맞대야 하는 것은 아니며, 프로젝트에 문제가 발생한다면 일단, 이 실천 방법을 고려해 본다.
2. Cross functional team
   • 프로젝트의 성공에 필요한 기술과 시야를 지닌 사람들을 모두 팀에 포함한다.
   • 팀원들은 소속감이 필요하다.
     • 우리는 소속되어 있다.
     • 우리는 이 안에 함께 있다.
     • 우리는 서로의 작업, 성장, 배움을 돕는다.
     • 말콤 글래드웰은 “The Tipping Point”에서 팀 규모의 지속이 끊어지는 두 지점을 12, 150으로 말한다. 팀의 크기가 이 한계 수치를 넘으면 팀을 나눈다. 열두 명은 하루에 모두와 편안하게 의사소통할 수 있는 사람들의 수다.
   • 팀원들은 필요에 따라 동적으로 변한다.
   • 프로젝트의 규모가 크다면, 문제를 나누어 여러 팀으로 구성한다.
3. 정보를 제공하는 작업공간
   • 작업 공간에 작업에 대한 것들을 채워, 프로젝트에 관심 있는 사람이라면 15초 안에 상황을 파악할 수 있게 한다.
   • 스토리 카드가 붙은 ‘스토리 벽’은 많은 정보를 제공한다.
     • 단, 정말 중요한 정보만을 위해 사용해야 한다.
     • 프로젝트 전체의 흐름을 볼 수 있으며 문제점을 파악해 볼 수 있다.
   • 차트는 일을 진전시키는 데 도움을 준다. 일이 해결되거나 진전이 없다면 폐기한다.
4. 활기찬 작업
   • 개인이 생산적으로 일할 수 있는 시간만큼만 일한다.
   • 컨디션이 좋지 못하면 팀을 위해 푹 쉬고 자신에 대한 제어권을 되찾는다.
   • ‘업무집중 시간’을 선언하는 것도 방법이다.
5. Pair programming
   • 개인적인 공간도 중요하며, 이를 존중한다.
   • 개인적 위생 상태와 건강도 중요하다.
   • 개인차를 존중하는 것이 무엇보다 중요하다. 불편함을 느낀다면 오히려 효율이 떨어질 수도 있다.
6. 스토리
   • 고객이 볼 수 있는 기능을 기본 단위로 계획한다.
     • 예를 들면, “사용자가 자주 쓰는 메뉴는 두 번 클릭만으로 쓸 수 있게 한다.” 같은 계획이어야 한다.
   • ‘요구사항’ 실천 방법과의 핵심 차이는 ‘일찍 추정하기’이다. ‘요구사항’이라는 단어는 변화를 포용하지 못하게 가로막는다.
     • 일찍 추정하면 사업과 기술적 시야가 상호 작용할 기회가 생기는데, 이를 통해 조기에 가치를 만들어 낼 수 있다. 이른 시기의 아이디어가 최대의 잠재력을 갖는다.
   • 스토리에는 짧은 글, 그림 설명 외에도 추가로 짧은 이름을 붙인다. 그 스토리를 인덱스 카드에 적어 사람들이 자주 다니는 벽에 붙인다.
   • XP식 계획은 매우 초기 단계에 스토리 추정을 한다. 이것은 모든 사람이 적은 투자로 가능한 많은 이익을 볼 수 있을지 생각하도록 만든다.
7. 일주일별 주기
   • 한 번에 일주일 분량의 일을 계획한다.
     1. 지금까지 진행된 상황을 검토하는데, 지난주의 실제 진행 정도가 예상 진행 정도를 달성했는지 포함해 검토한다.
     2. 이번 주에 구현할 일주일 분의 스토리를 고객이 고르도록 한다.
     3. 스토리를 여러 태스크로 나눈다. 팀 구성원들은 자기가 할 과업을 가져가고, 얼마나 걸릴지 추정한다.
   • 스토리에 대한 자동화 테스트를 완성하고, 스토리가 테스트를 통과할 수 있게 한다.
   • 만약 일주일 안에 모든 테스트를 통과시키지 못할 것 같다면, 가장 가치 있는 스토리를 선택해 그것만을 완성할 시간적 여유를 갖는다.
   • 계획짜기는 일종의 필요한 낭비다. 이것에 드는 시간을 줄이기 위해 노력한다.
     • Task stack을 만드는 것도 방법이 될 수 있다.
8. 분기별 주기
   • 한 번에 한 분기 분량의 일을 계획한다. 팀, 프로젝트, 진행 정도, 더 높은 목표, 프로젝트 방향의 일치 여부 등을 논의한다.
     • 병목, 특히 외부의 병목을 찾아본다.
     • Repair 작업을 시작한다.
     • 이번 분기의 theme들을 계획한다.
     • 그 theme에 대한 한 분기 분량의 스토리들을 고른다.
     • 프로젝트가 조직에서 차지하는 위치라는 큰 그림에 초점을 맞춘다.
   • ‘주제(theme)‘와 스토리를 구분하는 이유는, 스토리가 큰 그림에서 차지하는 위치를 고려하지 않고 자기 일에만 초점을 맞추는 것을 경계하기 위해서다.
   • 팀 차원의 반성을 한다. 병목을 찾고, 장기 실험을 제안할 수도 있다.
9. 여유
   • 계획을 세울 때, 일정에 뒤처질 경우 포기 가능한 ‘덜 중요한’ 태스크를 포함한다. 이는 신뢰 관계 구축을 위해 필요하다.
   • 습관적인 과잉약속을 피하고, 분명하고 솔직하게 의사소통한다.
10. 10분 빌드
    • 10분 안에 모든 테스트를 자동으로 실행하고 전체 시스템을 빌드한다.
      • 빌드를 자동화하고, 일부분이라도 테스트를 자동화시킨다.
11. 지속적 통합
    • 변경에 대해서는 2, 3시간 안에 통합하고 테스트한다.
    • 빌드와 테스트를 기다리는 시간은 작업에 대해 복기할 좋은 기회다.
    • 지속적 통합은 언제나 완제품을 내놓는 것을 목표로 한다.
12. TDD
    • 실패하는 자동화된 테스트를 작성한다.
    • 테스트가 실행되는 시간은 최대한 짧아야 한다.
13. 점진적 설계
    • 시스템의 설계에 매일 투자한다.
    • 현재의 설계가 최선의 설계에 근접(일치)하도록 점진적이고 지속적해서 작업한다.
    • 마지막 책임 지점(last responsible moment)까지 설계 투자를 미룬다. [[warning]] | 설계에 대한 투자를 최소화하라는 것이 절대 아니다. 설계만을 위한 과도한 투자를 경계하라는 뜻이다. 필요한 만큼만 설계에 투자한다.
    • 중복을 제거하는 것은 휴리스틱 하게 설계를 개선하는 방법이다.
    • 설계를 사용하는 시점과 최대한 가까워졌을 때 설계한다.

8. 시작하기

• 모든 사람에게 적합한 시작 지점은 없다.
• 한 번에 하나씩 바꾸는 방법은 매우 쉽고 효과적이다.
• 새로운 습관을 들이기는 쉽지 않다.
  • 빠르게 도입해도 괜찮지만, 예전으로 돌아가지 않게 추스를 시간을 확보한다.
• 무엇을 바꿀지 어떻게 결정할까?
  1. 어떤 일을 하고 있는지, 무엇을 이루고 싶은지 고민한다.
  2. 그 후, 실천 방법을 선택한다.
  3. 개발 프로세스를 개선하기 위한 스토리를 계획한다.
  4. 각 스토리에 대해 시간을 추정한다.
  5. 쉬운 것부터 순차적으로 진행해 본다.
• 변화를 위해서는 깨달음이 필요하다.
  • 각 실천 방법들을 보고, 현재의 위치를 찾은 다음 우선순위가 높고 목적과 일치하는 것을 고른다.
• 실천 방법을 강요하면 팀의 신뢰를 파괴하고 원망을 낳게 된다.

9. 보조 실천 방법

• 기본 실천 방법을 완전히 수행하고 있는 상태에서 실천한다.

1. 진짜 고객 참여
   • 구축하게 될 시스템에 따라 인생과 사업이 달라질 수 있는 고객을 팀에 포함한다.
   • 고객 “대행”이 아니기 때문에, 빠른 속도로 방향성과 예산에 대해 결정을 할 수 있다.
2. 점진적 배포
   • 레거시 시스템을 교체하는 등의 작업을 할 때는 점진적으로 교체한다.
   • 당장 다룰 수 있는 작은 기능이나 제한된 데이터 셋을 찾아 우선 작업한다.
3. 팀 지속성
   • 효율적인 팀은 계속해서 팀으로 놔둔다. 신뢰하는 인원끼리의 co-work를 깨지 않는다.
   • 전혀 변화를 주지 말라는 뜻은 아니며, 대체로 팀을 유지하되 구성원들을 적당히 회전시킨다.
4. 팀 크기 줄이기
   • 팀의 능력이 신장하면, 일은 유지하면서 팀은 줄이고 남은 팀원으로 새 팀을 만든다.
5. 근본 원인 분석
   • 결함이 발견될 때마다 결함과 원인을 모두 제거한다.
   • 결함이 다시 나타나는 것을 막는 것이 아니라, 팀의 반복적인 실수를 방지한다.
     1. 결함을 드러내는 시스템 차원의 자동화된 테스트를 작성한다.
     2. 결함을 재생산하는, 가능한 한 범위가 가장 좁은 unit test를 작성한다.
     3. 이 unit test가 통과하도록 코드를 고친다. 그와 동시에 시스템 차원의 테스트 역시 통과해야 한다. 그렇지 않다면 2번으로 돌아간다.
     4. 결함을 해결한 후에는, 왜 이 결함이 생겼는지, 이전에는 잡히지 않았는지 알아낸다. 원인을 찾았다면, 그 원인을 해결한다.
6. 코드 공유
   • 팀의 ‘집단 책임감’이 자리 잡은 후에 시도한다.
   • Pair programming이 도움이 된다.
7. 코드와 테스트
   • 오직 코드와 테스트만 영구 산출물로 유지한다. 다른 문서들은 코드와 테스트에서 생성되게끔 한다.
   • 지금은 쓸모없어진 산출물을 제거한다.
8. 단일 코드 기반
   • 코드의 흐름은 오직 하나뿐이어야 한다.
9. Daily deployment
   • 매일 밤 새로운 버전을 배포한다.
   • 우선 조치되어야 하는 것은 다음과 같다.
     • 결함을 줄이고, 테스트를 자동화한다.
     • 빌드 자동화
     • 배포 자동화
     • 롤백 가능한 환경 구성
     • 팀 내부, 그리고 고객과의 신뢰 구축
10. 범위 협상 계약
    • 시스템의 정확한 범위를 계속해서 협상한다.
    • 긴 계약 하나가 아니라, 짧은 계약에 여러 번 서명한다.
11. Pay per use (사용 별 지급)
    • 시스템이 사용될 때마다 돈을 청구한다.
    • 돈은 명확한 피드백 정보가 되기 때문에 제품을 개선하는 데 큰 도움을 준다.
    • 이 방식이 어렵다면, 구독 모델을 고려해본다.