이슈 추적 시스템 사용의 단점에 대한 연구가 있습니까? [닫은]

9

다음과 같은 이유로 문제 추적 시스템이 마음에 들지 않습니다.

문제를 설명하는 데 너무 많은 시간이 걸립니다. 이것은 사용법을 권장하지 않습니다.
버그를 보관할 장소를 만듭니다. 그리고 그들을위한 장소가 있다면 사람들은 보통 버그 원인을 수정하는 데 너무 신경을 쓰지 않아 언젠가 누군가가 버그를 고칠 수 있도록 버그를 고칠 수 있습니다.
시간이 지남에 따라 버그 목록이 너무 길어 아무도 더 이상 처리 할 수 없으므로 많은 시간을 소비합니다.

화이트 보드의 포스트잇을 사용하여 문제를 처리하고 대면 대화를 나누고 중요한 버그가 나타나는 즉시 죽이는 것을 선호합니다. 나는 그것이 오버 헤드의 가치가 있다고 생각하지 않기 때문에 버그 이력을 추적하는 데 너무 신경 쓰지 않습니다.

나 혼자 있니? 이슈 추적 시스템 사용의 단점 (또는 큰 장점)에 대한 연구 (서적 / 기사 / 무엇)가 있습니까?

project-management agile issue-tracking

— 사용자 1062120
소스

5

닫히고 투표가 너무 현지화되었습니다. 여기서 문제는 문제 추적 시스템이 아니라 회사의 버그 처리 프로세스와 관련이있는 것으로 보입니다.

— P.Brian.Mackey

1

포스트잇 메모 및 화이트 보드를 제외하고 어떤 문제 추적 시스템을 사용해 보셨습니까? 사용법에 대한 프로세스는 무엇입니까?

— FrustratedWithFormsDesigner

1

그 중 Jira 만 사용했습니다 ( "리듬"에 익숙해 질 때까지 오버 헤드가 많은 것 같습니다). 웹 UI의 팬은 아니지만 작업을 완료합니다. 여기서는 소스 제어도 수행하는 MKS도 사용합니다. 지라보다 낫다. 그들 중 누구도 완벽하지는 않지만 종이 노트와 사람들의 유기적 추억보다 여전히 낫습니다.

— FrustratedWithFormsDesigner

15

나는 그 질문에 혼란스러워한다. 사용 후 자사에 화이트 보드 IS 문제 추적 시스템. 프로젝트 / 팀 / 코드베이스가 충분히 작고 포스트잇 + 대면 작업이 작동하는 경우 프로세스에 더 많은 오버 헤드를 추가하도록 설득하는 데 어려움을 겪을 수 있습니다. 아래와 같이 시스템을 사용하는 데에는 많은 단점이 있습니다. 프로젝트와 팀이 성장하자마자, 특히 팀원이 같은 건물, 도시 또는 국가에 있지 않을 때 아래의 답변에 표시된 것처럼 다른 시스템이 빛나기 시작합니다.

— s_hewitt

2

스택 추적을 게시물에 어떻게 첨부합니까? 또는 스크린 샷? 또는 오류 메시지?

— jk.

41

문제를 설명하는 데 너무 많은 시간이 걸립니다. 이것은 사용법을 권장하지 않습니다.

버그를 설명 할 수 없다면 어떻게 고칠 수 있습니까?

버그를 보관할 장소를 만듭니다. 그리고 그들을위한 장소가 있다면 사람들은 보통 버그 원인을 수정하는 데 너무 신경을 쓰지 않아 언젠가 누군가가 버그를 고칠 수 있도록 버그를 고칠 수 있습니다.

그것은 소프트웨어가 아닌 팀의 문제입니다.

시간이 지남에 따라 버그 목록이 너무 길어 아무도 더 이상 처리 할 수 없으므로 많은 시간이 걸립니다.

다시 한 번 당신은 당신의 팀에 문제를 설명합니다.

