유저 스토리를 작성할 때 인터페이스는 생각하지 마세요
사용자 스토리에서 뽑은 226개의 핵심 파트 (1)
프로덕트 매니저, 프로덕트 오너, 개발자 등 애자일 방식으로 일을 하는 구성원이라면 '유저 스토리' 혹은 '사용자 스토리'라는 말을 많이 들어봤을 것이다. 간단하게 말하면 '유저는 OO를 위해 OO를 할 수 있다' 형식으로 표현되는, 기능에 대한 서술이다. 보통 프로덕트 매니저는 이 기능을 서술하고, 디자이너는 이 기능을 화면으로 그리고, 개발자는 이 기능을 실제로 구현한다.
결국 이 유저 스토리 (혹은 사용자 스토리)는 무엇을 왜 만들 것인지를 한 문장으로 서술한 것이다. 이 유저 스토리에 따라 팀이 꼭 필요한 것만 빠르게 만들지 혹은 쓸데없는 것들까지도 만들지가 결정되기 때문에, 정말 중요한 문장이다.
이렇게 팀이 무엇을 할지 결정하는 유저 스토리를 잘 쓰기 위해서는 역시 공부가 필요하다. 그리고 이 책은 유저 스토리를 어떻게 잘 쓸 수 있을지 알려주는 책이다. 2006년에 나와서 거의 15년이 넘은 책인데도, 2022년의 애자일 프로세스에서도 적용할 내용이 엄청 많다. 그만큼 변하지 않을 유저 스토리의 본질에 대해서 잘 설명한 책이다.
유저 스토리를 써야 하는 프로덕트 매니저, 프로덕트 오너, 유저 스토리를 화면으로 구현해야 하는 디자이너, 실제 기능으로 구현해야 하는 개발자 모두 이 책을 한 번씩 읽어봤으면 한다. 유저 스토리를 중심으로 각자가 어떻게 한 팀으로 어떻게 일하는지에 대한 힌트를 얻을 수 있다.
* 이 책에서 유저 스토리를 '고객'이 직접 작성해야 한다고 말한다. 여기서 말하는 고객은 진짜 Customer가 아니라, 고객의 입장을 가장 가까이서 대변할 수 있는 고객 팀을 의미한다. 보통 국내 스타트업에서는 이 고객 팀으로서 유저 스토리를 작성하는 역할을 보통 프로덕트 매니저 혹은 프로덕트 오너가 맡는 경우가 많다. 따라서 '고객'을 프로덕트 매니저 혹은 프로덕트 오너로 치환해서 읽으면 좀 더 명확하게 내용을 이해할 수 있다.
시작하기
개요
1. 소프트웨어 요구사항은 의사소통의 문제다. 소프트웨어를 사용하거나 팔기를 원하는 사람은 그것을 만드는 사람들과 의사소통을 해야 한다. 프로젝트가 성공하기 위해서는 다양한 사람들의 머리에서 나오는 정보가 필요하다.
2. 우리에게 필요한 것은 함께 일하는 방법이다. 그리하여 어느 한쪽이 우위를 점하지 않으며, 감정적으로 흐르거나 혹은 정치적일 수 있는 자원 할당 문제를 공동의 문제로 공유하는 것이다. 자원 할당 문제를 어느 한쪽에만 떠맡기는 프로젝트는 실패한다.
3. 우리는 당장 손에 잡히는 정보를 가지고 결정을 내려야 한다. 그리고 자주 그렇게 해야 한다. 프로젝트를 착수하는 시점에 모든 것을 포괄하는 결정을 하기보다, 프로젝트 전 기간에 걸쳐 의사를 결정해야 한다. 이렇게 하기 위해서는 가능한 자주, 신속하게 필요한 정보를 가져다주는 프로세스가 있어야 한다. 사용자 스토리는 이를 위한 것이다.
사용자 스토리란 무엇인가?
4. 사용자 스토리는 소프트웨어의 사용자나 구매자에게 가치를 줄 수 있는 기능을 서술한 것이다. 사용자 스토리는 다음 세 측면으로 구성된다.
• 서술(Written Description): 스토리는 서술 형태로 기록되며, 계획하거나 기억하기 위한 단서로 사용된다.
• 대화(Conversation): 스토리는 대화를 통해 세부사항을 구체화한다.
• 테스트(Test): 스토리는 테스트를 통해 세부사항을 문서화하고 전달하며, 스토리의 완료 여부를 판단한다.
◦ ex) 사용자는 자신의 이력서를 웹사이트에 게시할 수 있다.
5. 사용자 스토리는 사용자에게 가치를 평가받을 수 있도록 기능을 표현해야 한다. 따라서 다음과 같은 항목은 사용자 스토리로 적절하지 않다.
• 소프트웨어는 C++로 작성한다.
• 프로그램은 커넥션풀을 통해 데이터베이스에 연결한다.
세부사항은 어디에 있는가?
6. “사용자는 채용 정보"를 검색할 수 있다고 말하는 것과, 그것만을 참고로 코딩과 테스트를 시작할 수 있느냐는 것은 별개다.
7. 사실 스토리가 너무 큰 것보다는 스토리가 많은 것이 낫다. 간단히 말하면 스토리는 한두 명의 개발자가 반나절에서 길어야 2주일 안에 구현하고 테스트할 수 있는 정도의 크기가 적당하다.
8. 스토리가 너무 큰 경우에 가끔 ‘에픽(epic)’이라고 말하기도 한다. 에픽은 더 작은 스토리로 나눌 수 있다. 예를 들어 ‘사용자는 채용 정보를 검색할 수 있다'는 에픽은 다음과 같이 3개로 나눌 수 있다.
• 사용자는 위치, 급여 수준, 직업 명, 회사 명, 게시 날짜 등의 속성 값으로 채용 정보를 검색할 수 있다.
• 사용자는 검색 조건과 일치하는 채용 정보를 볼 수 있다.
• 사용자는 채용 정보를 게시한 기업에 대한 세부 정보를 볼 수 있다.
9. 하지만 스토리를 나눌 때 모든 세부사항을 하나하나 스토리로 만들지는 않는다. 모든 세부사항들까지 스토리로 작성하는 것보다, 개발팀과 고객이 이런 세부사항에 대해 논의하는 것이 더 낫다. 즉 세부사항이 정말 중요한 시점이 되었을 때 그에 관해 대화를 나누는 것이다.
“얼마나 길어야 하나요?”
10. 프로젝트에서도 사용자들이 기대하는 바를 이해하는 것은 중요하다. 그러한 기대는 인수 테스트(acceptance test)의 형태로 표현하는 것이 가장 효과적이다. 기대사항은 스토리를 어떻게 테스트할 것인가를 기억하기 위한 단서로서 작성된다.
• ex) 채용 정보를 입력하지 않고 시도해 본다. / 채용 정보를 아주 길게 넣어 본다. / 급여 정보가 빠진 경우를 확인해 본다. / 여섯 자리 급여로 시도해 본다.
11. 테스트 서술은 간결해야 한다. 테스트는 어느 때라도 추가하거나 제거할 수 있다. 이 과정의 목적은 스토리에 대한 부가 정보를 통해 개발자가 자기 일을 끝냈다는 것을 알 수 있도록 하는 것이다. 개발자들이 고객의 기대를 아는 것은 일의 완료 여부를 아는 데 중요하다.
프로세스는 어떤 모습일까?
12. 스토리 주도(story-driven) 프로젝트를 수행할 때 여러분이 처음으로 주목하게 되는 것은 고객과 사용자의 참여가 프로젝트를 하는 기간 내내 계속된다는 것이다.
13. 왜 고객이 스토리를 작성하는가? 개발자 대신 고객 팀이 사용자 스토리를 작성하는 데는 두 가지 주된 이유가 있다. 첫째, 각 스토리는 기술적 전문 용어가 아닌 비즈니스 언어로 작성해야 한다. 그래야 고객 팀에서 스토리를 어느 이터레이션이나 릴리즈에 포함시킬지 우선순위를 결정할 수 있다. 둘째, 제품의 주된 기획 주체로서 고객팀은 제품의 동작을 가장 잘 설명할 수 있다.
14. 스토리 작성 과정은 대상 시스템을 사용할 사용자의 유형을 고려하는 데서 시작하는 것이 가장 좋다.
15. 스토리는 주로 스토리 작성 워크샵에서 처음 작성하게 되지만, 프로젝트 진행 중에도 아무 때나 추가로 작성할 수 있다. 스토리 작성 워크샵에서는 참여자들이 브레인스토밍을 거쳐 가능한 많은 스토리를 찾아낸다.
16. 고객 팀과 개발자가 협력하여 이터레이션 길이를 1~4주 정도 범위에서 선택한다. 선택한 이터레이션 길이를 프로젝트가 끝날 때까지 변경하지 않고 사용한다. 개발자들은 이터레이션마다 소프트웨어의 일부 기능만이라도 그 자체로 쓸모 있는 코드를 인도해야 하는 책임이 있다. 고객 팀은 이터레이션 동안 긴밀하게 참여하고 개발자와 해당 이터레이션에서 개발하는 스토리에 대해 대화를 나누어야 한다.
17. 이터레이션 길이를 선택했으면, 개발자는 이터레이션마다 얼만큼 일할 수 있을지에 대해 추정해야 한다. 우리는 한 이터레이션 동안의 작업량을 ‘속도(velocity)’라고 부른다. 우리는 초기 추정치를 이용하여 각 이터레이션에서 어떤 작업들을 할지, 몇 번의 이터레이션이 필요할지에 대한 릴리즈 계획을 세울 수 있을 것이다.
18. 릴리즈 계획을 세우기 위해서는 먼저 스토리들을 여러 개의 묶음으로 분류하는데, 각 묶음은 하나의 이터레이션을 나타낸다. 각 묶음에 포함된 스토리들의 추정치를 더하여 속도 추정치를 넘지 않도록 한다.
릴리즈와 이터레이션 계획하기
19. 릴리즈는 하나 이상의 이터레이션으로 이루어진다. 릴리즈 계획은 프로젝트 일정과 구현할 기능 집합의 균형을 결정하는 일이다. 이터레이션 계획은 이번 이터레이션에 포함할 스토리를 선택하는 일을 말한다. 고객 팀과 개발자 모두 릴리즈 계획과 이터레이션 계획에 참여한다.
20. 릴리즈 계획은 고객 팀이 스토리에 우선순위를 매기는 것으로 시작한다. 우선순위를 부여할 때 다음 사항들을 고려해야 할 것이다.
• 사용자나 고객 다수가 원하는 기능인가?
• 다수는 아니지만 중요한 사용자나 고객이 바라는 기능인가?
• 이 스토리가 다른 스토리들과 응집성(cohesiveness)이 있는가?
21. 고객 팀은 개발자들의 목소리를 들어야 하지만, 우선순위를 매길 때는 조직에 최대의 가치를 가져오도록 신경 써야 한다.
22. 스토리 개발에 드는 비용 역시 우선순위를 부여할 때 고려할 요인이다. 스토리 개발 비용은 개발자들이 스토리에 부여하는 추정치다. 각 스토리에 ‘스토리 점수(story point)’를 추정치로 할당한다. 어떤 스토리를 스토리 점수 4점으로 추정한 것은, 그 스토리를 개발하는 데는 2점으로 추정한 다른 스토리보다 두 배 정도 시간이 걸릴 것을 예상한다는 의미다.
인수 테스트는 무엇인가?
23. 인수 테스트는 스토리를 개발한 뒤 그것이 고객이 기대하는 대로 정확히 동작하는지를 입증하는 과정이다. 가능하면 테스트는 각 이터레이션의 초기에 작성해야 한다. 초기에 테스트를 작성하게 되면 고객이 가정하는 것, 기대하는 것 등을 더 많이, 더 빨리 개발자에게 전달할 수 있기 때문에 큰 도움이 된다.
왜 바꾸어야 하는가?
24. 사용자 스토리는 다른 방법들보다 장점이 많다.
• 사용자 스토리는 문서보다 구두 의사소통을 강조한다.
• 사용자 스토리는 고객이나 개발자 모두 이해할 수 있다.
• 사용자 스토리는 계획 수립에 적당한 크기다.
• 사용자 스토리는 반복적 개발에 효과적으로 사용된다.
• 사용자 스토리는 무엇이 필요한지 잘 알 때까지 세부사항을 뒤로 미룰 수 있게 해 준다.
25. 사용자 스토리는 문서 작성보다 얘기 나누는 것을 강조하기 때문에, 잘 읽지도 않을 문서에 중요한 결정사항을 남기지 않는다. 오히려 스토리의 중요한 측면들이 자동화된 인수 테스트로 정의되어 자주 실행되게 한다.
스토리 작성하기
26. 좋은 스토리를 작성하기 위해서는 다음에 열거한 ‘좋은 스토리의 여섯 가지 특성'에 집중해야 한다.
• 독립적이다 (Independent)
• 협상 가능하다 (Negotiable)
• 사용자 및 고객에게 가치가 있다 (Valuable)
• 추정 가능하다 (Estimatable)
• 작다 (Small)
• 테스트 가능하다 (Testable)
독립적이다
27. 가능하면 스토리 간에 의존성을 배제하도록 신경 써야 한다. 스토리 사이에 의존성이 있으면 우선순위 결정과 계획 수립에 문제를 야기한다.
협상 가능하다
28. 스토리는 협상 가능해야 한다. 스토리는 계약서나 요구사항 명세서처럼 꼭 구현해야 한다고 기록된 것이 아니다. 스토리는 기능에 대한 짧은 설명일 뿐, 세부사항은 고객과 개발팀이 대화를 통해 협상해야 한다. 대개 너무 이른 시점에 세부사항을 명시하는 것은 작업량을 증가시킬 뿐이다.
29. 스토리 카드는 개발자와 고객이 대화를 재개할 수 있는 단서 역할을 한다. 이러한 점을 생각해 보면, 스토리 카드를 다음의 내용을 구성하는 것이 유용할 것이다.
• 대화를 재개할 단서 역할을 하는 한두 문장
• 대화 중에 해결된 쟁점에 대한 주석
사용자와 고객 혹은 구매자에게 가치 있다
30. ‘모든 스토리는 사용자에게 가치가 평가되어야 한다'라고 말할 수 있다. 하지만 반드시 그런 것은 아니다. 많은 프로젝트에서 사용자의 가치 평가와는 별개의 스토리도 사용한다.
31. 여러분이 정말 피해야 할 스토리는 개발자에게만 가치 있는 스토리다. 예를 들어 다음 스토리들은 피해야 한다.
• 모든 데이터베이스 연결은 커넥션풀을 통해 이루어져야 한다.
• 모든 에러 처리 및 로그 생성은 공통 클래스들을 통해 이루어져야 한다.
32. 스토리에서 사용자 인터페이스에 대한 가정을 배제하는 것과 마찬가지 이유로, 어떤 기술을 사용할지에 대한 기술적인 가정도 배제하는 것이 좋다.
추정 가능하다
33. 개발자들은 각 스토리의 크기 혹은 작업 소요 시간을 추정할 수 있어야 한다. 추정이 쉽지 않은 경우는 보통 다음의 세 가지 원인 때문이다.
1. 해당 분야의 지식(도메인 지식)이 부족하다.
2. 기술적인 지식이 부족하다.
3. 스토리가 너무 크다.
작다
34. 스토리가 너무 크거나 너무 작으면 계획 단계에서 사용할 수 없기 때문에 스토리의 크기는 아주 중요하다. 어떤 스토리가 적절한 크기인가 그렇지 않은가 하는 문제는 개발 팀의 역량이나 사용하는 기술에 따라 결정된다.
35. 스토리 나누기. 에픽은 다음 두 가지 중 하나다.
• 복합적인 스토리
• 복잡한 스토리
36. 복합적인 스토리는 작은 스토리를 여러 개 포함하는 에픽이다. 복합적인 스토리를 나누는 방법은 많다. 복합적인 스토리와 달리, 복잡한 스토리는 크기가 크면서도 작은 스토리들로 나누기가 쉽지 않다. 대개 스토리 자체에 대한 불확실성 때문에 복잡해지는 경우가 많은데, 이런 경우에는 문제를 조사하는 스토리와 기능을 개발하는 스토리로 나눌 수 있다.
• 웹에서 신용카드를 처리하는 방법을 조사한다.
• 사용자는 신용카드로 결제할 수 있다.
37. 복잡한 스토리는 알고리즘을 새로 개발하거나 기존의 알고리즘을 확장해야 하는 경우에 자주 발생한다.
38. 스파이크는 다른 이터레이션에 할당. 가능하면 조사하는 스토리를 실제 작업 스토리보다 한두 이터레이션 앞에 할당하는 것이 나을 것이다. 보통은 조사하는 스토리만 추정이 가능하고, 실제 작업 스토리는 그렇지 않다. 따라서 두 스토리를 같은 이터레이션에 포함할 경우 불확실성이 더 높아지게 된다.
39. 추정이 어려운 스토리를 분할할 때 얻는 가장 큰 이점은, 고객이 새 기능뿐 아니라 조사 작업에 대해서도 별도로 우선순위를 부여할 수 있도록 한다는 점이다.
40. 스토리 합치기. 가끔은 스토리가 너무 작을 수도 있다. 너무 작은 스토리란 것은, 그것을 작성하고 작업량을 추정하는 것이 내용을 변경하는 것보다 더 오래 걸릴 것 같은 스토리다. 주로 버그 보고서나 UI 변경에 대한 스토리들이 여기에 해당한다. 이런 작은 스토리들을 취급해야 한다면, 이것들을 더 큰 스토리로 합쳐서 반나절에서 며칠 정도의 작업량이 되도록 만드는 것이다.
테스트 가능해야 한다
41. 스토리는 테스트 가능하도록 작성해야 한다. 테스트를 성공적으로 통과해야 그 스토리가 성공적으로 개발되었다고 말할 수 있다. 스토리가 테스트할 수 없게 작성되었다면, 개발자가 언제 코딩을 그만두어야 할지 알 수 있을까?
사용자 역할 모델링
42. 많은 프로젝트에서 오직 한 유형의 사용자만 존재하는 것처럼 스토리를 작성하는 경우가 많다. 모든 스토리가 그 사용자 유형의 관점에서만 작성된다. 그러나 이런 식으로 단순화하는 것은 잘못된 생각이며, 자칫 시스템 주요 사용자 유형에 포함되지 않는 사용자들에게 필요한 스토리를 놓칠 수도 있다.
사용자 역할
43. 확실히 한 시각만으로는 스토리를 작성할 수 없다. 여러 사용자의 경험, 배경, 목적 등이 스토리에 반영되도록 해야 한다. 사용자들은 제각기 다른 배경과 목적으로 소프트웨어를 사용하겠지만, 비슷한 유형의 사용자들을 모아 ‘사용자 역할(user role)’로 부를 수 있을 것이다. 사용자 역할은 특정 사용자 집단이 시스템과 어떤 상호작용을 하는지 규정하는 속성의 집합이다.
역할 모델링 절차
44. 여기서는 효과적인 사용자 역할 목록을 만들기 위해 다음 절차를 따를 것이다.
• 사용자 역할 목록 초안을 위한 브레인스토밍
• 목록 초안 조직화
• 역할 통합하기
• 역할 다듬기
45. 사용자 역할 하나는 한 명의 사용자. 프로젝트에서 사용자 역할에 대해 브레인스토밍 할 때는, 구체적인 사용자를 나타내는 역할을 식별하도록 유의한다.
46. 시스템 역할. 가능하면 사용자 역할을 정의할 때, 시스템과 연동되는 다른 시스템보다는 시스템을 사용하는 사람에 초점을 맞추어야 한다.
47. 역할 속성(role attribution)은 어떤 역할을 수행하는 사용자들에 대한 사실 혹은 사용자와 관련된 유용한 정보다. 다른 역할과 구분할 수 있는 어떤 정보라도 역할 속성으로 사용할 수 있다. 여기서는 일반적인 역할 모델링에서 유용하게 사용될 수 있을 만한 속성들을 소개한다.
• 소프트웨어를 사용하는 빈도
• 해당 분야에 관한 전문 지식수준
• 컴퓨터 및 소프트웨어에 대한 일반적인 숙련도
• 개발 대상 소프트웨어에 대한 숙련도
• 소프트웨어에 대한 일반적인 사용 목적. 어떤 사용자들은 편리함을 우선시하며, 어떤 사용자들은 풍부한 기능을 선호한다.
도움이 되는 기법 두 가지
48. 등장인물(persona)은 사용자 역할을 대표할 만한 가상 인물이다. 여러분의 프로젝트에서 등장인물을 만들기로 결정했다면, 등장인물이 실제 대상 고객을 왜곡하지 않고 나타내도록 시장 및 인구통계에 근거해 충분한 조사가 선행 되어야 함을 명심한다.
49. 새로운 시스템을 설계할 때에는 극단적 인물을 사용하라. 극단적인 인물을 고려하면 여러분이 지나칠 수도 있는 스토리를 발견하게 된다. 극단적 인물을 고려하면 새로운 사용자 스토리를 찾을 수 있지만, 이것들이 제품에 포함되어야 하는지를 판단하기란 쉽지 않다.
스토리 수집하기
작은 것이라도 충분하다, 정말 그럴까?
50. 애자일 프로젝트에서는 한 번에 사용자 스토리를 모두 낚을 수 있을 정도로 촘촘한 그물을 사용하는 것이 불가능하다는 점을 인정한다. 이는 시간이 흐름에 따라, 혹은 이전 이터레이션에서 제품에 어떤 스토리가 추가 구현되었는지에 따라 스토리의 유효성이 달라짐을 의미한다.
51. 초기에 스토리를 모두 작성하는 것이 불가능함을 인정한다 하더라도, 할 수 있는 만큼은 스토리를 작성하려고 시도해 보아야 한다. 비록 그렇게 작성된 스토리가 고도로 추상화된 형태일지라도 말이다. 스토리를 이용하여 개발을 진행할 때의 장점 중 하나는 그것을 다양한 수준으로 상세화하여 작성하는 것이 매우 쉽다는 점이다.
기법
52. 스토리는 프로젝트 기간 동안 발전하고, 나타나고, 사라지기 때문에, 반복적으로 사용할 수 있는 스토리 수집 기법이 필요하다. 이러한 기법들은 지속적으로 적용할 수 있을 만큼 가볍고 불편하지 않아야 한다. 사용자 스토리 작성을 위한 훌륭한 기법 중에서 몇 가지를 뽑아보면 다음과 같다.
• 사용자 인터뷰
• 설문
• 관찰
• 스토리 작성 워크샵
사용자 인터뷰
53. 대부분의 사용자는 정말 필요한 것이 무언지 제대로 알지 못하며, 특히 그것을 표현하는 것에 익숙하지 않다.
스토리 작성 워크샵
54. 올바르게 실시한 스토리 작성 워크숍에서는 많은 스토리를 아주 빠르게 작성할 수 있다.
55. 충실도 낮은 프로토타입은 만들고 나서 며칠 안에 던져버리거나 지워버려야 한다. 프로토타입은 개발 프로세스에서 장기간 유지할 산출물이 아니다. 프로토타입을 검토할 때 다음과 같은 질문을 해 보면 빠뜨린 스토리를 식별하는 데 도움이 될 것이다.
• 사용자는 다음에 어떤 동작을 취할까?
• 여기서 사용자가 저지를 만한 실수는 어떤 것이 있을까?
• 이 지점에서 불명확한 것은 무엇인가?
• 어떤 부가 정보가 필요할까?
이 질문을 할 때 사용자 역할과 등장인물을 염두에 두어라. 사용자 역할에 따라 질문의 답이 달라질 수 있다.
56. 스토리 작성 워크샵에서는 스토리의 질보다 양에 초점을 두어야 한다. 워크샵의 목적은 가능한 짧은 시간에 최대한 많은 사용자 스토리를 작성하고자 하는 것이다. 워크샵은 화면을 설계하거나 문제를 해결하는 시간이 아니다.
사용자 스토리 인수 테스트
57. 인수 테스트를 작성하는 이유 중 하나는 고객과 개발자가 대화를 나누는 과정에서 언급된 세부사항들을 나타내기 위함이다. ‘시스템은 ~ 해야 한다'와 같은 문장을 일일이 작성하는 요구사항 명세서와는 달리, 사용자 스토리에서는 세부사항을 테스트로 표현한다.
58. 테스트는 두 단계로 수행된다. 첫 단계는 나중에 무엇을 테스트할지에 관한 짧은 메모를 스토리 카드 뒷면에 짧게 적어 놓는 것이다. 누구든 새로운 테스트가 떠오를 때 첫 단계를 실행한다. 다음 단계는 테스트에 관한 메모를 완전한 형태의 실행 가능한 테스트로 옮기는 과정이다. 두 번째 단계에서 만들어지는 테스트는 해당 스토리가 정확하고 완전하게 개발되었는지 입증하는 데 사용된다.
59. 인수 테스트는 스토리가 완전히 개발되었는지를 결정하는 기본적인 기준이 되기도 한다. 어떤 부분이 완료되었음을 알려주는 기준을 마련하는 것은 그 일을 하기 위해 너무 많지도 적지도 않은, 딱 적당한 시간과 노력만 들일 수 있도록 하는 최고의 방법이다.
코딩하기 전에 테스트부터 작성하기
60. 인수 테스트가 있으면, 프로그래머는 코딩을 시작하기 전에 유용한 정보를 많이 얻을 수 있다. 프로그래머가 이러한 이득을 얻기 위해서는 당연히 코딩을 시작하기 전에 스토리에 대한 인수 테스트를 작성해야 한다. 인수 테스트는 일반적으로 다음과 같은 때에 작성한다.
• 고객과 개발자가 스토리를 가지고 대화를 나누는 도중, 명백한 세부 사항을 기록하기 위해
• 이터레이션 초기 코딩을 시작하기 전에 스토리를 명확하게 이해하고자 할 때
• 프로그래밍 중이거나 그 이후라도 스토리에 필요한 새로운 테스트를 발견할 때
61. 이상적으로는 고객과 개발자가 스토리에 관하여 논의할 때 드러나는 세부사항을 테스트로 작성한다. 하지만 이터레이션을 시작할 때에는 고객이 주도적으로 스토리를 모두 검토하고 더 추가할 테스트가 없는지 확인해야 한다. 이때에는 스토리마다 스스로 다음과 같은 질문을 해 보는 것이 도움이 될 것이다.
• 프로그래머가 이 스토리에 대해 꼭 알아야 하는 내용은 무엇인가?
• 나는 이 스토리가 어떤 모습으로 구현될 거라고 가정하는가?
• 이 스토리가 다르게 동작할 만한 상황은 없는가?
• 스토리를 진행하는 중에 잘못될 만한 일은 무엇인가?
고객이 테스트를 명시한다
62. 소프트웨어는 고객의 비전을 실현하기 위해 개발하는 것이다. 따라서 인수 테스트는 고객이 명시해야 한다.
테스트 수행은 프로세스의 일부다
63. 아마도 대부분의 프로그램이 테스트를 통과할 것이며, 실제 사용자가 직접 사용하기 시작하면 그제야 에러가 난무하게 될 것이다. 두말할 것 없이 이 상황의 문제는 테스터가 프로그래머의 설명에만 의존하여 그것만 테스트한 데 있다. 고객 혹은 사용자의 직접 참여 없이 진행되는 테스트는 소프트웨어가 고객이나 사용자의 요구를 충족시키는지와는 무관한 것이다.
64. 사용자 스토리에서 테스트는 ‘코드 작성이 끝난 다음' 하는 것이 아니라, 개발 프로세스의 일부로 보아야 한다. 테스트가 확실히 수행되도록 하는 것은 제품 관리자와 테스터의 공동 책임이다. 제품 관리자는 프로젝트의 올바른 방향을 인식하고 있으며, 테스터는 모든 것을 의심하고 확인하는 사고방식을 가지고 있다. 이들은 이터레이션을 시작할 때 함께 모여 가능한 많은 테스트를 생각해서 작성한다. 그뿐 아니라 주간 회의에도 계속 참석해야 하며, 각 스토리의 세부 사항이 진척됨에 따라 추가 테스트를 명시해야 한다.
테스트는 얼마나 필요한가?
65. 고객은 테스트를 추가함으로써 스토리의 가치와 명확성을 높일 수 있는 한 계속 작성해야 한다. 그러나 불필요하게 중복하여 작성할 필요는 없다.
66. 또한 좋은 프로그래머라면 저수준 검증을 위한 단위 테스트를 만들 것이라는 점도 명심해야 한다. 예를 들어 2월 30일이나 6월 31일이 유효하지 않은 날짜라고 판별하는 등의 단위 테스트는 프로그래머들이 만들어야 한다. 고객이 이런 세부사항까지 일일이 지적할 필요는 없다. 고객은 스토리의 의도가 개발자에게 명확하게 전달되도록 하는 데 초점을 맞추어 테스트를 작성해야 한다.
FIT
67. 인수 테스트는 프로그램을 고객이 받아들일 만한 것인지 보여주기 위한 것이다. 이는 고객이 인수 테스트를 실행하는 사람이어야 함을 의미한다. 인수 테스트는 적어도 각 이터레이션이 끝날 때마다 실행되어야 한다. 한 이터레이션에서 잘 작동하던 코드가 다음 이터레이션을 진행하는 동안 깨지는 경우도 있기 때문에, 지난 모든 이터레이션의 테스트까지 함께 실행해야 한다. 이는 이터레이션이 횟수를 거듭할수록 인수 테스트를 실행하는 데 더 많은 시간이 걸리게 됨을 의미한다. 가능하면, 개발 팀은 일부 혹은 전체 인수 테스트를 자동화할 수 있는 방법을 찾아야 한다.
테스트의 종류
68. 테스트에는 종류가 많다. 고객 팀과 개발 팀 모두 적절한 종류의 테스트가 수행되는지 신경 써야 한다. 스토리를 테스트하는 것은 프로그램의 기능(동작)이 기대한 대로 구현되었는지를 확인하는 기능 테스트인 경우가 대부분이다. 하지만 다른 테스트 종류도 고려해 보아야 한다. 예를 들어 다음에 설명한 테스트 중에서 하나 혹은 모두를 고려해 볼 필요가 있다.
• 사용자 인터페이스 테스트(user interface test): 사용자 인터페이스 구성 요소들이 예상한 대로 동작하는지 확인한다.
• 사용성 테스트(usability test): 프로그램이 쉽게 사용할 수 있도록 개발되었는지 확인한다.
• 성능 테스트(performance test): 프로그램이 다양한 작업 부하에서 얼만큼 성능을 보이는지 측정한다.
• 스트레스 테스트(stress test): 사용자 초과, 트랜잭션 과다 등의 스트레스 상황에서 프로그램이 어떻게 동작하는지 확인한다.
69. 테스트는 버그를 확인하기 위한 것이지 실행을 확인하기 위한 것이 아니다. 애자일 프로젝트에서는 버그를 찾아 제거하기 위해 테스트를 한다.
좋은 스토리를 위한 지침
목적 스토리로 시작하라
70. 대규모 프로젝트, 특히 사용자 역할이 많고 다양한 프로젝트는 스토리 식별을 어디서부터 시작해야 할지 막막한 경우가 있다. 내 경험으로는, 한 번에 하나씩 사용자 역할을 선택하여 그 사용자가 새 시스템을 사용하는 주목적을 식별하는 것이 가장 효과적이었다.
케이크 자르듯 나누어라
71. 큰 스토리를 만났을 때에는 그것을 작은 스토리 조각으로 나눌 수 있다는 사실을 명심하자. 스토리를 나누는 훨씬 나은 방법은 나누어진 각각의 스토리가 시작부터 끝까지의 기능을 제공하도록 나누는 것이다. 각 스토리는 본래 스토리의 모든 계층(맨 위부터 맨 아래까지)에서 조금씩 가져와야 한다.
72. 케이크의 완전한 하나의 조각처럼 기능의 시작과 끝을 꿰뚫는 스토리를 그렇지 못한 스토리보다 우선 고려해야 한다. 여기에는 두 가지 이유가 있다. 첫째, 애플리케이션 아키텍처의 모든 계층을 포함하도록 함으로써 마지막 순간에야 특정 계층에서 문제가 발견되는 리스크를 줄일 수 있다. 둘째, 이상적이지는 않지만, 프로그램은 기능이 일부만 구현되었더라도 해당 기능들이 시스템의 처음부터 끝까지 포함한다면 실제 사용을 목적으로 사용자에게 릴리즈 될 수 있기 때문이다.
닫힌 스토리를 작성하라
73. 닫힌 스토리는 의미 있는 목적을 달성하는 형태로 작성되어 사용자로 하여금 무언가를 해냈다고 느끼게 하는 스토리를 말한다. 각 닫힌 스토리는 닫혀 있지 않은 처음 스토리의 부분에 해당한다. 닫힌 스토리 중 하나를 완성하고 나면 사용자는 무언가 해냈다고 느낄 것이다.
74. 닫힌 스토리를 작성할 때 조심할 점은 스토리의 기본적인 원칙에 위배되지 않도록 해야 한다는 것이다. 스토리는 추정이 가능한 정도로 작아야 하며 한 이터레이션 동안 개발 가능한 정도의 크기여야 한다는 점을 기억하라. 하지만 너무 이른 시기에 세부사항을 잡아내는 데 얽매이지 않도록 적당히 클 필요도 있다.
제약사항 기록하기
75. 제약사항 스토리 카드는 보통의 스토리 카드와 달리 작업량을 예측하지도 이터레이션의 일정에 포함시키지도 않지만 유용하게 사용된다. 최소한 다른 스토리와 함께 벽에 붙여 둠으로써 제약사항들을 잊지 않도록 하는 데 도움이 된다. 인수 테스트를 작성할 때 이러한 제약사항들을 위반하지 않도록 한다면 훨씬 좋을 것이다.
스토리의 크기는 시간축에 맞추어라
76. 여러분은 가장 중요한 부분에 주의를 집중하고 싶을 것이다. 일반적으로 이는 먼 나중에 일어날 일이 아닌 가까운 미래에 일어날 일에 더 집중하는 것을 의미한다. 사용자 스토리에서는 프로젝트 진행 일정에 따라 다양한 수준으로 스토리를 작성하는 것을 의미한다. 즉, 바로 다음에 진행할 이터레이션에 대해서는 일정을 계획할 수 있는 수준으로 작은 스토리를 작성하며, 훨씬 나중에 처리할 스토리는 정확하지 않더라도 더 크게 작성할 것이다.
되도록 사용자 인터페이스를 배제하라
77. 요구사항에 구현 세부사항과 같은 산출물 명세를 섞어 넣는 것은 모든 요구사항 기법에 나타나는 공통의 문제다. 요구사항을 명시할 때 직간접적으로 산출물의 구현 세부사항까지 함께 명시하는 것이다. 특히 사용자 인터페이스 측면에서 이러한 문제가 자주 발생한다. 여러분은 되도록 스토리에서 사용자 인터페이스에 관련된 사항을 배제하여야 한다.
78. 사용자 인터페이스에 관한 세부사항이 언젠가는 스토리에 포함될 수밖에 없다. 하지만 이렇게 되는 것은 소프트웨어가 좀 더 구체적인 모양을 갖추고 스토리가 더 이상 새로운 기능을 나타내는 것이 아니라 기존 기능을 수정하거나 확장하는 것을 의미하게 될 때다.
스토리가 아닌 것들
79. 사용자 스토리는 형식이 자유로워 시스템의 기능을 서술하는 데 적합하지만 모든 경우에 적합한 것은 아니다. 사용자 스토리와는 다른 양식으로 요구사항을 표현할 필요가 있다면 그렇게 하도록 하라.
스토리에 사용자 역할을 포함하라
80. 사용자 역할을 식별해 냈다면, 스토리를 작성할 때 사용자 역할을 적극 이용하도록 한다. ‘사용자는 이력서를 작성할 수 있다'라고 하는 대신 ‘구직자는 이력서를 작성할 수 있다'라고 작성한다. 별 차이가 없어 보이지만 이런 방식으로 스토리를 작성함으로써 개발자들의 생각 속에 구체적인 사용자가 자리 잡을 수 있다. 이름도 얼굴도 없는 딱히 누구라도 상관없을 일반적인 사용자 대신, 우리가 개발하는 소프트웨어를 통해 만족을 얻을 실제 사용자를 떠올릴 수 있게 된다.
한 명의 사용자를 대상으로 작성하라
81. 스토리는 한 명의 사용자들 대상으로 작성하였을 때 읽기가 가장 수월하다.
능동태로 작성하라
82. 사용자 스토리는 능동태로 작성하는 것이 읽거나 이해하기 더 쉽다. 예를 들어 ‘이력서는 구직자에 의해 게시될 수 있다'라고 하기보다 ‘구직자는 이력서를 게시할 수 있다'라고 작성하는 것이 더 낫다.
고객이 작성하라
83. 원칙적으로는 고객이 스토리를 작성한다. 많은 경우 개발자들은 스토리 작성 워크숍에서 직접 스토리를 작성하거나 고객에게 새로운 스토리를 제안하는 형태로 스토리 작성을 돕는다. 하지만 스토리 작성의 책임은 고객에게 있으며 개발자들에게 전가해서는 안 된다. 그뿐 아니라 고객에게는 이터레이션을 시작할 때 스토리의 우선순위를 매겨야 하는 책임도 있기 때문에 고객은 반드시 각 스토리를 이해하고 있어야 한다. 가장 잘 이해하는 방법은 직접 작성하는 것이다.
스토리 카드에 번호를 부여하지 말라
84. 스토리 카드를 처음 사용하는 경우라면 카드에 일련번호 같은 것을 부여하고 싶을 수 있다. 보통 이렇게 하는 이유는 번호를 부여함으로써 각 카드를 추적하기 쉽게 하기 위해서다. 하지만 스토리 카드에 번호를 부여하는 것은 무의미한 업무 분담만 늘리고 구체적인 기능을 논의하는 데 불필요한 추상성을 개입시키는 문제가 있다.
목적을 잊지 말라
85. 스토리 카드의 주목적은 구현할 기능을 논의하기 위한 단서 역할이라는 점을 잊지 말아야 한다. 단서는 간결해야 한다. 카드에는 나중에 대화를 재개하기 위해 기억하면 될 정도의 세부사항만을 써놓도록 하며, 너무 많은 세부사항을 써넣어 카드가 대화를 대신하지 않게 한다.
추정과 계획
사용자 스토리 추정
86. 어떤 프로젝트도 “언제 끝납니까?”라는 물음 없이는 진행될 수 없다. 스토리를 추정하기 위한 방법은 다음의 특징들을 가져야 한다.
• 스토리에 대해 새로운 내용을 알게 되면 언제든지 추정치를 수정할 수 있어야 한다.
• 에픽이든 작은 스토리든 그 크기에 상관없이 적용할 수 있어야 한다.
• 추정하는 데 시간이 많이 걸리지 않아야 한다.
• 진척 상황 및 남아 있는 작업량에 대해 유용한 정보를 제공해야 한다.
• 추정치가 정확하지 않더라도 큰 문제가 되지 않아야 한다.
• 릴리즈 계획에 사용할 수 있어야 한다.
스토리 점수
87. 앞에서 열거한 특징을 만족시키는 방법 중 하나는 추정의 단위로 ‘스토리 점수(story point)’를 이용하는 것이다. 스토리 점수는 팀마다 자신들에게 맞는 정의를 채택하여 사용할 수 있다는 장점이 있다.
88. 스토리를 이상적 작업일로 추정하는 것에는 두 가지 장점이 있다. 첫째, 경과 시간으로 추정하는 것보다 쉽다. 둘째, 이상적 시간으로 추정하는 것이 모호한 단위로 추정하는 것보다 조금 더 신뢰할만한 근거를 제공한다. 추정의 주목적 중 하나가 프로젝트 전체의 예상 작업량이 얼마인가 하는 질문에 답하기 위한 것이기 때문에, 어떠한 방법으로 추정하더라도 결국은 그 추정치를 시간 단위로 환산할 필요가 있을 것이다. 이상적 시간 단위로 추정함으로써 모호한 단위로 추정할 때보다 환산을 더 간단히 할 수 있다.
팀 전체가 함께 정한다
89. 스토리 추정은 팀에서 공동으로 해야 한다. 첫째, 스토리를 추정하는 시점에는 누가 어떤 스토리를 맡아 작업할지 아직 결정하지 않았으므로 스토리를 팀 전체가 맡았다고 보는 것이 가장 정확하다. 둘째, 개인이 추정하는 것보다 팀이 추정하는 것이 더 정확하다. 개발자들이 추정하는 고객도 참가하게 되지만, 고객은 자신이 수긍할 수 없는 경우라도 개인적인 추정치를 제시하거나 사견을 주장하는 것이 허락되지 않는다.
추정하기
90. 프로그래머는 스토리를 완료하기 위해 필요한 모든 것들을 추정에 포함시켜야 한다. 코드를 테스트하고, 고객과 회의를 하며, 고객이 인수 테스트를 준비하고 자동화하는 것들 도와주는 등의 요인들을 모두 고려해야 한다.
스토리 점수 활용
91. 이터레이션을 마치면 팀 전체가 완료한 스토리들의 스토리 점수를 합산한다. 합산한 스토리 점수는 앞으로 같은 기간의 이터레이션에서 완료할 스토리 점수에 대한 예측치로 사용할 수 있다. 한 이터레이션 동안 완료한 (혹은 완료할 것으로 예상되는) 스토리 점수를 ‘속도(velocity)’라고 부른다.
92. 스토리 점수로 추정할 때의 문제점은 수치 상의 차이를 설명하기 어렵다는 것이다. 추정치가 크다는 것은 그만큼 스토리를 잘 모르기 때문이라는 사실을 반영하여 값이 커질수록 간격도 커진다는 것을 확인할 수 있다.
잊지 말아야 할 몇 가지
93. 스토리 점수를 사용하다 보면 혼란스러운 경우가 간혹 있다. 보통은 스토리 점수를 너무 어렵게 생각하거나, 스토리 점수에 그 이상의 의미를 부여할 때 그러하다. 스토리 점수를 적절하게 사용하기 위해서 다음 사항들을 잊지 말아야 한다.
• 여러분의 팀이 사용하는 스토리 점수와 우리 팀이 사용하는 스토리 점수는 동등하지 않다.
• 스토리(특히 에픽)를 작은 스토리들로 나누는 경우에, 나누어진 스토리들의 추정치 합은 원래 스토리에 대한 추정치와 같을 필요가 없다.
• 마찬가지로, 스토리를 작업 단위로 나눌 때에도 하위 작업들의 추정치 합이 원래 스토리의 추정치와 같을 필요가 없다.
릴리즈 계획
94. 릴리즈 주기가 아무리 짧더라도 계획 없이 진행하기보다는 새 릴리즈에 포함될 기능들을 모으는 것부터 시작하는 것이 도움이 된다. 향후 몇 차례의 릴리즈에 포함될 주요 내용을 정리한 제품 개발 로드맵이 있다면 그것을 바탕으로 릴리즈 계획을 시작할 수 있을 것이다.
95. 제품 개발 로드맵은 시간이 지나면서 분명히 변경될 것이고, 사실 그것이 바람직하다. 변경된다는 것은 우리들이 제품과 시장에 관하여 더 알게 되고, 그만큼 제품을 더 잘 개발할 수 있게 되었다는 것을 의미하기 때문이다.
96. 개략적인 제품 개발 로드맵을 바탕으로 아래의 두 질문을 통해 릴리즈 계획을 시작하게 된다.
• 언제 릴리즈할 것인가?
• 각 스토리의 우선순위는 어떻게 되는가?
두 질문의 답을 구하고 나면, 각 이터레이션에서 수행할 작업량을 추정함으로써 릴리즈를 계획하게 된다. 이터레이션 당 수행 가능한 작업량의 추정치를 통해서 이번 릴리즈를 위해 이터레이션이 몇 번이나 필요한지 예측하게 된다.
언제 릴리즈할 것인가?
97. 반복적인 스토리 주도 프로세스에서는 릴리즈 날짜를 정확히 지정하기 쉽다. 다만 해당 릴리즈 날짜까지 어떤 기능들이 포함될지 결정하는 것은 어렵다.
어떤 것들을 포함시킬 것인가?
98. 릴리즈를 계획하려면 우선 고객이 스토리에 우선순위를 매겨야 한다.
• 필수 (Must-have)
• 희망 (Should-have)
• 선택 (Could-have)
• 보류 (Won’t-have)
99. 필수 기능은 시스템에 아주 중요한 기초가 되는 것이다. 희망 기능은 중요하지만 단기적으로는 차선책이 있는 것이다. 만약 프로젝트에 시간 제약이 없다면 희망 기능은 꼭 필요한 것으로 간주된다. 선택 기능은 시간이 부족한 경우 다음 릴리즈로 미루거나 누락될 수 있는 것들이다. 보류 기능은 좋기는 하지만 다음 릴리즈에 포함될 것으로 미루는 것들이다.
스토리 우선순위 매기기
100. 스토리를 정렬하는 데는 여러 기준이 있다. 그중 기술적인 요인에는 다음과 같은 것들이 있다.
• 스토리 미완성에 대한 리스크
• 스토리 구현을 늦췄을 때 다른 스토리에 미치는 영향
101. 고객과 사용자는 다음과 같은 자신들만의 스토리 정렬 기준이 있다.
• 사용자나 고객 다수가 원하는 정도
• 다수는 아니지만 중요한 사용자나 고객이 바라는 정도
• 다른 스토리와의 응집성
102. 개발자들은 대체로 그들이 구현하고 싶은 스토리를 위에 올려 두며, 고객 역시 마찬가지다. 순서가 일치하지 않는 경우에는 항상 고객의 의견이 우선이다. 하지만 고객은 개발 팀에서 제공하는 정보 없이 우선순위를 매길 수 없다. 최소한, 고객은 각 스토리가 대략 얼마나 걸릴지는 알아야 한다.
혼합된 우선순위
103. 고객이 우선순위를 매기는 것을 어려워한다면, 그것은 스토리를 나눌 필요가 있음을 의미할지도 모른다. 스토리를 나누면 고객은 나뉜 각 스토리에 우선순위를 다르게 매길 수 있게 된다.
리스크 높은 스토리
104. 애자일 접근법은 수지에 맞는 부분을 먼저 개발하는 쪽에 속한다. 애자일 프로젝트는 너무 빨리 리스크를 해결하려는 시도를 피하고, 필요하지 않을지도 모를 기반구조 코드를 작성하는 것을 미루도록 한다. 또한 수지에 맞는 부분을 선호하는 것은 프로젝트에서 가장 가치가 높은 기능이 준비되자마자 바로 릴리즈하는 것을 가능하게 한다.
105. 일반적으로 개발자들은 가장 리스크가 높은 스토리를 개발하고자 하는 경향을 보인다. 가끔은 이렇게 하는 것이 적절하지만, 그 결정은 고객이 내려야 한다. 그리고 고객은 우선순위를 매길 때 개발자들에게 얻는 정보를 고려한다.
기반구조에 대한 우선순위
106. 고객이 어떤 스토리를 뒤로 미루어도 되는지, 구현을 미루는 경우 비용이 얼마나 많이 들게 되는지 알 수 있도록 돕는 것은 개발자의 책임이다. 그렇다고 개발자들이 고객을 휘둘러 기술적으로 마음에 드는 기능을 먼저 구현하도록 유도해서는 안 된다.
이터레이션 길이 선택
107. 이터레이션 길이는 개발자와 고객이 함께 결정한다. 이터레이션 길이는 대체로 1주에서 4주 정도가 적당하다. 이터레이션이 짧으면 프로젝트의 방향을 자주 수정할 수 있고, 진척 상황에 대한 가시성도 확보하기 쉽다. 하지만 이터레이션마다 오버헤드가 조금 발생하게 된다. 그래도 너무 긴 이터레이션보다는 너무 짧은 이터레이션이 낫다.
108. 가능하면 프로젝트를 진행하는 동안 이터레이션 길이를 일정하게 유지하도록 한다. 이터레이션 길이를 일정하게 유지함으로써, 프로젝트는 자연스러운 리듬을 탈 수 있으며, 이러한 리듬은 팀이 개발 페이스를 지속하는 데 도움이 된다.
릴리즈 계획 생성하기
109. 팀 구성원이 모두 같은 공간에서 일하는지, 조직의 특성상 격식을 따라야 하는지에 따라, 릴리즈 계획을 공유할 수 있는 방법은 여러 가지가 있다. 릴리즈 계획은 아무것도 없는 상태에서 초기 예측으로서 사용하기 위한 것이다. 그리고 그러한 예측들은 새로운 정보를 얻게 되면서 지속적으로 재조정해야 한다. 이터레이션마다 속도를 모니터링하고, 기존의 추정치에 영향을 미치는 새로운 사실을 배울 때마다 스토리를 재추정해야 한다.
이터레이션 계획
이터레이션 계획 개요
110. 이터레이션을 계획하기 위해서는 팀 전체가 이터레이션 계획 회의에 참석해야 한다. 모든 개발자뿐만 아니라 고객도 회의에 참석해야 한다. 회의에서는 스토리들을 좀 더 세부적으로 살펴볼 것이므로 여러 가지 의문이 생길 것이다. 이러한 물음에 답할 수 있는 고객이 꼭 참석해야 한다. 이터레이션 계획 회의는 일반적으로 다음과 같은 절차에 따라 진행된다.
• 1/ 스토리에 대해 토의한다.
• 2/ 스토리를 작업 단위로 나눈다.
• 3/ 각 작업마다 개발자 한 명이 책임을 맡는다.
• 4/ 모든 스토리에 대한 토의를 거쳐 각 작업마다 책임자가 결정되면, 개발자들은 자신이 과하게 책임을 맡지 않았는지 확인하기 위해 자신이 맡은 작업들의 작업량을 추정한다.
스토리 토의
111. 이터레이션 계획 회의를 할 때는 이미 우선순위가 매겨진 스토리들이 준비되어 있다. 이 회의에서 프로그래머는 스토리 개발 난이도에 대한 의견을 변경할 수 있으며, 마찬가지로 고객도 스토리의 우선순위를 변경할 수 있다. 이터레이션 계획 회의는 고객이 이러한 우선순위 변경을 개발 팀에 전달하기에 가장 적절한 순간이다.
112. 이터레이션을 ‘진행하는 중’에는 고객이 우선순위를 변경하고 싶더라도 변경하지 않는 것이 가장 좋다. 이터레이션 중간에 고객이 자주 생각을 바꾸면 팀으로서는 문제가 아닐 수 없다.
작업 단위 나누기
113. 스토리를 작업 단위로 나누는 데는 특별한 기술이 없다. 스토리가 충분히 작아서 그 자체를 업무 단위로 사용할 수 있더라도, 더 작은 하위 작업으로 나누는 것이 일반적으로 더 효과적이다. 그 첫째 이유는, 스토리 하나를 개발자 한 명이 처음부터 끝까지 개발하지 않기 때문이다. 개발자마다 전문 분야가 있고, 또 일을 분담하는 것이 스토리를 더 빨리 구현할 수 있기 때문에, 한 스토리를 여러 개발자가 나누어 개발하게 된다.
114. 둘째, 스토리는 사용자나 고객의 관점에서 기능을 기술한 것이기 때문에, 개발자의 작업 목록으로는 적절하지 않다. 스토리를 세부 작업으로 변환하는 것은 개발자가 놓칠지 모를 사항을 정리하는 데 도움을 준다.
115. 애자일 프로세스에 대한 비판 중 하나는, 폭포수 모형 프로세스에 있는 것과 같은 코딩에 앞선 사전 설계 단계가 없다는 점이다. 그것이 사실이긴 하지만, 대신 애자일 프로세스에서는 설계를 자주, 신속하게 한다. 스토리를 작업들로 나누는 것은 최소한의 설계가 머릿속에 그려질 때 가능하다.
116. 스토리는 이미 충분히 작기 때문에 굳이 적절한 작업 크기까지 지침으로 제시할 필요는 없을 것이다. 다만, 스토리를 작업으로 나눌 때 다음 지침을 따른다면 도움이 될 것이다.
• 스토리를 구성하는 작업 중에서 특히 추정하기 어려운 작업이 있다면, 해당 작업을 스토리의 다른 부분들과 따로 분리한다.
• 다른 개발자와 나누어 진행할 수 있는 작업이 있으면 나눈다.
• 스토리의 일부분만 완료되어도 도움이 된다면, 그 부분을 별도의 작업으로 나눈다.
책임 맡기
117. 실제로는 작업이 완료되도록 할 책임은 팀 구성원 전체에게 있다. ‘모두 함께 한다'는 마음가짐이 필요하다. 그리고 이터레이션이 끝나가는데 어떤 개발자가 맡은 작업을 모두 완료하지 못했다면, 다른 누군가가 나서서 할 수 있는 만큼의 일을 넘겨받도록 해야 한다.
속도 측정 및 모니터링
118. 각 이터레이션에 포함되는 일정한 스토리 점수를 프로젝트의 속도라고 한다. 속도는 계획뿐만 아니라 관리 도구로도 유용하게 사용될 수 있기 때문에, 각 이터레이션을 마쳤을 때를 비롯하여 이터레이션을 진행하는 동안에도 팀의 속도를 지속적으로 관찰하는 것이 중요하다.
속도 측정
119. 속도가 중요한 측정치라고 했는데, 그렇다면 속도는 어떻게 측정할 수 있을까? 속도는 스토리 점수다. 각 스토리마다 점수가 부여되어 있으므로 속도를 계산하려면 이터레이션 동안 완료한 스토리들의 점수를 그대로 합하면 된다.
120. 처음에 가정한 속도가 틀릴 수도 있지만 개발 초기에는 속도가 변하기 쉽기 때문이다. 좀 더 장기적인 관점에서 속도의 추이가 어떠한지 알 수 있을 때까지는 이터레이션을 두세 번 지켜보아야 한다.
121. 이터레이션이 끝날 때까지 완료하지 못한 스토리는 어떻게 할 것인가? 속도 계산에 포함해야 하는가? 아니다. 부분적으로 완료한 스토리는 속도 계산에 포함하면 안 된다. 여기에는 여러 가지 이유가 있다. 첫째, 완료하지 못한 스토리에 대해 몇 퍼센트나 완료했는지 결정하는 것은 쉽지 않다. 둘째, 43.8과 같이 소수점 이하를 허용함으로써 속도의 정확성에 대한 그릇된 인상을 갖지 않도록 해야 한다. 셋째, 완료하지 못한 스토리는 사용자나 고객에게 명백한 가치를 제공하지 못한다. 넷째, 스토리가 너무 커서 부분 점수만 더하는 것으로도 속도에 크게 영향을 준다면, 그건 스토리가 너무 크다는 것을 말한다. 마지막으로 100% 완료한 스토리는 별로 없고 90% 완료한 것만 많은 상황은 어떻게든 피하는 것이 바람직하다. 남은 10%에 가장 복잡한 부분이 숨어 있을 수 있기 때문에, 스토리를 완전히 끝내기 전에는 속도 계산에 포함하지 말아야 한다.
계획 속도와 실제 속도
122. 누적 스토리 점수 차트(cumulative story point chart)는 각 이터레이션의 종료 시점까지 완료한 스토리 점수 총합계를 나타낸다.
이터레이션 소멸 차트
123. 진행 상황을 지켜보기 위해서는 ‘이터레이션 소멸 차트(iteration burn-down chart)’를 이용하는 것도 유용하다. 이터레이션 소멸 차트는 각 이터레이션의 종료 시점에 남아 있는 작업량을 스토리 점수로 나타낸 것이다.
124. 소멸 차트는 현재까지 완료한 스토리 점수를 통해 릴리즈의 진행 상황을 반영할 뿐만 아니라 해당 릴리즈에 남아 있는 계획된 스토리 점수의 변동 사항까지 반영해 준다는 특징을 가지고 있다. 소멸 차트는 개발 팀의 속도를 보여주지는 않지만, 프로젝트 진행 상황에 대한 종합적인 관점을 제공한다는 점에서 유용하다.
125. 애자일 소프트웨어 개발의 강점 중 하나는 프로젝트 초기에 요구사항에 대한 완전한 명세 없이도 시작할 수 있다는 점이다. 애자일 개발팀은 고객이 사전에 모든 것을 알기란 불가능하다는 점을 인정한다. 따라서 애자일 개발팀은 고객에게 아는 만큼만 알려달라고 하며, 나머지는 프로젝트가 진행되고 개발하는 소프트웨어에 대해 모두가 조금씩 더 알아가면서 고객이 의견을 추가하고 변경할 수 있도록 허용한다. 즉 스토리가 추가되거나 제외되기도 하며, 크기나 중요도가 변경되기도 한다는 것을 의미한다.
이터레이션 진행 중의 소멸 차트
126. 소멸 차트는 각 이터레이션의 종료 시점에서 프로젝트의 진행 상황을 추적하는 데 유용할 뿐 아니라, 이터레이션을 진행하는 동안에도 훌륭한 관리 도구로 사용할 수 있다. 이터레이션 진행 중에는 일일 소멸 차트(daily burndown chart)를 통해 해당 이터레이션에 남아 있는 작업량을 시간 단위의 추정치로 나타낸다.
127. 신규 작업은 현재 이터레이션에 이미 포함된 스토리를 완료하기 위해 꼭 필요하지만 계획 단계에서 누락된 것일 때에만 추가되어야 한다. 누군가 이번 이터레이션에 추가되었으면 하고 바라는 기능을 추가해서는 안 된다. 이런 유형의 변경은 다음 이터레이션에 계획에서 우선순위 결정을 통해 추가되어야 한다.
