애자일 / 스크럼 팀의 버그 워크 플로우는 무엇입니까?

애자일 / 스크럼 팀의 버그 워크 플로우는 무엇입니까?

-버그가 현재 스프린트의 스토리와 관련이있는 경우 수정합니다. -버그가 현재 스프린트의 스토리와 관련이없고 중요하지 않은 경우 우선 순위를 정하기 위해 제품 소유자에게 전송됩니다. -버그가 스프린트의 스토리와 관련이없고 중요하다면 버그를 수정합니다.

현재 스프린트에서 작동하는 것과 관련된 모든 것이 수정되었습니다. 버그를 고려하지 않고 버그를 기록하지도 않습니다. 우리는 이미 완료된 것으로 간주되는 버그 일 경우에만 버그를 고려합니다.

새로운 버그가 발생하면이를 백 로그에 추가하고 이해 관계자가 우선 순위를 정합니다. 스프린트에 남은 시간이 있다면 우선 순위는 낮지 만 남은 시간에 완료 할 수있는 더 쉬운 버그를 해결하는 경향이 있습니다.

나는 항상 버그가 이미 테스트에 실패한 이야기라고 생각했기 때문에 기능에 대한 일반적인 첫 번째 이야기 초안보다 더 잘 정의되었습니다.

따라서 버그가 스토리라고 확신하면 추정 및 우선 순위와 관련하여 다른 스토리와 마찬가지로 버그를 처리합니다.

이것에 접근하는 가장 좋은 방법은 실제로 버그를 먼저 고려할 것을 결정하는 것입니다.

많은 개발자들은 솔직히 버그가 아니기 때문에 현재 버그가 아닌 것으로 생각하고있는 것처럼 작동하지 않는 것을 고려하지 않을 것입니다. 현재 작업 중인데 여전히 결함이있는 경우 특정 버그가 실제로 완료되지 않았으므로 실제 결함이 없습니다. 역이 완성 된 작업에 적용됩니다. 무언가가 완성되어 테스트 / 릴리스 / 생산 준비가되었고 나중에 코드 나 사용에 결함이 발견되면 분명히 버그가있는 것입니다.

우리 회사는 다음 방법론을 사용하여 버그 수정시기를 결정합니다.

버그가 중요한 경우 해당 제품과 관련된 현재 스프린트에 적절한 우선 순위로 버그가 추가됩니다. 일반적으로 스프린트에이를 위해 약 10 %의 추가 시간을 계획하고 실제로 완료 할 계획이 아닌 추가 작업을 수행하지만 버그가 없거나 예상보다 더 빨리 완료된 경우 완전한.

버그가 중요하지 않은 경우 간단히 백 로그에 버그를 추가하고 일반적으로 다음 스프린트에서 완료합니다.

이것이 이상적인 흐름 인 이유는 명백한 누출이 있으며 때로는 경영진이 생각보다 빨리 완료해야한다고 결정하면 프로그래밍 관점에서 중요하지 않은 사항을 즉시 완료해야 할 수도 있습니다. 완료되었습니다.

제쳐두고 나는 최선의 방법은 구조를 고른 다음 고집하는 것이라고 생각합니다. 구조없이 작업을 시작하면 생산성에 대한 가장 큰 손실이 발생하기 시작합니다. 일단 구조를 분해하기 시작하면 내리막 길로가는 것이 매우 쉽습니다.

그것은 귀하의 질문에 과도하게 대답했을 수도 있지만, 이것들은 어떻게 처리 해야하는지에 대한 나의 생각입니다.

우리는 지속적인 결함 작업을 수행합니다. 설정과 마찬가지로 현재 작업과 관련된 중요한 문제가있는 경우 작업의 일부로 해결합니다. 결국, 관련된 결함이 있다면 이야기를 "완료"라고 부를 수 없습니다.

다른 버그의 경우 일반적으로 시간이 허락하는대로 수정합니다. 긴급한 문제가있는 경우 정상적인 기능 작업으로 돌아 가기 전에 몇 가지 이야기를 철회하고 버그 수정에 시간을 투자합니다.

스프린트 동안 발견 된 버그는 개발의 일부일뿐입니다.

스프린트 종료 후 발견 된 버그는 제품 백 로그에 들어갑니다. 우리는 무언가 버그 또는 개선 또는 변경이 있는지 사용자와 논쟁하지 않습니다. 사용자가 버그라고 부르고 싶다면 괜찮지 만 여전히 다른 새로운 작업으로 PB에 들어갑니다.