버그 추적 소프트웨어의 요점은 팀이 버그를 해결하도록 동기를 부여하는 것이 아니라 버그의 원인을 추적하고 다시 발생하는 것을 막을 수 있도록 기록을 유지하는 것입니다. 어떤 소프트웨어도 좋은 관리를 대신 할 수 없습니다.

— 톰 스콰 이어스
소스

추적 소프트웨어는 또한 수정할 버그를 추적하는 데 도움이됩니다. 스티커 메모가 떨어질 수 있으며 네 사람이 바로 작업 할 수있는 버그를 발견하면 세 개를 고치고 네 번째를 잊어 버릴 수 있습니다. 버그의 원인에주의를 기울이지 않아도 유용합니다.

— David Thornley

당신이 게임 화를 사용할 수 있습니다 팀의 문제를 해결하기 -> en.wikipedia.org/wiki/Gamification

— marc.d

11

@JoaoBosco : 손으로 쓴 티켓을 잃어버린 채 실수로 튀어 나옵니다 ... 사진을 기억하지 못하는 사람들에게 복잡한 버그를 설명 할 때를 제외하고는 대면 대화가 훌륭합니다. 사람들 은 대화에서 물건을 잊어 버릴 것입니다. 왜냐하면 그들이 원하는 것이 아니라 단순히 일어나는 일이기 때문입니다.

— FrustratedWithFormsDesigner

3

@JoaoBosco : GUI 오류의 스크린 샷은 어떻습니까? 손으로 다시 그리시겠습니까? 잘못된 데이터 출력 샘플 (데이터베이스 오류 인 경우 m 개의 잘못된 데이터 열이있는 n 개의 행을 손 으로 작성할 준비가 되었습니까?) 스티커 메모로 잘 번역되지 않는 결함과 관련된 다른 형태의 디지털 인공물? 이 모든 것을 이슈 추적 시스템의 티켓에 쉽게 첨부 할 수 있습니다. 나중에 스티커 메모를 텍스트 파일로 변환하려는 경우 티켓을 정렬, 주문, 분류 할 수있는 데이터베이스가 문제 추적에 도움이되지 않는 이유는 무엇입니까?

— FrustratedWithFormsDesigner

10

@ user1062120 : "버그를 유지할 장소가 없으면 사람들이 더 자주 수정하기 시작합니다."또는 버그를 무시하고 잊어 버리기 시작합니다. 그것은 "사람들에게 동기를 부여하는 속임수"가 아니라 약점을 강점으로 바꾸려는 터무니없는 시도입니다.

— Michael Borgwardt

12

IMO 출발점이 편향되어 있습니다. 개발자가 버그를 수정하지 못하면 적절한 버그 추적 도구, 포스트잇, 석재 조각 등을 사용하여 버그를 추적하는지 여부에 관계없이 프로젝트가 실패하게됩니다. 공구를 사용하지 않거나 잘못 사용하면 공구 결함이 아닙니다. (즉, 나쁜 버그 / 이슈 트래커는 물론 거기에 있습니다 ... 나는이 일에 완전히 부적절한 도구를 사용하여 프로젝트를 수행 했으므로 얼마나 나쁜지 알 수 있다고 생각합니다. 그러나 좋은 것도 있습니다. 최소한의 행사와 오버 헤드가 필요하므로 관련 정보에 집중할 수 있습니다.)

그러나 개발자가 관심을 갖고 프로젝트 크기가 사소한 것보다 크고 개발자가 한 명 이상인 경우 일종의 관리가 필요합니다 (실제 프로젝트에서 모두 공통적 임) ), 곧 다음과 같은 질문이 생길 것입니다.

