Scrum / Kanban 보드를 사용할 때 기존 이슈 트래커의 역할은 무엇입니까?

매우 높은 수준의 관점에서 볼 때 일반적으로 프로젝트 관리 도구에는 두 가지 유형이 있습니다.

1. Fogbugz, JIRA, BugZilla, Trac, Redmine 등과 같은 전통적인 이슈 트래커
2. 가상 카드 보드 / Pivotal Tracker, GreenHopper, AgileZen, Trello 등과 같은 민첩한 프로젝트 관리 도구

물론 Pivotal Tracker 작업은 JIRA로 가져올 수 있으며 GreenHopper 자체는 JIRA 이슈 기반 등에서 구현됩니다. 그러나 두 가지 유형의 도구 사이에서 방향의 차이를 여전히 볼 수 있다고 생각합니다.

기존의 이슈 트래커는 민첩한 프로젝트 관리를 수행하는 회사에서도 사용되는 것으로 보입니다. 내 질문은 왜 그렇게 하는가? 또한 회사에서 이슈 트래커를 사용해야한다고 생각하지만 생각할 때 실제로 왜 필요한지 잘 모르겠습니다.

예를 들어, Trello 개발은 Trello 자체 ( 이 가상 벽 참조)를 사용하여 관리하는 것 같습니다 ( 이 가상 벽 참조 ). 따라서 민첩한 PM 도구 중 하나를 사용하여 민첩하게 작업의 100 %를 수행 할 때 전통적인 이슈 트래커가 필요하지 않을 수 있습니다.

팀이 일할 수있는 방법은 적어도 세 가지가 있습니다. 팀에 적합한 것을 선택하십시오.

1. 세부 사항과 고급 개요

개별 작업을 추적하려면 이슈 트래커를 사용하십시오. 문제 추적기의 작업 요약으로 카드 보드를 사용하여 주요 기능의 큰 그림을 유지하십시오.

2. 버그 대 기능

이슈 트래커를 사용하여 개별 버그 및 고객 서비스 요청을 추적하십시오. 개발중인 새로운 기능을 추적하려면 카드 보드를 사용하십시오.

3. Milestone 소프트웨어 제공 및 지속적인 소프트웨어 제공

대규모의 새로운 기능 블록을 비 정기적으로 제공하는 경우 (예 : Windows 팀이고 몇 년마다 새 버전이있는 경우) 문제 추적기를 사용하십시오. 대규모의 완성 된 프로젝트가 고객에게 한 번에 모두 제공되는 개발 프로세스에 이상적입니다 (게임, 임베디드 소프트웨어 및 연간 또는 반년 릴리스를 기반으로하는 기존 소프트웨어 포함).

고객에게 지속적으로 또는 매우 빈번하게 가치를 제공하는 웹 팀과 같이 개발 된 고객에게 새로운 기능을 지속적으로 제공하는 경우 카드 보드를 사용하십시오. 이 시나리오에서 소프트웨어 개발 프로세스는 조립 라인과 거의 같고 시작과 끝이있는 프로젝트와 비슷합니다.

간단한 답변은 기존의 이슈 추적 소프트웨어가 백 로그를 관리하는 데 도움이되는 반면 스크럼 보드는 현재 스프린트와 릴리스를 추적하는 데 도움이된다고 생각합니다.

물론 두 가지 유형의 도구를 사용하여 두 가지를 모두 수행하는 것이 가능하지만 결국 타협해야합니다.

전체 공개 : Atlassian의 GreenHopper 제품 관리자이기 때문에 약간 편견이 있지만 오랫동안 Atlassian 외부의 Agile 개발에 참여했습니다.

애자일 계획 도구 또는 이슈 트래커 만 있으면 가능합니다. 문제는 그것이 최적이 아니라는 것입니다. 내 경험상 다음과 같은 이유로 최적이 아닙니다.

• 제품 계획은 일반적으로 백화점의 Epic 및 Story 수준에서 발생합니다. 민첩한 계획 도구가 여기에 좋습니다
• 그러나 오래된 말이 진행될 때, 적과 처음 접촉 한 후에도 어떤 계획도 살아남지 않습니다. 처음 몇 출시 후이 경우 당신이 결합 된 QA에 의해 기록되는 버그 (및 기타 피드백)와 결국, 고객은 그것을 압도 당신의 계획에 다시 공급하지만하는 등 이러한 필요를 지원

