#3 고객중심의요구사항기법 - 사용자스토리 : 자주 논의하는 주제

3부 자주 논의하는 주제

 

"사용자스토리가 요구사항 명세서, 시나리오, 유스케이스 등 다른 요구사항 기법과 어떻게 다를까?"

"어떠한 기법을 사용하든 항상 무언가 잘못될 가능성은 있다."

"사용자스토리는 종이 인덱스 카드에 작성해야 하는지 소프트웨어를 이용해야 하는지?"

"버그를 스토리로 작성해야 하는걸까?"

 

에 대한 궁금증을 자주 논의하는 주제에 풀어 설명되어 있다.

---

스토리가아닌것

사용자 스토리는 소프트웨어 요구사항 명세서, 유스케이스, 상호작용 설계 시나리오 등과는 다르다.

생각을 아무리 많이 한다 해도, 시스템을 사전에 완벽하게 기술하지 못한다.

산출물의 특징을 단순히 나열하기 보다는 사용자의 목적을 고려해 보는 것이 중요하다.

사용자스토리는 유스케이스와 비슷하나 유스케이스가 더 광범위하다.

사용자스토리의 수명은 일시적이며, 개발된 이터레이션 후에는 유지할 필요가 없다.

유스케이스는 개발자와 고객이 논의한 것에 동의하기 위해 작성되며,

사용자스토리는 릴리즈를 계획하거나 대화를 통해 상세한 요구사항을 찾기 위한 매개체로 이용된다.

사용자스토리는 분석작업의 결과물이 아니라, 분석 작업을 위해 사용되는 도구이다.

상호작용 설계 시나리오는 사용자 스토리보다 훨씬 상세하게 기술된다.

전형적인 상호작용 설계 시나리오는 하나의 사용자 스토리보다 훨씬 광범위하다.

하나의 시나리오는 여러 유스케이스로 구성될 수 있고, 하나의 유스케이스는 다시 많은 사용자 스토리로 구성될 수 있다.

 

{나의 현실}

위에 책의 내용을 요약하다보면, 난 사용자스토리를 잘못 사용한 것 같다. 이전에는 요구사항을 정의하면 요구사항을 유스케이 또는 비지니스 흐름을 정의 한 후, 이에 맞는 각 화면설계와 데이터 설계를 진행해서 작업을 진행해왔는데, 이러한 습관 대로 사용자스토리를 요구사항 명세와 비슷하게 쓴 것 같다. 또한, 그곳에 살을 덧붙여 상호작용 설계 시나리오의 모습까지 만든 것 같다. 정해진 오픈 시점에 고객이 원하는 기능을 모두 포함하고자 할 때 느긋하게 이를 계속 상의하면서 진행하기가 쉽지 않았다. 한 번에 끝내야 하는 개발범위를 놓고 본다면, 사용자스토리 단위로 쪼개기에 시간이 너무 부족하다. 어디까지 쪼개야 할지도 감이 없기도 하다. 이전에는 이 큰 덩어리를 하나의 버전으로 관리했다면, 이번에는 사용자 스토리를 모아서 이터레이션>릴리즈>최종프로젝트완료배포로 나눠서 버전관리를 했다는 것이 다르다. 좀 더 제대로 된 사용자스토리 사용법은 좀 더 작은 단위의 프로젝트부터 다시 시도해봐야 겠다.

 

왜 사용자 스토리인가?

구두 의사소통을 강조한다.

모든 사람이 이해할 수 있다.

계획 수립에 적합한 크기다.

반복적 개발에 효과적이다.

세부사항을 나중에 고려할 수 있게 한다.

기회주의적 설계를 지원한다.

참여적 설계를 유도한다.

암묵적 지식을 구축한다.

 

그럼에도 불구하고,  이런 단점도 있다.

대규모 프로젝트에서 스토리가 많을 때 스토리 사의 관계를 이해하기 어렵다.

요구사항 추적성이 요구될 때 스토리 외에 문서를 추가로 작성해야 한다.

작은 팀에서 대화를 통해 더 많은 지식을 가질 수 있지만, 큰 팀의 경우 이를 실행하기가 어려울 수 있다.

 

개발자

새로운 기법에 대한 이해가 필요

다른 요구사항 작성 기법의 장점을 이해하고 적절히 이용

 

고객

능동적인 참여

 

스토리 냄새 카탈로그

너무 작은 스토리

상호 의존적인 스토리

금도금

너무 상세한 스토리

사용자 인터페이스와 관련된 세부사항을 너무 일찍 포함하기

너무 앞서 생각하기

스토리를 너무 많이 나누기

고객이 우선순위 부여를 어려워하는 경우

고객이 스토리를 작성하거나 우선순위를 부여하지 않으려는 경우

 

개발자

고객과 함께 스토리의 이상증후를 자각하고 이를 제거하기 

 

고객

개발자와 함께 스토리의 이상증후를 자각하고 이를 제거하기

 

스크럼에서 사용자 스토리 사용하기

"사용자스토리는 익스트림 프로그래밍(XP)에서 유래했지만, 다른 애자일 프로세스 중 하나인 스크럼에 적용할 수도 있다."

 

스크럼은 반복적이고 점진적인 프로세스다.

스크럼은 프로젝트 스프린트라 불리는 30일 단위의 이터레이션을 통해 진행된다.

스크럼마스터는 프로젝트 관리자의 역할을 수행하지만 관리자보다는 리더나 촉진자에 가깝다.

일반적인 스크럼팀은 5명에서 7명의 개발자로 구성된다.

