저의 개발 팀은 개발자 1 명에서 2 명으로 100 % 성장했습니다. 나의 새로운 동료는 버그 추적 소프트웨어에 투자하고 싶습니다. 소규모 팀을 위해 이러한 소프트웨어에 이점이 있습니까?

나는 모든 "예"답변이 아이디어를지지하는 데 먼 길을 가고 있다고 생각합니다. 그러나 나는 결정이 몇 가지 질문에 근거한다는 생각을 버릴 것입니다.

• 팀으로서 어떻게 의사 소통하고 싶습니까? 2 명의 개발자가 있으면 이제 팀이됩니다. 어떻게 대화하고 싶습니까? 많은 민첩한 팀이 직접 토론 및 화이트 보드 스케치와 함께 살고 있습니다. 그러나 특히 우선 순위 목록에서 높지 않은 버그 인 경우 적어 놓을 수 있습니다.
• 고객과 어떻게 소통하고 싶습니까? 나는 이것에 대한 답을 모른다.하지만 버그 (또는 버전 릴리스 문서에서 수정 된 버그)를 게시 해야하는 이유가 있다면 결국 버그를 기록하게 될 것입니다. 스트레스가 적은 버그 관리 시스템을 선택할 수도 있습니다.
• 역사를 보존하는 데 가치가 있습니까? 정답은 "지금은 아닙니다"이지만 앞으로는 버그 경향을보고 싶기 때문에 사용자가 가장 많은 문제를 겪고있는 장소 나 확인에 시간을 소비 할 수있는 장소를 볼 수 있습니다 그리고 주요 릴리스 전에 검토 한 다음 버그 추적 시스템을 얻습니다. 역사에 관한 것은 기록을 원하는 날이 기록을 유지해야하는 날이 아니라는 것입니다.

IMO, 이러한 질문에 대한 답변은 제품이 어디로 가고 있는지, 어떻게 팀을 키우고 싶은지에 관한 것입니다. 그리고 "2 명 = 버그 추적 시스템의 이유"에 대한 것입니다. 더 큰 문제는 아마도 "구성 및 관리 시간과 구매 비용이 가치가있는 버그 추적 시스템입니까?"일 것입니다.

1, 그러나 고통스럽지 않은 경우에만. 예를 들어 GitHub 에는 소규모 팀을위한 충분한 기능 을 갖춘 매우 간단하고 유용한 이슈 트래커가 있습니다 . Bugzilla, Trac 등은 훌륭하지만 모두 사용하기 전에 하드웨어, 설치 및 구성이 필요하며 유지 관리 비용은 제로가 아닙니다.

우리는 버그 추적 소프트웨어를 처음 사용할 때 아주 작은 팀을 가졌으며 어떻게 든 해결되지 않은 문제를 해결하기 위해 우리가 생각한 것의 양에 놀랐습니다. 팀 규모에 관계없이 전적으로 가치가 있습니다.

예. 천 번 예.

버그 추적과 관련하여 생각하지 말고 티켓 추적으로 생각하십시오.

티켓에서 모든 작업을 볼 수 있다는 것은 큰 장점입니다. 한 곳에서 작업 기록을 유지할 수 있습니다. 누가 언제 그 일을했는지 ​​알고 있습니다. 어떤 요일에 어떤 일이 완료되었는지를 말하는 것만 큼 자세 할 수 있습니다.

버그 추적의 경우 모든 버그를 한 곳에 배치하고 완료된 버그와 진행중인 버그를 추적 할 수 있습니다.

그것은 당신이 훨씬 더 잘 관리하는 데 도움이됩니다.

하나 이상의 팀으로 가치가 있습니다.

공식 소프트웨어 솔루션을 구입하든 버그 / 기능 추적 시스템을 사용하든 관계없이 직면하십시오. 메모장에 있거나 스티커 메모 일 수 있으며 코드 상단의 주석 블록에있을 수 있습니다. 그러나 무작위로 개발하지 않는 한 할 일 목록을 어딘가에 적어 놓을 것입니다. 팀과 함께 성장할 수있는보다 체계적인 시스템을 사용해보십시오.

또한 고려할 가치가 있습니다. 많은 버그 추적 프로그램은 소규모 팀 (1-2)이 무료로 사용할 수 있으므로 혜택을 얻는 데 큰 비용이 들지 않습니다.

