무 버그 / 결함 정책으로 민첩성 유지

우리 프로젝트에서 우리는 제로 버그 (일명 제로 결함) 방법론으로 작업합니다. 기본적인 아이디어는 버그가 항상 기능보다 우선 순위가 높다는 것입니다. 스토리를 작업 중이고 버그가있는 경우 스토리를 승인하려면 문제를 해결해야합니다. 오래된 스토리에 대한 스프린트 동안 버그가 발견되면 버그를 백 로그에 놓고 해결해야합니다 (최우선 순위).

내가 해결하려는 이유는 항상 버그를 수정하지는 않기 때문입니다. 때때로 우리는 그것이 중요하지 않기 때문에 "수정하지 않을 것"이라고 선언합니다. 전체적으로 훌륭하게 들립니다. 우리는 고품질의 제품을 배송하고 있으며 거대한 버그 백 로그의 형태로 "혹"을 가지고 있지 않습니다.

그러나이 접근법이 올바른지 확실하지 않습니다. 나는 우리가 항상 심각한 버그를 최대한 빨리 수정하고 흥미롭지 않은 버그를 버려야한다는 데 동의하는 경향이 있습니다. 그러나 중요하지만 새로운 기능만큼 중요하지 않은 버그는 어떻습니까? 나는 그것들이 적절한 우선 순위로 백 로그에 제출되어야한다고 생각하는 경향이있다.

명확하게하기 위해 예를 들겠습니다. 프로젝트에서 flex로 작성된 UI로 작업합니다. 모든 화면 해상도에 대해 동일한 크기로 열리는 마법사 화면이 있습니다. 마법사 창을 확장하면 페이지 중 하나가 잘 보이지 않습니다 (마법사가 모든 것을 표시 할 수 있지만 스크롤 막대가 필요하지 않지만 사라지지 않는 세로 스크롤 막대가 있습니다). 이 버그는 못 생겼습니다. 반드시 수정해야한다고 확신합니다. 그러나 우리는 일정이 빡빡하고 우리가 두려워하지 않고 출시를 시작하지 않을 많은 기능을 가지고 있습니다. 그런 버그로 살 수 있다고 생각합니다. 수정해야하지만 다른 기능보다 우선 순위가 낮습니다 (따라서이를 완료 할 수없는 경우 적어도 더 중요한 기능은 생략하지 않았습니다). 그러나,

"수정하지 않음"으로 표시하고 싶지 않지만 가장 중요하지 않은 버그로 관리하는 방법에 대한 의견을 듣고 싶습니다.

새로운 코드를 작성하기 전에 버그를 수정하는 것은 실제로 Joel 테스트 의 12 가지 중 하나입니다 . Joel은 또한 이것이 필수 아이템 인 이유를 설명합니다.

일반적으로 버그를 수정하기 전에 기다리는 시간이 길수록 비용과 시간이 많이 소요됩니다.

선택하실 수 있습니다 :

• 요청이 많은 기능을 구현하고 버그 수정을 지연 시키면 수정 비용이 필연적으로 증가합니다.

• 또는 고객이 실망하여 고객에게 필요한 기능을 제공하는 데 너무 느리다는 점을 고려하여 지금 버그를 수정하십시오.

버그가 그다지 중요하지 않은 경우, 기능이 진행되는 동안 관리자는 먼저 기능을 구현하도록 요청한 다음 버그를 수정해야합니다. 비즈니스 측면에서, 이것은 경영진이 결과를 명확하게 이해하는 한, 즉 지금보다 나중에 버그를 수정하는 것이 더 어려울 수있는 완벽한 선택입니다.

"모든 버그가 수정 될 때까지 새로운 기능이 없음"을 고수하는 것이 최상의 비즈니스 선택이 아닐 수 있습니다. 이미 한계를 언급 했으므로 설명 할 필요가 없습니다.

그러나 사소한 버그를 수정하기 전에 매우 중요한 기능을 구현할 수있는 위험에는 한계가 있습니다. 100 명의 고객이 겪는 버그보다 1,000 명의 고객이 요청한 기능이 더 중요합니까? 주어진 버그를 수정하기 전에 주어진 기능을 수행해야하는지 평가하는 방법은 무엇입니까?

