초보 애자일 코치의 좌충우돌 코칭 경험기 - 3
Updated:
초보코치는 유저스토리를 워크샵 형태로 진행하기로 했다.
유저스토리가 무엇인지 부터 알아보기로 하자.
유저스토리란?
소프트웨어를 만들기 위한 요구사항을 어떻게 도출한 것인지는 오래 전부터 소프트웨어 공학의 관심사항 이였다. 초보코치는 일반적인 SI프로젝트에서 기존 시스템을 분석한다던가, 인터뷰를 한다던가, 컨설턴트 들이 작업한 PI 결과물 등의 문서 작업을 통해 요구사항을 문서로 작성하곤 했다.
유저스토리는 이런 것과 무엇이 다를까? 유저스토리는 정확한 정의는 없지만, 사용자 입장에서 가치 있는 기능을 서술한 것 정도로 요약할 수 있다.
기존 방식과는 다르게 문서화에 초점이 맞춰져 있는 것이 아니라, 유저스토리를 통해 고객과 대화하는 것이 주 목적이다. 그 의미는 엔지니어 또는 기술적인 것을 자세하게 적을 필요가 없다는 것이다. (그것은 고객에게 큰 가치를 주지 않는다. 고객은 결국, 그런 기술적인 것을 통해 비즈니스에 도움을 받고자 하는 것이기 때문이다.)
좋은 유저스토리를 얘기할 떄 INVEST 를 얘기한다.
- Indepedent : 독릭접
- Negotiable : 협상가능
- Valuable : 가치있는
- Estimatable : 예측가능
- Small : 작은
- Testable : 테스트가능
초보 코치는 이런 간단한 개념을 머릿속에 둔 채 경험이 풍부한 S수석의 도움을 받아 진행방식에 대해서 고민했다.
유저스토리 진행
참여자 선정 및 계획수립
시스템의 규모에 따라 참여자는 달라질 수 있다. 소규모의 프로젝트이고 고객이 팀에 같이 있으면, 회의실에 모여서 바로 진행이 가능하겠지만, 시스템이 커지고 사용자가 여러 명이라면 일정과 유저스토리 업무범위를 먼저 계획해서 진행해야 된다. 특히, 파워유저들의 참석이 중요하며, 자주 모일 수 없는 특성상 계획을 세워 미리 공유해야 된다.
역할자 식별
이제 필요한 사람이 다 모였다면, 유저스토리 워크샵을 시작해보자. 먼저, 역할자를 식별하고 정련하는 과정을 거쳐야 한다. A라는 업무가 있다면 해당 업무에서 사용자가 누가 있을지 생각하고 역할자를 최대한 단시간에 최대한 도출한다. 여기서, 이 역할자가 맞는지 안 맞는지 판단할 필요는 없다. 포스트잇 같은 것에 식별된 역할자를 작성하여 붙이고, 비슷한 역할자는 서로 모은다. 그리고 비슷한 역할자 중 가장 적절한 역할자 하나를 선택하고 나머지는 찢어 버린다. 역할자명만 가지고 판단이 힘들 때는 그 역할자를 작성한 사람이 설명을 하도록 한다.
유저스토리 맵 작성
유저스토리맵은 사용자(역할자)의 시스템 사용방법(여정)에 따라 가로로 펼쳐놓으면서 세로로는 유저스토리를 세부적으로 계층화를 하는 방법으로서 가시적이면서 누구나 이해하기 쉬워 많이 사용된다. 참여자들과 유저스토리맵을 작성하면서 우선순위를 식별하고 큰 덩어리의 유저스토리를 좀 더 구체화시킬 수 있다.
다음은 유저스토리 맵이 에픽(유저스토리를 여러개 가지고 있는 상위), 유저스토리와 어떻게 매핑되는지를 나타내는 예이다.
활동을 에픽으로, 작업은 유저스토리로 매핑 시킬 수 있으며, 각 작업 중 우선순위를 정해 릴리즈 플랜(Release Plan)에 적용할 수 있다.
다음 작업
유저스토리맵을 통해 유저스토리를 도출하여 Product Backlog 로 정리한다. 그리고 릴리즈 플랜을 세워 각 스프린트에서 개발할 유저스토리를 배치한다.
JIRA 라는 Tool 을 이용하여 작업하는 상세한 방법은 본 블로그에 있는 SK 의 Quick Guide 을 참조하도록 한다.
다음 시간에는 실제 스프린트가 시작되면 수행하는 애자일 활동 중 릴리즈 플랜과 Daily Scrum 미팅에 대해서 알아보도록 하자.
- 초보 코치의 느낌점
- 유저스토리의 경우 참여자, 특히 PO(Product Owner)의 업무 이해도에 따라 유저스토리를 통해 원하는 목표가 달라질 수도 있다. 목표가 달라질 수 있다는 의미는 무엇일까? 이것은 참여자들의 수준에 따라 결정이 될 수도 있다는 뜻이다. 사용자가 정말 오랫동안 해당 시스템 운영에 관여하여 프로세스를 자세히 알 수 있다면 단순히 유저스토리를 작성하는 것 뿐 아니라 유저스토리맵을 작성하며 업무 프로세스 개선도 논의해 볼 수 있다. 만약, 그렇지 않다면 주요 유저스토리를 뽑아내는데 집중해야 된다. 그 외 상황에 따라 유저스토리 구체화가 힘들 경우, 시스템의 주요 Pain Point 나 비기능 요건, 개선사항 정도 기대할 수 있다.
- 유저스토리 워크샵이 유저스토리 도출로만 끝나면 안 된다. 도출된 유저스토리는 고객과 지속적으로 대화하면서 구체화시켜 나가야 한다.
- 초보 코치는 유저스토리를 도출하는데 신경 쓰느라, 중요한 점을 하나 놓쳤다. 유저스토리가 있다면, 해당 유저스토리는 Test 가능해야 된다. 그러기 위해서는 유저스토리의 완료기준이 무엇인지도 같이 Product Backlog 에 기록되어야 한다.
초보 애자일 코치의 좌충우돌 코칭 경험기 - 2
초보 애자일 코치의 좌충우돌 코칭 경험기 - 3
초보 애자일 코치의 좌충우돌 코칭 경험기 - 4
초보 애자일 코치의 좌충우돌 코칭 경험기 - 5
초보 애자일 코치의 좌충우돌 코칭 경험기 - 6
< EOF >