모든 팀원이있는 한 버그 추적 소프트웨어가 필요하지 않습니다.

• 완벽한 사진 기억력이 있으며
• 자신의 생각을 팀의 다른 모든 구성원과 동기화 할 수 있습니다.

짧은 대답은 그렇습니다.

몇 가지 이유 :

1. 특정 버전에서 발견 된 버그를 기록하는 기능.
2. 아직 해결되지 않은 버그를 알 수있는 기능
3. 이후 다시 발견 된 버그를 수정 한 사람을 추적하십시오.
4. 개발자 회전율-잠정적 인 버스가 되더라도 지식 이전이 가능합니다.

설정 / 관리에 많은 시간이 걸리지 않는 것을보고 싶을 것입니다. 또한 소스 컨트롤과 통합 할 수있는 기능이 포함 된 것을 찾아 보는 것이 좋습니다.

이 답변은 인수 의 YES 쪽에 가중치를 추가 하는 것입니다.

나는 주로 하나의 팀입니다. SVN 통합과 함께 이슈 추적 (레드 마인)을 광범위하게 사용합니다.

그것은 정말로 훌륭하다. 그리고 나는 그것없이 미쳐 갈 것이다. 내가 잊어 버렸기 때문에 품질이 떨어지고, 내가해야 할 일을 느슨하게 추적하게됩니다.

생산성 도구 :

• 괜찮은 IDE
• 이슈 트래킹
• 소스 컨트롤

이슈 추적; 그것없이 집을 떠나지 마십시오

3보다 적 으면 Google 문서 스프레드 시트를 사용하여 아마 얻을 수 있습니다. 그러나 실제로 버그질라 등을 설치하는 데 드는 비용은 프로그래머의 비용 옆에 너무나 사소하여 그렇게하는 것이 더 좋습니다. (또한 당신이 7로 자라면 이미있을 것입니다)

팀의 팀조차도 일종의 버그 추적기, 텍스트 파일 또는 완전한 소프트웨어 등의 이점을 누릴 수 있습니다. 2 명의 개발자에게는 돈이 아닌 버그 추적 시스템을 설정하는 데 시간을 투자하는 것이 좋습니다. 프로젝트에 따라 종이에 버그를 기록하거나 공유 온라인 문서를 통해 목록을 유지 관리하거나 Trac 또는 Bugzilla와 같은 무료 버그 추적 소프트웨어를 사용하여 문제를 해결할 수 있습니다. Fogbugz 는 45 일 동안 무료 평가판으로 제공됩니다.

예.

몇 가지 방법을 추적해야합니다!

문제는 개발자 수보다는 버그 수입니다. 몇 가지 버그를 처리 할 때 Excel 시트로 관리 할 수는 있지만 가장 좋은 버그는 아닙니다.

명확한 장점이 있습니다-개인 프로젝트에서도 버그 추적 소프트웨어를 사용합니다. 버그 추적뿐만 아니라 'TODO'및 기능 요청 추적에도 유용합니다.

나는 혼자서 일할 때 모든 곳에서 버그를 사용 했습니다. 버그 정보를 소스와 함께 유지하여 DVCS와 함께 작동합니다. 중앙 서버가 필요하지 않으므로 오버 헤드가 매우 낮습니다. 단점은 버그를 적시에 전파하기 위해 새 버그를 입력하는 지점을 조심해야한다는 것입니다.하지만 대부분 버그를 추적하고 싶다면 최신 버그로 수정 한 것이 중요하지는 않지만 팀의 상태를 전체적으로 추적하는 것보다

하나만 사용하십시오

하나를 사용하기 시작하면 버전 제어 소프트웨어 나 분산 된 버전 제어와 마찬가지로 실무 상 편의를 실현하기 시작합니다.

성숙도

100 또는 1의 팀을 보유하고 있는지 여부는 중요하지 않습니다. 나는 버그 추적 및 분산 버전 제어 (로컬 커밋으로 인해 의미가 있음)를 사용하기 시작했으며 이미 다른 수준에서 느꼈습니다. 그것만으로, 나는 더 많은 노력을 기울이지 않고도 다른 수준에서 작업을 관리 할 수있었습니다.

트래커를 사용하면 문제를 예상하고 작업의 우선 순위를 지정할 수 있습니다. 버그 / 문제 트래커는 버그 / 문제뿐만 아니라 프로젝트 관리에 더 적합하며 각 프로젝트마다 반드시 있어야합니다 .

