User Stories Applied : Chapter 11 스토리가 아닌 것

사용자 스토리는 IEEE 830이 아니다.

Tip : IEEE 830 IEEE 컴퓨터학회에서는 소프트웨어 요구사항 명세서 작성에 관한 가이드라인을 출판하였다. ‘IEEE 830’이라 알려진 이 문서는 1998년에 최종적으로 개정되었다. 이 문서는 요구사항 명세 문서를 어떻게 구조화하는지, 프로토타이핑의 역할은 무엇인지, 훌륭한 요구사항 문서가 갖추어야 하는 특징은 무엇인지 등에 대해 언급한다. IEEE 830 스타일의 소프트웨어 요구사항 명세서의 가장 두드러진 특징은 기능 요구사항을 작성할 때 IEEE가 권장하는 방법인 ‘시스템은~~~ 해야 한다.’ 형태의 문장을 사용한다는 점이다.

IEEE 830 스타일의 요구사항 기술방식은 사용자의 목적보다는 요구사항 목록 자체에 주의를 기울이게 하기 때문에 프로젝트가 방향을 잃는 경우가 많았다. 요구사항 목록은 제품의 이미지를 전달하는 데 사용자 스토리만도 못하다.

예 : IEEE 830 방식

- 산출물에는 가솔린 엔진이 장착되어야 한다.

- 산출물의 바퀴는 네 개여야 한다.

- 산출물의 각 바퀴에는 고무 타이어가 끼워져 있어야 한다.

- 산출물에는 운전대가 있어야 한다.

- 산출물의 몸체는 강철이어야 한다.

예 : 사용자 스토리 방식

- 산출물은 우리 집 잔디를 깎는 일을 편리하고 빠르게 처리할 수 있게 한다.

- 산출물을 사용하는 동안 편안해야 한다.

사용자의 목적이 그대로 사용자 스토리가 되는 것은 아니지만, IEEE 830 문서는 요구사항들을 나열한 것인 반면 사용자 스토리는 사용자의 목적을 기술한다.

IEEE 830 스타일 요구사항 명세서는 요구사항을 모두 기술하기 전에는 개별 요구사항을 구현하는 데 드는 비용을 잘 알 수 없다

요구사항 목록을 단순히 나열하는 방법의 또 다른 문제점은 각 항목이 사용자의 행동이나 목적이 아니라 소프트웨어의 행동을 기술한다는 것이다. 요구사항 목록은 ‘어떻게, 왜, 누가 그 기능을 사용할 것인가’에 대해 답하지 않는다.

사용자 스토리는 유스케이스가 아니다.

사용자 스토리와 유스케이스 간의 명백한 차이점 중 하나는 다루는 범위가 다르다는 점이다.

• 사용자 스토리는 제약 조건을 두어, 일정 계획에 사용하기 편리하도록 작은 범위를 다룬다. 유스케이스는 대부분 사용자 스토리보다 훨씬 큰 범위를 포함한다.

• 사용자 스토리와 유스케이스는 그 완결성에도 차이가 있다. 제임스 그레닝은 “스토리 카드에 인수 테스트를 더하면 기본적으로 유스케이스와 동일하다”고 언급한 바 있다. 그는 사용자 스토리가 유스케이스의 주 성공 시나리오에 대응되고, 그 사용자 스토리에 대한 테스트들이 유스케이스의 확장부분에 해당한다고 말한다.

• 유스케이스는 개발 기간이나 유지보수 기간에 계속 사용된다. 반면 사용자 스토리는 그것을 개발한 이터레이션이 지나서까지 계속 사용하도록 만들어진 것이 아니다. 많은 팀이 스토리 카드를 보관하지 않고 간단히 없애 버린다.

• 유스케이스는 그렇게 하지 말 것을 권장함에도 불구하고 사용자 인터페이스에 관한 세부사항을 포함하는 경우가 많다.

• 유스케이스와 사용자 스토리의 또 다른 차이점은 작성 목적이 다르다는 점이다. 유스케이스는 고객과 개발자가 모두 읽고 이해할 수 있는 형식으로 작성된다. 그 목적은 고객과 개발 팀 간의 함의를 문서화하는데 있다. 반면에 사용자 스토리는 릴리즈나 이터레이션의 계획을 세우는데 도움을 주기 위해 작성되고, 사용자의 상세한 요구들에 관해 대화를 나누기 위한 매개체로서 사용된다.