프로그래머와 기술이 아닌 직원에게 친숙한 방식으로 버그 추적을 어떻게 처리합니까? [닫은]

우리는 실제로 프로젝트에 Mantis를 사용하고 있습니다. 아니면 "사용하려고합니다"라고 말해야합니까? 내가 아는 모든 버그 추적기의 문제는 프로그래머가 프로그래머를 위해 만든 것입니다. 따라서 디자인이 존재하지 않거나 완전히 터무니 없습니다.

물론 프로그래머로서 문제없이 사마귀를 사용할 수 있지만 프로젝트에 참여하는 모든 사람들이 너무 나쁘게 설계되어 사용하기 어려워서 글 머리 기호 목록으로 Google 문서를 만드는 것을 선호하는 경우 버그 추적기가 얼마나 유용합니까? 그들이 찾은 버그 나 제안 사항 중

포럼을 설치하려고합니다. 버그 추적기와 일반 글 머리 기호 목록 사이의 "중간"솔루션처럼 보입니다. 최소한 포럼에서는 제안에 대한 토론을 모니터하고 중앙 집중화 할 수 있습니다.

내 우려가 명확하지 않은 경우 내 질문은 다음과 같이 요약 될 수 있습니다.

비 기술적 인 사용자에 대한 버그 및 제안 보고서를 어떻게 처리합니까?

** 참여함으로써, 나는 실제 고객 또는 최종 사용자를 의미하지 않습니다. 우리의 통합 자, 프로젝트 관리자 및 QA와 관련된 사람들에 대해 생각하고 있습니다.

우리는 올해 초 Mantis에서 FogBugz (및 Kiln)로 전환했지만, 우리가 변경하지 않은 한 가지는 "사용자"가 버그 추적기에 전혀 액세스하지 못하게한다는 것입니다. 다른 부서 책임자 중 일부는 읽기 전용 액세스 권한을 갖지만 정직하게는 관리자이며 보통 몇 주 내에 잊어 버립니다. 소프트웨어 사용자는 구성 문제, 사용자 오류 또는 소프트웨어 버그인지 확인하는 단일 문제 해결 담당자를 처리합니다. 그런 다음이 사람은 실제 문제를 FogBugz에 입력하기위한 게이트 키퍼 역할을합니다. 이렇게하면 실제로 관련이없는 문제로 인해 시스템이 복잡해지지 않습니다.

따라서 실제 질문에 대답하기 위해 ... "프로그래머"만이 사용하기 때문에 버그 추적 소프트웨어는 "프로그래머에 의한", "프로그래머에 대한"라는 것이 실제로 문제가되지는 않습니다. 다른 사람들은 모두 인간을 직접 다루고 있습니다.

(우리 제품은 축소 제품이 아니며 모든 사용자는 직속 직원이거나 서비스 부서의 직원과 협력하고 있습니다.)

우리는 이런 종류의 일에 레드 마인 을 사용 합니다. 주요 트릭은 사용자의 대부분은 결코 볼 수없는 그들은 단지 support@example.com에 이메일을 보내 - 레드 마인을. 주로 레드 마인 계정을 숨기고 문제 번호를 포함하여 몇 가지 고급 트릭을 사용하여 업데이트를 레드 마인으로 유지할 수 있습니다. 좀 더 진보 된 사람들을 위해, 우리는 그들이 MANTIS보다 훨씬 현대적이고 사용자 친화적 인 것을 감안할 때 직접 레드 마인을 사용하도록했습니다.

현재 우리는 MKS를 사용하고 있습니다. 프로그래머가 아닌 사람들을 위해 보고서와 관심있는 요약이 포함 된 대시 보드를 설정했습니다. 이는 초기 설정을 수행해야하지만 결함의 진행률과 전체 요약을 모니터링 할 수 있음을 의미합니다. 보고서와 대시 보드에 액세스하는 방법을 보여 주면 그들은 또한 그들의 표를 수정하는 약간의 훈련이 필요하지만이됩니다 항상 이 될 몇 가지 훈련 오버 헤드. 다행히도 관련 기능에 비례했습니다.

나는 Redmine을 두 번째로 개인적으로 버그 Genie (예, 치즈 이름이 있지만 잘 디자인되었습니다 .PHP 환경에 있거나 어떤 이유로 든 Ruby를 실행할 수없는 경우)를 개인적으로 사용 하여 기술 사용자.

그 외에도 키 중 하나는 최종 사용자가 기본적으로 입력 한 것보다 더 많은 문제를 볼 필요가 없다는 것입니다 (선택적으로 중복 티켓을 피하는 검색 기능이있을 수 있지만 사용자의 요구와 설정에 따라 다름). 모든 문제를 확인하면 인터페이스가 복잡해져 최종 사용자가 혼동 될 수 있습니다. 일반적으로 사용자는 자신이 볼 수있는 것만 볼 수 있으므로 프로젝트 관리자는 예를 들어 자신이 제어하는 ​​프로젝트의 문제 만 볼 수 있습니다. 다른 사람들이 언급했듯이 최종 사용자의 경우 티켓 제출이 간단할수록 좋습니다. 추적기 UI가 필요없는 티켓 제출이 가능한 경우 보너스 포인트 (이메일 또는 티켓 제출에 필요한 필드 만있는 간단한 양식을 통해).

이전에는 Team Systems라고 알려진 "Visual Studio의 응용 프로그램 수명주기 관리 기능"을 사용합니다. 우리에게 큰 장점 중 하나는 쿼리 결과 (예 : "모든 요구 사항"또는 "다음 릴리스에없는 pri 2 이하의 모든 버그")를 스프레드 시트 또는 프로젝트 문서로 내보낼 수 있다는 것입니다. 프로젝트 관리자, 최종 사용자 담당자, 이해 관계자 등은 이러한 파일을 편집하여 우선 순위 변경, 설명 업데이트, 다른 사람에게 할당 등 무엇이든 할 수 있습니다. 그런 다음 파일이 TFS에 연결된 시스템으로 파일을 되 돌리면 게시 및 변경 사항은 다시 저장소로 이동합니다. 프로그래머는 Visual Studio에서 직접 작업 항목으로 작업하지만 프로그래머가 아닌 사람은 VS 근처에 가지 않습니다. 또한 각 TFS 프로젝트에 대한 공유 사이트가 있으므로

VS 상점이 아닌 경우 선택 사항이 아닌지 여부는 생각할 가치가 있습니다.

QA / PM 직원과 이야기하는 경우 다양한 공개 소스 및 폐쇄 소스 추적 도구를 평가해야합니다. 빌드 등을 설정하는 기능이있는 것이 좋으므로 QA / PM 담당자가 특정 빌드에 대해 티켓을 넣을 수 있으며 문제를 해결하면 테스트 할 빌드를 알 수 있습니다.

내가 사용한 대부분의 독점 도구는 실제로 프로그래머보다 프로그래머가 아닌 사용자를 위해 더 조정되었습니다. 스타 팀 (StarTeam)은 저에게 꽤 효과가 있었지만 여전히 주변에 있는지 모르겠습니다. 원하는 경우 필드 등을 사용자 정의 할 수 있습니다. 그들이 그렇게하지 않도록하십시오.

최종 사용자에 대해 이야기하는 경우 헬프 데스크 소프트웨어를 확인한 다음 헬프 데스크 직원이 필요에 따라 버그 도구로 에스컬레이션하도록해야합니다.