I. 사용자 스토리와 유스케이스?

[1]을 보면 이런 말이 나옵니다.

유스케이스 다이어그램은 UML의 많은 다이어그램에서 가장 혼란스럽고 쓸모없다. 나는 잠시 후 설명할 시스템 경계 다이어그램을 제외한 다른 유스케이스 다이어그램들을 여러분이 전혀 사용하지 않으면 좋겠다.

뭐 이런 말도 나옵니다.

유스케이스는 시스템의 동작 하나를 기술한 것이다. 유스케이스는 방금 시스템에게 특정한 일을 시킨 사용자의 관점에서 작성하며, 사용자가 보낸 자극 하나에 대한 반응으로 시스템이 진행하는 눈에 보이는 이벤트의 흐름을 포착한다.

눈에 보이는 이벤트란 사용자가 볼 수 있는 이벤트를 뜻한다. 유스케이스는 사용자의 눈에 보이지 않는 동작을 전혀 기술하지 않고 시스템 안에 숨겨진 메커니즘도 다루지 않는다. 오직 사용자가 직접 볼 수 있는 것만을 적어놓을 뿐이다.

좀 다른 식으로 말을 하고 있긴 하지만, 이 책의 저자는 "유스케이스는 가급적 상세하게 작성하고, 세부사항은 고객과 의논해라"라는 뜻의 말을 하고 있습니다. 이런 말은 아마 어디서 많이 들어본 소리일 겁니다. 맞습니다. "사용자 스토리"란 책에 보면 나오는 이야기이죠. 위와 같은 말을 한 다음에 저자는 다음의 유스케이스 사례를 보여줍니다. 유스케이스는 이 정도로 작성하면 좋지 않겠느냐,는 이야기를 하고 있는 것이죠.

상품을 구입하기

  1. 점원은 상품을 스캐너 위로 통과시킨다. 스캐너가 UPC 코드를 읽는다.
  2. 상품 가격과 설명이 지금까지 통과시킨 상품 가격의 합계와 함깨 고객 쪽의 화면에 표시된다. 가격과 설명은 점원의 화면에도 표시된다.
  3. 가격과 설명이 영수증에 출력된다.
  4. 점원이 UPC 코드가 올바르게 읽혔는지를 확인할 수 있도록 시스템이 잘 들리는 "승인"소리를 낸다.

실제로 유스케이스에 관한 책들을 보면 Use Case는 "기본 흐름"과 "대체 흐름"으로 구성된다는 것을 확인할 수 있는데요, 위의 유스케이스는 기본 흐름만 보여주고 있습니다. 사용자 스토리를 선호하는 개발자들은 유스케이스를 "기본 흐름"정도만 작성하는 선에서 마무리 짓기를 원할 것입니다. 하지만 시스템이 정상적으로 동작하지 않을 경우에 어떤 식으로 프로세스가 일어나야 하는지를 고객이 정확하게 명시하고자 하는 경우도 있을 수 있으니까, 그런 경우에는 "대체 흐름"도 작성해야 합니다. 사용자 스토리라면 대체 흐름은 아마 사용자 스토리 카드의 "테스트" 부분에 명시될 가능성이 높겠습니다만, 유스케이스 작성을 요구하는 부서에서 일하고 있다면 대체 흐름을 통해 그 사실을 적시할 필요가 있겠습니다. (유스케이스로 사용자 스토리 카드를 대체하는 것이죠.)  

위의 유스케이스를 보면 대략 다음과 같은 사실을 눈치챌 수 있습니다.

  1. 유스케이스의 제목은 사용자 스토리 관점에서 보면 에픽(Epic)이다
  2. 유스케이스를 구성하는 절차는 사용자 스토리가 아니다

왜 사용자 스토리가 아니라고 이야기 해야 하나요? 사용자 스토리는 "우리가 시스템을 통해 성취해야 할 무엇"을 시스템 전반에 걸쳐 "종적"으로 명시하는 것이지 결코 그 중 일부분만 떼어 내어 절차 단위로 분할하지 않습니다. 물론 위의 유스케이스는 "스캐너가 UPC코드를 읽는다"와 같은 독립적인 스토리가 될 수 있는 여지를 가지고 있는 작업도 포함하고 있습니다만, 그건 위의 유스케이스에 한정되는 것이지 다른 유스케이스에도 적용될 수 있는 이야기라고 보기는 좀 힘듭니다.


II. 회사가 유스케이스와 다이어그램을 작성하라고 요구합니다

자.  그렇다면 이제 이런 경우를 생각해 봅시다. 회사가 유스케이스와 다이어그램을 작성하라고 요구하는 경우에는 어떻게 해야 하나요? 그런 요구를 받은 사람이 사용자 스토리를 포함하는 애자일 프로세스의 추종자라면 (가령 저같은 사람 -_-;) 분명 그 요구에 무리한 부분이 있다고 느낄 것입니다. 유스케이스를 신봉하는 대부분의 조직은 개발 기간의 70% 정도를 유스케이스와 그 세부사항을 작성하는 데 투여하는 경향이 있습니다, 그렇게 해서 작성된 유스케이스가 실제 개발이 시작될 시점에 사용자의 요구를 몇 퍼센트나 정확하게 반영할까요? 개발자 집단이 유스케이스를 열심히 작성하고 있는 동안에도, 사용자의 요구사항은 끊임없이 변화하게 마련이라는 데에 주목합시다. [1]의 저자도 이야기하는 사항입니다만, 문서는 "덜 자세할 수록 더 정확" 합니다. 디버깅을 나중에 할 수록 결함 비용이 증가하듯이, 검증되지 않은 유스케이스를 보다 더 자세히 작성할 수록 나중에 개발 결과물이 산으로 갈 가능성은 더 높아집니다.

그런데 어떤 회사는 "그래도 유스케이스와 다이어그램을 작성해야 한다"고 요구합니다. 이런 조직은 대부분 잘 정의된 문서가 있어야 직성이 풀리는 조직입니다. [1]의 저자는 '그러니 문서는 가급적 맨 마지막에 작성해야한다'고 언급합니다. 그래야 문서가 개발된 결과물의 상태를 정확하게 반영하니까요.

