사용자 스토리는 시작과 끝이 존재하고 다른 사용자 스토리와 겹치지 않도록 개발된다면 위 세가지 문제를 해결할 수 있다. 개발자와 고객은 사용자 스토리를 통해 업무 프로세스를 얘기할 수 있고, 사용자 스토리 단위로 개발을 마치기 때문에 요구사항이 변경되어도 다른 사용자 스토리에 영향을 미치는 회귀 오류가 발생할 여지가 없고, 한번 개발이 완료된 사용자 스토리는 다시 살펴볼 필요가 없기 때문에 개발 진척을 정량적으로 명확하게 관리할 수 있다(그림5).
<그림5> 그림4의 사용자 스토리를 스크럼에 적용
Scrum 이미지 출처: https://upload.wikimedia.org/wikipedia/commons/4/43/Scrum_Flow_for_one_Sprint.png
애자일은 프로세스가 아니라 개발 문화를 바꾸는 것이다. 프로젝트에서 의사소통은 기능 단위가 아닌 사용자 스토리로 하게 되면 고객의 프로젝트 이해도와 참여를 높일 수 있다. 개발자들이 놓치지 쉬운 애자일의 장점 중 하나는 완성되어 고객에게 확인 받은(Accepted Deliverables) 사용자 스토리는 다시 손대지 않는다는 것이다.
기존 SI 프로젝트의 진척률을 살펴보면 지난 달 80%의 진척을 보여도 회귀 오류가 발생하면 이번 달 60%로 떨어질 수 있다. 하지만 애자일의 경우 완료된 것은 다시 손대지 않기 때문에 진척률 답게 관리되는 장점도 있다(그림6).
<그림6> 전통적인 SI와 애자일의 프로세스 비교
출처: LG CNS Agile Korea Conference 2012 자료
댓글 없음 :
댓글 쓰기