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

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

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

아, 맘 아픕니다. 책은 잘 읽었고, 몸으로 읽으려면 머리 좀 많이 써야할 것 같습니다.
http://okjsp.tistory.com2009-04-29T18:21:240.3810

+ Recent posts