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

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

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 이병준

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