따라서,  그런 조직에서 일한다면 이제 타이밍의 문제를 심각하게 고려해 볼 필요가 있습니다.

  1. 문서를 개발기간 초기에 작성해야 하는가?
  2. 문서를 개발기간이 끝난 뒤에 작성해도 되는가?

2의 경우라면 좋겠습니다만, 1의 경우라면 가급적 조직을 설득하는 게 좋겠습니다. '이런 저런 이유로, 문서관리 시스템에 지금 모든 문서를 일괄등록시키는 것은 불가합니다'라구요. 설득이 안된다면, 가급적 문서를 '점진적으로 개선'하는 방향으로 해 나가겠다고 설득하는 것이 좋겠습니다. 그런데 유스케이스는 과연 점진적으로 작성하는 것이 가능한 문서인가요? 의 유스케이스 사례만 보더라도, "승인"을 알리는 알람 시그널이 울려야 한다는 등의 세부사항이 유스케이스 안에 들어있어서 도대체 점진적인 작성이라는 것이 어려워 보이기는 합니다. 그러니, 유스케이스를 점진적으로 작성하려면 "개발에 관한 모든 요구 사항을 개발 전에 FIX 시키겠다는 환상을 버리"고, 문서에 포함된 내용이 점진적으로 발전하게 될 수 있음을 모든 사람에게 납득시켜야 합니다. 물론 조직에 따라서는 이렇게 하기가 좀 힘들 수도 있겠습니다.

유스케이스 작성에 있어서 한 가지 더 고려해야 할 사항은, 유스케이스 다이어그램의 작성입니다. 어떤 조직은 유스케이스 문서와 더불어 유스케이스 다이어그램이 나와 줘야 한다고 요구하기도 합니다. 그런 경우에는 [1]의 저자의 말대로 '시스템 경계 다이어그램' 정도를 작성하는 것이 옳아 보입니다. 그런데 '시스템 경계 다이어그램'은 대체 어떻게 작성해야 하나요?

유스케이스 다이어그램

