PM 추천 도서 - 사용자 스토리 (2)

지난 포스팅에서 '사용자 스토리(User Stories)'의 절반을 정리해보았는데요. 남은 절반을 이번 주말에.. 이렇게 또 정리해봅니다. 열심히 또 영차영차해야죠. 요즘 영차영차가 유행이라 저도 한 번 해봤습니다. 확실히 '기본'이라고 할 수 있는 사용자 스토리 책을 다시 보면서 정리해보니 스스로를 돌아보면서 반성하는데 아주 도움이 되네요. 큭

 

프로덕트 매니저/스크럼 마스터로서 지라(JIRA)를 활용하기 전에 꼭 읽어야 할 책 - 사용자 스토리(User Stories)

 

 

3부 자주 논의하는 주제

12장 스토리가 아닌 것

 

 

잘못될 징조

 

요구사항 명세서가 소프트웨어 개발 그룹과 다른 그룹(마케팅 그룹 혹은 제품 관리 그룹) 사이를 왔다갔다 한다면, 그것은 프로젝트가 잘못된 방향으로 진행되고 있다는 징조다.
(중략)
여러 그룹이 결국은 같은 문서를 다른 형태로 작성하고 있는 것을 자주 보게 된다. 그들은 나중에 비난 받을 것에 대비하여 무언가 준비해 놓고 있는 것일뿐이다. 사용자 스토리에서는 이렇게 어리석은 일이 발생하지 않는다. 문서보다 대화를 더 중요시 한다는 것은 어떤 것도 최종적인 것은 없다는 것을 의미한다. 문서는 계약서인 듯 보여서 최종적인 것처럼 느껴진다. 그러나 대화는 다르다. 우리는 오늘 대화를 하고 나중에 무언가를 배우고 나서 또 다시 대화한다.

 

 

아... 역시 또 반성하게 되네요. 특히 나중에 비난 받을 것에 대비하여 무언가 준비해 놓고 있다는 문구를 읽고 스스로를 많이 돌아보게 되었습니다. 진짜로 좋은 프로덕트를 만드는데 집중한 것인지 아니면 단순히 일하고 있다는 것을 보여주기 위해서 산출물을 만들진 않았는지 돌이켜 봐야겠어요. 흑.

 

 

사용자 스토리는 유스케이스가 아니다

 

사용자 스토리와 유스케이스는 그 완결성에도 차이가 있다. 제임스 그레닝(James Grenning)은 "스토리 카드에 인수 테스트를 더하면 기본적으로 유스케이스와 동일하다'고 언급한 바 있다. 그는 사용자 스토리가 유스케이스의 주 성공 시나리오에 대응되고, 그 사용자 스토리에 대한 테스트들이 유스 케이스의 확장 부분에 해당한다고 말한다.
(중략)
유스케이스와 사용자 스토리의 또 다른 중요한 차이점은 그 수명(longevity)에 있다. 유스케이스는 개발 기간이나 유지보수 기간에 계속 사용된다. 반면 사용자 스토리는 그것을 개발한 이터레이션이 지나서까지 계속 사용하도록 만들어진 것이 아니다. 많은 팀이 스토리 카드를 보간하지 않고 간단히 없애 버린다.

 

 

앞으로는 저도 이렇게 시도해보려고 합니다. 스스로도 사용자 스토리와 유스케이스 / 사용자 시나리오를 혼용해서 사용하고 있었는데요. 이번 기회에 조금 더 정확하게 사용해봐야겠네요. ㅠㅠ

 

 

13장 왜 사용자 스토리인가?

 

 

사용자 스토리는 구두 의사소통을 강조한다.
사용자 스토리는 모든 사람이 이해할 수 있다.
사용자 스토리는 계획 수립에 적합한 크기다.
사용자 스토리는 반복적 개발에 효과적이다.
사용자 스토리는 세부사항을 나중에 고려할 수 있게 한다.
사용자 스토리는 기회주의적 설계를 지원한다.
사용자 스토리는 참여적 설계를 유도한다.
사용자 스토리는 암묵적 지식을 구축한다.

 

 

