사용자 스토리
애자일의 광풍이 휘몰아치고 있습니다. 개인적으로는 소프트웨어 공학의 거품
걷어내기를 환영하는 바이지만, 애자일 방법론에 대해서 약간은 회의적인
시각으로 바라볼 필요가 있다고 생각합니다. 애자일의 부정적인 측면에
대해서는 다음 기회에 따져보기로 합시다. 애자일 운동을 통해 얻은 가장 큰
소득은 반복적이고 점진적인 접근법, 테스트 주도형 개발, 리팩터링의
재발견과 이에 대한 동의의 확산(특히 비 개발자 영역으로의 확산?) 이라고
생각합니다. 하지만 모든 "...주의"에는 포장 바꾸기가 은근슬쩍 끼어들
여지가 있습니다. "사용자 스토리" 는 프로젝트의 요구사항에 대한
애자일적인 접근법이라고 주장합니다. 하지만 들여다보면 어디서 많이 보던
내용입니다. "유스 케이스"와 뭐가 다른 거야? 이를 의식한 듯 저자는 "유스
케이스" 와의 차이를 구구절절 설명합니다. 하지만 "유스 케이스"가 꼭
그래야만 한다고 누가 주장하는 건데? 코번의 "유스케이스 바로 쓰기" 를
보시고 비교해 보세요. 저자의 주장은 이렇게 볼 수 있습니다. 요구사항
수집과 분석에 힘 빼지 말고 유스케이스를 형식 없이 대충 쓰자. 틀린 말은
아닙니다만 포장이 과합니다. 하지만 특별히 "유스 케이스"를 사용하고 있지
않으신 분들은 이 책으로 시작하셔도 크게 나쁠 것 같지는 않습니다. JIRA
이슈 등록의 가이드라인으로 활용하신다면 딱 좋을 듯 싶습니다. 또 하나 이
책에는 플래닝에 대한 내용이 조금 들어있습니다. 역시 출발점으로 삼기에
그리 나쁘지는 않아 보입니다. 관련 포스트:
마이크 콘 지음, 한주영 외 옮김/인사이트