기억을 지배하는 기록

사용자 스토리의 장점 구두 의사소통 모든 것을 기록하고 기록된 사항에 모두가 동의했다면, 어떠한 의견 차이도 발생하지 않을 것이며, 개발자들은 정확히 무엇을 만들어야 하는지 알고 테스터들은 정확히 무엇을 테스트해야 하는지 알며, 무엇보다 고객들은 정확히 자신들이 원하는 것..

사용자 스토리는 IEEE 830이 아니다. Tip : IEEE 830 IEEE 컴퓨터학회에서는 소프트웨어 요구사항 명세서 작성에 관한 가이드라인을 출판하였다. ‘IEEE 830’이라 알려진 이 문서는 1998년에 최종적으로 개정되었다. 이 문서는 요구사항 명세 문서를 어떻게 구조화하는지, 프로토타이핑의 역할은 ..

각 이터레이션에 포함되는 일정한 스토리 점수를 프로젝트의 속도라고 한다. 처음 프로젝트를 계획할 때는 과거 수행한 유사 프로젝트의 속도를 그대로 사용하거나 새롭게 만들어 새 프로젝트의 속도를 정할 수 있었다. 속도는 계획뿐만 아니라 관리 도구로도 유용하게 사용될 수 있기 ..

이터레이션을 계획하기 위해서는 팀 전체가 이터레이션 계획 회의에 참석해야 한다. 모든 개발자 뿐만 아니라 고객도 회의에 참석해야 한다. 회의에서는 스토리들을 좀더 세부적으로 살펴볼 것이므로 여러 가지 의문이 생길 것이다. 이러한 물음에 답할 수 있는 고객이 곡 참석해야 한다...

대부분의 소프트웨어 프로젝트에서는 두 달에서 여섯 달마다 새로운 릴리즈를 내놓는 것이 가장 좋다. 웹사이트 프로젝트 같은 경우는 이보다 더 자주 릴리즈하는 경우도 있다. 향후 몇 차례의 릴리즈에 포함될 주용 내용을 정리한 제품 개발 로드맵이 있다면 그것을 바탕으로 릴리즈 계..

목적 스토리로 시작하라 대규모 프로젝트, 특히 사용자 역할이 많고 다양한 프로젝트는 스토리 식별에 있어 막막한 경우가 있다. 이럴 때는 한번에 하나씩 사용자 역할을 선택하여 그 사용자가 새 시스템을 사용하는 주 목적을 식별하는 것이 가장 효과적이다. 케이크 자르듯 나누어라 큰..

인수 테스트를 작성하는 이유 중 하나는 고객과 개발자가 대화를 나누는 과정에서 언급된 세부사항들을 나타내기 위함이다. 사용자 스토리에서는 세부사항을 테스트로 표현한다. 나중에 무엇을 테스트할지에 관한 짧은 메모를 스토리 카드 뒷면에 짧게 적어 놓는다. 향후 만들어지는 테..

사용자가 소프트웨어에 원하는 바를 다른 사람이 짐작할 수도 있지만, 실제 사용자만이 정확히 알 수 있다. 하지만 제품에 대해 다양한 의견을 내줄 실제 사용자를 확보하지 못한다면, “대리 사용자(User Proxy)”에 의존해야 할 것이다. 대리 사용자는 실제 사용자는 아니지만, 프로젝트상..