나에게 그것은 소프트웨어에 관한 것이 아니라 소프트웨어를 둘러싼 프로세스입니다. 테스트 관리자로서 일상적으로 일하면서 저는 기본적으로 하나이며 다음과 같은 이점을 제공합니다.

나는 이것이 2 명 이상의 테스터 및 3 명 이상의 개발자들과 잘 작동한다는 것을 알았습니다.

개발자 버그 수정 노력 관리

우리는 개발자 "버그 큐"를 적극적으로 관리하여 개발자에게 할당 된 작업량을 제어하고 팀 전체에 버그 수정 작업을 레벨로 할당합니다.

무엇이 고쳐지지 않는지 결정

일상적인 프로세스에서 새로운 버그를 심사하는 것은 문제를 해결할 때뿐만 아니라 수행 할 작업과 수정하지 않은 작업에 집중할 수있는 좋은 방법입니다. 프로젝트 초기에 모든 것을 고치려고합니다. 결국 당신은 쇼 스토퍼를 고치기를 원하며 버그 추적 도구는 그 점에 좋습니다.

측정 항목이 필요할 때

나에게 가장 중요한 것은 메트릭스입니다. 즉, 버그 찾기 및 수정 트렌드를보고 싶을 때, 버그가있는 코드 영역이 있거나 테스터가 버그를 찾아서 다시 테스트하는 속도입니다. 버그 추적 시스템을위한 시간이다.

한 팀원이 버그 추적기를 필요로하기에 충분하다는 일반적인 의견에 동의합니다. 한두 명의 실제 사용자가 있지만 첫 번째 릴리스 이전에는 중요하다고 생각합니다.

개인적으로 저는 소스 제어와 버그 추적 모두를 위해 화석 을 좋아 합니다. 버그 추적기 및 위키에 잘 통합 된 완전 낮은 식 분산 SCM입니다. 또한 단일 실행 가능 설치로 광범위하게 이식 가능하며 내부 웹 응용 프로그램을 GUI로 사용합니다. 홈 페이지는 실제로 거의 전적으로 화석 사본으로 제공됩니다.

추적기를 개정 제어와 긴밀하게 통합하면 변경 사항을 티켓에 쉽게 연결하고 개정 (및 위키 페이지 편집)과 동일한 타임 라인보기에서 티켓 업데이트를 볼 수 있습니다.

네 네 네 네! 소프트웨어를 성공적으로 개발하려면 문제를 추적하고 우선 순위를 정하고 관리 할 수 ​​있어야합니다. 한 사람 만 있으면 스프레드 시트를 사용하여 오래된 소스 트리를 압축 할 수 있습니다. 프로젝트에 한 명의 개발자 만 추가하면 상황이 크게 바뀝니다. 갑자기 이슈 트래킹 및 소스 코드 제어가 필요하거나 이슈를 삭제하고 기능을 덮어 쓰며 일반적으로 비참한 시간을 보내고 있습니다.

아직 StackExchange의 모회사 인 FogCreek에 대해 언급 한 사람이 아무도 없습니다. FogBugz 소프트웨어는 내가 사용해 본 최고의 이슈 추적 앱입니다. 특히 호스팅 된 솔루션을 사용하는 경우 고속, 낮은 드래그 및 경제성. 그들은 두 개의 사용자 라이센스가 무료로 제공되는 무료 호스팅 평가판을 사용했습니다.

여기 내 2 센트입니다.

버그 추적을 위해 Google 문서 스프레드 시트를 사용하고 있습니다. 편집하거나 보려는 사람을 초대 할 수 있습니다. 그것의 무료 너무 많은 투자. 나는 버그에 대한 모든 작업을 추적합니다.

또한 웹 호스팅에 추가 비용을 추가하지 않는 웹 호스트에서 SVN을 실행합니다.

일부 클라이언트는 언 플러드 또는 다른 프로젝트 관리 / 버그 추적 소프트웨어를 사용해야했지만 위에서 언급 한 무료 솔루션을 선호합니다.

