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

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

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 ]

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

생각해보니, 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 ]

Extremely Agile/General2007.09.18 17:02
사용자 삽입 이미지

출처: http://www.extremeprogramming.org/map/project.html

위의 다이어그램에서 흥미있는 부분은 Spike에 관한 부분이에요. Spike는 Release Planning을 하기 위한 기본 자료입니다. 그러니까, 일의 규모나 시간 요구량을 가늠하기 위한 솔루션이죠. Spike는 "실용주의 프로그래머"라는 책에 따르면, "프로토타입"에 상응하는 개념이에요. 폐기해도 좋은 시스템이죠. 이 시스템은 시스템의 유저와 소통하고, 일의 규모를 정확하게 산정하기 위해서만 필요합니다. 꼭 최종 시스템에 가까울 필요는 없어요.

유저 스토리가 그것과 별개로 작성되고, 이것이 '요구사항' 형태로 'Release Planning'에 입력으로 제공된다는 것을 유의해 볼 필요가 있습니다. 특정한 유저 스토리를 구현하는 데 얼마만큼의 시간이 걸리게 될지 모를 때, 스파이크 솔루션을 만들어 보는 것이죠. 그렇게 하면 일의 규모를 보다 정확하게 가늠할 수 있습니다. 기술적인 난제에 마주했을 때, 그 문제만을 따로 떼어 그 문제를 해결하는 데 드는 비용을 계산해 보는 데에도 유용하겠어요.

다만 일반적인 스파이크와, 최초의 'Architectueral Spike'는 조금 구별할 필요가 있을 터인데, 초기의 스파이크 시스템은 팀 내의 구성원이 모두 공통적으로 사용하게 될 '용어' (객체나 컴포넌트의 이름이 될 수도 있고, 개념이 될 수도 있겠습니다)를 정하기 위한 시스템입니다. 사용자 스토리가 나오기도 전에 스파이크 솔루션을 만드는 것이 언듯 이해가 잘 안 가는 면도 있는데, 사실 계약을 수주하는 순간 그 계약의 결과로 구현될 시스템의 모습은 '대략적으로' 그려진다고 봐도 무방하지 않겠어요? 아래는 Architectural Spike 솔루션의 결과로 나오게 될 산출물인 "System Metaphore"라는 것이 무엇인지를 설명하는 인용문입니다. 역시 위의 사이트에서 참조했습니다.

Choose a system metaphor to keep the team on the same page by naming classes and methods consistently. What you name your objects is very important for understanding the overall design of the system and code reuse as well. Being able to guess at what something might be named if it already existed and being right is a real time saver. Choose a system of names for your objects that everyone can relate to without specific, hard to earn knowledge about the system.

 For example the Chrysler payroll system was built as a production line. At another auto manufacturer car sales were structured as a bill of materials. There is also a metaphor known as the naive metaphor which is based on your domain itself. But don't choose the naive metaphor unless it is simple enough

신고
Posted by 이병준

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

Extremely Agile/General2007.09.18 15:44

Extreme Programming에 관해 최근 이 책 저 책 열심히 보고 있습니다만.

Extreme Programming 혹은 Agile 방법론을 능숙하게 실행할 수 있거나 혹은 그 절차를 능숙하게 정의내릴 수 있는 프로그래머 혹은 아키텍트가 되려면, 대체 무엇을 알아야 하느냐. 이런 의문이 생기더군요.

그래서 몇 가지를 정리해봤습니다.

  1. 기술에 대한 열린 마음가짐 - 어떤 형태의 기술이던 열린 자세로 받아들이겠다, 는 마음가짐이 정말 중요한것 같습니다. 이런 자세가 없는 프로그래머는 어디서 일해도 실패하기 딱 좋습니다.
  2. 사람에 대한 열린 마음가짐 - 주변 사람들이 전부 자기와 같은 가치를 갖는 사람이라는 마음가짐을 가지고, 존중하는 자세가 필요합니다. 이런 자세가 없으면 왕따당하기 딱 좋지요...
  3. 기본적인 기술들에 대한 지식들 - 이런 지식들로는 뭐가 있을까요? 간단하게 꼽아보면 얼핏 생각나는 것만해도 UML, CVS, C++, Java, Design Pattern, Refactoring, Make, Ant, TDD, jUnit, CppUnit 등등이 있군요. 여기서 제가 잘 모르는 거로는 Ant가 있네요. -_-;

사실 UML과 C++, Java에 대해서는 오래 전부터 알고 있었습니다만, Design Pattern이나 Refactoring 기법, CVS에 대해서는 공부하기 시작한지 일년 남짓밖에 되질 않습니다.

하지만 개발을 진행하면 할수록, 상대적으로 저수준의 기술(C++, Java 등, 프로그래밍 언어레벨의 기술)보다는 그 상위의 개념에 대한 지식이 보다 절실하게 느껴지더군요. 사실 Extreme Programming에 사용되는 기술들은 프로그래밍 언어보다는 추상화 레벨이 높습니다. UML 같은 것은 'Language'라고는 하지만 실제로 구현될 시스템을 기술하는 기호언어에 가깝고, Design Pattern이나 Refactoring같은 기술들은 어떤 언어에도 적용될 수 있는 중립적인 기술이라 (물론 적용 형태는 언어에 따라 조금씩 달라질 수 있겠습니다만) 저수준의 지식이라고 하기는 힘들어요.

아키텍트라고 불리는 사람들에게 요구되는 것이 프로젝트 관리 능력이라고 본다면,  그런 역할을 맡는 사람들은 저수준의 프로그래밍 언어뿐 아니라, 보다 추상화 정도가 높은 언어(그런 언어들을 메타-프로그래밍 언어라고 부를 수 있을까요?)에도 능통할 필요가 있습니다. 사실 아키텍트는 단순한 개발자(주로 프로그래밍 언어만을 사용하여 소통하는) 뿐 아니라 다른 팀이나 고객들과도 소통을 할 의무가 있거든요. 그런 사람들에게 프로젝트의 궁극적인 지향점을 설명하려면, 보다 추상화 정도가 높은 언어로 개념을 다듬는 것이 필요하다는 거죠.

좀 일찍 이런 생각을 했으면 공부를 더 열심히 했을텐데... ㅋㅋ

최근에 관련해서 읽고 있는 (혹은 다 읽은) 책들은 다음과 같습니다.

  1. 익스트림 프로그래밍
  2. 사용자 스토리
  3. 린 소프트웨어 개발
  4. 테스트 주도 개발
  5. 실용주의 프로그래머
  6. 실용주의 프로그래머를 위한 버전 관리
  7. Java 프로그래머를 위한 UML, 실전에서는 이것만 쓴다

책을 안읽은지 너무 오래되어서 -_- 여러 책들을 한꺼번에 읽으려니까 좀 정신사납긴 하군요. ㅋㅋ



신고
Posted by 이병준

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

  1. 안녕하세요!!! 좋은 글 감사합니다. 자주올게요!!

    2011.01.28 01:15 신고 [ ADDR : EDIT/ DEL : REPLY ]