(역시 지난 글에 이어집니다.) 사용자 식별을 대강 마쳤으니 이제 사용자 스토리를 작성해볼 순서입니다. 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 이병준

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