최소한의 버그 추적기가 있다면 팀으로도 유용하다고 말하고 싶습니다. 내 친구의 프로젝트 사이트 QuokForge 중 하나에서 기본적으로 각 프로젝트에 대해 Red Mine 인스턴스를 제공합니다. 내 생각에 Red Mine에는 좋은 버그 추적기가 있습니다 (때로는 조금 이상하더라도). 즉, ONE 필드에만 텍스트를 입력하여 버그를 신고 할 수 있기 때문입니다. 나는 또한 전에 FogBugz 를 사용했습니다 . 2 명 이하의 사람에게는 무료입니다. 또한 하나의 텍스트 필드 만 작성하여 버그를 제기하는 것과 동일한 단순성을 허용합니다. (또한 그래프와 기타 유용한 것들도 제공합니다)

기본적으로 버그 신고를 엄격하고 공식적인 절차로 만들어 버그 보고서를 작성하기 위해 30 분을 따로 설정해야합니다 (BugZilla,보고 있습니다). 이것은 사람들이 그것을 사용하지 않을 것임을 의미합니다.

마지막으로, 버그리스트를 갖는 것은 (각각의 버그가 포함 된 텍스트의 약 50 자라도) 매우 중요합니다. "흠, 1.0 출시 예정. 나는 마지막 버그를 수정했다고 생각합니다." 또한 관리자가 실제로 무언가를하고 있음을 보는 것도 좋습니다. :). 팀에서는 머리에 다른 정신적 할 일 목록을 유지하려고하지 않기 때문에 더 가치가 있습니다. 그리고 "[정말 나쁜 보안 버그]를 고치 셨나요? 음, 그렇습니다. 그렇게 생각합니다. 그럼 1.0을 출시하겠습니다."

나는 또한 기능을 추적하는 것을 좋아합니다. 이것은 좀 더 선택 사항이지만 여전히 할 일 목록을 머리에 두는 정신적 인 작업을 오프로드 할 수 있다는 이점이 있습니다.

또한, Joel 이 그것에 대해 무엇 을 말 했는지 를보십시오

당신은 그 숫자에 도달했습니다 ... 2 ! 유일한 개발자 인 경우에도 버그 추적 소프트웨어를 사용하면 얻을 수있는 이점을 볼 수 있지만 총 개발자 수가 1 명일 때 소프트웨어 없이도 얻을 수 있습니다.

그러나 두 명 이상의 개발자가있는 즉시 버그 추적 소프트웨어를 사용하지 않는 이유는 없습니다.

예. 그리고 bitbucket http://www.bitbucket.org를 추천 합니다. 무료 버그 추적 및 수은의 무료 개인 저장소를 제공합니다.

하나. 어떤 경우에는 할 일 목록과 비슷합니다.

나는 당신에게 시간을 투자하여 가정합니다. 거기에 무료 버그 추적 시스템이 많이 있으며 두 사람 팀에 적합합니다. 더 큰 팀이 생길 때까지 상용 제품을 보지 않았습니다.

나는 당신의 질문이 당신의 오해를 강조했다고 생각합니다. 버그 추적이 필요한 팀이 아니기 때문에 제품입니다.

그렇다면 소프트웨어에서 버그 추적을 수행해야합니까? 글쎄, 그게 도움이 될 것 같니?

다음 두 가지 조건이있는 경우에는 가치가 없습니다.

1. 문제 수명이 짧습니다. 이 경우 간단한 작업 보드로는 충분할 수 있습니다 (여러 가지 이유로 워크 플로우를 시각화하는 것이 현명하기 때문입니다). 그러나 문제를 빠르게 해결할 수 없으면 f.ex. 버그를 빠르게 수정하면 문제를 추적하는 것이 유용합니다.
2. 코드 변경 사항은 자동 테스트를 통해 실제 문서로 문서화됩니다. 즉, 버그 및 수정 사항은 표시 될 때 실패한 테스트로 설명되며 수정 후 테스트는 회귀 테스트가됩니다. -기능 변경 사항은 자동 수락 테스트 (예 : FitNesse 또는 Cucumber와 같은 일부 BDD 도구 사용)로 문서화됩니다. 이러한 문서는 Jenkins와 같은 CI 서버에서 쉽게 구할 수 있어야합니다.

1 또는 2가 없으면 문제 추적의 이점이 있습니다.

아니

버그를 추적하지 말고 수정하십시오 .

중요한 것은 팀의 규모가 아니며, 버그를 수정하기 전에 목록에서 버그를 기꺼이 보는 것입니다.

Agile / TDD를 사용하는 경우 버그 목록이 짧고 버그가 목록에 오래 머 무르지 않습니다. 이 경우 모든 추적 시스템으로 충분합니다.