eXtreme Programming - 3
앞의 글에서 이어지는, eXtreme Programming의 1부를 요약, 정리한 글.
10. 전체 XP팀
- 효율적으로 일하기 위해서는 많은 사람의 시각을 반영해야 한다.
- 대규모 배포를 드문드문할 때보다, 꾸준하고 부드럽게 할 때 가치가 창출된다.
- 스스로를 ‘팀’이라는 전체 중 일부로 보아야 한다.
- 테스터
- 테스터는 구현에 앞서 고객이 system level의 테스트를 작성하는 것을 돕는다.
- 개발자에게는 테스트 관련 기법을 지도한다.
- Test suite가 있다면, XP팀에서 사소한 실수를 잡아낼 책임은 개발자에게 있다.
- 시스템 구현에 앞서 기능을 정의하고 명시하는 일을 돕고, 스토리를 선택해 그것을 테스트로 전환한다.
- 명세가 업데이트되거나 추가되면 계속 테스트를 추가하고, 필요한 경우 개발자와 pair programming 한다.
- 상호작용 설계자
- 시스템의 전반적인 메타포를 선택하고, 스토리를 작성하고, 새로운 스토리를 위해 이미 배포된 시스템의 사용 양상을 조사한다.
- 최종 사용자의 문제를 해결하는 것이 중요한 목표다.
- 고객이 스토리를 작성하고 명료하게 만드는 일을 돕는다.
- 아키텍트
- 대규모 refactoring 과제를 찾아내고 실행한다.
- 시스템 차원의 테스트를 작성한다.
- 스토리를 구현한다.
- 프로젝트가 발전하는 동안 아키텍처의 방향을 잡아준다.
- 아키텍처의 변화를 작고 안전한 단계로 나누어 실현한다. 큰 그림을 유지하며 시스템 전체를 따라간다.
- 현재의 아키텍처를 스트레스 테스트로 무너뜨리고, 이것을 간신히 넘어설 만큼만 개선하는 식으로 분할 정복하는 것도 의미 있다.
- Project manager
- 팀 내외간의 원활한 의사소통을 책임진다.
- 팀에게 프로젝트 진전 정도를 상기시킨다.
- 계획과 현실이 일치하도록 유지할 책임이 있다.
- Product manager
- 스토리를 작성하고, 주기별로 스토리를 골라내며, 명확하지 않은 명세에 답변한다.
- 일이 많은 경우 요구사항의 우선순위를 정한다.
- 스토리의 구현 순서는 사업적인 이유에 따라 결정해야 한다.
- 고객의 요청사항을 개발자에게 전달하여 개발자가 대응할 수 있도록 의사소통을 장려한다.
- 임원
- XP팀에게 자신감, 책임감을 주입한다.
- 개선을 감시하고 권장하고 조정한다.
- 여러 문제에 직면하더라도 장기적인 시야를 유지한다.
- XP팀의 건강도를 측정한다.
- 첫 배포부터 결함을 극적으로 줄인다.
- 투자를 시작하는 시점과 수익이 발생하는 시점의 시차를 줄인다.
- 위의 수치를 가지고 목표를 정할 때, 근본적인 문제를 해결해야 한다.
- XP팀을 다른 팀에게도 긍정적으로 보이게 만든다. 타부서의 압박에 버틸 수 있어야 한다.
- 테크니컬 라이터
- 시스템을 글과 그림으로 표현해 팀에 필요한 피드백 사슬을 생성한다.
- 고객과 더 긴밀한 관계를 맺는다.
- 제품을 배우는 일을 돕고, 다른 팀의 구성원들이 헷갈려 하면 다른 출판물이나 스토리로 해결한다.
- 사용자
- 스토리를 작성하고 고르는 일을 돕고, domain 영역에 관련한 결정을 내린다.
- 전체 공동체를 대표한다는 사실을 잊지 않는다.
- 공동체의 다른 사람들과 이야기를 나누기 전에 큰 결정을 내리지 않는다.
- 개발자
- 스토리와 태스크를 추정한다.
- 스토리를 태스크로 나눈다.
- 테스트와 코드를 작성하고 시스템 설계의 점진적 개선을 실행한다.
- 개발 프로세스를 자동화한다.
- 사회적 기술과 인간관계 기술을 잘 습득한다.
- 처음에는 역할이 고정되어있더라도, 신뢰가 확립되면 역할에 상관없이 본인의 최선을 다한다.
- 권위와 책임의 연결을 늘 염두에 둔다.
- 테스터
11. 제약이론
- 전체의 시스템 처리능력을 살펴보는 접근 방법.
- 시스템에서는 한 시점에 제약지점이 하나 존재한다.
- 전체 시스템의 처리능력을 키우려면,
- 제약 지점을 찾고
- 100% 가동하도록 한 다음
- 제약 지점의 성능 향상, 다른 곳으로 작업량 분산 혹은 제약 지점을 제거한다.
- 보통의 경우 제약 지점 앞에 작업이 누적된다. 이는 곳 병목을 의미한다.
- Software 개발에는 push 모델과 pull 모델이 있다.
- Push 모델은 태스크를 쌓아놓고, 설계를 쌓은 다음 통합하여 테스트할 코드를 쌓는 방법이다.
- Pull 모델은 구현 직전에 스토리가 명시되고, 명세에서 테스트가 나오고, 인터페이스는 테스트 작업의 필요에 맞게 설계되고 코드는 인터페이스와 테스트에 맞게 작성된다.
- 설계는 코드를 작성하는 동안 필요에 맞게 다듬어진다.
- 남은 스토리는 선택을 기다리며 남아있다.
- XP는 pull 모델을 지향한다.
- 미시적 최적화가 아닌 전반적인 처리능력 개선에 초점을 맞춘다.
- 보상 체계를 개인의 생산성 대신 전체적인 처리량을 기준으로 한다.
- XP가 좁고 명료할 때 XP의 가치가 비즈니스에 드러난다.
- XP를 적용할 때는 임원의 후원을 받고, 바깥사람들과 튼튼한 관계를 맺는다.
- 개발조직이 바뀌는 순간 다른 부분의 업무 구조에도 영향을 준다.
12. 계획 짜기: 범위 관리
- XP의 계획 짜기는 현재 있는 목표, 가정, 사실을 분명히 드러내는 것부터 시작한다.
- 명시적인 현재 정보가 있다면 무엇을 범위에 넣고 뺄지, 다음에 무엇을 할 것인지 서로 동의를 끌어낼 수 있다.
- XP의 계획 짜기는 ‘장보기’와 비슷하다.
XP 장보기 추정치 가격 시간 예산 스토리 상품 - 정해진 예산으로 가격에 맞는 최적(사고 싶은 것을 최대한 많이 사도록)의 장보기를 해야 한다.
- 다음 할 일을 정하는 것 역시 계획 짜기의 일부이다.
- 계획 짜기가 복잡한 이유는 스토리의 비용과 가치가 불확실한 탓이다.
- 추정치 계산을 위해 피드백을 이용하고 가장 좋은 정보를 얻기 위해 결정 시기를 늦춘다.
- 그렇기 때문에 매일, 매주, 매 분기 계획 짜기가 필요하다.
- 계획은 미래 예측이 아니다.
- 불확실성으로 가치가 깎이지 않는다.
- 계획은 다른 팀과 보조를 맞추고, 일의 시작지점을 알려주며, 팀의 목표를 알려준다.
- 제품의 품질을 낮춘다고 일이 줄어들지는 않는다.
- 계획은 다음의 스텝으로 세운다.
- 해야 할 일을 목록으로 작성한다.
- 각 항목의 작업 시간을 추정한다.
- 지금 계획 중인 주기를 위한 예산을 세운다.
- 해야 할 일들을 예산 내 범위에서 합의한다. 협상할 때, 추정치나 예산을 변경하면 안 된다.
- 계획을 세울 때 모든 팀 구성원의 목소리를 들어본다.
- 계획 짜기는 모두가 함께해야 한다.
- 계획에는 협동이 필요하다.
- 계획 짜기는 듣기, 말하기, 지정된 기간 안에 목표를 정렬하기 등을 단련할 기회다.
- 계획을 통해 조화롭게 일할 때, 우리는 팀이 된다.
- 어떤 스토리를 구현할지 선택할 때는 스토리를 여러 가지 방식으로 정렬한다.
- 스토리를 공간적으로 배열해보고, 관계를 파악한다.
- “완료 시간” 추정은 테스트, 구현, refactoring 등을 모두 끝내고 배포할 준비가 완료됨을 의미한다.
- 추정을 개선하려면 최대한 빨리 피드백을 받는다.
- 1달이면 1주일 간격으로 4
5번 반복을, 1주일이면 하루에 45번 반복해서 피드백을 진행한다.
- 1달이면 1주일 간격으로 4
- 하루에 할 수 있는 일의 양은 정해져 있음을 명심한다.
- 작업 주기 중간에 계획과 달라진다면 반드시 계획을 조정해야 한다.
- 일이 잘 풀리지 않으면, 우리의 가치와 원칙을 고수하고 실천 방법들을 효율적으로 수정한다.
- 수치가 잘못되었다면 수치를 고치고 결과에 대해 의사소통한다.
- 계획에 대해서 아무것도 숨기지 않는다. 누구에게나 공개되어있고, 접근할 수 있게 한다. 우리의 좋은 계획이란 인간관계를 반영한 계획이다.
13. 테스트: 일찍, 자주, 자동화
테스팅은 버그의 존재만 보여 줄 수 있지 버그의 부재까지는 보여 줄 수 없다.
Program testing can be used to show the presence of bugs, but never to show their absence.
- 모든 결함을 제거하는 것은 불가능하다.
- 결함은 비용이 많이 들지만, 그것을 고치는데에도 비용이 많이 든다. 대부분의 결함은 막기 위하여 드는 비용보다 결함 때문에 발생하는 비용이 더 크다.
- XP의 실천 방법들은 명료한 의사소통을 통해 결함을 줄인다.
- 애초에 결함이 발생할 일을 만들지 않거나, 결함을 통해 미래의 실수를 피하는 법을 배운다.
- 결함은 언제나 존재한다.
- 개발의 목표는 결함의 발생을 경제적으로 감내 가능한 수준까지 낮추는 것이다.
- 또 하나의 목표는, 팀에 대한 신뢰가 합리적으로 자랄 수 있는 수준까지 결함을 줄이는 것이다.
- 자신을 보호하려고 에러를 숨기는 것은, 시간과 에너지를 낭비하는 일이다.
- XP에서 테스팅은 결함 문제에 대응하는 기술적 활동이다.
- 테스트 비용 효율을 높이기 위해 재확인(double check)과 결함 비용 증가 원칙(Defect cost increase)을 적용한다.
- 테스트 재확인: 테스트를 작성하면서, 어떤 계산을 하고 싶은지 표현한다. 그리고 구현하면서 상당히 다른 방식으로 다시 표현한다. 두 표현이 맞다면, 구현과 테스트는 일치한다.
- 결함 비용 증가 원칙: 결함은 일찍 발견할수록 수정 비용이 적게 든다.
- 자동화된 테스트를 프로그래밍의 내부 순환에 넣음으로, 결함을 더 일찍 적은 비용으로 고칠 수 있게 해준다.
- 잘못을 저지르는 그 사람이 테스트를 작성해야 한다.
- 개발자는 자신의 관점으로만 코드와 테스트를 만들기 때문에, 재확인의 가치를 잃게 된다.
- 어떤 계산 결과를 복사하여 추정치로 삼는 것은 위험하다. 때로는 손으로 계산한 추정치가 도움을 준다.
- 개발자의 시선으로 만들어진 TC(Unit test)와 고객, 사용자의 시선으로 만들어진 TC(e2e test) 두 벌을 준비하면 좋다.
- 테스트의 즉각성이란 테스트는 반드시 자동화되어야 함을 의미한다.
- 자동화된 테스트는 스트레스를 줄여준다.
- 개발 후 테스트를 모두 없애고, 테스트의 자원을 개발 프로세스 내부의 효율적인 곳으로 옮겨온다.
- 테스트를 먼저 하든 나중에 하든 상관없다. 어떤 틀에 맞는 코드를 짜거나 어떤 코드에 맞는 틀을 짜도 좋다. 가장 이익이 많이 남는 쪽으로 하면 된다.
- XP에서는 가능하면 TDD를 지향한다. 인터페이스가 구현에 과도한 영향을 받지 않게 도와준다.
- 테스트는 프로젝트 진전의 척도를 제공한다.
- 테스트는 팀의 자신감에 타당한 기반이 되며, 상호 간의 신뢰를 제공한다.