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. 일주일별 주기

   • 한 번에 일주일 분량의 일을 계획한다.
   • 지금까지 진행된 상황을 검토하는데, 지난주의 실제 진행 정도가 예상 진행 정도를 달성했는지 포함해 검토한다.
   • 이번 주에 구현할 일주일 분의 스토리를 고객이 고르도록 한다.
   • 스토리를 여러 태스크로 나눈다. 팀 구성원들은 자기가 할 과업을 가져가고, 얼마나 걸릴지 추정한다.
   • 스토리에 대한 자동화 테스트를 완성하고, 스토리가 테스트를 통과할 수 있게 한다.
   • 만약 일주일 안에 모든 테스트를 통과시키지 못할 것 같다면, 가장 가치 있는 스토리를 선택해 그것만을 완성할 시간적 여유를 갖는다.
   • 계획짜기는 일종의 필요한 낭비다. 이것에 드는 시간을 줄이기 위해 노력한다.
   • Task stack을 만드는 것도 방법이 될 수 있다.

8. 분기별 주기

   • 한 번에 한 분기 분량의 일을 계획한다. 팀, 프로젝트, 진행 정도, 더 높은 목표, 프로젝트 방향의 일치 여부 등을 논의한다.
   • 병목, 특히 외부의 병목을 찾아본다.
   • Repair 작업을 시작한다.
   • 이번 분기의 theme들을 계획한다.
   • 그 theme에 대한 한 분기 분량의 스토리들을 고른다.
   • 프로젝트가 조직에서 차지하는 위치라는 큰 그림에 초점을 맞춘다.
   • ‘주제(theme)‘와 스토리를 구분하는 이유는, 스토리가 큰 그림에서 차지하는 위치를 고려하지 않고 자기 일에만 초점을 맞추는 것을 경계하기 위해서다.
   • 팀 차원의 반성을 한다. 병목을 찾고, 장기 실험을 제안할 수도 있다.

9. 여유

   • 계획을 세울 때, 일정에 뒤처질 경우 포기 가능한 ‘덜 중요한’ 태스크를 포함한다. 이는 신뢰 관계 구축을 위해 필요하다.
   • 습관적인 과잉약속을 피하고, 분명하고 솔직하게 의사소통한다.

10. 10분 빌드

    • 10분 안에 모든 테스트를 자동으로 실행하고 전체 시스템을 빌드한다.

      • 빌드를 자동화하고, 일부분이라도 테스트를 자동화시킨다.

11. 지속적 통합

    • 변경에 대해서는 2, 3시간 안에 통합하고 테스트한다.
    • 빌드와 테스트를 기다리는 시간은 작업에 대해 복기할 좋은 기회다.
    • 지속적 통합은 언제나 완제품을 내놓는 것을 목표로 한다.

12. TDD

    • 실패하는 자동화된 테스트를 작성한다.
    • 테스트가 실행되는 시간은 최대한 짧아야 한다.

13. 점진적 설계

    • 시스템의 설계에 매일 투자한다.
    • 현재의 설계가 최선의 설계에 근접(일치)하도록 점진적이고 지속적해서 작업한다.

    • 마지막 책임 지점(last responsible moment)까지 설계 투자를 미룬다.

      설계에 대한 투자를 최소화하라는 것이 절대 아니다. 설계만을 위한 과도한 투자를 경계하라는 뜻이다. 필요한 만큼만 설계에 투자한다.

    • 중복을 제거하는 것은 휴리스틱 하게 설계를 개선하는 방법이다.
    • 설계를 사용하는 시점과 최대한 가까워졌을 때 설계한다.

8. 시작하기

• 모든 사람에게 적합한 시작 지점은 없다.
• 한 번에 하나씩 바꾸는 방법은 매우 쉽고 효과적이다.

• 새로운 습관을 들이기는 쉽지 않다.

  • 빠르게 도입해도 괜찮지만, 예전으로 돌아가지 않게 추스를 시간을 확보한다.

