답변:
이상적으로는 반복 할 때마다 소프트웨어에 버그가 없어야하고 버그를 수정하는 것이 각 스프린트의 일부 여야하므로 스토리 포인트를 지정할 때 버그 수정에 필요한 작업을 고려해야합니다 (즉, 버그를 생성 할 가능성이 높은 작업은 더 많은 스토리 포인트가 할당되어 있습니다).
그러나 실제로는 테스트가 얼마나 엄격한 지에 상관없이 버그가 배포 후 항상 드러납니다. 이런 일이 발생하면 버그를 제거하는 것이 또 다른 변경 사항입니다. 이 상황에서 버그 보고서와 기능 요청 간에는 근본적인 차이가 없습니다. 두 경우 모두 응용 프로그램에 특정 동작이 표시되고 사용자 (또는 다른 이해 관계자)는 변경 내용을보고 싶어합니다.
비즈니스 관점에서 볼 때 버그 수정 및 기능도 동일합니다. 실제로는 (시나리오 B) 그렇지 않거나 (시나리오 A); 두 시나리오 모두 비용과 혜택이 첨부되어 있으며, 적절한 비즈니스 담당자는이를 평가하고 더 많은 수익을 올리는 모든 것 (비즈니스 전략에 따라 장기 또는 단기)으로 진행합니다.
그렇습니다. 스토리 포인트를 버그에 할당하십시오. 버그 대 기능 및 버그에 대한 버그의 우선 순위를 어떻게 다른가? 두 가지 모두에 대한 개발 노력이 어느 정도 필요하며 비교하는 것이 좋습니다.
이것의 가장 큰 문제점은 버그 수정이 종종 추정하기 어렵다는 것입니다. 실제 노력의 90 % 이상이 원인을 찾는 데 있습니다. 일단 발견하면 정확한 추정치를 얻을 수 있지만 검색에 걸리는 시간을 판단하는 것은 거의 불가능합니다. 심지어 버그를 재생산 하는 데 대부분의 시간이 소요되는 버그에 대해서도 꽤 많이 보았습니다 . 반면에 버그의 특성에 따라 추정하기 전에 최소한의 조사만으로 검색 범위를 좁힐 수 있습니다.
포인트로 버그를 추정하는 것은 본질적으로 다른 답변에서 이미 지적했듯이 본질적으로 어렵습니다. 이상적인 해결책은 스프린트가 승인 된 후 기능에서 발견 된 버그가 새로운 기능으로 간주되어야한다는 것 입니다.
그러나 버그에 대한 이러한 포인트 평가의 어려움은 Agile PM 소프트웨어 패키지가 태스크와 버그를 몇 시간 안에 예상 할 수있게하는 여러 가지 이유 중 하나입니다. 포인트 평가에 숙련되기 위해서는 근면과 경험이 필요하기 때문입니다. 많은 프로젝트는 속도를 올바르게 결정하는 데 심각한 문제가 있으므로 많은 애자일 프로젝트는 포인트를 사용하여 스프린트에 어떤 스토리를 만드는지 결정하지만 번 다운 차트를 계산할 때 시간을 사용 합니다.
스프린트 커밋을 결정하는 데 시간 추정치가 사용되지 않는 한, 직관적이지만 반가운 것처럼 보입니다. 초과 커밋은 자연스럽게 누락되거나 불완전한 기능 또는 초과 근무로 이어질 수 있으므로 시간이 지남에 따라 모든 관련 포인트는 포인트 추정에서 더 나은 결과를 얻도록 강제됩니다.
당신은 안 버그 해상도로 포인트를 준다. 버그가 개발자가 이미 스토리를 완료 한 포인트 를 얻은 스토리에서 발생한다는 사실을 고려하십시오 . 실제로 처음부터 포인트를 얻지 말아야 할 포인트를 다시 받지 않아야 합니다.
버그 수정은 속도에 부정적인 영향 을 미칩니다 . 그렇지 않으면 떨어지는 품질은 영향을받지 않거나 심지어 증가 된 속도로 보상됩니다!
아마도 유용한 링크 :
버그를 사용자 스토리로 취급하고 여러 포인트를 할당하는 것이 좋습니다. 필자는 사용자 스토리와 마찬가지로 "X로서, Z로 Y를 원합니다"라는 형식으로 작성하지 않아도됩니다. "X로서 IY, Z가 발생하면 더 많이 작성하지만 Z '는 예상되는 동작입니다. "
이 기능의 장점은 새로운 기능 요청과 함께 버그 수정의 우선 순위를 지정할 수 있다는 것입니다. 진실은 때때로 버그를 수정하는 것보다 새로운 기능이 더 중요하다는 것입니다. 그러나 필요한 작업의 크기를 적절하게 조정할 수 있으므로 작업 능력이있을 때 스프린트에 맞출 수 있습니다.
버그를 수정하는 데 필요한 노력을 추정하기가 어려울 수 있습니다. 서로 상호 작용하는 여러 구성 요소가 포함될 수 있으므로 누군가가 큰 시스템 조각 또는 여러 사람이 수정 작업을 수행하는 데 매우 익숙해 지도록 요구할 수 있습니다.
이야기를 추정하는 것은 시간이지나면서 팀이 문제를 해결 한 경험이 있다는 개념에 근거합니다. 그것으로 정확도가 향상되고 팀 속도를 측정하기 위해 속도를 설정할 수 있습니다. 미래의 스프린트에 대한 신뢰할 수있는 예후를 확립하기위한 완벽한 방법론.
버그는 소프트웨어 개발 회사의 삶의 사실입니다. 스토리를 개발하는 동안 버그를 모두 포착해야한다는 데 동의하지만, 항상 달성 할 수는 없다는 점을 인정하면 모든 팀이 계획해야하는 것이어야합니다. 프로세스가 팀을 지배해야한다고 고집스럽게 생각하는 대신, 다른 방식으로 진행해야합니다.
물론, 비즈니스 측면에서 버그 나 이야기는 팀이 다루고있는 것이 중요하지 않습니다. 둘 다 제품 소유자에게 동일한 가치를 제공 할 수 있습니다.
우리 팀에서는 버그를 추정하는 몇 가지 기술을 실험했습니다.
1로 우리는 잘못 실패했습니다. 대부분의 버그에 대해 90 %의 시간이 버그 분석에 소요되는 것으로 나타났습니다. 그 후 버그 수정은 스토리와 같은 방식으로 평가 될 수 있습니다. 스프린트로 버그를 계획함으로써 우리는 알 수없는 스코프가 거의 모든 스프린트가 실패한 지점까지 스토리 해결에 영향을 미친다는 실수를 저질렀습니다.
90/10 비율 (분석 대 버그 수정) 추정 기술 옵션 2를 기반으로 한 스프린트 계획에 포함되지 않은 분석 계획을 세워야한다는 것을 의미했습니다 (옵션 1에서 배웠지 만 실제 솔루션은 없었습니다). 분석 된 버그로 진행하는 방법). 그 결과 스프린트가 계획된 항목에 집중 한 이후 버그 분석이 수행되지 않았습니다. 팀은 백 로그의 버그에 집중할 시간이 없었습니다. 그래서 결국 그들은 끝내지 못했습니다.
우리는 이제 불확실성을 수용하여 옵션 3을 결정했습니다. 우리는 제품 백 로그를 팀에 의해 스토리 포인트와 버그 백 로그를 사용하여 추정 할 수있는 정기적 인 스토리 / 작업 부분으로 분리했습니다. 버그 백 로그에서 제품 소유자는 비즈니스 가치와 매우 거친 팀 판단에 따라 버그 순위를 정합니다. 팀은 스프린트 중에 버그에 집중하는 데 소비 할 수있는 시간을 할당 할 수 있습니다. 어쨌든 계획을 세울 수 없었기 때문에 제품 소유자는 정확한 결과를 알지 못합니다. 버그 백 로그와 일반 백 로그의 비율은 각 백 로그의 현재 상태와 콘텐츠의 중요도 및 비즈니스 가치에 따라 각 스프린트마다 조정할 수 있습니다.
불확실성을 제거함으로써 팀을 다시 자유롭게했습니다. 스프린트는 알려지지 않은 버그로 인해 손상되지 않았습니다. 버그를 다른 백 로그로 분리함으로써 팀의 정기적 인 스프린트 포커스를 높이고 상당한 비즈니스 가치를 포함하는 버그를 마무리했습니다.
따라서 스토리 포인트가 적합한 지 여부에 따라 다릅니다. 먼저 스토리 포인트를 사용하여 버그를 추정하려고합니다. 그것이 실패하면 내 옵션 3을 시도하십시오. (30 스프린트 이전의) 팀은 비즈니스 가치가 큰 오래된 버그에 다시 초점을 맞췄습니다. 또한 팀이 단순히 예측할 수없는 것을 제공하지 않아도되었습니다. 우리가 현실에 더 가까워졌고 버그 수정을 통해 비즈니스 가치의 큰 덩어리 (버그 대 스토리 비율에 따라) 를 제공 하면서 스프린트를 다시 성공하게 한 것은 알려지지 않은 내용을 수용하고있었습니다 . 최근에 사용한 비율은 50/50입니다.
이야기 포인트를 버그에 할당하는 가장 큰 대답에 동의하지 않아야합니다. 스토리 포인트는 새로운 가치를 제공하기위한 것이어야합니다. 제품 가치 및 비 가치 품목에 포인트를 할당하려는 경우 시간을 추정하고 추적 할 수도 있습니다.
버그는 어제 수행 한 오버 헤드이며 제품 완성 속도를 나타내지 않으며 새로운 제품 가치도 창출하지 않습니다 (생각해보십시오). 버그는 일종의 인터럽트 및 매주 처리해야 할 다른 모든 소 파이와 같습니다. 스토리 포인트의 전체 아이디어는 제품 (또는 기능 세트)을 제공 할시기를 추적 / 추정한다는 것입니다. 스토리 포인트는 임의적이며 이것이 비평가 오버 헤드를 추정에서 제거하는 방법입니다. 일반적으로 비 가치 작업은 주 단위로 일정하므로 팀 속도에 맞춰집니다. 팀은이 비 가치 작업을 제거하거나 줄일 때 가속화합니다.
다시 말해, 왜 포인트를 버그로 추적합니까? 그래서 마지막 날에 각 회원이 얼마나 "일"했는지 알고 있습니까? 그만! 나쁜 관리자! :) 선수가 아닌 팀을 측정하십시오. 한 사람이 자신의 몸무게를 당기지 않으면 팀이 스스로 관리하도록 장려하십시오. 훨씬 더 효과적입니다. 스토리 포인트 항목을 수행하면 개인의 기분이 좋아지지 않아야하지만 스프린트가 끝날 때 헌신적으로 노력할 때 팀 전체가 기분이 좋아야합니다. 스포츠에서 목표는 팀이나 개인에게 좋습니까? 개인이 자신을 위해 경기하면 팀은 장기적으로 패배합니다.
결국에는 포인트를 전혀 사용하지 않으려합니다. 추정은 실제 작업에서 제외되는 시간입니다. 팀이 최대 치에 도달하면 포인트를 전혀 사용하지 않고 스프린트에 넣을 수있는 아이템 수를 정확히 알 수 있습니다. 그들은 추정이 프로세스 낭비라는 작업 단위를 분해하는 기술을 마스터했습니다.
일부 작업은 예측 가능하고 일부 작업은 예측할 수 없습니다. 추정 할 수없는 것들에 대해서는 예산을 사용하십시오.
결함을 수정하는 것은 알 수없는 구성 요소가 여러 개 있으므로 쉽게 평가할 수있는 작업이 아닙니다. 결함의 원인은 무엇입니까? 원인이 이해되면 어떻게 해결할 수 있습니까? 이 변경이 나머지 시스템에 어떤 영향을 미칩니 까? 이 결함을 수정하여 몇 개의 새로운 결함을 주입 했습니까?
결함의 원인은 소프트웨어 라이프 사이클의 어느 시점에서나 발생할 수 있음을 이해해야합니다. 오해 또는 잘못 알려진 요구 사항, 잘못된 설계 또는 잘못된 가정, 잘못된 코딩, 잘못된 테스트, 현재 릴리스에서 얻은 정보를 기반으로 한 문제에 대한 새로운 지식 ...
버그 수정 작업을 위해 두 가지 다른 방법으로 예산을 만들 수 있습니다. 효과적으로 사용한 몇 가지 아이디어는 다음과 같습니다.
그런 다음 목표는 할당 된 예산 내에서 가능한 한 많은 결함을 수정하는 것입니다. 보고 된 결함의 우선 순위를 정하기위한 고객 전략에 대해 논의하십시오. 예를 들어, 중요도에 따라 우선 순위별로 결함을 정렬합니까? 엄격한 우선 순위? 먼저 "낮은 과일"을 공격해야합니까? UI 버그 먼저?
또한 버그를 수정해도 가치가 없습니다. 고정 결함은 폐기물의 한 형태입니다. 이미 기능에 대한 가치를 얻었으므로 버그를 수정하기위한 "보너스 포인트"를 얻지 않아야합니다.
예산이 있으면 계획을 세우는 데 도움이되지만 여전히 정확한 속도를 알 수 있습니다. 버그 수정을 위해 특정 수의 포인트를 책정하고, 과거 데이터를 기반으로 예산에 대략적인 시간을 제공 한 다음, 예산 내에서 최대한 많은 버그를 스쿼시하십시오!
이야기, 버그 및 집안일과 각각의 요점에 중점을 두는 대신 고객에게 기능을 제공하는 데 집중하는 것이 좋습니다.
고객은 소프트웨어가 작동하기를 기대하며, 비즈니스 발전을 위해 개발, 개선 및 새로운 기능에만 실질적인 가치를 부여합니다.
버그 수정은 중요 할 수도 있지만 비즈니스를 새로운 영역과 새로운 고객으로 끌어 들이지 않습니다 (접선 적으로 그리고 결국은 그렇지만 즉시 관리가 측정하는 것은 아닙니다).
따라서 점수는 더 높은 속도의 관점에서 볼 때 가장 잘 볼 수 있으며, 비슷한 점수를 매긴 스토리에 대해 주당 몇 개의 포인트가 수행 되었습니까?
이로 인해 이번 주 이야기가 완벽하게 완료되고 그렇지 않은 경우가 많다는 사실을 시급하게 요구하지 않고 기록적인 기록으로 관리 할 수 있습니다. 그러나 사전 통제력 상실과 이에 대한 신뢰 증가로 인해 일부 관리자는 공포의 문을 열게 될 것입니다.
Pivotal Tracker (JIRA, Trak, Trello 등도 사용)를 사용하며 Pivotal Tracker는 집안일이나 버그에 대한 포인트도 사용하지 않습니다. 위와 똑같은 이유로 JIRA에서도 자신을 볼 때도 마찬가지입니다.