유스케이스 다이어그램 (http://www.oracle.com/technology/global/kr/pub/columns/051024_jdeveloper_uml.html)

애자일 개발 조직이라면 사용자 스토리 식별 과정에서 나온 스토리들을 역으로 "에픽"으로 그룹화 한 다음 그것으로 유스케이스 이름을 정하고, 그 이름들로 경계 다이어그램을 그려 나갈 수 있습니다. 비-애자일 조직이라고 하더라도 그런 식으로 작업해서 효율을 높일 수 있습니다. 유스케이스를 그리는 것이 유일한 목적인 비-애자일 조직에서도 사용자 스토리는 활용될 수 있다는 것이죠.


참고문헌

  1. Java  프로그래머를 위한 UML: 실전에서는 이것만 쓴다
  2. 사용자 스토리(User Story Applied)

이 글은 스프링노트에서 작성되었습니다.

신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 윤영석

    늘 1번만 염두에두고서 어떻게 개발전 단계에서 모든 문제를 포함 할수 있을지만 고민했는데
    처음으로 2번의 방법도 존재한다는 걸 생각해봤습니다;

    2012.04.04 16:37 신고 [ ADDR : EDIT/ DEL : REPLY ]

[앞 글에서 계속 이어집니다] 그러면 이제 스토리(혹은 스토리 카드 ^^;)를 하나씩 분석해 보도록 하죠. 지난 번에 스토리에 하나씩 번호를 매겼었는데, 그 순서대로 진행하면 좋겠지만 아쉽게도 좀 무리가 있습니다. 우선, 이해가 편한 부분부터 하나씩 살펴보도록 하겠습니다. 본 글에서 '추정치'는 며칠 만에 구현할 수 있느냐,를 나타내는 값입니다.

각 스토리 아래쪽에는, 해당 카드에 적혀있을 만한 내용을 함께 적어보도록 하겠습니다. 편의상 카드에 스토리 번호를 함께 적었는데, 실제로는 이 번호는 필요가 없습니다. 번호를 순서대로 유지하는 비용이 쓸데없이 더 붙기 때문이죠. 그냥 제가 설명을 돕기 위해 적었다고 생각해주세요.

11. 네트워크 관리자는 시스템의 상태 (가동상태? 중지상태?)를 살펴볼 수 있다
11.1 시스템이 가동중인지 살펴볼 수 있다
11.2 시스템이 종료된 상태인지 살펴볼 수 있다

인수 테스트
T.1 시스템을 가동시키고 GUI에 표시되는 시스템 상태가 "가동중"으로 나타나는지 확인
T.2 시스템을 종료시키고 GUI에 표시되는 시스템 상태가 "종료됨"으로 나타나는지 확인

시스템의 상태를 살펴볼 것이라고만 했고, 실시간인지 조금 지연이 있어도 상관이 없는지는 명시되지 않았군요. 조금 지연이 있어도 괜찮다면 작년에 DBMS를 이용해 구현한 버전이 있으니 좋습니다만(추정치 1), 지연을 허용하지 않는 경우에는 간단하게라도 네트워크 프로토콜을 하나 구현해야 할 것 같습니다. (UDP이면 제일 좋을것 같네요.) 상태를 살펴보는 쪽이 네트워크를 통한 'Observer' 구실을 해야 하니까, 구현이 이틀 정도는 걸릴 수 있습니다. (추정치 2)

이 경우에 판단 기준이 되는 것은 아무래도 실시간성입니다. DBMS를 통해 시스템 상태를 파악하도록 하면 테이블에 대해서 GUI가 계속적으로 Polling을 해야 하는 문제가 있을 수 있을 것 같습니다. 고객 N에게 '어느 정도의 지연을 허용할 수 있느냐'를 물어봤습니다. 고객 N은 '1 sec 정도의 지연은 허용할 수 있다' 고 이야기했습니다. 그렇다면 1초마다 계속 polling을 하도록 구현하면 되는군요.

고객 N에게 'GUI가 하나만 존재하는지, 여러 개 존재할 수 있는지' 물어봤습니다. 고객 N은 여러 개 존재할 수 있다고 대답했습니다. 여러 개의 GUI를 처리할 수 있도록 하는 것은 구현을 DBMS로 가져가는 경우에는 간단합니다만, 네트워크 프로토콜을 통해 구현하는 경우에는 문제가 조금 까다로와질 수 있습니다. (뭐 그래도 심각한 것은 아닙니다.)

우선 지금으로선 추정치 2를 선택하고 넘어가는 것이 좋을 것 같습니다. 구현을 어떤 쪽으로 하는 것이 좋을지 결론을 내릴 수 없기 때문입니다. 나중에 구현을 변경하는 것도 충분히 가능한 문제이고, 1일과 2일은 큰 차이가 없다고 보아도 좋을 것이기 때문에 우선은 이렇게 하려고 합니다. 고객도 구현의 향방을 결정지을만큼 중요한 제약조건(constraint)은 아직 내놓지 못한 상태입니다.


12. 네트워크 관리자는 시스템에서 발생한 중요한 사건 기록(예: 장애 내역, 장애 발생 시간, 장애 발생 지점 등)들을 살펴볼 수 있다
12.1 네트워크 관리자는 시스템에서 발생한 중요 사건 기록을 간단히 조회할 수 있다

인수 테스트
T.1 시스템 장애를 발생시키고 그 장애가 조회 되는지 확인
...

어떻게 처리하느냐에 따라 다르지만, 단순히 로그를 보는 정도의 구현이라면 하루나 이틀이면 충분할 수 있습니다. 복잡한 질의가 가능하도록 하려면 좀 어렵습니다. 일단은 '간단히 조회'하는 수준으로 하도록 하려고 합니다. 그 이상이 필요하다면 고객 N이 요구를 했겠지만, 고객 N은 아직 아무런 요구를 내놓지 않았고 (스스로도 어디까지를 필요로 하는지 아직 확신이 없습니다) 개발자들도 그 이상을 개발할 생각은 없습니다. 고객에 다른 요구를 내놓는다면 스토리를 변경하고, 너무 크다 싶을 경우에는 잘게 쪼갠 다음 각각을 다시 추정하면 되겠습니다. 그런데 생각해보니 이 스토리에 대한 GUI는 새로 만들어야 하겠군요. GUI 구현에 하루에서 이틀 정도는 걸릴 것 같습니다. (추정치 4)


13. 네트워크 관리자는 접속망의 네트워크 사용량에 대한 정보를 실시간으로 살펴볼 수 있다

접속망을 구성하는 링크가 다양하기 때문에, 사용량에 대한 정보를 실시간으로 살펴보려면 아무래도 링크 별로 살펴볼 수 있는 기능이 있어야 할 것 같습니다. 그러려면 사용량에 대한 정보가 링크별로 관리가 되어야 할 것 같네요. 고객 N에게 어떤 형태로  살펴보길 원하냐고 했더니 그 비슷한 이야기를 하는군요. 그정도로 추정을 마무리 짓고 넘어가면 될 것 같습니다. 이 부분도 GUI가 새롭게 추가되어 들어가야 하는 부분입니다. (추정치 7)


14. 네트워크 관리자는 시도된 호, 승락된 호, 거부된 호에 대한 통계 정보를 살펴볼 수 있다

시도된 호와 승락된 호, 거부된 호에 대한 통계 정보를 살펴보는 기능은 기존에 있었습니다. (추정치 1) 고객도 기존에 있었던 기능을 참고하여 스토리를 작성하였다고 하니, 사소한 수정 정도만 하는 선에서 구현을 할 수 있을 것 같습니다.


15. 네트워크 관리자는 거부된 호가 발생한 네트워크 링크의 위치를 추적하고, 그 사용량을 확인할 수 있다.
18. CRM 관리자는 고객 불만이 접수된 시간에 문제가 있었던 네트워크 링크를 찾아내고, 그 링크의 네트워크 사용량 정보를 확인할 수 있어야 한다

위의 두 개의 스토리는 대상으로 하는 사용자의 범주는 서로 다르지만, 추정을 하다보니 본질적으로 같은 스토리로 확인이 되었습니다. 그러니 굳이 구현을 분리하는 것 보다, 하나로 통합해서 구현하는 것이 좋을 것 같습니다. 거부된 호가 발생할 때 마다 그 링크 위치와 당시 대역폭 사용량, 거부 발생 시각 등의 정보를 어딘가에 기록해 두면 될 것 같습니다. 구체적으로 어디에 저장할 지는 아직 결정을 하지 않았지만, DBMS에 저장하나 파일에 저장하나 드는 수고는 비슷할 것 같습니다. GUI에 시간 기준 검색 기능이 들어가야 하므로 GUI 구현이 새롭게 들어가야 합니다. (추정치 5)

이런 식으로 해서 16번은 3으로 추정했고, 남은 두 개의 스토리(17, 19) 번도 각각 3으로 추정했습니다. 그런데 이야기를 나누다 보니 CRM 관리자를 지원하기 위한 기능은 꼭 연내에 구현될 필요가 없군요. 나중에 모든 기능이 완결된 다음에 천천히 생각해 보아도 되는 스토리라고 합니다. 그래서 이 두 개의 스토리는 일단 찢어버리기로 했습니다. 이런 이야기가 스토리를 만드는 단계에서 나오지 못한 건 좀 의아합니다만, 뭐 프로젝트가 언제나 정해진 가닥을 잘 따라서 굴러가는 것은 아니니까, 양해하고 넘어가기로 합시다.

자. 그럼 이제 남은 스토리들을 한번 보죠.

"일반 VoIP 사용자는 음성 통화를 할 수 있다"와 같은 스토리는 규모가 어마어마하게 큰 스토리로 생각됩니다. 이런 스토리의 추정을 할 때에는 좀 여러가지로 고려해야 할 것이 많을 것 같습니다. 우선 관련된 시스템들부터 살펴볼까요? VoIP 사용자가 음성 통화를 할 수 있으려면, 관련된 시스템이 다 구현되어야 합니다.

TIP: 스토리를 작성하거나 추정할 때에는, 수직적으로 해야 합니다. 관련된 개별 컴포넌트 각각에 대해서 스토리를 작성하는 것이 아니라, 해당 스토리에 관련된 모든 컴포넌트에 대해서 추정치를 수집하고 개발 계획을 세워야 합니다. 이터레이션이 끝나거나 빌드가 끝난 후 만들어질 결과물이 항상 '돌아가는 것이 가능한 시스템' 이어야 하기 때문에 그렇습니다.

우선 VoIP 단말로부터 발생하는 SIP 메시지들을 받아서 처리할 Call Server가 있어야 합니다. 해당 Call Server는 전화 요청을 처리해서 대역폭 수락 제어 프로세스가 이해할 수 있는 메시지로 변환한 다음, 대역폭 수락 제어 프로세스에게 보내어 현재 가용한 대역폭이 있는지 알아보고, 있는 경우에만 호를 계속 진행하여야 합니다. Call 서버와 대역폭 수락 제어 프로세스가 합쳐져서, 하나의 대역폭 수락 제어 시스템을 구성하게 됩니다.
 
다행히 Call Server는 이미 구현된 것이 있으니 그대로 쓰면 될 것 같습니다. 따라서 Call Server의 존재는 스토리 추정에 영향을 미치지 않습니다. (나중에 자질구레한 수정이 필요할지도 모르겠습니다.) 대역폭 수락 제어 시스템이 Call Server와 인터페이스를 가져야 한다는 것이 문제인데, 이 인터페이스도 역시 기존에 존재하던 것을 그대로 가져다 쓰면 될 것 같습니다. 역시 추정치에는 큰 영향을 미치지 않습니다.

문제는 대역폭 수락 제어 시스템에 온 호 요청을 어떻게 처리하느냐 하는 문제입니다. 우선 전화와 관련된 접속망들을 식별하여야 하고, 해당 접속망들에 가용한 대역폭이 남아있는지를 판단해야 합니다. 이 부분은 현재 구현이 되어 있지 않으므로 새롭게 구현해야 합니다. 이 부분의 추정치를 판단해 보니, 자료 구조 구현하는 부분, DBMS 구현하는 부분 등등을 따져봐도 최소 일주일은 걸릴 것 같다는 판단이 듭니다.

그러므로, "일반 VoIP 사용자는 음성 통화를 할 수 있다"는 스토리의 추정치는 7일 입니다. 개발자의 말에 따르면 음성 통화를 구현하는 거나 영상 통화를 구현하는 거나 동일한 로직을 사용하기 때문에, 다른 부분은 변경될 필요가 없다고 하는군요. 그러므로 그 두 스토리는 아예 합쳐 버릴 수 있습니다.

처음에는 이 스토리가 에픽일거라고 생각했는데, 관련된 시스템들을 전부 훑어 내려가다보니 그렇지 않다는 결론에 도달했습니다. 다행입니다. 아무튼 이런 과정들을 앞서 검토하지 않고 남겨둔 모든 스토리들에 반복했습니다. 그 결과, 다음과 같은 표를 얻었습니다.

스토리 추정치

스토리 추정치


다른 스토리에 병합된 것들은 추정치가 0입니다. 연내에 개발할 필요가 없다고 판단된 것들도 추정치는 0입니다. 총 스토리 합은 29로 계산되었습니다.

그러면 이제 릴리즈 계획을 세워야 합니다. 그런데 하필이면 본 프로젝트는 릴리즈 일자가 12월 말까지로 고정되어 있는 프로젝트입니다. 지금은 10월이니까, 시간이 두달 남아 있습니다. 해당 릴리즈 일자까지 구현하기로 한 모든 기능은 다 구현이 마쳐져야 한다는 것이 고객 측의 요구사항입니다. 다행이 추정치가 30 미만이라, 이터레이션을 몇 번 돌면 릴리즈 일자까지 개발을 마감할 수 있을 것 같습니다.

일단 이터레이션 간격은 2주로 하기로 했습니다. 1주로 할까도 생각해봤지만, 너무 짧습니다. 자질구레한 회의가 많아지면 구현에 드는 시간이 줄어들 수도 있습니다.

2주의 이터레이션을 세 번 정도 돌면 위의 스토리들의 구현은 대략적으로 완료가 되어야 합니다. 물론, 이터레이션을 돌 때 마다 완료된 스토리 점수를 합산한 다음, 개발 속도를 다시 계산해야 하고, 그 계산된 수치에 따라 예상은 조정될 필요가 있습니다.

자. 그러면 이제 각각의 이터레이션에 구현되어야 할 스토리들을 살펴보겠습니다.

이터레이션 1 - 총합 10

  • 일반 VoIP 사용자는 음성 통화를 할 수 있다 + VoD 사용자는 영화를 선택하고 재생하고, 중단할 수 있다. (7)
  • 네트워크 관리자는 시스템의 상태(예: 가동/중지/비정상적 종료 등을 포함하는)를 살펴볼 수 있다 (2)
  • 네트워크 관리자는 시도된 호, 승락된 호, 거부된 호에 대한 통계 정보를 살펴볼 수 있다 (1)

이터레이션 2 - 총합 7

  • 네트워크 관리자는 시스템에서 발생한 중요한 사건 기록(예: 장애 내역, 장애 발생 시간, 장애 발생 지점 등)들을 살펴볼 수 있다 (4)
  • 네트워크 관리자는 시스템 설정 정보를 입력할 수 있어야 한다 (3)

이터레이션 3 - 총합 7

  • 네트워크 관리자는 접속망의 네트워크 사용량에 대한 정보를 실시간으로 살펴볼 수 있다 (7)

이터레이션 4 - 총합 5

  • 네트워크 관리자는 거부된 호가 발생한 네트워크 링크의 위치를 추적하고, 그 사용량을 확인할 수 있다 (5)

우선순위를 나름대로 고려해서 이터레이션을 나누었습니다. 전화 기능은 우선적으로 완료되어야 하는 기능이니까 이터레이션 1에 포함되어 있고, 관리 기능들은 차후에 구현되어도 좋은 기능이라 그 이후에 포함되어 있습니다. 그런데 보면 이터레이션의 길이가 10으로 (1주의 근무일은 5라고 가정했습니다) 되어 있는데, 각 이터레이션의 스토리 점수 총 합은 10으로 딱 떨어지지 않습니다.

이런 경우에는 스토리들을 더 작은 조각으로 나누어 그 중 일부를 앞부부분으로 전진배치 시키거나 하는 방법을 써서 각 이터레이션을 균등하게 만들 수 있겠습니다. 하지만 지금 잡은 스토리 추정치가 절대적으로 옳다는 보장도 없고, 10으로 잡은 프로젝트 진행 속도가 유효한지도 알 수 없으니 (프로젝트의 속도는 이터레이션이 한 번 돌아 봐야 보다 정확하게 추정할 수 있을 테니까요) 우선은 이렇게 잡고 나서 작업을 진행해도 큰 무리는 없을 것 같습니다.

자. 그러면 이제 2 주 단위의 이터레이션을 3.5회 도는 것이니까, 14 * 3.5 = 49일 정도의 기간(작업일과는 다릅니다)이 소요되겠군요. 이정도면 크게 나쁘지 않은 추정인 것 같습니다. (정말로?)

[다음 글에 계속...]

신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. <A href="http://blueandyellow.blog22.fc2.com/">SEX</A>できるサイト<A href="http://pyridoxiamine.blog34.fc2.com/">逆援助</A>専門の出会い<A href="http://gyakuenjyoyattemita.blog10.fc2.com/">逆援助</A>でセレブ女性とH<A href="http://douteiget.blog102.fc2.com/">童貞</A>喪失も可能<A href="http://hurinxxx.blog19.fc2.com/">不倫</A>がした

    2009.03.19 15:33 신고 [ ADDR : EDIT/ DEL : REPLY ]

(역시 지난 글에 이어집니다.) 사용자 식별을 대강 마쳤으니 이제 사용자 스토리를 작성해볼 순서입니다. CRM 관리자가 하는 일이 과연 있을까? 네트워크 관리자랑 상당부분 중복되지 않을까? 하는 생각이 들었습니다만, 스토리를 작성해 보기 이전에 사용자 범주를 과도하게 축소해버리는 것도 위험하겠다, 는 생각도 들었습니다. 사용자가 줄어든다는 것은, 그만큼 스토리 작성에 있어 유용하게 써먹을 수 있는 관점들이 줄어드는 것을 의미하기도 하니까요.

그래서 일단은 사용자들은 그대로 두고, 대략적인 사용자 스토리들을 작성해봤습니다. 과연 필요한 모든 스토리들을 다 작성했을까? 하는 의구심도 들었습니다만, User Stories Applied라는 책에도 나와있다시피, 사용자 스토리를 만드는 것 조차도 점진적으로 해 나갈 수 있는 부분이니까 크게 걱정하지 않아도 될 것 같습니다.

사용자 스토리 추출 과정에서 도출된 스토리들은 다음 그림과 같습니다. (역시 너무 작아서 잘 안보이는군요ㅋ)

만들어진 사용자 스토리들

만들어진 사용자 스토리들


원래는 사용자 스토리 하나 당 카드 하나씩을 사용해야 합니다만, 모니터 화면이 너무 작아서 그렇게는 못했습니다. 아무래도 카드 묶음을 하나 사는게 좋을것 같기도 해요. 여기 저기서 스토리 구현을 마치고 스토리 카드를 찢을때의 쾌감에 대해서 이야기를 하는데, 이런 식으로 진행하면 그런 쾌감을 느끼기는 힘들거든요. ㅋ

아무튼, 이 스토리들을 좀 잘 보이게 다시 나열해 보면, 아래와 같습니다.

  1. 일반 VoIP 사용자는 음성 통화를 할 수 있다
  2. 일반 VoIP 사용자는 통화 종료 후에 통화 시간을 확인할 수 있다
  3. 일반 VoIP 사용자는 통화 종료 후에 대략적인 통화 요금을 확인할 수 있다
  4. 음성+화상 VoIP 사용자는 음성+화상 통화를 할 수 있다
  5. 음성+화상 VoIP 사용자는 통화 종료 후에 통화 시간을 확인할 수 있다
  6. 음성+화상 VoIP 사용자는 통화 종료 후에 대략적인 통화 요금을 확인할 수 있다
  7. 음성+화상 VoIP 사용자는 음성 통화 중에 화상 통화를 시작할 수 있다
  8. 음성+화상 VoIP 사용자는 음성 통화 중에 화상 통화를 종료할 수 있다
  9. VoD 사용자는 웹 상에서 영화를 선택한 다음 재생할 수 있다
  10. VoD 사용자는 재생중인 영화를 종료할 수 있다
  11. 네트워크 관리자는 시스템의 상태(예: 가동/중지/비정상적 종료 등을 포함하는)를 살펴볼 수 있다
  12. 네트워크 관리자는 시스템에서 발생한 중요한 사건 기록(예: 장애 내역, 장애 발생 시간, 장애 발생 지점 등)들을 살펴볼 수 있다
  13. 네트워크 관리자는 접속망의 네트워크 사용량에 대한 정보를 실시간으로 살펴볼 수 있다
  14. 네트워크 관리자는 시도된 호, 승락된 호, 거부된 호에 대한 통계 정보를 살펴볼 수 있다
  15. 네트워크 관리자는 거부된 호가 발생한 네트워크 링크의 위치를 추적하고, 그 사용량을 확인할 수 있다
  16. 네트워크 관리자는 시스템 설정 정보를 입력할 수 있어야 한다
  17. CRM 관리자는 접수된 고객 불만을 확인할 수 있어야 한다
  18. CRM 관리자는 고객 불만이 접수된 시간에 문제가 있었던 네트워크 링크를 찾아내고, 그 링크의 네트워크 사용량 정보를 확인할 수 있어야 한다
  19. CRM 관리자는 고객 불만에 응대할 수 있도록 고객의 정보를 확인할 수 있어야 한다
뭐 이정도로군요. 사실 1~10까지의 사용자 스토리는 너무 단순하긴 해요. 그런데 제가 구현할 시스템이 다른 더 거대한 시스템의 일부인데다, 제 입장에서 보면 저 정도 스토리만 알고 있으면 나머지 부분 (주로 사용자 인터페이스에 해당하는) 은 크게 모르고 있어도 상관이 없어서, 우선은 개의치 않기로 했습니다.

그런데 이 스토리들을 보면, 사실 구현될 시스템의 대략적인 정보는 얻을 수 있어도 정말로 구체적인 정보는 알 수가 없습니다. 가령 13번을 보면 네트워크 사용량에 대한 정보을 실시간으로 살펴볼 수 있어야 한다는 스토리가 있는데, 어떤 정보를 실시간으로 살펴볼 수 있어야 한다는 것인지에 대해서는 아무런 이야기가 없지요.

이런 정보는 나중에 그 스토리를 구현할 사람이 고객과 의사소통을 해 나가면서 알아내야 합니다. 그런대 대체 언제 알아내야 하는 걸까요?

'언제' 알아내야 하는가가 '왜' 중요한지를 이해하려면, '추정'의 문제를 생각해 봐야 합니다. 나중에 이 스토리를 놓고, 그 스토리를 완료하는 데 얼마나 걸릴지를 추정해야 할 것이거든요. 그 추정치를 놓고 이터레이션 계획이나 릴리즈 계획을 세워야 하니, 추정은 정말로 중요한 과정이죠. 그런데 스토리를 완료하는 데 드는 시간을 추정하려면 그 스토리가 정확하게 무엇을 요구하는지를 알 필요가 있을 수 있거든요.

그러니 가급적이면 스토리를 추정하는 자리에 고객도 참여하도록 하는 것이 중요할 겁니다. 그러면 추정하는 과정에서 개발자들이 궁금한 게 생기면 고객에게 물어보면 되지요.

물론, 방금 예로 든 '네트워크 사용량 정보를 확인할 수 있어야 한다'는 스토리는 그런 세부사항까지 미리 알지 않아도 괜찮기는 해요. 네트워크 사용량 정보라는 게 질의하는 순간에 주어지는 값을 기반으로 계산해서 얻어지는 값이라면 복잡하겠지만, 저장된 값을 간단히 조작해서 보여주는 수준이라면 굳이 세부사항을 생략하더라도 나름 정확한 추정을 할 수 있겠죠.

TIP: 추정하는 자리에는 고객을 참여시켜라


그런데 정말로 이 정도 사용자 스토리면 충분한걸까요? ㅋㅋ

네. 뭐 현재로서는 이정도면 충분할 겁니다. 뭔가 빠진 것이 있다면 스토리 추정 과정에서 발견될 것이고, 성에 차지 않는다면 추정을 끝내고 난 다음에 릴리즈 계획을 짜기 전에 스토리들을 전반적으로 다시 한 번 재검토 해 봐도 될 테니까요. 거기다 CRM 관리자라는 사용자를 지우지 않고 남겨둔 덕분에, 그 사용자 관점에서 유용한 스토리를 얻을 수 있었습니다. 네트워크 관리자와 비슷한 기능을 요구하는 대목도 있긴 합니다만, 보는 시각이 다르니까 나중에 고객과 이야기를 하다보면 조금 다른 방향으로 가지를 쳐 나가겠지요.

그러면 지금부터는 사용자 스토리들에 대한 추정을 해 봐야 하겠군요. 위의 스토리들을 다시 한 번 재검토하지 않는 이유는, 추정하는 과정이 어차피 검토를 수반하는 데다, 그 와중에 에픽(epic: 너무 큰 사용자 스토리)이 발견되어 더 작은 스토리로 나누어야 하는 경우에는 그 자리에서 그렇게 하면 될 것 같기 때문입니다.

(다음 글에 이어서...)

신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

(앞 글에 이어서 계속됩니다)  그런데 생각해 보니, 그것보다는 더 다양한 사용자가 있을 법도 합니다. 그래서 고민을 좀 해봤습니다. (같이 할 사람이 좀 있었으면 고민을 안했어도 되었을텐데.. ㅎㅎ)

생각해보니, VoIP 사용자로는 두 가지 부류가 있을 수 있겠더군요. 하나는 일반 VoIP 전화 사용자이고, 다른 하나는 음성/화상 겸용 VoIP 전화 사용자. 어떤 사용자냐에 따라서 시스템에 바라는 바도 좀 달라질 수 있겠습니다.

그리고 생각해보니까, 관리자도 두 가지 부류가 있을 수 있겠더군요. 네트워크를 관리할 네트워크 관리자와, 고객과의 관계를 관리하는 것이 주 업무인 CRM 관리자. CRM 관리자 입장에서는 고객의 불평불만을 처리할 근거 자료가 필요하니까, 혹시라도 전화가 안된다면 그 원인을 신속하게 파악하는 것이 필요하겠어요. 그러니 시스템이 그런 기능을 지원할 수 있다면 좋겠지요.


추가된 사용자들

추가된 사용자들


그래서, 새로운 부류의 사용자 두 가지가 추가되었습니다. 위의 그림을 보시면 (그림이 넘 작나요? -_-;;) 어떤 사용자가 추가되었는지 보실 수 있을 거에요. 그런데 그냥 그렇게 두자니 조금 심심한 감도 있고 해서, 젤 윗단에 사용자의 '대분류'를 넣어봤습니다.

제가 만든 '대분류' 체계에 따르면, 사용자는 (1) VoIP 전화 사용자 (2) VoD 사용자 (3) 관리자의 세 가지 부류로 나눌 수 있어요. VoIP 전화 사용자에는 a. 일반 VoIP 전화 사용자 b. 음성+화상 VoIP 전화 사용자의 두 가지 사용자가 있는 것이고, 관리자에는 a. CRM 관리자 b. 네트워크 관리자의 두 가지 사용자가 있는 것이죠. VoD 사용자에 대해서는 특별히 하위 범주의 사용자들을 찾아낼 수가 없어서, 그냥 그대로 두었습니다.

자. 여기까지 해서 대충 사용자들을 식별해 봤습니다. 이제 '시스템을 성공적으로 구축하는 데 도움이 되지 않을 것 같은 역할을 하는 사용자에 대한 카드'를 찢어버려야 하는데, 뭐 지금으로선 다들 나름대로 의미가 있을 것 같군요. (사실 사용자를 많이 식별하지 못했기 때문에 그런 것일수도 있습니다.) 그러니 찢어버리는 작업은 생략하도록 하겠습니다. :-P

그럼 이제 역할을 좀 다듬어 봐야 할 것 같네요. '역할 모델링'이라고도 하는 작업인데, 사용자의 '속성'을 고민해 보는 작업입니다. 사용자의 속성을 잘 파악하게 되면, 나중에 스토리를 찾아내는 과정이 좀 더 편해질 수도 있을 것 같습니다.

가령 음성/화상 겸용 VoIP 전화 사용자의 경우, 저는 그 사용자가 다음과 같은 속성을 갖는다고 가정했습니다.

사용자 역할 : 음성/화상 겸용 VoIP 전화 사용자

전화비 절약을 위해 VoIP 전화기를 선택했으며, 화상통화에 관심이 있어 음성/화상 겸용 VoIP 전화를 구매했다. VoIP라는 개념이 낯설기는 하지만 '일반 전화와 똑같은 방법으로 통화를 할 수 있다면' 써볼만 하다고 생각하며, 통화를 시작할 때나 혹은 통화가 진행중인 도중 언제라도 상대의 얼굴을 보고 싶다면 화상 통화 기능을 활성화시켜 상대를 보고싶어 한다. 인터넷을 통한 전화라고 해서 품질이 일반 전화보다 나빠야 한다고 생각하지는 않는다. 전화의 사용법은 가급적 일반 전화와 유사하기를 기대한다.

아까 식별했던 모든 사용자에 대해서 이런 작업을 반복해서 적당한 곳에 붙여놓으면, 나중에 필요할 때 마다 참고할 수 있을 겁니다. 시간 관계 지면 관계(?)도 있고 하니, 다른 사용자에 대한 속성 탐색 작업은 생략하겠습니다. X-)

