eXtreme Programming - 3

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

10. 전체 XP팀

• 효율적으로 일하기 위해서는 많은 사람의 시각을 반영해야 한다.
• 대규모 배포를 드문드문할 때보다, 꾸준하고 부드럽게 할 때 가치가 창출된다.

• 스스로를 ‘팀’이라는 전체 중 일부로 보아야 한다.

  1. 테스터
  2. 테스터는 구현에 앞서 고객이 system level의 테스트를 작성하는 것을 돕는다.
  3. 개발자에게는 테스트 관련 기법을 지도한다.
  4. Test suite가 있다면, XP팀에서 사소한 실수를 잡아낼 책임은 개발자에게 있다.
  5. 시스템 구현에 앞서 기능을 정의하고 명시하는 일을 돕고, 스토리를 선택해 그것을 테스트로 전환한다.
  6. 명세가 업데이트되거나 추가되면 계속 테스트를 추가하고, 필요한 경우 개발자와 pair programming 한다.
  7. 상호작용 설계자
  8. 시스템의 전반적인 메타포를 선택하고, 스토리를 작성하고, 새로운 스토리를 위해 이미 배포된 시스템의 사용 양상을 조사한다.
  9. 최종 사용자의 문제를 해결하는 것이 중요한 목표다.
  10. 고객이 스토리를 작성하고 명료하게 만드는 일을 돕는다.
  11. 아키텍트
  12. 대규모 refactoring 과제를 찾아내고 실행한다.
  13. 시스템 차원의 테스트를 작성한다.
  14. 스토리를 구현한다.
  15. 프로젝트가 발전하는 동안 아키텍처의 방향을 잡아준다.
  16. 아키텍처의 변화를 작고 안전한 단계로 나누어 실현한다. 큰 그림을 유지하며 시스템 전체를 따라간다.
  17. 현재의 아키텍처를 스트레스 테스트로 무너뜨리고, 이것을 간신히 넘어설 만큼만 개선하는 식으로 분할 정복하는 것도 의미 있다.
  18. Project manager
  19. 팀 내외간의 원활한 의사소통을 책임진다.
  20. 팀에게 프로젝트 진전 정도를 상기시킨다.
  21. 계획과 현실이 일치하도록 유지할 책임이 있다.
  22. Product manager
  23. 스토리를 작성하고, 주기별로 스토리를 골라내며, 명확하지 않은 명세에 답변한다.
  24. 일이 많은 경우 요구사항의 우선순위를 정한다.
  25. 스토리의 구현 순서는 사업적인 이유에 따라 결정해야 한다.
  26. 고객의 요청사항을 개발자에게 전달하여 개발자가 대응할 수 있도록 의사소통을 장려한다.
  27. 임원
  28. XP팀에게 자신감, 책임감을 주입한다.
  29. 개선을 감시하고 권장하고 조정한다.
  30. 여러 문제에 직면하더라도 장기적인 시야를 유지한다.

  31. XP팀의 건강도를 측정한다.

      1. 첫 배포부터 결함을 극적으로 줄인다.
      2. 투자를 시작하는 시점과 수익이 발생하는 시점의 시차를 줄인다.
      3. 위의 수치를 가지고 목표를 정할 때, 근본적인 문제를 해결해야 한다.
  32. XP팀을 다른 팀에게도 긍정적으로 보이게 만든다. 타부서의 압박에 버틸 수 있어야 한다.
  33. 테크니컬 라이터
  34. 시스템을 글과 그림으로 표현해 팀에 필요한 피드백 사슬을 생성한다.

  35. 고객과 더 긴밀한 관계를 맺는다.

      • 제품을 배우는 일을 돕고, 다른 팀의 구성원들이 헷갈려 하면 다른 출판물이나 스토리로 해결한다.
  36. 사용자
  37. 스토리를 작성하고 고르는 일을 돕고, domain 영역에 관련한 결정을 내린다.
  38. 전체 공동체를 대표한다는 사실을 잊지 않는다.
  39. 공동체의 다른 사람들과 이야기를 나누기 전에 큰 결정을 내리지 않는다.
  40. 개발자
  41. 스토리와 태스크를 추정한다.
  42. 스토리를 태스크로 나눈다.
  43. 테스트와 코드를 작성하고 시스템 설계의 점진적 개선을 실행한다.
  44. 개발 프로세스를 자동화한다.
  45. 사회적 기술과 인간관계 기술을 잘 습득한다.
  46. 처음에는 역할이 고정되어있더라도, 신뢰가 확립되면 역할에 상관없이 본인의 최선을 다한다.
  47. 권위와 책임의 연결을 늘 염두에 둔다.

