나는 ASIC 용 C로 펌웨어 코드를 작성하는 스크럼 프로젝트에서 일하고있다.스크럼, 스프린트에서 버그를 처리하는 방법 및 버그를 예측하는 방법
우리는 종종 버그를 찾기가 어렵습니다. 그러나 어떻게 이러한 버그를 추정 할 수 있습니까?
저는 스크럼 마스터에게 제가 버그를 추정하는 능력이 없다고 항상 말합니다. 버그에 대한 시간 추정을 정말 싫어하기 때문입니다.
당신은 어떻게 당신의 스크럼 프로젝트에서 이것을 처리합니까?
버그를 추정하는 것은 정말 어려운 일입니다.만약 당신이 그것을 할 수 있다면, 당신은 이미 솔루션을 가지고있을 것이고 그것은 더 이상 버그가 아닙니다. :) 그래서, 하나씩 추정하려고 시도하는 대신, 을 할당하는 것입니다. "버그 수정 시간"동안 Sprint와 그 시간 동안 가장 중요한 버그를 수정합니다. 이것은 최선의 노력 전략이며, 할당 된 시간 동안 최대한 많은 것을 수정합니다.
예, 버그를 수정하는 데 걸리는 시간을 측정하십시오. 어쩌면 그것들을 "wtf? -bugs", "ahh-of-course-bugs"등으로 분류 할 수 있습니다. 같은 클래스의 과거 버그 평균에 따라 미래 버그를 예측합니다. 시간 낭비를 추적하는 것은 실제로 또 다른 어려운 문제입니다. – Christian
Ack! 가장 중요한 버그를 수정하면 버그를 발견하자마자 모든 버그를 수정하지 않고 있음을 알 수 있습니다. 연기 된 버그는 수정하는 것이 훨씬 더 비쌉니다. –
@Adrian 나는 "문화를 멈추라"문화에 전적으로 동의하고 믿는다 : 버그를 발견하자마자 버그를 수정하라. 그러나, 잘, 당신은 항상 스프린트 동안 그들 모두를 찾을 수 없습니다. –
이전 버그 수정에 소요 된 평균 시간을 기준으로 추정하는 방법은 어떻습니까?
몇 시간이 아닌 몇 주가 소요될 것으로 예상하십시오.
스크럼 마스터가 버그 수정 시간을 예측할 때의 문제를 이해하지 못한다면 프로젝트에 최소한의 프로그래밍 지식이있는 스크럼 마스터를 사용하면 도움이 될 것입니다.
그건 약간 가혹한 :) 많은 경우 개발자는 문제를 해결할 시간을 허락하는 몇 가지 배경 지식을 가지고 있다고 생각합니다. – Cocowalla
"미래를 예측하는 것은 어렵습니다."
버그를 분석하고 해결 방법을 찾지 않는 한 추정 할 수 없습니다. 이것은 백 로그를 모른 채 스크럼 계획 회의를하는 것과 같습니다.
큰 예상치를 사용하여 불확실성을 알릴 수 있습니다. 역사적인 데이터에는 제한된 가치가 있습니다. 노력 배포가 새로운 버그에 대해서도 동일 할 때도 한 버그에 많은 도움이되지 않습니다. 또한 새 버그는 평균적으로 더 쉽거나 더 어려울 수 있습니다.
일관된 스토리 포인트 견적을 기반으로 일주일에 완료 할 수있는 스토리 포인트 수에 대한 기록을 작성하는 것이 좋습니다. 여기에는 버그 수정 시간도 포함됩니다.
예를 들어 이전 스프린트에서 일주일에 20 가지 스토리 포인트를 완료 할 수 있습니다. 이 20 개 포인트의 개발은 2 일 이내에 완료 될 수 있지만 테스트와 버그 수정이 있습니다. 우리는 dev 버그에 대해 추정하지 않습니다. 각각의 새로운 스토리에는 대략 버그 수정 시간이 포함될 것으로 예상됩니다. 라이브 버그는 추정 이전에 조사되어야하며, 정확하게 추정하기 위해 가능해야합니다.
저는 Jeff Sutherland에게 물었습니다. PatientKeeper에서 버그를 수정하기 위해 반나절 일정으로 추정했습니다. 버그의 특성상 대략적인 평균을 찾을 수있을 정도로 예측할 수있는 것이면 이것은 공정한 전략이라고 생각합니다.
그러나 실제로는 실제로 해결할 수있는 것은 아닙니다. 버그가 무엇인지 이해하는 것은 종종 어렵습니다. 문제를 해결하는 것보다 분석하는 데 더 오랜 시간이 걸릴 수 있습니다. 이는 종종 버그를 예측하기 어렵고 예측하기 어렵게 만든다. 스프린트에 포함 된 모든 작업을 분석해야하며, 버그는 종종 다른 작업보다 더 많은 분석이 필요합니다.
"예측할 수없는"버그가 발생했을 때 우리는 문제가 무엇인지 알아내는 데 고정 된 시간을 할당해야합니다. 예 : 우리는 그것을 이해하려고하는 버그를 파헤 치기 위해 하루 (또는 x 포인트)를 소비하기로 결정하고, 다음 스프린트의 실제 문제를 해결할 계획이다. 그러나 그것이 충분히 파악할 시간이 아니라면 현재 스프린트에서 더 많은 시간을 낭비하기를 원하지 않으며 다음 번에 다시 고려해야 할 것입니다. 경우에 따라 버그가 매우 중요 할 수 있으며, 예상치 못한 결과로 인해 살아야합니다.
우리는 "이 버그가이 모듈과 이러한 파일 중 일부 디버깅 나는 그것을 해결할 수와 관련이 알고있다" 버그 "내가 그것을 업데이트 할 필요가 잘못된 것입니다 어디 있는지"를 분류 할 수 있습니다 "이 버그가 왜 생겨 났는지 확신 할 수 없다." 프로젝트에 대한 우리의 경험을 바탕으로 처음 2 가지 경우를 예상 할 수 있습니다. 마지막 사례에 대한 추정은 실제로 힘듭니다. 나를 위해 일했다
한 가지 방법은 첫 번째 장소 :
이 작동하는 방법은 버그가 발견되면, 고정이 이야기의 구현에 우선한다는 것입니다 버그를하지 않는 것입니다. 이미 존재하는 기능이 100 % 작동하면 새로운 기능을 추가 할 수 있습니다.
물론 버그를 분류합니다. 이 중지 생산 라인 접근법은 치명적인 버그에만 적용됩니다. 치명적인 버그보다 덜 중요한 기능 향상 스토리로 취급되며 향후 다른 스프린트에서 예상되거나 계획됩니다.
심각한 버그 수정을위한 시간 할당은 결국 팀 속도에 반영됩니다.
모든 버그에 대해 4 시간의 분석 시간을 예측합니다. 또한 버그의 우선 순위도 있습니다. 차단기 또는 중요 버그는 다른 것이 구현되기 전에 수정해야합니다. 수정해야 할 많은 버그로 인해 구현 된 스토리가 낮아집니다. 그러나 우리는 다음 기능을위한 강력한 소프트웨어를 보유하고 있습니다.
버그를 추정하는 데별로 유용하지 않습니다. 그냥 막지 말고 찾거나, 작업 표시 줄에 표시하거나, 무엇이든 사용하십시오. 우선 순위를 지정하고 수정하십시오. 당신이 보내는 시간은 속도에 영향을 미칠 것입니다. 그리고 그것은 중요한 속도입니다. 스피드는 다음 스프린트에서 기대할 수있는 진도를 나타내는 지표입니다.
일부 통계에 관심이 있다면 대신 스프린트 당 버그 수를 사용하십시오.
비슷한 질문을 한 시간 전에 받았고 good responses을 받았습니다.
실제 목표는 버그와 관련된 위험을 완화하는 것입니다. 즉 스케줄이 실행되지 않게한다. 매우 자주, 팀은 어떤 이야기가 까다로운 버그를 미리 만들 가능성이 있는지를 식별 할 수있을 것입니다. 따라서 한 가지 완화 전략은 예상치 못한 상황에 가능한 한 많은 시간을 할애하여 이러한 이야기를 먼저 다루는 것입니다.
낚시에 비해 버그 수정이 들렸습니다. 신비한 버그를 고치는 데 얼마나 걸릴까요? 물고기 잡는 데 얼마나 걸릴까요? 해당 용어로 제품 소유자에게 설명해보십시오.
스프린트 도중 버그 수정을 위해 (컨택트 가능한 시간의 10-20 %) "칸티발"방식을 사용하는 것이 좋습니다. 즉, 제품 소유자와 이야기하고 버그 수정 비용을 통제 할 수 있음을 팀이 제품의 품질을 느낄 때마다 경험적으로 조정할 수 있음을 설명합니다. . 목표는 물론 시간을 줄이고 투명성을 증진시키는 것입니다.제품 소유자는 가장 중요한 우선 순위가 고정 될 수 있도록 일반적으로 보존 가치 (Retainment value) - 가장 중요한 버그를 처리하는 버그 백 로그의 우선 순위를 정하는 데 도움을 줄 수 있습니다.
칸뱅 (KanBan) 작업이란 팀이 일정한 간격으로 (매일 일어 서서 좋은 시간을 보낸 후) 버그 큐에있는 것을 확인하고 모든 팀 구성원의 전문 기술을 사용하여 모양을 파악합니다 그리고 무엇을 검사 할 것인가, (일반적으로 쌍이 정말 좋음) 버그를 취합니다. 우발 사고가 끝나면 팀은 손을 들고 제품 소유자와 대화를하고, 이야기가 끝난 후에도 버그가 수정되어야하는지 결정해야합니다. 그렇지 않으면 다음 스프린트를 기다릴 수 있습니다.
일반적으로 투명성을 통해 스크럼 팀 (PO 및 SM 포함)은 수정 비용이 무엇인지 파악하고 품질 및 전달 속도의 균형을 맞추기 위해해야 할 일을 파악해야합니다. 일반적으로 PO와 대화를하는 좋은 방법입니다 :-)
은 Pascal Thivent의 답변에 상당히 동의합니다. 우리 스프린트의 은 대개 더 긴급한 작업이있을 경우 조정할 수있는 작업을 선택합니다.
버그가 발생하면 우선 순위를 지정하고 중요도를 설정합니다. 높은 우선 순위 또는 심각도 인 경우 우리는이를 수행 할 것이고이 스프린트에서 중요하지 않은 작업은 백 로그로 돌아갈 것입니다.
버그가 없거나 버그가 긴급하지 않으면 우리는 모든 스프린트 작업을 수행 할 것입니다.
스프린트가 많이 실행 된 경우 버그 수정에 많은 노력을 기울 였음을 보여주는 통계가있을 수 있습니다. 다음 번 스프린트의 벤치 마크가 평균적인 노력을 기울이는 것이 다른 옵션입니다.
버그 수정 시간은 쉽게 예측할 수 있습니다. 힘든 오류 막대를 예측하고 있습니다! ;-) –
[민첩한 반 패턴 : 버그 수정 크기 조정 또는 예상] (http://www.agileforall.com/2010/05/05/agile-antipattern-sizing-or-estimating-bug-fixes/) –