"언제나"해결하기 위해 점점 늘어나는 문제 더미를 어떻게 처리합니까?


15

우리는 소프트웨어 프로젝트의 문제를 추적하기 위해 JIRA를 사용하고 있습니다. 우리가 알아 차린 한 가지 효과는 종종 새로운 문제를 만들지 만 문제가 해결 될시기가 언제인지는 아직 알 수 없다는 것입니다. 그래서 우리는 그러한 이슈가 할당 된 가짜 '먼 미래'이정표를 발명했습니다.

이와 같이이 이정표에 할당 된 문제는 계속 증가하고 있으므로 이것이 좋은 접근 방법이 아닌 것 같습니다. 지금까지는 그 수가 너무 많아서 타당성을 검토하는 것은 많은 일이되었습니다. 귀하와 관련된 구성 요소가 제거되어 일부가 유효하지 않게되었습니다. 그들 중 일부는 다른 문제로 복제되었습니다. 그들 중 일부는 잘못 표현 된 설명을 가지고있어서 아무도 더 이상 자신이 무엇인지 알지 못합니다.

다른 소프트웨어 개발 팀은 유효하지만 언제든지 해결되지 않는 문제를 어떻게 처리합니까? 당신은 그들을 전혀 기록 귀찮게합니까? 다음 계획 버전에 할당 한 후 다음 릴리스가 다가 오면 다시 확인합니까? 다른 것?


1
당신이 내 직장에 대해 이야기하고있는 것 같습니다. 그것으로 행운을 빕니다, 나는 지금 잠시 동안 강탈하고 그 시점에서 진행이 느려지지 않습니다. 쓰레기가 너무 많아서 더 이상 무시할 수 없을 때까지 경영진은 귀찮게하지 않는 것 같습니다.
deadalnix

왜 수정해야합니까? 중요하지 않고 결코 고쳐지지 않으면 완벽합니다.
B 세븐

답변:


11

이들은 회사에 합류 한 새로운 개발자를 위해 수정하기에 좋은 첫 접촉 버그입니다. 또는 주니어 개발자가 시스템에 대한 지식을 소비 할 수 있습니다.

그렇지 않은 경우 수정하는 데 걸리는 시간을 정당화 할만큼 심각하지 않은 경우 "수정하지 않음"으로 표시 할 수 있습니다.


3
+1 해결되지 않기 때문에 기술적 문제 일뿐만 아니라 사회적 문제 일 수도 있습니다. 때때로 당신은 단지 아니오라고 말해야합니다. 버그, 특히 사소하거나 불필요한 기능을 계속 수정하면 사람들의 기대치가 높아지고 더 많은 것을 요구할 것입니다.
Keyo

4
주니어 프로그래머가 버그를 고치는 것은 나쁜 생각입니다. 불행히도 이것은 업계에서 널리 퍼져있는 사례입니다. 버그를 수정하는 가장 비용 효율적인 방법은 버그를 소개 한 개발자가 버그를 수정하도록하는 것입니다.
Trasplazio Garzuglio

6
@MarcoDinacci- "비용 효율적인"항목에 따라 다릅니다. 단기적으로 보면 당신이 맞습니다. 그러나 프로젝트가 오래 지속되는 경우 주니어 프로그래머에게 '수정 버그'할당을 투자하는 것으로 볼 수 있습니다.
mouviciel

2
@mouviciel 저는 주니어 프로그래머가 버그 작업을하는 것보다 더 좋고 자극적 인 방법이 있다고 생각하지만 그것이 코드베이스를 배우는 방법이라는 데 동의합니다. 이 접근법의 또 다른 문제점은 상급 개발자가 버그를 도입하지 않아도되는 코드를 작성하게 될 수 있다는 것입니다.
Trasplazio Garzuglio

3
@MarcoDinacci, 다르게 말해 보자. 선임 개발자가 양질의 작업을 수행하기 위해 외부 프로세스가 필요한 경우 팀에는 근본적인 문제가 있습니다. 좋은 개발자, 특히 고령자에게 IMHO 는 품질에 대한 내부 동기가 있어야합니다. 팀의 의견 리더 (들)에서 그러한 동기가 부족한 경우, 프로젝트는 불가피하게 실패 할 것이며, 어떤 프로세스도 도움이 될 수 없습니다.
Péter Török

11

버그없이 응용 프로그램이 더 가치있는 경우에만 버그를 수정해야합니다.

텍스트 필드가 잘못 정렬되어 있고 수정하는 데 3 일이 걸리면 비용이 너무 높을 수 있습니다. 반대로 사용자가 텍스트 필드에 전혀 쓸 수 없으면 신속하게 수정해야합니다.

일반적으로 문제가 발견 된 직후 문제를 해결하는 것이 더 쉽습니다. 시간이 지나면 개발자는 코드의 일부가 작동하는 방식을 잊어 버려 버그를 수정하는 데 시간이 오래 걸리고 비용이 더 많이 듭니다.