11. 제약이론

• 전체의 시스템 처리능력을 살펴보는 접근 방법.

  • 시스템에서는 한 시점에 제약지점이 하나 존재한다.
  • 전체 시스템의 처리능력을 키우려면,
  • 제약 지점을 찾고
  • 100% 가동하도록 한 다음
  • 제약 지점의 성능 향상, 다른 곳으로 작업량 분산 혹은 제약 지점을 제거한다.
  • 보통의 경우 제약 지점 앞에 작업이 누적된다. 이는 곳 병목을 의미한다.

• Software 개발에는 push 모델과 pull 모델이 있다.

  • Push 모델은 태스크를 쌓아놓고, 설계를 쌓은 다음 통합하여 테스트할 코드를 쌓는 방법이다.
  • Pull 모델은 구현 직전에 스토리가 명시되고, 명세에서 테스트가 나오고, 인터페이스는 테스트 작업의 필요에 맞게 설계되고 코드는 인터페이스와 테스트에 맞게 작성된다.
  • 설계는 코드를 작성하는 동안 필요에 맞게 다듬어진다.
  • 남은 스토리는 선택을 기다리며 남아있다.
  • XP는 pull 모델을 지향한다.

• 미시적 최적화가 아닌 전반적인 처리능력 개선에 초점을 맞춘다.

  • 보상 체계를 개인의 생산성 대신 전체적인 처리량을 기준으로 한다.
• XP가 좁고 명료할 때 XP의 가치가 비즈니스에 드러난다.

• XP를 적용할 때는 임원의 후원을 받고, 바깥사람들과 튼튼한 관계를 맺는다.

  • 개발조직이 바뀌는 순간 다른 부분의 업무 구조에도 영향을 준다.

12. 계획 짜기: 범위 관리

• XP의 계획 짜기는 현재 있는 목표, 가정, 사실을 분명히 드러내는 것부터 시작한다.
• 명시적인 현재 정보가 있다면 무엇을 범위에 넣고 뺄지, 다음에 무엇을 할 것인지 서로 동의를 끌어낼 수 있다.

• XP의 계획 짜기는 ‘장보기’와 비슷하다. |XP|장보기| |-|-| |추정치|가격| |시간|예산| |스토리|상품|

  • 정해진 예산으로 가격에 맞는 최적(사고 싶은 것을 최대한 많이 사도록)의 장보기를 해야 한다.

• 다음 할 일을 정하는 것 역시 계획 짜기의 일부이다.

  • 계획 짜기가 복잡한 이유는 스토리의 비용과 가치가 불확실한 탓이다.
  • 추정치 계산을 위해 피드백을 이용하고 가장 좋은 정보를 얻기 위해 결정 시기를 늦춘다.
  • 그렇기 때문에 매일, 매주, 매 분기 계획 짜기가 필요하다.

• 계획은 미래 예측이 아니다.

  • 불확실성으로 가치가 깎이지 않는다.
  • 계획은 다른 팀과 보조를 맞추고, 일의 시작지점을 알려주며, 팀의 목표를 알려준다.
• 제품의 품질을 낮춘다고 일이 줄어들지는 않는다.

• 계획은 다음의 스텝으로 세운다.

  1. 해야 할 일을 목록으로 작성한다.
  2. 각 항목의 작업 시간을 추정한다.
  3. 지금 계획 중인 주기를 위한 예산을 세운다.
  4. 해야 할 일들을 예산 내 범위에서 합의한다. 협상할 때, 추정치나 예산을 변경하면 안 된다.
  5. 계획을 세울 때 모든 팀 구성원의 목소리를 들어본다.

• 계획 짜기는 모두가 함께해야 한다.

  • 계획에는 협동이 필요하다.
  • 계획 짜기는 듣기, 말하기, 지정된 기간 안에 목표를 정렬하기 등을 단련할 기회다.
  • 계획을 통해 조화롭게 일할 때, 우리는 팀이 된다.

• 어떤 스토리를 구현할지 선택할 때는 스토리를 여러 가지 방식으로 정렬한다.

  • 스토리를 공간적으로 배열해보고, 관계를 파악한다.
