버그 수정을 스크럼 프로세스에 맞추는 가장 좋은 방법은 무엇입니까? [닫은]

저는 지난 며칠 동안 스크럼에 대해 공부하고 읽었으며 Sprint Planning 및 작업에 대해 읽었습니다. 내 마음에 떠오른 한 가지 문제는 Scrum에서 버그를 처리하는 방법입니다. Henrik Kniberg는 그의 저서 Scrum and XP from the Trenches 에서이 문제를 다루는 몇 가지 방법을 나열합니다 .

1. 제품 소유자는 우선 순위가 가장 높은 Jira 항목을 인쇄하여 스프린트 계획 회의에 가져 와서 다른 스토리와 함께 벽에 붙입니다 (이렇게하면 다른 스토리와 비교하여 이러한 항목의 우선 순위를 암시 적으로 지정 함).
2. 제품 소유자는 Jira 항목을 참조하는 스토리를 만듭니다. 예 :“가장 중요한 백 오피스보고 버그, Jira-124, Jira- 126 및 Jira-180 수정”.
3. 버그 수정은 스프린트 외부에있는 것으로 간주됩니다. 즉, 팀은 버그를 수정할 시간을 확보 할 수 있도록 충분히 낮은 초점 요소 (예 : 50 %)를 유지합니다. 그런 다음 팀이 Jira가보고 한 버그를 수정하는 데 각 스프린트마다 일정 시간을 소비 할 것이라고 가정합니다.
4. 제품 백 로그를 Jira에 넣습니다 (예 : Excel 도랑). 다른 이야기처럼 버그를 다루십시오.

이것이 정말로 프로젝트별로 결정되어야하는 것입니까, 아니면 더 나은 솔루션이 있습니까? 각 접근 방식의 문제점을 생각할 수 있습니다. 이러한 접근 방식에서 가장 잘 작동하는 하이브리드가 있습니까? 프로젝트에서 이것을 어떻게 처리합니까?

이것은 매우 좋은 질문이며이 문제에 대한 다른 접근 방식과 관련하여 몇 가지 관찰이 있습니다.

1. 백 로그 항목으로 모든 버그를 동일하게 처리하는 것은 이론적으로는 좋은 생각처럼 들릴 수 있지만 (한 곳에서 작업을 추적) 실제로는 제대로 작동하지 않습니다. 버그는 일반적으로 저수준이고 더 많으므로 각 버그에 대해 개별 사용자 스토리를 작성하면 "실제"스토리가 곧 모호해질 것입니다.
2. 수정을 위해 예약 된 각 스프린트의 명시적인 시간은 제품 소유자가 볼 수있는 방식으로 수행하면 괜찮습니다. 버그는 일일 스크럼 중에 언급되어야하며 수정 된 버그에 대한 논의는 스프린트 검토 중에 발생해야합니다. 그렇지 않으면 제품 소유자가 프로젝트에서 무슨 일이 일어나고 있는지 알 수 없습니다.
3. 전체 백 로그를 버그 추적 도구에 넣으면 1과 동일한 문제가 발생합니다. 더욱이 대부분의 버그 추적기는 스크럼을 염두에두고 설계되지 않았으며 이러한 목적으로 사용하는 것은 고통 스러울 수 있습니다.

가장 만족스러운 솔루션은 모든 스프린트에 "티켓"또는 "버그"라는 단일 사용자 스토리를 배치하는 것이 었습니다. 그런 다음 이러한 스토리는 특정 버그를 설명하는 하위 수준 작업 (계획 중에 알려진 경우) 또는 일반적인 버그 수정을 위해 주어진 시간을 예약하는 메타 작업으로 나눌 수 있습니다. 이렇게하면 제품 소유자가 프로세스를 볼 수 있으며 번 다운 차트에 진행 상황이 반영됩니다.

실제로 새로운 기능인 모든 "버그"를 무자비하게 닫고 새로운 백 로그 항목을 생성하는 것을 잊지 마십시오. 또한 스프린트가 완료된 것으로 간주하려면 스프린트가 끝나기 전에 현재 스프린트에 대해보고 된 모든 버그를 수정해야합니다.

실제로 나는 이 질문에서 jpeacock의 대답이 최선이라고 생각합니다 . 버그 수정에 소요 된 시간을 스크럼으로 계산합니까?

인용하겠습니다.

• 버그가 수정하기 쉽고 빠르면 (라이너 1 개 등) 수정하면됩니다.
• 버그가 사소하지 않고 차단기가 아니라면 백 로그에 추가하십시오.
• 버그가 차단기 인 경우 작업 (현재 스프린트에)을 추가하여 수정하는 데 필요한 작업을 캡처하고 작업을 시작합니다. 사용 가능한 총 시간이 변경되지 않았으므로 새 시간을 설명하기 위해 다른 항목 (현재 스프린트에서)을 백 로그로 이동해야합니다.

첫 번째 단계는 버그가 무엇인지 정의하는 것입니다. 버그는 의도 / 설계된대로 프로덕션에서 작동하지 않는 기능인 경우에만 버그라고 가르칩니다. 이들은 새로운 개발에 대해 우선 순위가 지정되는 버그 유형 PBI가됩니다. 프로덕션에서 누락 된 기능은 기능이며 정상적인 제품 백 로그 항목이됩니다. 스프린트 중에 발견 된 결함있는 코드는 불완전한 작업으로 간주되며 현재 작업이 완료 될 때까지 다음 스토리로 이동하지 않기 때문입니다. 팀은 항상 문제가되는 코드를 작업하기 때문에 스프린트에서 이러한 결함을 추적 할 필요가 없습니다. 포스트잇은 팀 동료들 사이에 빠른 알림을 위해 여기에서 매우 편리 할 수 ​​있습니다. 손상된 코드를 수정하는 것은 항상 새 코드를 작성하는 것보다 우선합니다.