그런데 이쯤 해 놓고 "User Stories Applied"를 다시 읽어보니, 대부분의 팀들은 이 이상 작업할 필요는 없다고 하는군요. 저도 이 쯤에서 사용자 식별에 관한 작업은 마무리 지어야 할 것 같습니다.

다음으로 해야 할 일은 이제 스토리를 작성하는 일이 되겠군요. 스토리 작성을 위해 프로토타입을 한 두 번 정도 만들어야 할 일이 생길지도 모르겠습니다.

(다음 글에 이어서...)
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

User Stories에 대해서 관심을 가지기 시작한지는 솔직히 얼마 되지 않습니다. ^^; 몸담고 있는 조직이 개발 조직이 아니라서, 사실 개발 방법론쪽으로 관심을 가지는 것이 그다지 도움이 되는 상황은 아니죠.

하지만 그렇다고 개발을 아주 안 할 수는 없는 노릇이라, 가급적이면 개발을 잘 하는 것이 좋겠다... 뭐 이런 생각은 항상 가지고 있었습니다. 그래서 최근에 Extreme Programming, User Stories, TDD, CVS 등등 연관되어 있는 방법론, 기법, 기술 등을 열심히 보고 있는 중입니다. 과연 이 상태 (지적 욕구에 충만한 이런 상태) 가 얼마나 오래 갈 지는 알 수 없습니다만 ㅋㅋ 지속되는 동안에는 이 블로그에도 엇비슷한 글들이 계속 올라오게 되리라 생각합니다.

