최근 OOA&D를 읽고 유스케이스 작성에 관심을 갖게 되었다.
그와 유사하게 사용자 요구사항을 관리하는 기법 중에는 '사용자 스토리'라는 것도 있다.
이 둘의 차이점이 뭔지 정확히 인지하고 있지 못한터라 주말동안 '사용자 스토리'라는 책을 읽어봤다.
내용이 난해하지 않아 책은 술술 넘어가는 편이였다.
사용자 스토리는 유스케이스에 비해 몇몇 장점이 있는 듯 하다.
유스케이스는 해당 프로세스에 대한 정확한 흐름을 기술해야 했다.
즉, HF OOA&D에 예시로 나와있는 강아지문 만들기에서는..
외부접근자(강아지)가 접근을 시작한 시점부터 프로세스를 끝낼때까지의 전체적인 흐름을 순서대로 나열했어야 했다. 이 경우 모든 예외사항을 예상하고 서술해야 하는 부담감이 있다.
하지만 사용자스토리는 좀 달랐다.
처음부터 완벽한 것을 요구하지 않는다.
완벽한 요구사항 대신 훨씬 가치있다고 여기는 적절한 스토리와 그 스토리를 통해서 '대화'를 이끌어 내는 것이 목적이다.
이점은 '모든 요구사항을 처음부터 식별해 낼 수 없다'는 점에서 적절한 접근방법인 것 같다.
유스케이스도 필수적인 내용만을 쓰거나 (사용사 스토리에선 이것을 essential use case라고 표현한 것 같다), 점진적으로 내용을 상세화 시켜갈 수 있겠지만 사용자 스토리에 비해선 작성하는데 부담감이 있는 것 같다.
실제로 써봐야 이 두가지 방법 사이의 장단점을 확실히 감잡을 수 있겠지만..
각각의 장점을 취한다면 괜찮은 조합이 될 것 같다.
- 고객의 요구사항 수집 단계에서는 '사용자 스토리'를 사용하여 빠르게 진척시키고, 이를 통해 작업을 추정해본다.
- 이렇게 모아진 스토리에 우선순위를 매기고, 이터레이션(반복작업의 주기, 1week로 할 예정)에서 감당할 수 있는 스토리들을 선정해서 작업리스트를 만든다.
- 각 이터레이션에 작업들이 배정되면 세부사항을 논의한다. 이때 스토리카드 뒷장에 테스트를 써 넣거나 주석을 달수도 있겠지만, 유스케이스를 써보도록 한다.
이유는, 사용자스토리는 작업간의 관계를 표현하는데는 한계가 있는 듯하다. (종이 한장씩 따로 존재하므로..) 유스케이스를 사용해 작업내용을 구체화 시키는게 이 단계에선 더 유용해 보인다.
(일단 실험적으로라도 해보자!)
- 하나의 이터레이션이 끝나면, 이터레이션 동안 완료된 스토리 / 추정치 변경 / 추가된 스토리 등의 점수를 합산하여 프로젝트에 대한 소멸차트를 그려보는게 좋을 것 같다.
작업 진척 상황을 추적하는데 아주 유용할 것 같다.
책을 통해서 '사용자 스토리'가 무엇인지에 대해선 대략 감을 잡을 수 있었다.
하지만 가장 중요한건 '써먹어 보는것' 같다.
팀원들간의 공감대가 형성되지 않으면 이런 작업을 실행해 보는 것은 어려울 수밖에 없다.
다행히 팀원들이 XP에 대한 이해가 있고 의욕도 있어 책을 통해 얻은 지식이 실제 행동으로 옮겨질 수 있을 것 같다.
지행일치.. 시도해보자!
댓글