엄격한 규칙이없고 경영진이 개발 프로세스를 잘 이해하지 못하는 경우 몇 년 안에 버그로 가득 찬 백 로그가 생겨서 다른 멋진 기능보다 먼저 수정하기에 충분히 중요하지 않은 것으로 간주 될 수 있습니다.

상황의 특정 하위 수준 세부 정보로 다이빙하는 것 외에도 기본, 기본 사항을 올바르게 갖추 었는지 확인하는 것이 좋습니다.

이와 관련하여, "버그가 항상 기능보다 우선 순위가 높다"는 정책이 특히 중요하다고 생각합니다. 특히이 단어 는 애자일 선언문에 명시된 네 가지 원칙 중 두 가지 이상에서 항상 벗어납니다 .

프로세스 및 도구에 대한 개인 및 상호 작용

계획에 따라 변경 에 응답

나는 민첩한 원칙의 적용에 대해 민첩 해야 한다고 굳게 믿고 있기 때문에 정책을 변경해야한다고 주장하지 않습니다 .

그러나 편차를 정당화 할 수 있는지 여부와 방법을 이해할 때 적어도 알고 있어야 합니다 . 간단하게, 당신은 더 나은하게 넣어 당신이 실제로 그렇게 설득력에 덮여 무의미한 가짜로 밀어하지 않습니다 "민첩"이라고 부르는 것을 반 Arsed 애자일 선언문 :

프로세스 및 도구에 대한 개인 및 상호 작용 및
해당 개인 ( '자원'이라는 용어를 선호)이 상호 작용하는 방식을 제어하기위한 필수 프로세스 및 도구가 있습니다.

소프트웨어 가 포괄적으로 문서화 되어있는 한 포괄적 인 문서에 대한 작업 소프트웨어

물론 엄격한 계약의 경계 내에서 계약 협상을 통한 고객 협업
및 엄격한 변경 관리 대상

변경 에 대응하기
위한 세부 계획이 마련된 경우 계획에 따른 변경에 대한 대응

교묘함을 위해, 제로 버그 정책이 벗어나는 것은 민첩한 원칙 일뿐 만 아니라.

내가 참여한 민첩하지 않은 프로젝트에서는 일반적으로 우선 순위가 높은 기능의 릴리스 지연을 정당화 할만큼 중요하지 않은 버그를 수정하는 데 프로그래머에게 시간을 보내는 것이 현명하지 않은 것으로 간주되었습니다 .

이 때문에 경영진은 일반적으로 다음 릴리스에 어떤 버그를 기다릴 것인지 결정하는 데 약간의 노력을 기울 였습니다 ( 투자 한 것이 더 정확할 수도 있음).

• ^{우연히 미션 크리티컬 소프트웨어를 사용하십니까? 이 경우에는 제로 버그 정책이 매우 합리적이며 민첩하고 민첩하지 않은 원칙을 손상시킬 가치가 있기 때문에 묻습니다. 이 경우 민첩한 프로세스를 상상하기가 어렵습니다.}

미션 크리티컬 소프트웨어로 작업하지 않는 한 경영진의 기술과 사고 능력을보다 면밀히 평가하는 것이 좋습니다.

내 말은, 당신이 묘사 한 바에 따르면, 버그와 기능을 올바르게 우선 순위 지정하는 것은 단순히 불가능합니다. 이 경우, 비교적 일상적인 작업을 처리 할 수 ​​없다면 다른 어떤 기능을 수행 할 수 없습니까? 경쟁력있는 급여를 제공합니까? 경력 성장 기회? 근무 조건?

적절하게 지적했듯이, 제로 버그 정책은 중요하지 않은 문제가 깔개 아래에서 무시되거나 밀려날 위험이 있습니다.

새로운 문제가보고되면 다음과 같은 3 가지 결정을 내릴 수 있습니다.

1. 그것은 진짜 버그이며 가능한 빨리 고쳐야합니다 : 백 로그 위에 놓으십시오
2. 이는 실제 버그이지만 응용 프로그램의 기능에 중요하지는 않습니다. 일반적인 이야기로 바꾸고 제품 소유자가 우선 순위를 정하도록하십시오.
3. 버그가 아니거나 복제본이거나 해결해야 할 가치가 없습니다. 적절한 이유로 거절하십시오.