제품 백로그는 아직 제품에 추가되지 않았거나 현 스프린트에 포함되지 않았지만 추후 제품에 추가될 기능들의 목록이다.

스프린트 백로그는 현 스프린트에서 수행할 작업들의 목록이다.

스크럼에서는 제품 소유자가 XP의 고객 역할을 수행한다.

제품 소유자는 제품 백로그에 우선순위를 부여한다.

스프린트의 시작 시 팀은 해당 스프린트 동안 무엇을, 얼마나 완료할 것인지 선택하고 이행 약속을 한다.

짧은 일일 스크럼 회의를 연다. 이 회의에서 각 팀원은 어제 무엇을 완료하였으며, 오늘은 무엇을 할 것이고, 장애요소는 무엇인지 말한다.

각 스프린트에서는 잠재적으로 출시 가능한 증가분을 생성해야 한다.

스프린트를 종료할 때 팀은 스프린트 검토 회의를 열고 소프트웨어를 시연한다.

 

{나의현실}

 스크럼에 대한 정의를 읽다보니, XP를 사용하면서 스크럼 회의를 스탠딩 미팅이라는 이름으로 사용하고 있었던 것 같다. 스프린트는 XP에서는 이터레이션 주기로 보면 될 듯 하다. XP는 짧게는 1주에서 4주까지 이터레이션 주간으로 보니, 이와 유사하다고 볼 수 있다. 다만, 나의 경우는 소프트웨어 시연은 릴리즈 단계에서 진행하는데 스크럼에서는 매 이터레이션 단계에서 진행하는 것 같다. 사용자스토리는 스크럼에서 얘기하는 백로그에 해당할 것 같다. 처음에는 감이 없고, 용어도 헷갈렸는데 이제 각각의 용어에 대한 이해가 어느정도 되는 것 같다.

 

그 밖에 논의하는 주제들

비기능 요구사항 처리하기 

시스템특성	제약사항의 예
성능(performance)	데이터베이스 검색 질의 중 80% 이상이 2초 이내에 결과를 화면에 보여주어야 한다.
정확성(accuracy)	적어도 55% 이상의 확률로 축구 경기의 승자를 예측할 수 있어야 한다.
이식성(portability)	리눅스로 이식하는 것을 어렵게 만드는 어떠한 기술도 사용하지 않아야 한다.
재사용성(reusability)	데이터베이스와 데이터베이스 접근 코드는 추후 다른 애플리케이션에서 재사용 가능하도록 작성되어야 한다.
관리용이성(maintainability)	각 컴포넌트에 대한 자동화된 단위 테스트가 존재해야 한다. 적어도 24시간마다 한 번씩 모든 자동화된 단위 테스트를 실행해야 한다.
상호운용성(interoperability)	시스템은 Java로 작성되어야 한다. 모든 설정 데이터는 XML로 저장되어야 한다. 데이터베이스는 MySQL을 이용한다.
가용성(availability)
사용성(usability)
보안(security)
용량(capacity)	데이터베이스는 성능 목표치를 만족하면서도 명세된 하드웨어에서 2천만명의회원정보를 저장할 수 있어야 한다.

 

인덱스 카드와 소프트웨어 중 어느 것을 사용할 것인가? 

• XP의 공동체의 많은 사람들은 단순함을 이유로 종이카드 선호
• 소프트웨어를 이용 시 요구사항 명세서와 같이 불필요한 세부 사항이 추가될 가능성
• 팀이 한 곳에 모이기 힘든 경우는 소프트웨어가 선호

사용자 스토리가 사용자 인터페이스에 미치는 영향

• 애자일 기법은 사용자인터페이스 설계를 무시하는 경향이 있으며,
• 해결책으로 애자일 사용례 중심 설계기법이 제안됨.
• 사용자 역할모델링 수행 - 고수준의 사용자 스토리 수집 - 스토리 우선순위 부여 - 스토리 정련 - 스토리들 그룹짓기 - 종이 프로토타입 제작 - 프로그래밍 시작

개발이 끝난 후에도 사용자 스토리를 계속 보관할 것인가?

버그 리포트와 사용자 스토리의 관계

• 흰카드는 일반 스토리
• 빨간카드는 버그 스토리
• 파란카드는 기술적인 작업로 분류하여 사용하는 방법

개발자

요구사항을 기술하는 다양한 기법을 제안하고 적절한 것을 사용할 책임

프로젝트에서 인덱스카드를 사용할지 소프트웨어 시스템을 이용할지 결정

프로젝트 초기에 사용자 인터페이스 설계에 대한 장단점을 이해

 

고객

사용자스토리가 제대로 반영하지 못하는 요구사항이 있다면, 다른 요구사항 기법 사용 요구

프로젝트에서 인덱스카드를 사용할지 소프트웨어 시스템을 이용할지 결정

프로젝트 초기에 사용자 인터페이스 설계에 대한 장단점을 이해

 

{나의 현실}

스토리가아닌것을 읽을 때는 이번 프로젝트에서 사용자스토리를 매우 잘못 사용한 것 같았는데, 그 밖의 논의 사항들을 마무리하면서 보니 적절히 혼용하여 사용한 것 같아 약간의 안도감이 들기도 한다. 차츰 애자일 프로세스에 익숙해지고, 장점을 살려 업무에 적용할 수 있기를 기대해본다.

---

<사용자스토리 마이크 콘 지음/한주영.심우곤.송인철 옮김 책 내용 요약>

1부 사용자스토리 시작하기

2부 추정과 계획

3부 자주 논의하는 주제

4부 예제