• 무엇을 바꿀지 어떻게 결정할까?

  1. 어떤 일을 하고 있는지, 무엇을 이루고 싶은지 고민한다.
  2. 그 후, 실천 방법을 선택한다.
  3. 개발 프로세스를 개선하기 위한 스토리를 계획한다.
  4. 각 스토리에 대해 시간을 추정한다.
  5. 쉬운 것부터 순차적으로 진행해 본다.

• 변화를 위해서는 깨달음이 필요하다.

  • 각 실천 방법들을 보고, 현재의 위치를 찾은 다음 우선순위가 높고 목적과 일치하는 것을 고른다.
• 실천 방법을 강요하면 팀의 신뢰를 파괴하고 원망을 낳게 된다.

9. 보조 실천 방법

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

• 진짜 고객 참여

  • 구축하게 될 시스템에 따라 인생과 사업이 달라질 수 있는 고객을 팀에 포함한다.
  • 고객 “대행”이 아니기 때문에, 빠른 속도로 방향성과 예산에 대해 결정을 할 수 있다.

• 점진적 배포

  • 레거시 시스템을 교체하는 등의 작업을 할 때는 점진적으로 교체한다.
  • 당장 다룰 수 있는 작은 기능이나 제한된 데이터 셋을 찾아 우선 작업한다.

• 팀 지속성

  • 효율적인 팀은 계속해서 팀으로 놔둔다. 신뢰하는 인원끼리의 co-work를 깨지 않는다.
  • 전혀 변화를 주지 말라는 뜻은 아니며, 대체로 팀을 유지하되 구성원들을 적당히 회전시킨다.

• 팀 크기 줄이기

  • 팀의 능력이 신장하면, 일은 유지하면서 팀은 줄이고 남은 팀원으로 새 팀을 만든다.

• 근본 원인 분석

  • 결함이 발견될 때마다 결함과 원인을 모두 제거한다.
  • 결함이 다시 나타나는 것을 막는 것이 아니라, 팀의 반복적인 실수를 방지한다.
  • 결함을 드러내는 시스템 차원의 자동화된 테스트를 작성한다.
  • 결함을 재생산하는, 가능한 한 범위가 가장 좁은 unit test를 작성한다.
  • 이 unit test가 통과하도록 코드를 고친다. 그와 동시에 시스템 차원의 테스트 역시 통과해야 한다. 그렇지 않다면 2번으로 돌아간다.
  • 결함을 해결한 후에는, 왜 이 결함이 생겼는지, 이전에는 잡히지 않았는지 알아낸다. 원인을 찾았다면, 그 원인을 해결한다.

• 코드 공유

  • 팀의 ‘집단 책임감’이 자리 잡은 후에 시도한다.
  • Pair programming이 도움이 된다.

• 코드와 테스트

  • 오직 코드와 테스트만 영구 산출물로 유지한다. 다른 문서들은 코드와 테스트에서 생성되게끔 한다.
  • 지금은 쓸모없어진 산출물을 제거한다.

• 단일 코드 기반

  • 코드의 흐름은 오직 하나뿐이어야 한다.

• Daily deployment

  • 매일 밤 새로운 버전을 배포한다.
  • 우선 조치되어야 하는 것은 다음과 같다.
  • 결함을 줄이고, 테스트를 자동화한다.
  • 빌드 자동화
  • 배포 자동화
  • 롤백 가능한 환경 구성
  • 팀 내부, 그리고 고객과의 신뢰 구축

• 범위 협상 계약

  • 시스템의 정확한 범위를 계속해서 협상한다.
  • 긴 계약 하나가 아니라, 짧은 계약에 여러 번 서명한다.

• Pay per use (사용 별 지급)

  • 시스템이 사용될 때마다 돈을 청구한다.
  • 돈은 명확한 피드백 정보가 되기 때문에 제품을 개선하는 데 큰 도움을 준다.
  • 이 방식이 어렵다면, 구독 모델을 고려해본다.