각설하고.

이 글은 "User Stories: 실무 적용 사례"의 첫 번째 글입니다. 제가 하고 있는 업무에 실제로 User Story를 적용해 본 사례에 대해서 이야기를 해 보려고 합니다. (사실 완료된 업무는 아니고 지금 진행중인 업무입니다.) 업무 내용에 대해서도 소상히 말씀을 드릴 수 있으면 좋겠습니다만 사실 업무 성격상 외부에 공개가 조금 어려울 수도 있는 부분이 있기 때문에, 자세히 말씀 드리지 못하고 건너뛰는 부분도 있을 수 있습니다. (어쩌면 잘 몰라서 그러는 것일지도 모릅니다 *쿨럭*) 그런 부분에 대해서는 양해를 부탁드립니다. :-)

- - -

올해, 저는 대략 다음과 같은 이름의 시스템을 개발하게 되었습니다. (저는 네트워크 분야에서 일을 하고 있습니다.)

"VoIP, VoD 세션 요청에 대한 대역폭 기반 호 수락 제어 시스템"

이름 자체는 거창하기 짝이 없습니다만 하는 내용은 그렇지 않을지도 모릅니다. :-) 아무튼 위의 시스템이 하려고 하는 바는 이런 겁니다. 네트워크의 자원은 유한합니다. 대역폭은 무한히 주어질 수 없습니다. 그런데 대략적으로나마 그 자원의 크기(즉, 링크당 대역폭의 크기)를 알수 있다고 가정하고 (그 정보는 장비에 질의해보면 알 수 있다고 치겠습니다) 하나의 VoIP(혹은 VoD) 플로우가 보장받아야 할 대역폭의 양을 절대적으로 지원해 줄 수 있는 네트워크 장비가 있다고 치면, '이미 알고 있는 자원의 크기'를 기준으로 해서, '얼마나 많은 VoIP(혹은 VoD) 세션을 지원할 수 있는지'를 알 수 있습니다. 간단하죠. 그냥 나눗셈을 하면 됩니다. :-)

