변경 위험에 따라 작업 / 버그 분류

현재 작업중 인 프로젝트에는 문제가 있습니다. 버그와 작업이 너무 새롭거나 너무 경험이 부족한 사람들에게 할당되고 작업으로 인해 더 많은 버그가 발생합니다. 문제는 코드 품질 문제로 인해 소프트웨어의 일부가 다른 것보다 훨씬 "위험"하다는 것입니다. 작업과 관련된 위험을 추정하고 어떤 개발자에게 어떤 작업이 할당되는지주의를 기울여이 문제를 해결하려고 노력했습니다.

우리는 JIRA를 사용하여 이러한 추정을 추적하기 위해 라벨링 문제를 시작했습니다. 버그 / 작업을 분류하기 위해 몇 가지 측정 항목을 사용하는 것으로 나타났습니다.

• 얼마나 명확하고 직설적입니까? 예를 들어 많은 디자인 작업이 필요하거나 간단한 UI 버그 수정이 필요한지 여부입니다.
• 코드의 영향을받는 영역의 유지 관리 가능 정도 잘 설계된 지역입니까, 진흙의 큰 공입니까?
• 필요한 변경에 의해 영향을받는 프로그램의 양은 얼마입니까?

가능한 범주가 무엇인지 시작했을 때 명확한 아이디어가 없었기 때문에 레이블이 지저분합니다. 작업을 다른 사람에게 할당하기 전에 견적을 요구할 수 있도록 새 필드 ( "위험"과 같은)를 추가하도록 요청하려고합니다.

전에 이런 종류의 일을 한 사람이 있습니까?

대부분의 버그 추적 접근 방식의 실패 중 하나는 시스템의 최종 사용자의 관점 인 방정식의 한쪽 만 처리한다는 것입니다. 이 문제는 1 주일 (우선 순위) 동안 기다릴 수있는 중요한 버그 s입니다.

다차원 버그 추적을 설명하는 블로그 게시물 은 개발자 관점 (PEF 및 REV)을 포함하여이 문제를 해결합니다.

PEF 값은 사용자의 관점입니다.

• P의 아인 -이 발견 될 때 버그가 얼마나 고통스러운?
• E는 ffort - 얼마나 많은 노력이 해결할 걸립니까?
• F- 빈도-버그는 얼마나 자주 발생합니까?

REV 측면은 개발자의 관점입니다.

• R의 ISK - 수정 얼마나 위험하다?
• E는 ffort -이 수정에 소요되는 많은 노력?
• V의 erifiability - 얼마나 쉬운 그것은 버그가 수정되어 있는지 확인하는 것입니다?

이들 각각은 1..9 척도로 측정되며 1은 낮고 쉬우 며 9는 높고 단단합니다. PEF와 REV에 점수를주기 위해 숫자가 합산됩니다.

설명 된 비트를 다루는 부분 :

• 얼마나 명확하고 직설적입니까? 예를 들어 많은 디자인 작업이 필요하거나 간단한 UI 버그 수정이 필요한지 여부입니다.
• 코드의 영향을받는 영역의 유지 관리 가능 정도 잘 설계된 지역입니까, 진흙의 큰 공입니까?
• 필요한 변경에 의해 영향을받는 프로그램의 양은 얼마입니까?

이러한 요소는 REV에 설명 된 노력과 위험에 영향을 미칩니다.

예, 그것은 전에 싸웠던 것입니다. 나는 과거에 Redmine의 사용자 정의 필드 에이 모델을 사용했으며 합리적으로 성공했습니다.

PEF와 REV 점수를 비교할 때 가장 큰 장점이 있습니다. PEF가 21이고 REV가 7이면 큰 승리가 될 수 있습니다. PEF 7과 REV 21은 한동안 피해야 할 부분이지만 위험과 노력 측면에서이를 해결하는 이점보다 클 수 있기 때문입니다.

그런 다음 REV 점수를보고 경험이 적은 개발자에게 위험이 적은 항목을 할당 할 수 있습니다 (위험이 적고 높은 노력이 종종이 상황에 이상적임).

나는 당신이 여기서 말하는 것을 '복잡성'이라고하는 것이 더 좋다고 말할 것입니다. 물론 변경이 복잡할수록 '위험'이 높을수록 경험이 부족한 프로그래머가 새로운 버그를 도입 할 수 있습니다. 실제 문제라면 그러한 분야를 소개하는 것은 나쁜 생각이 아닙니다.

그러나 당신이 쓴 것을 판단하면 두 가지 문제가있는 것 같습니다.

1. 신규 또는 경험이없는 프로그래머를 상대하고 있습니다.
2. 코드의 (많은 / 일부) 품질에 문제가있는 것 같습니다.

작업을 관리하고 우선 순위를 정하는 데 도움이되는 '복잡성'필드와 같은 것을 소개하는 것 외에도 위의 두 가지 문제의 위험을 완화하는 데 중점을 둘 것을 제안합니다.

첫 번째 문제를 해결하기 위해 새로운 프로그래머가 버그에 대해 작업하기 전에 숙련 된 프로그래머와 새로운 버그를 모두 논의하는 프로세스를 만들었습니다. 또한 새로운 버그가 발생할 위험을 낮추고 새로운 프로그래머가 더 빨리 속도를 낼 수있는 코칭 ​​기회로 사용할 수 있도록 코드 검토를 확실히 소개하겠습니다.

코드 품질과 관련하여 두 가지 작업을 수행합니다. 먼저, 썩는 과정을 멈추십시오. 새로운 열등한 코드가 도입되는 것을 막을 수있는 코딩 표준과 관행에 동의하십시오. 제안 된 코드 리뷰도 여기에 도움이 될 것입니다. 둘째, 코드의 최악 부분을 식별하고 리팩토링 및 정리를 시작합니다.

예, 경험이 부족한 개발자에게 너무 복잡한 문제를주지 않는 것이 좋습니다. 그러나 단점은 당신이 그들에게 쉬운 일만하게하면 배우지 못할 것이라는 점입니다.

대체 전략은 코드 검토 체제를 구축하는 것입니다. 초보자가 까다로운 작업을 수행하도록 (이유 내에서) 작업을 철저히 검토하십시오.

단기적으로 이것은 모든 사람에게 더 많은 일입니다. 장기적으로 복잡한 작업을 처리 할 수 ​​있고 코드 품질과 관련하여 "동일한 페이지에있는"전체 개발자 팀이 생깁니다.