우리는 소프트웨어 프로젝트의 문제를 추적하기 위해 JIRA를 사용하고 있습니다. 우리가 알아 차린 한 가지 효과는 종종 새로운 문제를 만들지 만 문제가 해결 될시기가 언제인지는 아직 알 수 없다는 것입니다. 그래서 우리는 그러한 이슈가 할당 된 가짜 ‘먼 미래’이정표를 발명했습니다.
이와 같이이 이정표에 할당 된 문제는 계속 증가하고 있으므로 이것이 좋은 접근 방법이 아닌 것 같습니다. 지금까지는 그 수가 너무 많아서 타당성을 검토하는 것은 많은 일이되었습니다. 귀하와 관련된 구성 요소가 제거되어 일부가 유효하지 않게되었습니다. 그들 중 일부는 다른 문제로 복제되었습니다. 그들 중 일부는 잘못 표현 된 설명을 가지고있어서 아무도 더 이상 자신이 무엇인지 알지 못합니다.
다른 소프트웨어 개발 팀은 유효하지만 언제든지 해결되지 않는 문제를 어떻게 처리합니까? 당신은 그들을 전혀 기록 귀찮게합니까? 다음 계획 버전에 할당 한 후 다음 릴리스가 다가 오면 다시 확인합니까? 다른 것?
답변
이들은 회사에 합류 한 새로운 개발자를 위해 수정하기에 좋은 첫 접촉 버그입니다. 또는 주니어 개발자가 시스템에 대한 지식을 소비 할 수 있습니다.
그렇지 않은 경우 수정하는 데 걸리는 시간을 정당화 할만큼 심각하지 않은 경우 “수정하지 않음”으로 표시 할 수 있습니다.
답변
버그없이 응용 프로그램이 더 가치있는 경우에만 버그를 수정해야합니다.
텍스트 필드가 잘못 정렬되어 있고 수정하는 데 3 일이 걸리면 비용이 너무 높을 수 있습니다. 반대로 사용자가 텍스트 필드에 전혀 쓸 수 없으면 신속하게 수정해야합니다.
일반적으로 문제가 발견 된 직후 문제를 해결하는 것이 더 쉽습니다. 시간이 지나면 개발자는 코드의 일부가 작동하는 방식을 잊어 버려 버그를 수정하는 데 시간이 오래 걸리고 비용이 더 많이 듭니다.
여전히 버그가 남아있는 경우 일부 회사는 새로운 코드를 작성하지 않습니다. 다른 사람들은 배달 전에 테스트 단계까지 귀찮게하지 않습니다.
회사에서는 새로운 버그를 수정하기 전에 많은 시간을 할애하여 버그가 누적되도록합니다. 팀의 사기가 엄청난 버그 목록을 보는 것도 좋지 않습니다.
수정해야 할 버그와 그렇지 않은 버그를 결정하고 다음 마일스톤 이전에 문제를 해결하기 위해 기존 팀원에게 고칠 버그를 지정하여 기존 버그를 정리하기 위해 하루를 보내는 것이 좋습니다. .
답변
문제 추적에는 “시간 제한”상태가 있습니다. 문제가 몇 개월 또는 몇 년이 지난 후에도 클라이언트가 문제를 촉구하거나 다시 제기하지 않으면이 상태가 최종 상태로 사용됩니다. 관리자가 공개 된 문제를 정리하도록 요청할 때마다이 작업은 자동이 아니라 수동으로 수행됩니다. 이 과정에서 일부 문제는 해결하기 쉽고 상대적으로 중요하기 때문에 해결 될 가능성이 높습니다 (강제 또는 파일 파일이 없어도).
답변
나는 JIRA를 사용하지 않고, 직장에서 fogbugz를 가지고 있지만 이것이 대부분의 버그 추적기에 적용된다고 확신합니다. 이것을 쓰는 동안 나는 일하는 방식이 폭포보다 민첩하다는 것을 깨달았고 마감일은 구체적이지 않으며 중요한 것은 우선 순위입니다.
- 상사가 너무 많은 티켓을 여는 것에 관심이 있다면 처음에는 사소한 티켓을 만들지 마십시오. 당신은 실용적이어야하고 혜택이없는 기능 / 수정 사항을 추가해서는 안됩니다. 인생에서 코드를 연마하거나 UI를 조정하는 것이 더 쉬워지면 추가하십시오. 제품의 사소한 결함을 수정하여 자신을 위해 일을하지 마십시오. 완벽한 것은 없습니다.
- 중요하지 않은 버그 / 기능은 현재 이정표에 있지만 우선 순위는 낮습니다. 문제에 대해 더 많은 불만 / 요청이 언급되면 우선 순위를 높일 수 있습니다.
- 고칠 수없는 것, 재현 할 수없는 것, 복제 할 수없는 것의 닫기 / 해결. 일부 버그는 너무 사소하거나 너무 오래 걸리는 기능 요청입니다. 때로는 이러한 수정 / 기능을 요청하는 사람에게 “죄송합니다. 시간이 없습니다”라고 말하면됩니다.
- 필요에 따라 버그의 우선 순위를 정하고 우선 순위 및 마일스톤별로 티켓 목록을 정렬하십시오.
- 그들이 이정표를 만들지 않으면 미래의 이정표로 옮기십시오.
- 티켓이 완료된 다른 티켓에 종속 된 경우 티켓을 차단 된 것으로 표시하거나 티켓을 계층 구조로 구성하여 ticket-x 및 ticket-y가 관련되어 있음을 알 수 있습니다.
- 티켓에 누군가의 피드백이 필요한 경우 해당 사람에게 티켓을 할당하십시오.
궁극적으로 항상 우선 순위가 낮은 티켓이 많이 있지만 위의 포인트로 최소화 할 수 있습니다.
답변
우리는 JIRA를 사용하고 추가 해결 상태를 가지고 있습니다 Suspended. 기능 / 버그가 잠시 포기해야하는 경우 Suspended로 해결됩니다. 이렇게하면 현재주의를 기울여야하는 현재 활성화 된 문제 목록 또는 만족스러운 처리 된 것으로 알려진 해결 된 문제 목록과 여전히 섞이지 않으며 여전히 데이터베이스에 있습니다.
일시 중지 된 문제 목록은 필요에 따라 정기적으로 재검토하기 위해 자주 검토하는 항목입니다.
답변
올바른 JIRA 용어를 모르지만 각 “티켓”에 만료 날짜를 두는 것이 좋습니다. 특정 시간 내에 기능 요구 또는 버그 심각도에 따라 구현으로 확대되지 않은 경우 처음에는 그다지 중요하지 않을 수 있습니다. 파일 더미를 자동으로 유지하는 데 도움이됩니다. 나는 종종 “좋지 않을까”또는 “원하는대로 완벽하게 작동하지 않는다”에 따라 티켓을받습니다. 아무도 그것을 위해 충분히 밀지 않거나 그 사용자가 충분한 영향력을 가지고 있지 않으면, 완료되지 않고 몇 달 후에 티켓을 닫습니다.