그런 간단한 가정에 기반한 호 수락 제어 시스템을 만들겠다는 겁니다. 현재 몇 개의 플로우가 특정한 링크에 흘러다니고 있는지를 알면, 현재 얼마만큼의 대역폭이 그 링크에 대해서 사용되고 있는지를 알 수 있습니다. 그런 정보에 의거하여 '새로운 VoIP/VoD세션을 받아들일 것인지 말 것인지'를 결정하는 수락제어 시스템을 만들어 보겠다, 는 겁니다. 이런 시스템을 통상 "Accounting Based 수락제어 시스템"이라고도 부르죠.

수락제어 시스템을 만드는 동기도 단순합니다. 어떤 특정한 링크에 허용되어 있는 대역폭 이상의 트래픽이 그 링크에 흘러들어오게 되면, 패킷들이 그 순간부터 랜덤하게 drop되기 시작합니다. 그러면 네트워크 링크상의 모든 플로우들이 성능 저하를 경험하게 되죠. 그런 상황을 피해보겠다는 겁니다.

그런데 말로 풀어보면 간단하기 짝이 없는 이 시스템을 실제로 구현하려고 해 보니, 그다지 간단하지가 않습니다. 우선 망에서 자원들(주로 네트워크 노드들과 그 사이의 링크들) 및 그 자원에 부여된 대역폭 크기를 수집을 해 와야 하고, Call Server는 SIP 요청들(INVITE, BYE 등등)을 처리해야 하고, ... 등등 할 일이 꽤나 많습니다.