따라서 애자일 계획 도구 만 있으면 훌륭하지만 제품이 성숙 해지고 외부 입력이 많아 질수록 해당 입력을 효과적으로 관리하기가 점점 더 어려워집니다. 이러한 외부 기고자 중 일부는 단순히 '관리되는 민첩한 백 로그'유형의 방식으로 기여할 수 없으며 문제를 제출하고 계속 진행하기를 원합니다. 여기서 이슈 트래커를 사용하면 이러한 기여자를 참여시키고 제품 개발을 계속 진행하는 지속적인 비즈니스를 성공적으로 관리 할 수 ​​있습니다.

두 도구가 모두 필요하다고 말하고 싶습니다. 또한 통합해야 할 필요가 있습니다. 그렇지 않으면 둘을 동기화하기 위해 모든 시간을 소비하게됩니다.

일부 제품은 스토리와 작업에 비해 결함에 대해 조금 더 최적화되어 있지만 실제로 큰 차이는 없습니다. 강제 구조 또는 필수 필드 측면에서 너무 많은 오버 헤드를 발생시키지 않는 우수한 민첩한 PM 도구를 결함 추적에 쉽게 사용할 수 있습니다. 내 현재 프로젝트는 작업과 결함 모두에 단일 도구를 사용하고 있으며 POS 제품과는 별도로 작동합니다. :)

우리 는 버그 추적기의보다 전통적인 역할 인 Joel의 답변 에서 3 위인 DoneDone 이라는 이슈 추적기를 실행합니다 . 실제로, 컨설팅은 역사적으로 비정기적인 간격으로 많은 웹 사이트 형태로 코드를 제공하기 때문에 구축했습니다.

우리는 한 달 전에 DoneDone 사용자에게 약간의 봉사 활동을했으며, 그들 중 상당수는 Trello 및 Sprint.ly와 유사한 프론트 엔드를 요청하여 더욱 지속적인 코드 / 릴리스주기를 요청했습니다. 또 다른 유용한 통찰력은 이러한 많은 사람들이 QA가 시작되기 전에 DoneDone을 ​​사용하고 있기 때문에 프로젝트 (또는 기능)가주기 사이에서 이동할 때 한 곳에서 모든 데이터를 원한다는 것입니다.

내 두 센트는 약간의 워크 플로우가 적용된 모든 데이터입니다. 차이점은 실제로 UI이며 팀을 수용하는 방법과 당시의 방법론 및 / 또는 프로젝트 단계입니다.

문제 추적은 프로젝트 관리가 아닙니다. 많은 도구가 둘 다 수행 할 수 있도록 설계되었으므로 한 시스템이 다른 시스템을 대체하지는 않습니다.

Kanban 보드는 현재 진행중인 작업에 대한 멋진 개요를 제공하며 우선 순위가 무엇인지 한눈에 알 수있는 반면 이슈 트래커를 사용하면 문제를 버전 관리 시스템에 연결할 수 있으며 더 잘 작동합니다. Kanban 백 로그에 있어야 할 모든 것을 기록하는 수단으로, 그러나 Kanban 보드를 읽기 어려운 엉망으로 만드는 추가 세부 사항이 있습니다.

문제는 두 개념이 잘 작동하고 서로를 잘 지원한다는 것입니다. 물론 하나의 깔끔한 응용 프로그램 내에서 두 세계를 모두 활용할 수있는 시스템을 보유하고 있다면 선이 약간 흐려질 수 있지만 개념은 여전히 ​​상당히 분리되어 있습니다.

명확한 답변이 있는지 모르겠으므로 내 경험을보고하고 있습니다 ...

년 동안 나는 완전히 등의 Fogbugz, 락스, Trac에 같이 그러나, 나는 최근에 (정말 그냥, 민첩성 우리는 민첩한입니다 작업을했다, 사실 버그 추적 시스템에 판매되었다 하고 민첩한를). 우리는 오래되고 역사적인 버그 목록이나 멋진 아이템이 없습니다.

그러한 도구는 사용하지 않습니다. 중요한 것은 우리가 꽤 빨리 얻는 것입니다. 그다지 중요하지 않은 점은 무엇입니까?

우리가 할 시간이 없다는 것을 알면서도 매일 최고의 가치를 제공한다는 것을 아는 것은 매우 자유 롭습니다.