SI 프로젝트에 애자일을 적용할 수 없는 이유는 첫번째로 업무에 익숙하지 않은 개발자가 짧게는 3개월에서 길어도 1년을 넘지 않는 기간만 프로젝트에 투입되는 경우가 많았다. 업무도 모르는데 오래 머물지도 않아 있는 동안은 최선을 다하지만 주어진 기간에 맞는 수준까지만 수행하는 경우가 대부분이었다. 그러다 보니 Refactoring, TDD, Reuse 등 소프트웨어공학과 관련된 것은 물론이고 개발 외에는 신경 쓰지 않는 것이 보통이었다.
두번째는 요구사항의 변경이다. 프로젝트 초기에 정해진 요구사항은 프로젝트가 종료할 때까지 가급적 수정하지 않아야 하지만 요구사항의 변경에 의해 개발 중간에 변경되는 경우가 허다했다. 이런 수정은 회귀 오류를 발생시켜 프로젝트 전방위적으로 영향을 미쳤다.
세번째는 기능 중심으로 개발된다는 점이다. SI 프로젝트의 요구사항은 대체로 기능 중심으로 정의된다. 기능 중심으로 정의되면 개발하면서 유즈케이스와 시퀀스 다이어그램의 변경이 수시로 발생한다. 각각의 기능을 연결하면서 예기치 않는 오류가 빈번하게 발생하기 때문이다. 고객은 기능 단위로 일하지 않고 업무 프로세스에 맞춰서 일을 하기 때문이다. 이 세가지를 정리하면 업무를 잘 모르고, 개발 완료된 것이 변경되면 다른 개발에도 영향을 미치고, 마지막으로 고객은 업무 프로세스로 일하지 기능으로 일하지 않는다는 것이다.
해결점을 찾아보면 업무 프로세스 단위로 요구사항을 정의하고 개발하면 문제점이 해소될 여지가 있다. 애자일에서는 고객이 일하는 단위인 업무 프로세스를 사용자 스토리(User Story)라는 이름으로 정의하고 모든 프로세스가 사용자 스토리 단위로 움직인다. 이 것을 그림으로 나타내면 그림4와 같다.
<그림4> SI 프로젝트에 사용자 스토리 적용
댓글 없음 :
댓글 쓰기