개발을 어떻게 진행할까, 머리를 싸매던 끝에

기왕 하는 김에 Extreme Programming을 해 볼까

하는 무모한 생각을 하게 됩니다. -_-

그래서 일단 "들은 풍월도 있고 하니" 유저 스토리부터 한 번 작성을 해 봐야겠다, 하는 생각을 하게 되었습니다. User Story하면 모두들 "User Story Applied"를 읽는 것 같아, 저도 읽어봤습니다. 그리고 나서 아무 생각없이 유저 스토리를 작성하기 시작했(?)습니다. 유저 스토리는 시스템 사용자가 '시스템을 어떻게 사용하느냐'를 기술하는 것을 그 목적으로 합니다. 그래서 '누가' '무엇을 위해' 시스템을 사용하는지를 중심으로 기술하게 되죠. 하지만 Use Case 보다는 매우 간단합니다. Use Case는 가능한 모든 경우를 자세하게 기술하는 것을 목적으로 하는 반면, 사용자 스토리는 그 밑바탕부터가 '점진적인 개선'이나 '점진적 상세화'를 목적으로 하기 때문에, 그렇게 자세할 필요는 없습니다. 상세히 적어야 할 부분이 있다면 테스트 항목에 나열하면 되죠. (뭐 다 아시는 내용이겠습니다만...)

