버그 수정을 스크럼 프로세스에 맞추는 가장 좋은 방법은 무엇입니까? [닫은]
저는 지난 며칠 동안 스크럼에 대해 공부하고 읽었으며 Sprint Planning 및 작업에 대해 읽었습니다. 내 마음에 떠오른 한 가지 문제는 Scrum에서 버그를 처리하는 방법입니다. Henrik Kniberg는 그의 저서 Scrum and XP from the Trenches 에서이 문제를 다루는 몇 가지 방법을 나열합니다 .
- 제품 소유자는 우선 순위가 가장 높은 Jira 항목을 인쇄하여 스프린트 계획 회의에 가져 와서 다른 스토리와 함께 벽에 붙입니다 (이에 따라 다른 스토리와 비교하여 이러한 항목의 우선 순위를 암시 적으로 지정).
- 제품 소유자는 Jira 항목을 참조하는 스토리를 만듭니다. 예 :“가장 중요한 백 오피스보고 버그, Jira-124, Jira- 126 및 Jira-180 수정”.
- 버그 수정은 스프린트 외부에있는 것으로 간주됩니다. 즉, 팀은 버그를 수정할 시간을 확보 할 수 있도록 충분히 낮은 초점 요소 (예 : 50 %)를 유지합니다. 그런 다음 팀이 Jira가보고 한 버그를 수정하는 데 각 스프린트마다 일정 시간을 소비 할 것이라고 가정합니다.
- 제품 백 로그를 Jira에 넣습니다 (예 : Excel 도랑). 다른 이야기처럼 버그를 다루십시오.
이것이 정말로 프로젝트별로 결정되어야하는 것입니까, 아니면 더 나은 솔루션이 있습니까? 각 접근 방식의 문제점을 생각할 수 있습니다. 이러한 접근 방식에서 가장 잘 작동하는 하이브리드가 있습니까? 프로젝트에서 이것을 어떻게 처리합니까?
이것은 매우 좋은 질문이며이 문제에 대한 다른 접근 방식과 관련하여 몇 가지 관찰이 있습니다.
- 백 로그 항목으로 모든 버그를 동일하게 처리하는 것은 이론적으로는 좋은 생각처럼 들릴 수 있지만 (한 곳에서 작업을 추적) 실제로는 제대로 작동하지 않습니다. 버그는 일반적으로 저수준이고 더 많기 때문에 각 버그에 대해 개별 사용자 스토리를 생성하면 "실제"스토리가 곧 모호해질 것입니다.
- 수정을 위해 예약 된 각 스프린트의 명시적인 시간은 제품 소유자가 볼 수있는 방식으로 수행하면 괜찮습니다. 버그는 일일 스크럼 중에 언급되어야하며 수정 된 버그에 대한 논의는 스프린트 검토 중에 발생해야합니다. 그렇지 않으면 제품 소유자가 프로젝트에서 진행되는 작업을 인식하지 못합니다.
- 전체 백 로그를 버그 추적 도구에 넣으면 1에서와 동일한 문제가 발생합니다. 게다가 대부분의 버그 추적기는 스크럼을 염두에두고 설계되지 않았으며 이러한 목적으로 사용하는 것은 고통 스러울 수 있습니다.
가장 만족스러운 솔루션은 모든 스프린트에 "티켓"또는 "버그"라는 단일 사용자 스토리를 배치하는 것이 었습니다. 그런 다음 이러한 스토리는 특정 버그를 설명하는 하위 수준 작업 (계획 중에 알려진 경우) 또는 일반적인 버그 수정을 위해 주어진 시간을 예약하는 메타 작업으로 나눌 수 있습니다. 이렇게하면 제품 소유자가 프로세스를 볼 수 있으며 번 다운 차트에 진행 상황이 반영됩니다.
실제로 새로운 기능인 모든 "버그"를 무자비하게 닫고 새로운 백 로그 항목을 생성하는 것을 잊지 마십시오. 또한 스프린트가 완료된 것으로 간주하려면 스프린트가 끝나기 전에 현재 스프린트에 대해보고 된 모든 버그를 수정해야합니다.
실제로이 질문에 대한 jpeacock의 답변이 최선이라고 생각합니다 . 버그 수정에 소요 된 시간을 스크럼으로 계산합니까?
인용하겠습니다.
- 버그가 수정하기 쉽고 빠르면 (라이너 1 개 등) 수정하면됩니다.
- 버그가 사소하지 않고 차단기가 아니라면 백 로그에 추가하십시오.
- 버그가 차단기 인 경우 작업 (현재 스프린트에)을 추가하여 수정하는 데 필요한 작업을 캡처하고 작업을 시작합니다. 사용 가능한 총 시간이 변경되지 않았으므로 새 시간을 설명하기 위해 다른 항목 (현재 스프린트에서)을 백 로그로 이동해야합니다.
첫 번째 단계는 버그가 무엇인지 정의하는 것입니다. 버그는 의도 / 설계된대로 프로덕션에서 작동하지 않는 기능인 경우에만 버그라고 가르칩니다. 이들은 새로운 개발에 대해 우선 순위가 지정되는 버그 유형 PBI가됩니다. 프로덕션에서 누락 된 기능은 기능이며 정상적인 제품 백 로그 항목이됩니다. 스프린트 중에 발견 된 결함 코드는 불완전한 작업으로 간주되며 현재 작업이 완료 될 때까지 다음 스토리로 이동하지 않기 때문입니다. 팀은 항상 문제가되는 코드를 작업하기 때문에 스프린트에서 이러한 결함을 추적 할 필요가 없습니다. 포스트잇은 팀 동료들 사이에 빠르게 알림을 보낼 때 매우 편리합니다. 손상된 코드를 수정하는 것은 항상 새 코드를 작성하는 것보다 우선합니다. 결함이 이야기의 오해로 인한 것이라면 이야기를 시작하기 전에 수용 조건에 대해 작업해야합니다.
재고는 낭비입니다. 버그 추적은 인벤토리입니다. 버그 추적은 낭비입니다.
백 로그 항목으로 모든 버그를 동일하게 처리하는 것은 이론적으로는 좋은 생각처럼 들릴 수 있지만 (한 곳에서 작업을 추적) 실제로는 제대로 작동하지 않습니다. 버그는 일반적으로 저수준이고 더 많기 때문에 각 버그에 대해 개별 사용자 스토리를 생성하면 "실제"스토리가 곧 모호해질 것입니다.
기능보다 버그가 더 많으면 엔지니어링 관행에 대해 작업해야합니다. 이것은 다른 것이 잘못되었고 추적이 답이 아니라는 냄새입니다. 더 깊이 파헤쳐 라. 사실 벌레는 항상 냄새가납니다. 그것들은 멋지지 않으며 많은 경우 근본 원인을 찾아 제거하고 버그 추적에 집중하지 않아야합니다.
목록에서 결함을 추적하지 말고 찾아서 수정하십시오-Mary Poppendieck
실제로 재고가 낭비라면 결함 재고는 어떻습니까?
그래서 저는 항상 테스트 중심 개발과 지속적인 통합을 통해 Stop-the-Line 정신 을 구현하려고 노력하여 대부분의 결함을 재 작업 목록에 올리는 대신 찾아 수정합니다.
그리고 결함이 통과하면 새 코드를 작성하기 전에이를 수정합니다 (버그가있는 이야기는 어쨌거나 완료되지 않음). 그런 다음 프로세스를 수정하여 오류를 방지하고 결함이 발생하는 즉시 감지합니다.
모든 솔루션에 맞는 하나의 크기는 없으며 각 프로젝트는 다릅니다. 버그는 미션 크리티컬에서 거의 고칠 가치가없는 것으로 분류 될 수도 있습니다.
시스템 실행에 중요하지 않은 이상 버그가 스토리 카드가되는 것을 선호합니다. 이는 기능 개발과 버그 수정의 우선 순위를 매우 명확하게 만듭니다. 버그 수정이 "스프린트 외부"로 간주되는 시나리오에서 버그 수정은 정말 사소한 버그를 수정하는쪽으로 이동할 수 있지만 정말 중요한 비즈니스 기능은 개발되지 않습니다.
버그를 스토리 접근 방식으로 설정하기 전에 여러 가지 순열을 검토했습니다. 몇 가지 다른 것을 시도하고 팀 복고풍 회의에서 재생하십시오.
우리의 경우 (그린 필드 개발, 2-3 명의 개발자) 발견 된 버그가 기록되고 버그로 명확하게 표시되며 심각도에 따라 다음 반복에 할당되거나 백 로그에 남습니다. 중요하고 긴급한 버그의 경우 지속적인 반복에 추가됩니다.
I don't know why something as simple as fixing bugs is complicated with rules.. Scrum has very few rules, remember? Every feature, Support, Recommendation or Defect is a Backlog issue in Scrum, there is no differentiation. So, as the Scrum guide says: the tasks in a Sprint are never limited to what you decide during the planning meeting the Daily Scrum helps people discuss "impediments" along their way.
Why?
So you discuss and think rationally as a team if you want the defect i.e. backlog issue to go into PBI or remain in this Sprint and deliver it...
Better question is how do I stop creating bugs in development phase? see--> http://bit.ly/UoTa4n
If you are identifying and documenting bugs you will have to triage and fix then at some future time. This leads to "stabilisation sprints" i.e. one whole sprint just to fix bugs. Or you can add them back to the backlog and prioritise them as part of some future sprint. It also means that you will are providing and expect to get signed off and released software with known bugs in it (P3 & P4 aka cosmetic and minor).
This is not really agile?
I have tabled the idea in our project to introduce a short bug fix sprint every third sprint. Our current sprints are three weeks.
The idea is that it will allow all dev to focus on bug fixing together, allow focus on just new stories in regular sprints and keeps a regular focus on reducing tech debt.
Bug fixes will be grouped into relevant stories and prioritised. Emphasis is not on sizing before the sprint as devs struggle to size bug fixes without getting stuck in to understand the nature of the defect.
Has anyone tried this or have any feedback on how they think this might work?
Cheers, Kevin.
참고URL : https://stackoverflow.com/questions/1593328/best-ways-to-fit-bug-fixing-into-a-scrum-process
'program story' 카테고리의 다른 글
| Oracle 저장 프로 시저에서 "AS"와 "IS"의 차이점은 무엇입니까? (0) | 2020.09.12 |
|---|---|
| Google Play 스토어에 내 Android 앱이 내 기기와 호환되지 않는다고 표시되는 이유는 무엇입니까? (0) | 2020.09.12 |
| Android 카메라 방향을 올바르게 설정하는 방법은 무엇입니까? (0) | 2020.09.12 |
| Scala의 "new"키워드 (0) | 2020.09.12 |
| 트위터 부트 스트랩으로 작업하는 HTML 이메일을받은 사람이 있습니까? (0) | 2020.09.12 |