본문 바로가기

사용자 스토리6

사용자 스토리와 유스케이스 I. 사용자 스토리와 유스케이스? [1]을 보면 이런 말이 나옵니다. 유스케이스 다이어그램은 UML의 많은 다이어그램에서 가장 혼란스럽고 쓸모없다. 나는 잠시 후 설명할 시스템 경계 다이어그램을 제외한 다른 유스케이스 다이어그램들을 여러분이 전혀 사용하지 않으면 좋겠다. 뭐 이런 말도 나옵니다. 유스케이스는 시스템의 동작 하나를 기술한 것이다. 유스케이스는 방금 시스템에게 특정한 일을 시킨 사용자의 관점에서 작성하며, 사용자가 보낸 자극 하나에 대한 반응으로 시스템이 진행하는 눈에 보이는 이벤트의 흐름을 포착한다. 눈에 보이는 이벤트란 사용자가 볼 수 있는 이벤트를 뜻한다. 유스케이스는 사용자의 눈에 보이지 않는 동작을 전혀 기술하지 않고 시스템 안에 숨겨진 메커니즘도 다루지 않는다. 오직 사용자가 직접.. 2007. 10. 15.
게으른 프로그래머와 사용자 스토리 제 주변엔 게으른 사람들이 좀 있습니다. 유유상종이라고, 저부터도 굉장히 게으른 편입니다. 스스로 프로그래머를 자처하고 있으니, 저는 '게으른 프로그래머'입니다. 흔히 프로그래밍에 있어서 게으름은 '창조의 어머니'에 비유되고는 합니다. 프로그래밍은 복잡한 문제를 단순하게, 그것도 컴퓨터의 힘을 빌어 풀어보자는 것이므로, 사실은 귀차니즘 신봉자의 게임이라고도 할 수 있습니다. 그러니 '게으르면 게으를수록 프로그래밍에 능하다'는 Myth가 유포되는 것도 어쩌면 당연한 일일지 모르죠. 하지만 정말로 그럴까요? (오늘의 질문입니다.) 주변의 사례를 한번 살펴보겠습니다. 제 주변에는 '어찌나 모든것을 귀찮아 하는지 회의시간에도 꾸벅꾸벅 졸기만 하는' 프로그래머가 한명 있습니다. (편의상 그를 A라고 하겠습니다.).. 2007. 10. 14.
사용자 스토리 : 실무 적용 사례 (04) [앞 글에서 계속 이어집니다] 그러면 이제 스토리(혹은 스토리 카드 ^^;)를 하나씩 분석해 보도록 하죠. 지난 번에 스토리에 하나씩 번호를 매겼었는데, 그 순서대로 진행하면 좋겠지만 아쉽게도 좀 무리가 있습니다. 우선, 이해가 편한 부분부터 하나씩 살펴보도록 하겠습니다. 본 글에서 '추정치'는 며칠 만에 구현할 수 있느냐,를 나타내는 값입니다. 각 스토리 아래쪽에는, 해당 카드에 적혀있을 만한 내용을 함께 적어보도록 하겠습니다. 편의상 카드에 스토리 번호를 함께 적었는데, 실제로는 이 번호는 필요가 없습니다. 번호를 순서대로 유지하는 비용이 쓸데없이 더 붙기 때문이죠. 그냥 제가 설명을 돕기 위해 적었다고 생각해주세요. 11. 네트워크 관리자는 시스템의 상태 (가동상태? 중지상태?)를 살펴볼 수 있다 .. 2007. 10. 1.
사용자 스토리 : 실무 적용 사례 (03) (역시 지난 글에 이어집니다.) 사용자 식별을 대강 마쳤으니 이제 사용자 스토리를 작성해볼 순서입니다. CRM 관리자가 하는 일이 과연 있을까? 네트워크 관리자랑 상당부분 중복되지 않을까? 하는 생각이 들었습니다만, 스토리를 작성해 보기 이전에 사용자 범주를 과도하게 축소해버리는 것도 위험하겠다, 는 생각도 들었습니다. 사용자가 줄어든다는 것은, 그만큼 스토리 작성에 있어 유용하게 써먹을 수 있는 관점들이 줄어드는 것을 의미하기도 하니까요. 그래서 일단은 사용자들은 그대로 두고, 대략적인 사용자 스토리들을 작성해봤습니다. 과연 필요한 모든 스토리들을 다 작성했을까? 하는 의구심도 들었습니다만, User Stories Applied라는 책에도 나와있다시피, 사용자 스토리를 만드는 것 조차도 점진적으로 해 .. 2007. 10. 1.