• “완료 시간” 추정은 테스트, 구현, refactoring 등을 모두 끝내고 배포할 준비가 완료됨을 의미한다.

• 추정을 개선하려면 최대한 빨리 피드백을 받는다.

  • 1달이면 1주일 간격으로 4~5번 반복을, 1주일이면 하루에 4~5번 반복해서 피드백을 진행한다.
• 하루에 할 수 있는 일의 양은 정해져 있음을 명심한다.

• 작업 주기 중간에 계획과 달라진다면 반드시 계획을 조정해야 한다.

  • 일이 잘 풀리지 않으면, 우리의 가치와 원칙을 고수하고 실천 방법들을 효율적으로 수정한다.
  • 수치가 잘못되었다면 수치를 고치고 결과에 대해 의사소통한다.
• 계획에 대해서 아무것도 숨기지 않는다. 누구에게나 공개되어있고, 접근할 수 있게 한다. 우리의 좋은 계획이란 인간관계를 반영한 계획이다.

13. 테스트: 일찍, 자주, 자동화

테스팅은 버그의 존재만 보여 줄 수 있지 버그의 부재까지는 보여 줄 수 없다.

Program testing can be used to show the presence of bugs, but never to show their absence.

- Edsger W. Dijkstra

• 모든 결함을 제거하는 것은 불가능하다.

  • 결함은 비용이 많이 들지만, 그것을 고치는데에도 비용이 많이 든다. 대부분의 결함은 막기 위하여 드는 비용보다 결함 때문에 발생하는 비용이 더 크다.

• XP의 실천 방법들은 명료한 의사소통을 통해 결함을 줄인다.

  • 애초에 결함이 발생할 일을 만들지 않거나, 결함을 통해 미래의 실수를 피하는 법을 배운다.

• 결함은 언제나 존재한다.

  • 개발의 목표는 결함의 발생을 경제적으로 감내 가능한 수준까지 낮추는 것이다.
  • 또 하나의 목표는, 팀에 대한 신뢰가 합리적으로 자랄 수 있는 수준까지 결함을 줄이는 것이다.
  • 자신을 보호하려고 에러를 숨기는 것은, 시간과 에너지를 낭비하는 일이다.

• XP에서 테스팅은 결함 문제에 대응하는 기술적 활동이다.

  • 테스트 비용 효율을 높이기 위해 재확인(double check)과 결함 비용 증가 원칙(Defect cost increase)을 적용한다.
  • 테스트 재확인: 테스트를 작성하면서, 어떤 계산을 하고 싶은지 표현한다. 그리고 구현하면서 상당히 다른 방식으로 다시 표현한다. 두 표현이 맞다면, 구현과 테스트는 일치한다.
  • 결함 비용 증가 원칙: 결함은 일찍 발견할수록 수정 비용이 적게 든다.
• 자동화된 테스트를 프로그래밍의 내부 순환에 넣음으로, 결함을 더 일찍 적은 비용으로 고칠 수 있게 해준다.
• 잘못을 저지르는 그 사람이 테스트를 작성해야 한다.

• 개발자는 자신의 관점으로만 코드와 테스트를 만들기 때문에, 재확인의 가치를 잃게 된다.

  • 어떤 계산 결과를 복사하여 추정치로 삼는 것은 위험하다. 때로는 손으로 계산한 추정치가 도움을 준다.
  • 개발자의 시선으로 만들어진 TC(Unit test)와 고객, 사용자의 시선으로 만들어진 TC(e2e test) 두 벌을 준비하면 좋다.

• 테스트의 즉각성이란 테스트는 반드시 자동화되어야 함을 의미한다.

  • 자동화된 테스트는 스트레스를 줄여준다.
• 개발 후 테스트를 모두 없애고, 테스트의 자원을 개발 프로세스 내부의 효율적인 곳으로 옮겨온다.

• 테스트를 먼저 하든 나중에 하든 상관없다. 어떤 틀에 맞는 코드를 짜거나 어떤 코드에 맞는 틀을 짜도 좋다. 가장 이익이 많이 남는 쪽으로 하면 된다.

  • XP에서는 가능하면 TDD를 지향한다. 인터페이스가 구현에 과도한 영향을 받지 않게 도와준다.
  • 테스트는 프로젝트 진전의 척도를 제공한다.
• 테스트는 팀의 자신감에 타당한 기반이 되며, 상호 간의 신뢰를 제공한다.