버그 / 문제를 추적하기 위해 공유 스프레드 시트를 사용하지 말 것을 어떻게 하시겠습니까?

우리 회사에서 개발자는 적절한 버그 추적 도구를 사용하여 응용 프로그램의 문제를 관리하려고합니다. 그러나 경영진은 공유 스프레드 시트 (이전에는 공유 엑셀 파일, 이제는 동시 액세스가 가능한 웹 기반 솔루션의 스프레드 시트)를 사용해야합니다.

그들의 주장은 스프레드 시트를 통해 프로젝트 상태를 한 눈에 더 잘 볼 수 있다는 것입니다. 이를 통해 각 버그에 대해 누가 작업하고 있는지 확인할 수 있으며, 개발자가 작업중인 버그에 대한 시간 추정을 작성해야하므로 버그를 모두 해결하는 데 필요한 시간을 예상 할 수 있습니다.

아시다시피, 이것은 개발자에게 사용하기에 실용적이지 않습니다 (버그 추적 소프트웨어는 이유로 개발되었습니다). 그렇다면 개발자의 작업을 쉽게하기 위해 버그 추적 소프트웨어를 어떻게 옹호 할 수 있습니까?

보너스로, 경영진이 높은 수준의 견해로 피드백 (버그 수, 버그 수, 버그 추정 시간)을 얻을 수 있도록 권장하는 소프트웨어는 무엇입니까?

그렇다면 개발자의 작업을 쉽게하기 위해 버그 추적 소프트웨어를 어떻게 옹호 할 수 있습니까?

이 진술이 주어지면 :

스프레드 시트를 사용하면 프로젝트 상태를 한눈에 더 잘 볼 수 있으므로 프로젝트 상태를보다 상세하게 볼 수 있습니다.

스프레드 시트를 "실시간"으로 (또는 가능한 한 가깝게) 효과적으로 만들 수있는보고 도구가있는 시스템을 살펴 봐야합니다. 이 중 하나를 발견하면 개발자가 "적절한"시스템을 사용하게되면 관심있는 데이터가 (예를 들어) 더 정확하고 최신 정보임을 의미합니다.

어떤 버전의 스프레드 시트가 최신 버전입니까? 그 스프레드 시트는 누구입니까?

괜찮은 버그 추적기는 스프레드 시트로 할 수있는 작업 만 수행합니다.

• 변경 사항이있을 때 관련 당사자에게 이메일을 보냅니다.
• 최신 정보의 단일 정식 소스를 제공합니다
• 요약 보고서를 제공하여 프로젝트 상태에 대한 높은 수준의 뷰를 제공합니다.

개인 프로젝트에는 Mantis를 사용합니다 (설정하기가 쉽기 때문에). Work는 Trac 을 Mercurial 통합과 함께 사용합니다 .

Mantis는 상자에서 개설 / 폐쇄 / 할당 된 버그 수와 같은 것들을 제공하며 대부분의 버그 추적기가 가능하다고 생각합니다. 나는 시간 예측에 대해 모른다. 왜냐하면 내가 귀찮게하지 않기 때문이다. Trac (또는 직장에서의 설치)에는 시간 추정치가 있으며 마일스톤 당 추정치를 합산하는 맞춤형 보고서를 작성하기 쉽습니다.

다른 사람의 대답은 좋습니다. 또 다른 측면이 나에게 일어난다.

스프레드 시트 주변의 보안은 어떻습니까? 경영진이 임의의 개발자가 실수로 CTRL + A, DELETE 버튼을 눌렀을 때 실제로 문제가 발생할 우려가 있습니까? 적절한 버그 추적 시스템은 이러한 종류의 데이터 손상을 허용하지 않습니다. 그리고 그것은 악의를 설명하지도 않습니다. 특정 개발자가 더 많은 크레딧을 원하고 모든 결함 수정 사항을 자신에게 다시 할당하기 시작하면 어떨까요? 실제 시스템에는 그러한 종류의 것이 눈에 띄는 감사 내역이 있습니다. 스프레드 시트는 그렇지 않습니다.

요구 사항이 충족 될 것임을 경영진에게 보여 주어야합니다.