이렇게하면 덜 중요한 문제를 완전히 잊을 수는 없지만 다음 스프린트에서 새로운 반짝이는 기능을 모두 강제하지는 않습니다. '이야기로 전환'은 경영진이 계속 버그없는 정책을 따르고 있다고 주장 할 수 있으며 제품 소유자는 백 로그의 기능의 중요성과 문제의 중요성 간의 균형을 유지할 수 있어야합니다.

이 절차를 사용하면 언급 한 스크롤 막대와 같은 문제가 프로젝트가 끝났을 때 여전히 해결되지 않을 수 있지만 아무도 (고객을 포함하여) 중요하지 않다고 생각하지 않았기 때문입니다. 문제가 발견 된 시간.

나는 당신이 계획을 좋아하지만, 당신이 식별했듯이, 그것을 작동시키기 위해서는 약간의 조정이 필요합니다-당신이 관찰했듯이, 현실은 종종 버그 수정을 능가하는 새로운 기능입니다 .....

내 제안은 각 스프린트마다 버그 우선 순위를 높이는 것입니다. 레벨 5에 버그가 있다고 가정합니다 (1- 높이, 5 = 낮음). 나중에 5, 4 스프린트로 시작하며 레벨 1 버그입니다. 그러나 우선 순위 계산에 필요한 마인드는 "각 스프린트 종료시 미해결 버그의 우선 순위 증가"가 아니라 "현재 우선 순위-스프린트 수"입니다. 이는 우선 순위가 "재설정"되어 더 이상 지연되지 않도록 방지합니다.

다음 스프린트에서 레벨 1 버그를 해결해야합니다 ......

설명하기 쉽고 구현하기 쉽습니다 ....

이제는 요청을 처리 할 수있는 범위가 다를 수 있습니다. 잠시 후 요청을 처리하거나 처리해야합니다. 완료되거나 삭제되어 값이없는 기능의 백 로그를 방지합니다.

소프트웨어 개발의 모든 것에 대해 너무나 문자 그대로 또는 단호하게 행동하려고 할 때 문제가 발생합니다. 새로운 기능이 추가되기 전에 버그가 수정되어야하지만 문제의 범위와 함께이 결정을 내릴 때 각각의 중요성을 고려할 것입니다. 모든 예외가 있습니다.

일부 응용 프로그램은 너무 커서 전혀 관련이없는 섹션이 있습니다. 직원 급여 GUI에 몇 가지 성가신 버그가 있기 때문에 채무 지불 모듈의 모든 새로운 기능을 보류 해야하는 이유를 알 수 없습니다. 일부 마법사 단계 GUI 성가심이 회사 웹 사이트의 구매 섹션에있는 경우이를 수정하십시오. 그러나 추가 기능이 추가 보안, 비즈니스 요구 사항, 특히 규정 변경의 결과 인 경우 많은 버그가 수정되지 않았을 수 있습니다.

어느 한 쪽을 완성하기위한 시간과 자원의 큰 불일치 이외에, 일부 사용자 / 고객 입력을 얻는 것이 가장 좋습니다. 새 기능을 얻는 것이 의미가있는 경우 버그에 계속 대처할 수 있으면 기능을 추가하십시오. 목표는 버그가 쌓이는 것을 피하는 것이므로 중지 간격이 있어야합니다. 어떤 시점에서 많은 작은 문제들이 큰 문제가됩니다.

테스트를 실행할 때 버그를 표시하기 위해 테스트를 작성하는 것이 버그를 수정하기에 좋은 시작입니다. 그러나 최우선 순위 인 버그를 고치려고 할 때는 계속하기 전에 두 번 생각해야합니다. 나는 그것을 고치는 것을 생략하지 않았다. 그러나 중요하지 않은 리소스를 사용하여 이러한 버그를 해결할 수 있습니다. 우리 팀에서는 버그 목록에서 가장 우선 순위가 낮은 버그로 새로운 리소스를 훈련시킵니다. 이런 식으로, 우리는 새로운 자원을 훈련시킬 수있는 기회를 얻었을뿐만 아니라 그들이 신청에 대한 수정을했다는 확신을 줄 수 있습니다. 이를 통해 다음 우선 순위가 지정된 작업에 자원 할 수 있습니다.

도움이 되었기를 바랍니다 :)