인사이트 출판에서 agile 이라는 시리즈의 책 중 하나인 사용자스토리다. 애자일프로젝트 관리를 찾게 되면, 생소한 용어들을 만나게 된다. 예전의 개발용어로는 요구사항정의라 부르는 것을 사용자스토리로 표현되는 것이라 보면 될 듯 하다.
애자일방법론을 채택하게 되면 그 아래 사용되는 기법은 여러가지를 혼용 또는 선택하여 사용할 수 있을 것이다.
혹자는 애자일 방법론으로 XP를 얘기하기도 하고, 스크럼을 이야기 하기도 한다.
또는 어떤이는 칸반을 채택했다고도 한다.
이곳저것 읽은 것들을 조합해보면 딱 그거로 대체된다라 할 수는 없지만, 내포하고 있는 의미들이 비슷한 것끼리 묶어 보았다. 나는 XP를 주로 활용하고, 여기에 칸반을 더하여 운영해보고 있는 중이다.
이전에 요구사항정의라는 것을 XP에서는 사용자스토리 스크럼에서는 스프린트백로그로 볼 수 있을 것 같다.
물론 위의 저 "사용자스토리"라는 책 내용을 읽어 보면 문서로 정의되는 요구사항정의라는 부분이 얼마나 많은 왜곡이 있을지에 대한 이야기 하고 있으며, 이를 개선하기 위해 개발자, 고객, 사용자는 대화를 자주 나누어야 한다고 한다. 사용자 스토리는 이러한 대화를 나누기 위해 대화의 주제가 되기도 하며, 업무의 양, 업무의 난이도, 업무에 소요되는 시간을 추정하는 기초정보가 되기도 하고, 인수 테스트조건의 기준정보가 되기도 한다.
"아래에는[사용자스토리 - 마이크 콘 지음 / 인사이트 ]읽은 내용을 간략히 요약 정리하여, 재참고하고자 한다. 현재 사용자스토리라는 이름을 쓰고 있기는 하지만, 상황에 맞게 쓰다보니, 이 책에서 이야기 하고 있는 것에 많이 벗어나 있는 것 같다. "
1부 시작하기
"우리는 멋진 장문의 요구사항 문서를 작성할 만한 시간이 없었기 때문에, 고객과 직접 이야기를 나누면서 일하는 방식을 취하기로 했다. "
"요구사항을 표현하는 수단으로, 말은 (특히 문서로 작성되었을 때에는) 매우 부족한 매개체다. 잘못 해석할 가능성을 극복하기 위해 개발자, 고객, 사용자는 대화를 자주 나누어야 한다."
{나의 현실}
요구사항문서, 화면기획서등 웹개발을 하면서 수 많은 삽질을 통해 작업을 하지만, 읽는 사람들마다 다르게 해석할 뿐만 아니라 마지막에 결과물을 확인할 때쯤에는 많은 부분이 변형/누락되어 있음 확인하게 된다. 그래서, 이 방법을 쓰면 조금 나을까 하였는데, 기존 기획서에 익숙한 이들에게 사용자스토리라고 내밀었을 때 이를 통해 그림을 그릴 수 없다는 피드백으로 인하여 결국 화면기획서라는 문서삽질은 여전히 되고 있다. 다만, 이전과 달리 기획서를 전달한 후 각자 해석하여 진행하지 않고, 이 내용으로 각자가 정확히 이해하고 있는지 대화하는 시간을 많이 가지게 된 점은 이전과 달라진 점이다. 또한, 사용자스토리별로 업무의 양, 난이도, 추정을 통해 버전관리가 좀 더 용이해진 점도 있다. 좀 더 익숙해지면 간소한 사용자스토리로 보다 스피드하게 업무의 범위를 산정할 수 있기를 기대해본다.
사용자스토리의 구성
서술(written description) : 스토리는 서술 형태로 기록되며, 계획하거나 기억하기 위한 단서로 사용된다.
대화(conversation) : 스토리는 대화를 통해 세부사항을 구체화한다.
테스트(test) : 스토리는 테스트를 통해 세부사항을 문서화하고 전달하며, 스토리의 완료여부를 판단한다.
* 사용자 스토리는 사용자에게 가치를 평가 받을 수 있도록 기능을 표현해야 한다.
* 인덱스 카드에 쓰일 수 있을만큼의 길이가 적당하다.
* 세부사항은 추가 스토리로 작성한다.
고객팀의 구성
테스터, 제품관리자, 실제 사용자, 상호작용 설계자가 모두 포함된다.
프로세스의 형태
폭포수개발방법론의 경우 요구사항작성-분석-설계-구현-테스트가 하나의 주기로 고객은 요구사항작성에만 참여하지만 애자일개발방법론의 경우 스토리주도(story-driven)프로젝트로 시작에서 끝까지 함께 참여하여 만들어나가며 사용자스토리 - 대화 - 구현 - 발표/배포의 주기를 짧게 자주 가지게 된다.
릴리즈와 이터레이션 계획하기
이터레이션 주기에 진행할 스토리를 선택하는 것
즉, 이터레이션 주기가 1주일이라면 1주일에 완성할 수 있는 팀의 속도에 맞춰
스토리 수를 정하고, 어떤 스토리를 선택할지 우선순위를 정하는 것이라 할 수 있다.
* 우선순위를 부여할 때 고려할 사항
사용자나 고객 다수가 원하는 기능인가?
다수는 아니지만 중요한 사용자나 고객이 바라는 기능인가?
이 스토리가 다른 스토리들과 응집성이 있는가?
인수테스트
스토리를 개발 한 뒤 그것이 고객이 기대하는 대로 정확히 동작하는지를 입증하는 과정으로
이터레이션이 시작되면 개발자는 코드를 작성하고, 고객 팀은 테스트를 작성한다.
사용자스토리의 특성
사용자 스토리는 문서보다 구두 의사소통을 강조한다.
사용자 스토리는 고객이나 개발자 모두 이해할 수 있다.
사용자 스토리는 계획 수립에 적당한 크기다.
사용자 스토리는 반복적 개발(iterative development)에 효과적으로 사용된다.
사용자 스토리는 무엇이 필요한지 잘 알때까지 세부사항을 뒤로 미룰 수 있게 해준다.
스토리 작성하기
독립적이다.(Independent)
협상가능하다.(Negotiable)
사용자 및 고객에게 가치가 있다.(Valuable)
추정가능하다.(Estimatable)
작다(Small)
테스트가능하다.(Testable)
INVEST - 좋은 스토리를 작성하는 여섯가지 특징
사용자 역할 모델링
사용자역할목록 초안을 위한 브레인스토밍
목록초안 조직화
역할통합하기
역할다듬기
스토리 수집하기
사용자인터뷰
설문
관찰
스토리작성워크샵
대리 사용자와 일하기
사용자 스토리 인수 테스트
코딩하기 전에 테스트부터 작성하기
고객이 테스트를 명시한다.
테스트의 수행은 프로세스의 일부다.
좋은 스토리를 위한 지침
목적 스토리로 시작하라
케이크 자르듯 나누어라
닫힌 스토리를 작성하라
제약사항 기록하기
스토리의 크기는 시간축에 맞추어라
되도록 사용자 인터페이스를 배제하라
스토리가 아닌 것들
스토리에 사용자 역할을 포함하라
한 명의 사용자를 대상으로 작성하라
능동태로 작성하라
고객이 작성하라
스토리 카드에 번호를 부여하지 말라
목적을 잊지 말라
아래는 다음 글에 계속...
'Agile 애자일' 카테고리의 다른 글
| 애자일 팀 그리고 그 구성원의 역할 (0) | 2020.10.07 |
|---|---|
| #4 고객중심의요구사항기법 - 사용자스토리 : 사용자역할에서 인수테스트까지 (0) | 2020.08.23 |
| #3 고객중심의요구사항기법 - 사용자스토리 : 자주 논의하는 주제 (0) | 2020.08.06 |
| #2 고객 중심의 요구사항 기법 - 사용자스토리: 추정과 계획하기 (0) | 2020.08.05 |
| 애자일 프로젝트 관리 - 개요와 적용경험 (0) | 2020.06.27 |