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

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

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 ]