어떤 버그 중 먼저 수정해야합니까? (참고 : 제정신 프로젝트에서는 개발자가 아닌 제품 소유자 및 / 또는 관리자가 결정해야합니다. 우선 개발자는 열려있는 모든 버그를 알고 있어야 합니다!)
우리는 얼마나 많은 오픈 버그와 심각성을 가지고 있습니까?
출시 준비를하기 전에이 중 어느 것을 수정해야합니까?
이러한 수정 프로그램을 계획하는 데 시간이 얼마나 걸리나요? 종종 버그를 평균적으로 수정하는 데 시간이 얼마나 걸립니까?
마지막 릴리스에서 클라이언트가 몇 개의 버그를보고 했습니까?
이 버그를 수정 한 사람은 누구이며 언제, 어떤 코드 변경 / 구성 / 데이터 변경 사항이 수정 되었습니까?
출시하려고하는 릴리스에 어떤 버그 수정이 포함되어 있습니까?
...

포스트잇 메모를 기반으로 반복적이고 안정적이며 효율적으로 이러한 질문에 답변 할 수 있습니까 ?

예, 이슈 트래커에 버그 데이터를 입력하면 약간의 오버 헤드가 발생합니다. 그러나 저장된 버그 데이터에서 위와 같은 보고서를 찾고 작성하는 데 드는 시간과 노력으로 보상됩니다.

— 페테르 토 ö
소스

포스트잇은 모든 것에 응답하지 않습니다. 도구 일뿐입니다. 그래도 우선 순위를 정하고 오픈 버그, 수정 된 버그 등에 대한 통계를 작성할 수 있습니다. 내가 말하는 것은 이슈 관리 시스템이 관리 문제를 해결하는 데 도움이되는 것보다 역효과를 낳을 수 있다고 생각합니다.

— user1062120

7

@ user1062120 : 그리고 다른 모든 사람들은 당신이 매우, 매우 틀렸다고 말합니다. 포스트는 자사가 있습니다 문제 추적 시스템, 필수적인 기능이 많이 부족 그냥 아주 가난한.

— Michael Borgwardt

물론 @ user1062120은 이론적으로 모든 메모에 스티커 메모를 사용하여 답변 할 수 있습니다. 각각에 고유 ID를 추가하면 자세한 기록 메모를 계속 추가하십시오 (따라서 잠시 후에 큰 스티커 메모가 필요합니다 :-) 현재 질문 (더 큰 프로젝트에서 새로운 사람을 고용해야 할 수도있는 ;-)에 따라 정렬, 재구성 및 재정렬에 엄청난 시간을 소비하십시오.

— Péter Török

@ user1062120, 예를 들어 계획은 위의 질문 1을 산출합니다. 우선 순위에 따라 스티커 메모를 재 배열합시다. 곧 PM은 Q2에게 질문합니다 : 죄송합니다. 심각도별로 재 배열하십시오. 그러나 Q1은 여전히 열려 있으므로 우선 순위별로 다시 정렬 해 보겠습니다. 죄송합니다. Joe의 책상에 있었기 때문에 3 개의 포스트잇이 제외되었습니다. 다시 시작하십시오! 그런 다음 Q6-역사적인 포스트잇을 저장하는 상자를 발굴하고 손으로 직접 찾아 적절한 것을 찾은 다음 뒷면의 낙서를 읽으십시오. 변경 사항을 설명하기위한 것입니다. 근처에 창문을두고 서둘러 바람을 피하여 포스트잇을 저장하십시오.

— Péter Török

9

귀하의 방법론은 제한된 수의 프로그래머가있는 매우 작은 프로젝트에서 작동 할 수 있습니다. 프로젝트가 커지면 문제 추적 시스템을 갖는 것이 특히 다른 코드 릴리스에서 수정 사항이 나오게 될 때 다른 팀 간의 조정에 훨씬 더 중요해집니다. 복잡한 프로젝트에는 많은 움직이는 부품 / 구성 요소가 있으며 문제를 예약하고 수정하는 것이 좋은 문제 추적 구현의 큰 부분입니다.

관심을 가질만한 일부 기사 / 연구에는 Zend의 Jira 사용에 관한 기사 와 버그 추적 시스템의 사용에 관한 프랑스 연구가 포함 됩니다.

— JW8
소스

1