재고는 낭비입니다. 버그 추적은 인벤토리입니다. 버그 추적은 낭비입니다.

백 로그 항목으로 모든 버그를 동일하게 처리하는 것은 이론적으로는 좋은 생각처럼 들릴 수 있지만 (한 곳에서 작업을 추적) 실제로는 제대로 작동하지 않습니다. 버그는 일반적으로 저수준이고 더 많으므로 각 버그에 대해 개별 사용자 스토리를 작성하면 "실제"스토리가 곧 모호해질 것입니다.

기능보다 더 많은 버그가있는 경우 엔지니어링 관행에 대해 작업해야합니다. 이것은 다른 것이 잘못되었고 추적이 답이 아니라는 냄새입니다. 더 깊이 파헤쳐 라. 사실 벌레는 항상 냄새가납니다. 그것들은 멋지지 않으며 많은 경우 근본 원인을 찾아 제거하고 버그 추적에 집중하지 않아야합니다.

목록에서 결함을 추적하지 말고 찾아서 수정하십시오-Mary Poppendieck

실제로 재고가 낭비라면 결함 재고는 어떻습니까?

그래서 저는 항상 테스트 중심 개발과 지속적인 통합을 통해 Stop-the-Line 정신 을 구현하려고 노력하여 대부분의 결함을 재 작업 목록에 올리는 대신 찾아 수정합니다.

그리고 결함이 통과하면 새 코드를 작성하기 전에이를 수정합니다 (버그가있는 이야기는 어쨌거나 완료되지 않음). 그런 다음 프로세스를 수정하여 오류를 방지하고 결함이 발생하는 즉시 감지합니다.

모든 솔루션에 맞는 하나의 크기는 없으며 각 프로젝트는 다릅니다. 버그는 미션 크리티컬에서 거의 고칠 가치가없는 것으로 분류 될 수도 있습니다.

시스템 실행에 중요하지 않은 이상 버그가 스토리 카드가되는 것을 선호합니다. 이는 기능 개발과 버그 수정의 우선 순위를 매우 명확하게 만듭니다. 버그 수정이 "스프린트 외부"로 간주되는 시나리오에서 버그 수정은 정말 사소한 버그를 수정하는 방향으로 이동할 수 있지만 정말 중요한 비즈니스 기능은 개발되지 않습니다.

우리는 버그를 스토리 접근 방식으로 설정하기 전에 많은 순열을 검토했습니다. 몇 가지 다른 것을 시도하고 팀 복고풍 회의에서 재생하십시오.

우리의 경우 (그린 필드 개발, 2-3 명의 개발자) 발견 된 버그가 기록되고 버그로 명확하게 표시되며 심각도에 따라 다음 반복에 할당되거나 백 로그에 남습니다. 중요하고 긴급한 버그의 경우 진행중인 반복에 추가됩니다.

버그를 수정하는 것만 큼 간단한 것이 규칙과 복잡한 이유를 모르겠습니다. 스크럼에는 규칙이 거의 없습니다. 기억하십니까? 모든 기능, 지원, 권장 사항 또는 결함은 Scrum의 백 로그 문제이며 차별화가 없습니다. 따라서 스크럼 가이드에 따르면 Sprint의 작업은 계획 회의 중에 결정한 내용으로 제한되지 않습니다. Daily Scrum은 사람들이 "장애물"에 대해 논의하는 데 도움이됩니다.

왜?

따라서 결함, 즉 백 로그 문제가 PBI에 들어가거나이 스프린트에 남아 전달하기를 원하는 경우 팀으로서 합리적으로 논의하고 생각합니다.

더 나은 질문은 개발 단계에서 버그 생성을 중지하는 방법입니다. 참조-> http://bit.ly/UoTa4n

버그를 식별하고 문서화하는 경우 나중에 분류하고 수정해야합니다. 이것은 "안정화 스프린트", 즉 버그를 수정하기위한 하나의 전체 스프린트로 이어집니다. 또는 백 로그에 다시 추가하고 향후 스프린트의 일부로 우선 순위를 지정할 수 있습니다. 이는 또한 귀하가 알려진 버그 (P3 및 P4 일명 외형 및 사소함)가 포함 된 소프트웨어를 제공하고 로그 오프하고 출시 할 예정임을 의미합니다.

이것은 정말 민첩하지 않습니까?

나는 우리 프로젝트에서 세 번째 스프린트마다 짧은 버그 수정 스프린트를 도입하는 아이디어를 표명했습니다. 현재 스프린트는 3 주입니다.

아이디어는 모든 개발자가 함께 버그 수정에 집중할 수 있도록하고, 정기적 인 스프린트에서 새로운 이야기에만 집중할 수 있도록하며, 기술 부채를 줄이는 데 정기적으로 집중할 수 있도록하는 것입니다.

버그 수정은 관련 스토리로 그룹화되고 우선 순위가 지정됩니다. 개발자가 결함의 특성을 이해하지 않고 버그 수정 크기를 조정하는 데 어려움을 겪기 때문에 스프린트 전에 크기 조정에 중점을 두지 않습니다.

누구든지 이것을 시도했거나 이것이 작동 할 것이라고 생각하는 피드백이 있습니까?

건배, 케빈.