애자일 소프트웨어 개발 방법론을 사용할 때, User Story를 사용해서 대부분의 요구사항을 수집합니다. User Story는 "의사소통 대상과 대상별 요구사항“의 간결한 형태와 수락기준으로 구성됩니다. User Story는 간결하지만 잘 작성하는 것이 무척 어려운 작업입니다. User Story 작성 시 흔히 범하는 5가지를 실수를 검토해봄으로써 올바른 User Story 작성법을 살펴보도록 합니다.
[5 가지 흔한 실수들]
1. 단일 사용자를 위한 User Story
- 예 : “ 사용자로써 나는 광고를 관리할 수 있기 원한다 . 왜냐하면 기한이 만료되고 실수가 있는 광고를 제거할 수 있기 때문이다 .”
- 언뜻 보면 모든 요소가 있어서 User Story 로 별 문제가 없어 보임
- 특색에 맞게 사용자를 살펴보면 광고관리를 이해하고 수행하는 사용자는 광고 조정을 하는 포탈 관리자나 모든 광고 목록을 가지고 상황에 따라 광고들을 교체하는 광고주들을 뜻함
- 페르소나나 역할을 놓치고 있음
2. 제품 소유자를 위한 User Story
- 예 : “ 제품의 소유자로써 나는 광고를 지울 수 있는 시스템을 원한다 . 왜나하면 사용자들이 광고를 지울 수 있기 때문이다 .”
- 모든 요소들이 있지만 뭔가 어색함
- ‘ 당신이 무엇을 원한다 . 당신은 그것을 가지고 있다 ’ 는 형식으로 User Story 를 쓰는 사람이 단지 하고 싶은 행위에 초점을 두고 있으며 , 사용자 기대에 대한 단서를 주는 역할이나 페르소나가 없음
3. 개발자를 위한 User Story
- 예 : “ 개발자로써 나는 폴더 위젯을 재배치하기를 원한다 . 왜냐하면 나는 폴더 위젯을 유지하고 싶기 때문이다 .”
- 기술적인 백로그 (Technical backlog) 나 기술적인 요구사항의 대표하는 예임
- 이와 같은 User Story 는 기술적 채무 (Technical Debt) 으로도 불리며 , 기술적 채무는 소프트웨어 업데이트 , 리팩토링 (Refactoring), 프레임웍의 교체와 같은 유지보수 관련 필수적인 일을 포함함
- 고객을 위한 가치를 대변하지는 않고 , 애자일 관점에서 매 주기의 마지막에 비즈니스적 가치를 수반해함
- 역할에 페르소나를 붙여 사용자관점에서 기술하는 예로 ‘ 상업적인 사용자로서 나는 동시에 여러 검색을 할 수 있는 시스템을 원한다 . 왜냐하면 나는 일을 좀 더 빨리 하고 싶기 때문이다 .’ 를 둘 수 있음
- 수락기준들은 향상을 측정 가능하고 테스트 가능하도록 정의해야 함
- 예 : ‘ 한 사용자가 동시에 5 가지 검색을 할 수 있음 ’
4. 고객을 위한 비즈니스 가치나 혜택이 없음
- 예 : “ 상업 광고주로써 나는 필터링 옵션을 원한다 ”
- 역할도 있고 니즈도 있지만 이유와 비즈니스 가치가 없음
5. 수락기준이나 만족조건이 없음
- 수락기준이 없는 것은 개발업무를 잘못 정의하거나 잘못된 평가로 시작해서 전체를 오류덩어리로 만들 수 있음
- 이해부족으로 Story 가 테스트를 통과하지 못할 수도 있고 Test Case 가 다른 기준들을 적용할 수도 있음
- 수락기준은 요구사항을 명확하게 이해하고 주기별 결과물을 받아들일지는 결정하는 중요한 역할을 함
- 수락기준을 만드는 좋은 방법은 '~ 한다면 어떻게 될까 ?(What if ... ?)', ' 어디서 (Where) ...?', ' 언제 (When) ... ?', ' 어떻게 (How) ... ?' 와 같은 질문을 해보는 것임
- 예제들을 사용해서 가정들을 제거해서 간결하게 만들어보면 Story 가 세련되어지고 재구성되고 좀 더 작은 Story 로 나뉘어질 것임
댓글 없음 :
댓글 쓰기