참조 해 주셔서 감사합니다. 나는 그들을 살펴볼 것이다. 네, 여기 3 개의 소규모 팀에서 일하고 있습니다.

— user1062120

2

질문에서 명시 적으로 요구되는 참조에 대해 +1입니다.

— mattnz

4

연구가있을 수 있지만 현장에서 사람들의 힘든 경험은 더 좋습니다. 대부분의 이슈 추적 시스템은 설계를 주도하는 프로세스로 인해 어려움을 겪고 있습니다. 이슈 트래커는 종종 다음과 같은 2 가지 사용자를 지원해야합니다.

개발팀
시스템 사용자

Cal Henderson (이전의 Flickr)은 많은 이슈 트래커의 디자인과 그가 GitHub 이슈 트래커를 선호하는 이유에 대해 큰 글 을 올렸습니다 (I처럼). 또한 Garrett Dimon은 Sifter 의 디자인을 다루고 보다 효과적인 문제 추적 을 위해 프로세스를 단순화하는 방법을 보여 주었습니다 . 팀의 문제 추적 워크 플로를 단순화하기 위해 두 게시물의 아이디어 중 일부를 채택했습니다.

그럼에도 불구하고 여전히 프로세스와 도구를 통해 사람들에게 제공됩니다. 내 일반적인 생각은 이슈 트래커가 관리해야하는이 백 로그를 만드는 경향이 있다는 것입니다. 심사하는 동안 사람들은 버그가 무엇인지 합리화 할 가능성이 높습니다. 이 과정에서 버그가 문제인지 여부에 대한 버그가 제기되는 즉시 결정을 내립니다. 일단 결정이되면 버그는 Pivotal Tracker에 들어갑니다. 여기서의 차이점은 우리가 원하지 않는 일에 대한 보류 펜이 아니라 우선 순위 지정 을 위해 트래커를 사용 한다는 것입니다. 실제로 Icebox가 너무 커지기 시작하면 버그를 포함하여 항목을 적극적으로 삭제합니다. 문제가 처리하기에 충분히 큰 경우 다시 나타납니다.

버그 이력이 거의 필요하지 않습니다. 때때로 누군가가 버그의 증상을 언급 할 수 있으며, 우리가 이미 처리 한 문제와 관련이 있는지 확인하기 위해 검색을 수행 할 수 있습니다. 그러나 드문 일입니다.

TL; DR 프로세스에 집중하고 간단한 도구를 선택하고 문제가 발생할 때이를 해결합니다.

— kstewart
소스

그것이 바로 내가 의미 한 바입니다. 또한 항목이 표시되는 즉시 우선 순위를 지정하고 중요하지 않은 항목도 삭제합니다. 중요한 것들이 제 시간에 다시 올 것입니다. 모든 것을 추적하는 오버 헤드가 가치가 없다는 것을 알았습니다. 작은 포스트잇 화이트 보드를 사용한다는 것은 물리적으로 모든 것을 등록 할 수없고 중요한 것만 등록한다는 것입니다. 따라서이 트릭은 가능한 빨리 처리하도록합니다. 그러나 이것이 내 경우이므로 모든 곳에서 작동하는지 확실하지 않습니다.

— user1062120

2

중요한 버그가 나타나 자마자 죽이기

당신이 여기 열린 문을 뚫고있는 것처럼 들립니다. 이슈 트래커를 사용하든 아니든 관계없이 중요한 버그는 가능한 빨리 "종료"됩니다.

아 그리고 "그들이 등장하는"부분은 상당히 미끄러운 BTW입니다. 한 프로젝트에서 우리는 전체 제품을 비즈니스에서 버릴 위협이있는 중요한 버그를 가지고있었습니다 (더 중요한 것이 무엇입니까?). 매우 복잡하고 (아키텍처 오류) 수정하는 데 시간이 오래 걸린다는 것을 알고있었습니다. 고객은 우리에게 제품을 떨어 뜨리기 전에 1 년을 수리하기로 한 것에 대해 친절하게 동의했으며 약 1 년 후에 해결했습니다.