구두 의사소통

 

사용자 스토리를 사용하는 목적은 우리가 바라는 기능들의 모든 세부사항까지 문서로 자세히 기록하자는 것이 아니다. 오히려 나중에 개발자와 고객이 대화를 이어갈 수 있을 정도의 내용을 담은 짧은 문장들을 기록하자는 것이다.
(중략)
그리고 비록 요구사항 문서에 쓰여있는 각 문장이 완벽하더라도 여전히 두 가지 문제가 존재한다. 첫째, 사용자는 소프트웨어가 개발됨에 따라 더 많은 것을 배우게 되고, 자신이 원하는 것을 더 구체적으로 알게 된다. 둘째, 각 부분의 완벽함이 전체의 완벽함을 보장하지 않는다. 톰 파펜딕은 완벽하게 제작된 왼쪽 신발 100개가 있더라도 그것이 완벽한 신발 한 켤레가 될 수는 없다고 하였다. 따라서 완벽한 요구사항보다 훨씬 가치 있는 것은 '적절한 스토리'와 '잦은 대화'를 병행하는 것이다.

 

 

이번 사용자 스토리를 읽고 가장 많이 생각하게 된 부분이 "구두 의사소통" 부분입니다. 약간 고백하자면 "구두 의사소통"이 약하다는 피드백을 종종 받은 적이 있었는데요. 개인적으로 구두 의사소통보다 글로 업무하는 것을 더 효율적이라는 믿음이 제 마음속 한 켠에 있어서 쉽게 잘 안 변했던 부분이었던 것 같아요. 그런데 이번 기회에 변화하기로 마음을 먹었습니다. 마음 속에 새겼습니다.

 

 

완벽한 요구사항보다 훨씬 가치 있는 것은 '적절한 스토리'와 '잦은 대화'를 병행하는 것

 

 

사용자 스토리는 반복적 개발에 효과적이다

 

예를 들어 어떤 프로젝트를 시작했다고 하자. 나는 제일 먼저 '사용자는 이메일을 작성, 전송할 수 있다'와 같은 에픽을 작성한다. 이 스토리는 초기 계획 단계에 적절하게 쓰일 수 있다. 나중에 이 스토리를 다음과 같이 여러 개의 스토리로 나눈다.

- 사용자는 이메일 메시지를 작성할 수 있다.
- 사용자는 이메일 메시지에 그림을 포함할 수 있다.
- 사용자는 이메일 메시지를 전송할 수 있다.
- 사용자는 이메일을 특정 시간에 전송하도록 예약할 수 있다.

 

 

에픽과 스토리은 결국 크기의 차이인 것 같습니다. 이러한 정의 활용하면 지라(JIRA) 같은 관리 도구를 사용할 때 확실히 정리정돈이 잘 되는 것 같아요.

 

스토리는 기회주의적 개발을 지원한다

 

약 20년 전 파나스와 클레멘츠(Parnas and Clements 1986)는 이러한 형태로 진행되는 프로젝트를 절대 볼수 없을 것이라고 말했다. 그들은 다음과 같은 이유를 제시하였다.

- 일반적으로 사용자와 고객은 자신이 원하는 것을 정확히 알지 못한다.
- 소프트웨어 개발자가 모든 요구사항을 파악했더라도, 그 소프트웨어를 개발하기 위해 필요한 많은 세부사항은 시스템을 개발하면서 비로소 명확해진다.
- 모든 세부사항을 미리 알 수 있다 해도 인간인 이상 그 모든 것을 이해하기는 힘들다.
- 우리가 모든 것을 이해할 수 있더라도 제품이나 프로젝트에는 변경 사항이 발생하기 마련이다.
- 사람은 실수를 한다.

 

 

