사용자 스토리8점
사용자 스토리에서는 IEEE830에서 제시한 프로젝트 스펙따라 애플리케이션이 만들어지는 것을 추천하지 않습니다. 대신 인덱스카드(흔히 독서카드라고 얘기하는)를 이용해서 사용자의 애플리케이션에 대한 스토리를 중심으로 요구사항을 정제해갈 것을 얘기합니다. 스토리가 적혀있는 여러 카드들에 중요도와 점수를 부여하고 팀원들이 나눠갖는 식이죠.

고객 중심의 요구사항 기법이라고 소개가 됩니다만 언제 고객 중심 아닌 프로젝트가 있었겠습니까. 하지만 일을 요청하는 자와 프로그램을 만들어 내는 사람과의 생각의 단절 때문에 소프트웨어 프로젝트가 힘들지 않나 생각해봅니다.

가슴아픈 부분도 있습니다.
증상:"고객이 스토리를 작성하고 거기에 우선순위를 부여하는 책임을 지지 않으려고 한다"
논의:비난이 난무하는 조직에서는 모든 책임을 회피하는 것이 최선이라고 아는 사람들이 있기 마련이다. 책임이 있는 일이 아니라면 실패한다고 비난 받을 이유가 없으며, 그러면서도 성공했을 때는 거기에 기여했다는 명분을 가질 수 있다. 이러한 문화에 젖은 사람들은 릴리즈에 포함할 것들의 우선순위를 결정하는 것과 같이 결정하기 힘든 문제에 관여하지 않으려고 한다. 그들은 한발짝 물러서서 "당신이 마감 기일에 맞추어 모든 것을 완성하지 못하는 것은 내 문제가 아니니 당신이 알아서 하라."하고 말할 것이다.
from: 사용자 스토리, 마이크 콘, 인사이트, 224p

아, 맘 아픕니다. 책은 잘 읽었고, 몸으로 읽으려면 머리 좀 많이 써야할 것 같습니다.
http://okjsp.tistory.com2009-04-29T18:21:240.3810
저작자표시 비영리 변경금지
사용자 스토리10점
사용자 스토리의 세 가지 요소는 서술(written description), 대화(conversation), 테스트(test) 라고 합니다. 사용자가 고객이냐 의뢰인이냐 아니면 다른 개발자이냐에 따라서 사용하는 용어들이 제한됩니다. 고객이나 의뢰인에게는 자바, log4j, cache등의 용어를 사용하지 않습니다. 대신 애플리케이션의 기능과 할 수 있는 작업에 대한 용어들로 사용자 스토리가 정해집니다. 함께 일을 하는 그룹들과는 좀 더 기술적인 얘기들로 채워지겠죠.

여튼 읽기 시작했습니다. 고객 중심의 요구사항 기법 "사용자 스토리(User Stories Applied)" 프로그래머들이 제일 힘들어하는 고객의 말 바꾸기에 대응할 수 있는 고객이 무엇을 원하는지 뽑아내는 방법을 기대해 봅니다. 사실 자기가 무엇을 원하는지 구체적으로 알고 프로그램을 의뢰하는 경우는 드물기 때문입니다. 그것을 제한된 시간과 자금 하에서 효과적으로 뽑아내는 일이 함께 하지 않으면 비행기 만들어 달라고 요청받고 나중에 우주선 내놓으라는 식이 될테니까요.
http://okjsp.tistory.com2009-04-23T05:47:330.31010
저작자표시 비영리 변경금지

+ Recent posts

티스토리툴바