이슈 트래커에 관해서는 거의 10 년 동안 이것들을 사용해 왔으며, 일반적으로 내 주변의 모든 프로그래머 는 트래커와 거의 시간 을 보냈습니다 (메모에 대해 이야기하고 있습니다; 관리자는 다른 이야기입니다). 나는 그렇지 않은 경우 (드물게) 사례를 보았습니다.이 모든 경우에 무언가가 심각하게 깨졌습니다.

대면 대화와 문제 추적에 관한 연구와 관련하여 다시 한 번 여기 문을 열고있는 것처럼 느껴집니다. 이슈 추적은 일반적인 서면 커뮤니케이션입니다. 일을 논의 할 것으로 많은 연구 전시가, face2face의 통신은 훨씬 더 효율적보다 전화를 통해 차례로 훨씬 더 효율적보다 기록 .

실제로 f2f에 대해 물어 보면 트래커를 사용하여 물건을 토론하는 것처럼 느껴집니다. 이것은 목적이 아닙니다. 의도 된 용도를 파악하려면 이름을 천천히 명확하게 입력하십시오 : 이슈 추적 시스템 .

버그 목록이 너무 길어집니다

내 경험상 위의 문제는 문제가 아닙니다.

함께 긴 버그 목록 개발자들은 훨씬 앞서 큐 계획 수정을 설정할 수 있습니다. 이것은 생산성만큼 향상됩니다. 나에게 이것은 기본적으로 작업 할 대기열이있을 때 열반입니다. 먼저 버그 - 수정 - 일, 두 번째 버그 - 수정 - 일, 다음 버그 - 수정 - 일 등 등 아니 바보 중단, 오 - 그래서 효율적인 F2F 대화와 전혀 고통스러운 산만 순수한 흐름 .

긴 버그 목록 이 문제가 된 경우를 한 번 기억합니다 . 고위 경영진의 일부 바보가 개발자가 거의 매일 50-100 더미에서 다음 버그를 선택하도록하는 정책을 결정할 때 일어났습니다. 정말 낭비입니다. 이것을 머리 위로 에스컬레이션하고 고치는 방법을 알아낼 때까지 몇 개월의 고통이 걸렸습니다.
편리한 작업 흐름을 구축 한 후 얼마 지나지 않아 "끝없는 백 로그"가 마술처럼 비었다는 것을 발견했습니다.

— 모기
소스

2

나는 최근 1 년 동안 발생한 300 개가 넘는 오픈 버그 (주로 UI)를 통해 2.5 일을 보냈으며, 모두 프리랜서 나 인턴, 또는 오랫동안 다루지 않은 프로젝트 관리자에게 할당되었습니다. 나는 이미 고정되었거나 더 이상 관련이없는 것으로 그들 중 약 절반을 닫을 수 있음을 발견했습니다. 내가 적절한 사람들에게 할당 한 후 나머지는 괜찮은 속도로 고정되고 있습니다. 버그 추적 시스템은 제대로 사용되지 않았지만, 그렇지 않은 경우, 모든 버그 (쇼 스토퍼는 없지만 아주 추악한)는 반드시 잊혀 졌을 것입니다.

— Michael Borgwardt

1

@MichaelBorgwardt 예 , 200, 400, 1000과 같은 무서운 숫자로 얼어 붙지 않는 한 내 경험에서 아무도 그것을 처리 할 수 없도록 너무 오래 나열합니다 . 나는 호기심을 빠르게 확인했습니다. 작년에 나는 300 개 이상의 문제를 고쳤습니다-나 혼자 (!). 호기심으로 팀의 다른 사람들도 독특하다고 생각했습니다. 아니요, 200-400 수정 / 년은 평균 속도로 보입니다. 500 버그 그러나 이러한 모습을 두려워, 4-5 개발자, 케이크 조각에 대한 반년의 작업 일 수 있습니다 :)

— gnat