그러니 이런 것도 스토리가 될 수 있을 것 같습니다.

사용자는 VoIP 전화기를 사용해 전화를 걸 수 있다.

이 경우에는 '사용자'가 성취하려는 목적이 '전화를 거는' 것이죠. 그런데 이 사용자 스토리는 너무 커서 구현이 일이주 안에는 좀 어려울 것 같네요. 이런 스토리를 흔히 에픽(Epic)이라고 합니다. 이런 것은 나중에 사용자 스토리를 더 작은 단위로 나누는 과정에서 그 크기가 줄어들게 됩니다.

아무튼 그건 그렇고.

스토리가 이렇다 보니, '좋은 스토리'를 작성하려면 '시스템을 사용할 사용자'가 명확하면 명확할 수록 좋겠다', 뭐 이런 결론에 이르게 됩니다. 책에서는 사실 사용자 부류를 식별하려면 워크샵같은 자리를 마련해서 관련된 사람들이 전부 모인 다음에 사용자들을 식별해 나가도록 하는 게 좋다고 권고하고 있습니다만(뭐 일종의 브레인 스토밍이죠), 저는 저 혼자 실습을 진행하는 관계로 -_- 혼자 해 보기로 했습니다.

혼자 하려니 사용자 식별 과정에서 이용되는 '카드' 같은것을 만들기도 귀찮아서, 일단은 Note+라는 포스트잇 프로그램을 써 보기로 했습니다.

처음에 식별된 사용자들

처음에 식별된 사용자들


우선 생각할 수 있는 것으로, 네트워크 서비스 가입자가 있습니다. (저도 집에서는 그런 가입자 중 한사람입니다.) 이 가입자들을 좀 더 세분화해 보자면 VoIP 서비스 사용자가 있을 수 있고, VoD 서비스 사용자가 있을 수 있습니다. 그 이외에, 개발될 시스템을 사용할 주 고객으로, 네트워크 운영자가 있을 수 있습니다. 네트워크 운영자는 VoIP나 VoD 서비스에 의해 대역폭이 어떻게 소모되고 있는지를 항시 모니터링할 수 있었으면 좋겠다, 는 바램을 가지고 있는 부류의 사람들입니다.

그런데 이정도의 사용자만 식별하면 충분한걸까요?

(다음 글에 이어서...)
 

신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. daliot

    켄트 벡이 한국에 옵니다. 관심이 있으실 것 같아 링크를 남깁니다.
    http://www.sten.or.kr/bbs/board.php?bo_table=news&wr_id=1807

    2009.08.27 19:00 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. daliot

    9월 4일 열리는 Kent Beck의 Responsive Design 세미나에 대한 호응이 너무 좋아서 정원이 이미 꽉차고 말았습니다. 9월 2일에도 같은 세미나를 하기 때문에 혹시라도 선착순에 밀리신 분이시라면 한번더 기회가 있다는 것을 알려 드립니다.

    http://sten.or.kr/bbs/board.php?bo_table=news&wr_id=1822

    2009.08.30 17:07 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 저도 알고 있었습니다. 다만 참석할 시간 내기 어려운 상황이어서요. 제가 9월 8일까지는 프로젝트 마무리에 전념해야 하는 상황이라...

      2009.08.31 10:01 신고 [ ADDR : EDIT/ DEL ]