여전히 버그가 남아있는 경우 일부 회사는 새로운 코드를 작성하지 않습니다. 다른 사람들은 배달 전에 테스트 단계까지 귀찮게하지 않습니다.

회사에서는 새로운 버그를 수정하기 전에 많은 시간을 할애하여 버그가 누적되도록합니다. 팀의 사기가 엄청난 버그 목록을 보는 것도 좋지 않습니다.

수정해야 할 버그와 그렇지 않은 버그를 결정하고 다음 마일스톤 이전에 문제를 해결하기 위해 기존 팀원에게 고칠 버그를 지정하여 기존 버그를 정리하기 위해 하루를 보내는 것이 좋습니다. .


6

문제 추적에는 "시간 제한"상태가 있습니다. 문제가 몇 개월 또는 몇 년이 지난 후에도 클라이언트가 문제를 촉구하거나 다시 제기하지 않으면이 상태가 최종 상태로 사용됩니다. 관리자가 공개 된 문제를 정리하도록 요청할 때마다이 작업은 자동이 아니라 수동으로 수행됩니다. 이 과정에서 일부 문제는 해결하기 쉽고 상대적으로 중요하기 때문에 해결 될 가능성이 높습니다 (강제 또는 파일 파일이 없어도).


1
이것은 좋은 전략입니다. 몇 년 동안 당신을 괴롭히는 버그를 아는 것은 영원히 양탄자에 휩쓸 릴 수 있다는 것은 그것을 다루는 데 큰 동기가됩니다.
Steve Jackson

2

나는 JIRA를 사용하지 않고, 직장에서 fogbugz를 가지고 있지만 이것이 대부분의 버그 추적기에 적용된다고 확신합니다. 이것을 쓰는 동안 나는 일하는 방식이 폭포보다 민첩하다는 것을 깨달았고 마감일은 구체적이지 않으며 중요한 것은 우선 순위입니다.

  • 상사가 너무 많은 티켓을 여는 것에 관심이 있다면 처음에는 사소한 티켓을 만들지 마십시오. 당신은 실용적이어야하고 혜택이없는 기능 / 수정 사항을 추가해서는 안됩니다. 인생에서 코드를 연마하거나 UI를 조정하는 것이 더 쉬워지면 추가하십시오. 제품의 사소한 결함을 수정하여 자신을 위해 일을하지 마십시오. 완벽한 것은 없습니다.
  • 중요하지 않은 버그 / 기능은 현재 이정표에 있지만 우선 순위는 낮습니다. 문제에 대해 더 많은 불만 / 요청이 언급되면 우선 순위를 높일 수 있습니다.
  • 고칠 수없는 것, 재현 할 수없는 것, 복제 할 수없는 것의 닫기 / 해결. 일부 버그는 너무 사소하거나 너무 오래 걸리는 기능 요청입니다. 때로는 이러한 수정 / 기능을 요청하는 사람에게 "죄송합니다. 시간이 없습니다"라고 말하면됩니다.
  • 필요에 따라 버그의 우선 순위를 정하고 우선 순위 및 마일스톤별로 티켓 목록을 정렬하십시오.
  • 그들이 이정표를 만들지 않으면 미래의 이정표로 옮기십시오.
  • 티켓이 완료된 다른 티켓에 종속 된 경우 티켓을 차단 된 것으로 표시하거나 티켓을 계층 구조로 구성하여 ticket-x 및 ticket-y가 관련되어 있음을 알 수 있습니다.
  • 티켓에 누군가의 피드백이 필요한 경우 해당 사람에게 티켓을 할당하십시오.

궁극적으로 항상 우선 순위가 낮은 티켓이 많이 있지만 위의 포인트로 최소화 할 수 있습니다.


2

우리는 JIRA를 사용하고 추가 해결 상태를 가지고 있습니다 Suspended. 기능 / 버그가 잠시 포기해야하는 경우 Suspended로 해결됩니다. 이렇게하면 현재주의를 기울여야하는 현재 활성화 된 문제 목록 또는 만족스러운 처리 된 것으로 알려진 해결 된 문제 목록과 여전히 섞이지 않으며 여전히 데이터베이스에 있습니다.

일시 중지 된 문제 목록은 필요에 따라 정기적으로 재검토하기 위해 자주 검토하는 항목입니다.


1

올바른 JIRA 용어를 모르지만 각 "티켓"에 만료 날짜를 두는 것이 좋습니다. 특정 시간 내에 기능 요구 또는 버그 심각도에 따라 구현으로 확대되지 않은 경우 처음에는 그다지 중요하지 않을 수 있습니다. 파일 더미를 자동으로 유지하는 데 도움이됩니다. 나는 종종 "좋지 않을까"또는 "원하는대로 완벽하게 작동하지 않는다"에 따라 티켓을받습니다. 아무도 그것을 위해 충분히 밀지 않거나 그 사용자가 충분한 영향력을 가지고 있지 않으면, 완료되지 않고 몇 달 후에 티켓을 닫습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.