Bugzilla에서 사용자 스토리를 어떻게 구현해야합니까? [닫은

Question

저의 작업에 참여한 몇몇 개인은 일부 민첩한 소프트웨어 개발 / 프로젝트 관리 원칙을 구현하는 이점을 분석하는 그룹을 구성하기 위해 모였습니다.

개발자로서 저는 사용자 스토리에서 큰 이점을 볼 수 있습니다. 우리는 현재 릴리스의 단계를 모니터링하고 향후 릴리스를 계획하는 데 사용할 수있는 정보 라디에이터를 구성하려고합니다. 이 프로세스에 사용자 스토리를 사용하고 싶습니다.

현재 우리는 문제 추적을 위해 Bugzilla를 사용하고 있습니다. 대부분의 릴리스 계획은이 시스템의 버그를 사용하여 수행됩니다. Bugzilla의 사용은 아마도 변하지 않을 것입니다. 적절한 비용 ($ 0)에서 필요한 대부분을 제공합니다.

한 가지 문제는 사용자 스토리를 버그에 매핑하는 것입니다. 릴리스 관리는 현재 버그 번호를 사용하여 수행됩니다. 문제는 하나의 사용자 스토리에 세 가지 버그 또는 그 반대가 포함될 수 있다는 것입니다.

단일 사용자 스토리에 대해 여러보고 된 버그를 갖는 시나리오에서 한 가지 아이디어는 스토리를 철자하고 해당 스토리를 구성하는 어린이 버그에 대한 종속성을 설정하는 사용자 스토리 버그를 갖는 것입니다. 나는 이것이 너무 복잡 해지고 이해 관계자, 개발 및 QA 사이에 혼란을 야기 할까 걱정됩니다. 또한, 그것은 Bugzilla를 상당히 혼란스럽게 할 것입니다.

이미이 길에있는 사람이 있습니까? 그렇다면 무엇을 했습니까? Bugzilla에서 사용자 스토리에 대한 아이디어를 포기해야합니까? 더 간단한 솔루션이 있습니까?

모든 생각은 감사 할 것입니다.

Answer 1

나는 Bugzilla에서 비슷한 일을했으며, 내가 찾은 해결책은 계층 적 "스토리 버그"등을 구현하지 않는 것이 었습니다. 우리는 또한 혼란을 야기 할 것이라고 결정했고 우리가 원하는 것에 너무 복잡했습니다. 내가 이전에 사용한 솔루션은 단순히 버그 설명에 사용자 스토리 번호를 넣는 것입니다. 링크를 버릴 수 있도록 링크를 버릴 수 있습니다. 약간 패치 워크이지만 꽤 잘 작동합니다.

Answer 2

사용자 스토리에 하나 이상의 버그 사례가 필요하다면 너무 큽니다. 필요한 기능의 추상화로 사용자 스토리를 작은 것들로 나누어 스토리 당 하나의 사례 만 필요합니다. 그런 다음 그런 식으로 계획하고 진행할 수 있습니다.

우리는 접근 방식을 사용하려고 노력했습니다 @mcwafflestix 사례에서 사용자 스토리의 공식 (Wiki) 문서에 대한 링크가 포함되어 있지만, 얼마 후에 우리는 더 작은 사용자 스토리를 만드는 것이 더 좋다는 것을 발견했습니다. 각 사용자 스토리가 다음과 같이 구현되기 때문에 더 나은 응용 프로그램 디자인으로 이어집니다. 가능한 한 추상화되어 코드의 더 나은 테스트 가능성과 유지 관리 가능성을 제공합니다.

Answer 3

Bugzilla에서 의존성 링크 사용이 스토리 추적에 사용되는지 여부에 관계없이 스토리에서 키워드를 사용하는 것이 좋습니다. 우리는 '이야기'를 사용합니다. 키워드를 사용하면 제품 트리의 스토리 대 버그를 쉽게 추적 할 수 있습니다. 또한 Bugzilla 설치에서 시간 추적을 사용하는 것이 좋습니다. 시간이 이야기에서만 추적 되더라도.