그들의 주장은 스프레드 시트를 통해 프로젝트 상태를 한 눈에 더 잘 볼 수 있다는 것입니다. 이를 통해 각 버그에 대해 누가 작업하고 있는지 확인할 수 있으며, 개발자가 작업중인 버그에 대한 시간 추정을 작성해야하므로 버그를 모두 해결하는 데 필요한 시간을 예상 할 수 있습니다.

따라서 더미 시스템을 설정하고 스프레드 시트를 사용하는 것보다 더 나은 정보를 얻을 수 있다는 데모를 보여줍니다.

지금까지 모든 사람들은 비슷하고 적절한 반응을 얻었습니다. 아직 언급되지 않은 중요한 측면이 있습니다. 버그를 추적하고 균열을 통해 아무것도 미끄러지지 않도록하려면 두 가지가 필요합니다.

• 좋은보고, 요약 및 세부 사항 모두-나중에 검색 가능
• 모든 사람은 최신 사본이 어디에 있는지 알아야합니다.

Excel 스프레드 시트 사용을 옹호하는 거의 모든 환경에서 모든 사람의 컴퓨터에이 스프레드 시트의 사본이 다르며 그 중 어느 것도 동일하지 않습니다. 따라서 진행 상황을 검토하는 과정이 매우 어렵고 비생산적입니다.

Trac, RedMine, JIRA, Mantis 또는 원하는 모든 것과 같은 중앙 집중식 서버는 이러한 문제를 모두 처리합니다. 이때 회사의 요구에 가장 잘 맞는 문제입니다. 환경에 따라 이러한 도구는 버전 제어 시스템과 마찬가지로 IDE와 통합 될 수 있습니다 (Eclipse에는이 기능이 있습니다). 이렇게하면 할당 된 버그를 훨씬 쉽게 처리 할 수 ​​있습니다.

환경을 모르지만 Visual Studio 사용자에게는 TFS를 적극 권장합니다. 전체보고 기능과 함께 소스 제어 및 문제 추적을 통합합니다. 또한 권한 계층, 전체 히스토리 추적 (즉, 누가 버그를 설정했는지, 왜 설정했는지에 대한 이유)을 제공하여 "버그"와 "문제"및 "향상된"및 기타 원하는 사항을 구분할 수 있습니다. Visual Studio IDE와 완전히 통합됩니다. 체크인 된 코드와 버그를 함께 묶어 특정 빌드에 연결할 수 있습니다. 그리고 훨씬 더.

저는 다양한 소스 제어 시스템 (VSS, SVN, TFS ...)과 많은 버그 추적 시스템 (맞춤형 독점 시스템, 트래커, SharePoint, 예, Excel 등)을 사용했지만 돈을 위해 사용했습니다. TFS는 돈과 시간에 투자 할 가치가 있습니다.

그렇습니다. Excel로 내보내거나 가져올 수 있습니다.

적절한 이슈 트래커로의 전환을 판매하려면 현재 시스템에서 이슈 관리에 어떤 이슈가 있는지 ( '만약 괜찮다면 ...') 알아 내고 그 가려움증을 긁을 수 없는지 확인해야합니다. 그들을 위해.

경영진의 주장을 읽고

그들의 주장은 스프레드 시트를 통해 프로젝트 상태를 한 눈에 더 잘 볼 수 있다는 것입니다. 이를 통해 각 버그에 대해 누가 작업하고 있는지 확인할 수 있으며, 개발자가 작업중인 버그에 대한 시간 추정을 작성해야하므로 버그를 모두 해결하는 데 필요한 시간을 예상 할 수 있습니다.