왜 스토리를 택하지 않나? 와 요약

 

(중략)
스토리를 사용해야 하는 이유는 많지만, 몇 가지 단점도 있다. 대규모 프로젝트에서는 수백 수천 개의 스토리를 구조화하기 힘들다. 요구사항 추적성을 위해 추가로 문서를 작성해야 할지도 모른다. 또한 스토리는 직접 대화를 통해 암묵적 지식을 구축할 수 있지만, 대규모 프로젝트에서는 대화만으로 문서를 완전히 대체할 수 없다.

 

 

14장 스토리 냄새 카탈로그

 

내용이 무엇인가 봤더니 사용자 스토리를 사용할 때 나타나는 "나쁜 냄새(bad smell)' 들의 카탈로그였습니다. 이 부분이 개인적으로는 많이 유용했는데요. 그 이유는 저도 처음에 많이 겪었던 부분이라서 많이 공감이 됩니다. 사용자 스토리를 활용하다 보면 많이 부딪히는 문제들인데 미리 알고 있으면 큰 도움이 되겠죠? 여기는 큰 유형만 살펴보겠습니다.

 

예) 나쁜 냄새: 증상

- 너무 작은 스토리: 추정치를 빈번히 조정해야 함.
- 상호 의존적인 스토리: 스토리들 간의 의존성 때문에 이터레이션을 계획하기가 어려움.
- 금도금: 개발자들이 이터레이션 계획에 포함되지 않은 기능을 추가하거나 마음대로 해석하여 그 스토리를 구현하는데 필요한 것 이상의 작업을 하고 있다.
- 너무 상세한 스토리: 스토리 구현에 앞서 세부사항들을 모으는 데 시간을 과도하게 소비한다. 또는 스토리에 대해 이야기 나누는 것보다 스토리를 작성하는 데 시간을 더 많이 소비한다.
- 사용자 인터페이스와 관련된 세부사항을 너무 일찍 포함시키기: 프로젝트(특히 신제품 개발 프로젝트) 초기에 작성된 스토리들이 사용자 인터페이스와 관련된 세부사항들을 포함한다.
- 너무 앞서 생각하기: 이 냄새는 여러 가지 증상으로 확인할 수 있다. 스토리들을 인덱스 카드에 기록하기 어렵다거나, 팀의 규모나 위치 조건 때문에 어쩔 수 없는 경우가 아닌데도 인덱스 카드보다 소프트웨어를 활용하려고 한다거나, 누군가가 세부사항들까지 잡아내기 위한 스토리 템플릿을 제안한다거나, 더 상세한 (예를 들어 일 단위 대신 시간 단위의) 추정치를 부여할 것을 제안하는 등의 증상이 있다.
- 스토리를 너무 많이 나누기: 이터레이션을 계획할 때 작업량을 맞추기 위해 스토리를 나누는 경우가 많다.
- 고객이 우선순위 부여를 어려워 함: 스토리를 선택하고 우선순위를 부여하는 일은 어렵다. 때로는 스토리에 우선순위를 부여하는 것이 너무나 어려워 거기서 냄새가 날 수도 있다.
- 고객이 스토리를 작성하거나 우선순위를 부여하지 않으려고 함: 고객이 스토리를 작성하고 거기에 우선순위를 부여하는 책임을 지지 않으려고 한다.

 

 

15장 스크럼에서 사용자 스토리 사용하기

 

애자일(Agile)하게 소프트웨어를 개발하는 팀이라면 요즘(2020년 즈음) 가장 많이 사용하는 방법이 스크럼 방법론일 것 같은데요. 그렇다면 15장을 꼭 살펴봐야 합니다. 스크럼에서 사용자 스토리를 어떻게 활용하고 있는지 설명해주는 부분입니다.

 

스크럼은 반복적이고 점진적이다

 

