행복한 아빠

이전에 "우리팀의 스토리 점수 산정법"이란 제목으로 스토리 점수 산정하는 기법 두 가지를 소개했습니다. 사실 많이 알려진 기법이고 유용하여, 우리팀은 이 기법들을 전파한 사람들에게 그저 감사할 따름입니다. 일이 재미있어지고 효과도 굉장하죠. 애자일을 이용하여 일하는 팀들은 한 번 해 볼만 합니다. (이미지출처) k16wire님 블로그를 보고 생각나는 것이 있어 정리합니다. 나이를 더 먹기 전 내가 일했던 추억(?)들을 남기기 위해 일하는 현장을 찍고는 합니다. (사실 다른 의도로 찍은 것도 고백합니다.) 우리팀이 델파이 기법으로 스토리 점수 산정하는 현장을 공개합니다. 0. 카드 만들기 백로그라고도 하고 사용자 스토리라고도 많이 부릅니다. 우리도 사용자 스토리라고 많이 부르기도 하지만 간단히 그냥 카드라..

사용자 스토리를 관리하는 방법이야 조직마다 다를 겁니다. 훌륭한 요구사항 관리 도구를 사용하는 조직도 있고 많은 조직은 포스트 잇으로 관리하기도 할 겁니다. 저도 다른 조직이 일하는 방법을 참조하고 싶은데 직접 그 조직이나 회사에 가서 일해보지 않는 이상 알기 어렵고 실제 일하는 현장의 자료는 찾기 어려워 우선 우리 팀이 일하는 방법을 소개해 볼까 합니다. 사용자 스토리 관리 우리팀은 사용자 스토리를 인덱스 카드로 관리합니다. 문구점에서 800원이면 한 묶음 살 수 있지요. 그래서 우리는 사용자 스토리를 스토리 카드 또는 그냥 카드라고 부르기도 합니다. 이 카드를 벽에 붙이기 어려워하고 있는데(포스트 잇이 아니라) 팀원 중 한 명이 핀으로 인덱스 카드를 쉽게 꼿고 옮길 수 있는 판때기(?)를 구해왔습니다..

Agile을 이용하면서 요구사항 관리기법을 사용자 스토리를 이용하고 있습니다. 사용자 스토리 나누는 것도 어렵지만 초기에 스토리 점수를 산정하느라고 많은 시행착오를 겪어야만 했습니다. 우리팀은 추정과 계획을 스토리 점수를 이용하여 하기에 스토리 점수가 중요한 역할을 합니다. 스토리점수 크기 보통 스토리 점수는 2의 배수(0, 2, 3, 4, 8, 16)를 사용하거나 피보나치 수열(1,2,3,5,8,13)을 사용하는데 우리는 피보나치 수열을 사용합니다. 2의 배수는 스토리 점수간 간극이 너무 차이가 나서 피보나치 수열을 사용하지만 어짜피 큰 스토리의 경우 편차가 심하기에 2의 배수를 사용해도 괜찮을 듯 합니다. 우리팀의 스토리 점수 산정 기준은 5점을 보통 크기의 기능으로 산정하고 그보다 큰지 작은지를 판..

사용자 요구사항을 분석하고 관리하는 방법은 참 까다롭다. SI 프로젝트를 진행할 때면 프로젝트에서 요구하는 프로세스가 CBD나 UP이기에 유스케이스를 주로 사용하지만 회사 내부 프로젝트에서는 사용자 스토리 기법을 사용한다. 계속 사용하는 요구사항 관리 기법이기는 했는데 아직 사용자 스토리 책을 읽어보지 않아 한번 보고 내가 사용하는 방법이 잘 되어가는 건지 점검하기 위해 읽어보았다. 사용자 스토리의 작성 방법은 매우 간단하다. 고객의 입장에서 가치있는 기능을 작은 인덱스 카드에 최소한의 정보만 기록하여 관리하는 것이다. 이렇게 간단하게 관리하여 프로젝트가 제대로 진행될지 의심스러울 것이다. 물론 이 인덱스 카드 한장만으로 설계나 구현은 불가능하다. 이게 사용자 스토리가 가지는 강력한 힘이다. 무슨 말인고..