나는 그들 모두와 동의했고 모든 하나 는 JIRA에 의해 충족되었습니다 (나는 내가 사용하는 것이므로 JIRA에 대해서만 언급합니다.

JIRA와 같은 도구를 사용하면 현재 설정의 모든 장점을 유지할뿐만 아니라 많은 새로운 이점을 얻을 수 있다는 점을 강조해야합니다.

이야기 시간.

몇 달 전에 저는 일주일 휴가로 돌아와서 회사 전체가 고개를 끄덕였습니다. 개발 부서의 다른 부서에서 수개월 동안 진행해 온 프로젝트는 갑자기 급박 한 우선 순위였으며 팀 전체가 문제를 해결하기 위해 작업중인 작업에서 제외되었습니다. 그날 회의에서 회사의 소유자는 다음 날 몇 조각을 치우고 나머지는 그 다음날 나머지 부분을 노크 해달라고 요청했습니다.

6 주 후 우리는 거의 멈추지 않은 작업 / 수면주기 후에 마침내 그 사실을 전달했습니다.

"완료"에 대한 메트릭은 고객에게 더 이상 피드백이 없다는 것입니다. 새롭고 흥미 진진한 소식은 이전에는 없었던 각 버전의 피드백 (이메일로 우리에게 전달됨)에서 나타 났으며, 그들이 말한 모든 단어는 즉시 사양의 일부였습니다. ").

하룻밤 늦게 이메일과 체크 아웃으로 출력되는 버그 보고서를 관리하면서 HAD IT를 완전히 놀라게했습니다. 테스트 서버에 Mantis를 설치하고 방금 수신 한 피드백 문서를로드했습니다. 관리자를 사용자로 설정하고 문제가 해결 될 때 관리자로부터 이메일을 받기 시작했습니다.

약 6 시간 안에 나는 모든 팀을 구성했습니다. PM은 클라이언트 이메일을 Mantis로 필터링하고 개발자는 문제 목록을 주장하고 작업했습니다. 또한 시스템 내부에서 설명 및 통신을 요청하여 각 항목에 대한 세부 정보를 종이없이 기록 할 수있었습니다.

다음날 그들은 프로젝트의 나머지 부분을 Tech Lead에게 요청했습니다. 살아있는 수류탄을 넘기는 것과 같았지만 나는 그것을 가지고 달려갔습니다. 2 주 후 마침내 우리는 고객이 코링을 잡아 당기고 현장을 생산할 수있는 능력을 소진했습니다. Mantis는 이제 버그를 관리하는 방법이며 프로젝트 초기부터 기능 요청을 처리하는 방법이 될 수 있습니다.

TL; DR : 자체 설치하고 자신의 작업에 사용하십시오. 그 자체로 가치를 입증하십시오.

BTW, 이것은 버전 관리에 대해 따르는 것과 동일한 정책입니다. 관리자는 파일 병합을 신뢰하지 않기 때문에 잠금이 필요한 정책에서 Subversion을 사용합니다. 괜찮습니다.하지만 SVN 프로젝트를 확인한 후에는 개발에 사용하기 위해 즉시 로컬 git 저장소를 만듭니다.

우리는 Atlassian Jira를 사용하고 있습니다.

다음과 같은 많은 보고서가 있습니다.

관리자가 스프레드 시트를 열면 필요한 모든보고 데이터가 선택한 앱에서 업데이트되는 스프레드 시트를 만들어야합니다. 당신이 그것을 작동하게하면 논쟁이 없습니다.

네트워크 공유에서 버그 추적 스프레드 시트로 잘못 될 수있는 사항 :

• 다른 사람이 열어 놓은 후에는 편집 할 수 없으며 워크 스테이션을 잠그고 점심을 먹습니다.
  • "명백한"해결 방법은 새 버전을 작성하여 저장하는 것입니다. 이것은 브랜치를 생성하고 Excel은 병합하기에 좋지 않습니다. 누군가의 작업이 손실됩니다.
• 문서는 숨겨진 행으로 저장 될 수 있으며 몇 주 동안 문제가 간과됩니다.
• 무엇이든 삭제할 수 있으며 기록 추적이 미미합니다. "지난 주에 입력 한 자세한 문제 분석은 어떻게 되었습니까?"
• '제한된'필드에 값을 쉽게 추가 할 수 있습니다. "이 버그의 심각도는 어떻게 '에픽 실패'로 표시 되었습니까?"
• 잘라 내기 및 붙여 넣기는 수식을 덮어 씁니다. 계산은 쉽게 상수가 될 수 있습니다.

나는이 모든 것을 통해 살아왔다. 그리고 우리는 여전히 배달 할 수있었습니다 ... 단지 3 개월 늦었고 수천 시간의 계획되지 않은 초과 근무 시간이 발생했습니다.

"무료입니다!" 보통 꽤 좋은 주장입니다. Pivotal Tracker 는 무료이며 설치가 필요하지 않으며 스프레드 시트가 적은 것보다 관리자에게 더 쉽게 높은 수준의보기를 제공 할 수 있습니다.

편집하다:

저의 성가심에, 피보 탈 트래커는 더 이상 무료가 아니라고 발표되었습니다. :(