반복적(iterative) 프로세스는 계속적인 정련 작업을 통해 진행되는 프로세르를 의미한다. (중략) 검색 화면을 코딩하는 것을 예로 들면, 첫 이터레이션에서는 검색 화면에서 간단한 검색 기능만을 지원하도록 코딩한다. 두 번째 이터레이션에서는 부가 검색 조건들을 지원한다. 세 번째 이터레이션에서 마지막으로 에러 처리 부분을 추가하는 식이다.

점진적(incremental) 프로세스는 소프트웨어를 여러 부분으로 나누어 각 부분을 개별적으로 개발하고 전달하는 프로세스를 의미한다. 증가분(increment)에 해당하는 각 부분은 그 자체로 온전한 기능을 수행한다.

 

 

스크럼의 기본

 

과거에 학습하면서 정리해놓은 글이 있는데 참고하시면 좋을 것 같아요. 애자일(Agile)과 스크럼(Scrum)과 지라(JIRA) 이야기

 

스크럼 프로젝트는 스프린트(Sprint)라 불리는 30일 단위의 이터레이션을 통해 진행된다. 각 스프린트를 시작할 때, 스크럼 팀은 그 스프린트 동안 수행할 작업량을 결정한다. 수행할 작업들은 제품 백로그(product backlog)라 불리는 우선순위가 매겨진 목록에서 선택한다. 스크럼 팀이 해당 스프린트 동안 완료하기 위해 선택한 작업들은 제품 백로그에서 스프린트 백로그(sprint backlog)라는 목록으로 옮겨진다. 매일 열리는 일일 스크럼 회의(daily scrum meeting)에서 현재 진행 상황을 파악하고 대처할 수 있도록 한다.

 

 

제품 백로그

 

제품 백로그는 제품에 필요한 모든 기능을 담은 주 목록이다.

 

 

스프린트 계획 회의

 

스프린트 계획 회의(Sprint planning meeting)은 스프린트를 시작할 때마다 열린다. (중략) 팀원들과 제품 소유자는 함께 스프린트 목표(sprint goal)를 정의한다. 스프린트 목표는 해당 스프린트 동안 팀이 이루고자 하는 것을 간략히 기술한 것이다. 스프린트 종료 시점에 하는 스프린트 검토 회의(sprint review meeting)에서 해당 스프린트의 성공 여부는 제품 백로그의 개별 항목들을 구현했는지 여부가 아니라 스프린트 목표를 달성했는지에 따라 평가된다.

 

 

스프린트 검토 회의

 

각 스프린트에서는 잠재적으로 출시 가능한 형태의 증가분을 제품 소유자에게 인도해야 한다. 즉 스크럼 팀은 한 달간의 스프린트를 마쳤을 때 소프트웨어의 일부분이기는 하지만 테스트까지 모두 마친, 사용 가능한 형태를 완성해야 한다. 잠재적으로 출시 가능한 형태란, 이렇게 만들어진 소프트웨어가 새 버전으로 출시 및 배포하는 데 드는 노력을 감수할 만큼 충분한 기능을 포함한다면, 기꺼이 고객(혹은 내부 고객)에게 출시할 수도 있음을 의미한다.

 

 

일일 스크럼 회의

 

아마 스크럼이 짧은 일일 회의를 하도록 문서화한 최초의 프로세스일 것이다(Beedle 1999). 스크럼에서는 이 회의를 '일일 스크럼(daily scrum)'이라 부른다.

1. 어제 무엇을 했는가?
2. 오늘 무엇을 할 것인가?
3. 장애요소는 무엇인가?

(중략)
일일 스크럼은 가능하면 위 질문들만으로 진행되어야 하며, 시스템 일부분에 대한 설계나 제기된 문제 해결을 시도하면 안 된다. 그러한 사항드른 어딘가에 적어 두었다가 회의가 끝난 뒤에 해결하도록 한다. 쟁점사항 해결을 위해 나중에 모일 팀원들을 정하는 것은 괜찮지만 회의 중에 문제를 해결하려 해서는 안 된다.

 

 

스크럼에 스토리 추가하기

 

나(글쓴이)는 스크럼의 백로그 항목들을 사용자 스토리의 형태로 작성하여 큰 효과를 보았다(Cohn 2003). 일반적인 스크럼에서 제품 백로그에 새로운 기능, 논의해야 할 쟁점사항, 고쳐야 할 결함 등 다양한 사항을 넣을 수 있는 것과 달리 오직 사용자 스토리만을 넣도록 제한하였다. 제품 백로그의 각 스토리는 사용자나 제품 소유자에게 가치 있는 내용을 기술해야만 한다.

제품 백록그에 사용자 스토리만을 넣도록 제한함으로써 제품 소유자가 우선순위를 부여하는 것이 훨씬 쉬워진다. 사용자 스토리로 작성된 백로그 항목들은 제품 소유자가 이해할 수 있는 용어로 기술되어 있으므로 제품 소유자가 기능 간 우선순위를 비교하는 것이 더 쉬워진다.

 

 

16장 그 밖의 주제

 

비기능 요구사항 처리하기

 

모든 것을 스토리 형태로 표현해야 한다는 강박관념은 사용자 스토리를 사용하는 데 장애물이 될 수 있다. 프로젝트를 진행하다 보면 적어도 몇 가지 요구사항은 스토리로 표현하기가 어렵다는 것을 느끼게 된다. 흔히 이러한 요구사항들은 시스템의 비기능 요구사항인 경우가 많다. (중략)
비기능 요구사항들은 시스템의 동작 방식에 제약을 가하는 경우가 많다. 예를 들어 '시스템은 Java로 작성되어야 한다.'는 요구사항은 프로젝트에 흔히 포함되는 요구사항이다. 이 요구사항은 분명히 시스템 설계 전반에 영향을 주는 제약사항이다. 7장 「좋은 스토리를 위한 지침」에서 논의하였듯이,제약사항은 그 내용을 카드에 기록하고 '제약사항'이라고 표시해 두는 것이 좋다.

 

 

버그 스토리

 

자주 제기되는 질문 중 하나는 스토리와 버그 리포트 사이의 관계에 대한 것이다. 경험에 비추어볼 때 각 버그 리포트를 하나의 스토리로 간주하는 것이 가장 좋다. 버그 수정이 보통의 스토리 하나를 구현하는 것과 비슷한 시간이 걸린다면 버그를 다른 스토리와 마찬가지로 취급할 수 있다. 다만 쉽게 수정할 수 있는 버그는 몇 개씩 묶어서 스토리로 취급한다.

 

 

4부 예제

4부 예제는 가상의 프로덕트팀이 사용자 스토리의 내용을 실행하는 이야기가 담겨져 있는데요. 이 내용이 진짜 굉장히 유용합니다. 이론적으로만 알고 있는 것과 실제 실행하는 것 사이에 발생하는 갭을 극복하는데 큰 도움이 되는 것 같아요. 예제의 내용도 실제 소프트웨어 개발팀에게 일어나는 상황을 진짜 자연스럽게 소개하고 있습니다.

 

 

와... 이렇게 사용자 스토리(User Story)를 한 번 정리했네요. ㅠㅠ 내용을 알고는 있지만 실행하는 것이 생각보다 쉽지는 않은데요. 음... 계속 실행만 하다보니 같은 실수를 반복하는 것 같아서 다시 책을 보니 역시나 제가 아직 부족한 점이 많다는 것을 깨닫게 되었네요. 실행하지 않은 상태에서 책을 읽었을 때와 이번에 다시 읽었을 때는 확실히 큰 차이가 있는 것 같습니다. 이론과 실행이 항상 함께 하는 것이 좋을 것 같다는 생각이 계속 드네요. ㅎㅎ 영차영차 해야죠.

 

조만간 다른 책들도 한 번 깊게 정리해봐야겠네요. 후덜덜