개인 프로젝트의 버그를 어떻게 추적합니까? [닫은]


45

집에서 만든 프로젝트에 대한 결함 추적 프로세스를 재평가해야하는지 결정하려고합니다. 지난 몇 년 동안 TODO코드에서 태그를 사용하여 결함을 추적하고 특정 뷰에서 추적합니다.

불행히도이 시스템이 지속 불가능한지 궁금해지기 시작했습니다. 내가 찾은 결함은 일반적으로 작업중인 코드 스 니펫과 관련이 있습니다. 즉시 이해되지 않는 버그는 잊혀지거나 무시되는 경향이 있습니다. 나는 거의 9 개월 동안 심한 결함이있는 아내를 위해 신청서를 작성했으며 그것을 고치는 것을 잊어 버렸습니다.

개인 프로젝트의 결함을 추적하기 위해 어떤 메커니즘을 사용합니까? 특정 시스템 또는 우선 순위를 지정하고 관리하는 프로세스가 있습니까?



1
이것은 faq가 주제를 벗어난 것으로 간주하는 질문으로 줄을 벗어날 수 있습니다. "어느 기술이 더 낫습니까?"
jzd

Trello는 이런 종류의 도구를위한 훌륭한 도구이며 무료입니다.
gahooa

답변:


25

프로젝트가 길거나 할 일 목록이 간단한 경우 Fogbugz (무료 개별 라이센스) (Google 작업 사용)


7
좋은. FogBugz에 무료 버전 (학생 및 스타트 업 에디션이라고 함)이 있다는 것을 몰랐습니다.
Eric King

간단히
살펴보면

FogBugz를 사용한 후에 다른 사람이 어떻게 다른 것을 선호하는지 알 수 없습니다. 난 그냥 자신을 위해 한 개인의 Fogbugz을 만들어 위해서하는 다수의 Fogbugz 계정을 추적 할 필요가 없게 : earlz.fogbugz.com
Earlz

17

나는 보통 웹 기반 개정 관리 시스템 (Github, Bitbucket, Redmine, Google Code 등)을 사용하여 소스 코드를 저장하고 버그를 추적합니다. 특정 코드에 버그가 있다고 생각되면 수정 번호 / 변경 목록 / 변경 세트에서 문제를 생성하고 의심되는 파일과 줄 범위를 지정할 수 있습니다.


8

프로젝트 당 스프레드 시트 / 텍스트 파일을 사용했습니다 (코드의 ToDo 주석은 나열 된 이유로 잘 확장되지 않습니다. 코드에 국한되어 있으며 문제가 없으면 문제가 발생하는 경향이 있습니다. 균열).

최근 에 홈 네트워크에 Redmine 서버를 설정했습니다 . 하나의 "팀"에 대해서는 약간 무겁지만, 저는 제 자신의 시간에 꽤 많은 프로젝트를 진행하고 있으며 더 복잡한 곳에서 이상한 위키 페이지와 함께 이슈 트래커 + 리포지토리 옵션을 사용하는 경향이 있습니다.

내 친구가 같은 목적으로 Pivotal Tracker 를 맹세 하지만 현재 고용주는 내부적으로 Redmine을 사용하므로 연습이 필요하다고 생각했습니다. 나쁘지 않습니다.

오픈 소스 프로젝트의 경우 GitHub의 이슈 추적을 사용합니다.


정기적으로 문서를 작성하는 한 코드의 작업 주석이 Doxygen / 유사 주석 인 경우 더 효과적입니다. 생성 된 문서에서 수집 된 할 일 (및 버그) 목록을 얻습니다. 분명히 전용 버그 추적기의 유연한보고 옵션이 부족하며 주석이 현재 버전에서 삭제 될 때 리포지토리에서 오래된 (아마도) 해결 된 버그를 찾지는 않지만 소규모에서는 상당히 잘 작동 할 수 있습니다. 간단한 프로젝트.
Steve314

7

실제로 호스팅 된 웹 서버 (블로그 및 기타 용도로 사용)에 Free MANTIS 버그 추적기 시스템을 설치했으며 모든 결함을 여기에 넣었습니다.

다시 말해 나는 마치 전문적이고 돈을 지불 한 것처럼 물건을 운영합니다.

나는 그것이 더 나은 사고 방식 (결함을 없애는 것 등)을 유지하고 산업에서 일반적으로 사용되는 다른 관행과 일관성을 유지하는 데 도움이된다는 것을 알게되었습니다.

코드 등으로 TODO 노트를 사용하십시오. 그러나 "언젠가 더 효율적으로해야 거품 정렬이 성능을 떨어 뜨립니다." 또는 저녁 식사를 위해 떠났을 때 어디로 갔는지에 대한 즉각적인 메모가 필요합니다. :)


나는 MANTIS를 사용했고 굉장합니다!
Job


5

우리는 직장에서 JIRA 를 사용 하고 있으며 그 팬을 매우 좋아합니다. 많은 제품과 사람들이 관여하고 있으며 모두 잘 관리합니다.


+1 Jira는 내가 찾은 최고의 이슈 추적 시스템입니다. 사용하기 쉽고 필요할 때 점차 고급 기능을 사용하십시오. 기술이 아닌 사용자도 문제를보고하고 추적 할 수있을 정도로 친숙합니다.
Maglob

또 다른 칭찬. Jira는 강력하고 "발열적인"툴로, 긍정적 인 피드백주기를 촉발하는 것 이상을 제공합니다.
Maglob

4

나는 얼마 전에 이것에 대한 답을 찾고 왔으며 그 후에 나에게 이러한 주요 목표를 충족시키는 매우 깔끔하고 간단한 시스템을 개발했습니다.

중요한 순서의 목표 :

  1. 가능한 한 쉽게 새로운 작업 / 버그를 입력 할 수있게함으로써, 발견하거나 꿈꾸는 즉시 정리하고 자리를 잃기 전에 코딩으로 돌아갈 수 있습니다.
  2. 검색, 클릭, 드릴 다운없이 많은 문제를 쉽게보고 관리 할 수 ​​있습니다.
  3. 버전 관리와 쉽게 연결할 수 있도록하여 문제를 해결하기 위해 변경 한 사항이나 코드의 특정 변경을 유발 한 작업 또는 버그를 나중에 확인할 수 있습니다.
  4. 최소 설치 및 구성 및 최소 가격으로 비교적 쉽게 설정할 수 있습니다.

(3과 4는 덜 중요하며, 그것들을 제공하지 않은 시스템에 대해서는 괜찮 았을 것입니다. 그러나 이것은 가능합니다).

1 단계 : Bitbucket에서 프로젝트 받기

내가 사용 의 bitbucket을 (예를 들어 엑스 코드에서 아이폰 OS 프로젝트에 대한) 문제 추적 및 Git 버전 관리를 위해. 나는 FogBUGz (JoelOn Software에서 수년간 읽은 내용)와 GitHub 및 기타를 보았지만 비트 버킷에는 소규모 팀을 위해 최고의 무료 기능이 설정되어있는 것 같습니다.

2 단계 : 프로젝트에서 비트 버킷 이슈 추적 사용

다음으로 동일한 비트 버킷 프로젝트에서 이슈 추적을 설정했습니다. 그래서 내 프로젝트에는 이제 자식 저장소와 이슈 추적이 있습니다.

3 단계 : 문제 추적을 쉽게하십시오!

이를 위해 Bitbucket 카드 를 사용하고 있습니다 .Bitbucket Cards 는 Bitbucket 문제에 대한 멋진 간단한 칸반 같은 프론트 엔드입니다. Bitbucket 계정에 로그인하고 원하는 열을 설정하면됩니다. 백 로그, 다음, 버그 및 해결의 네 가지 열이 있습니다. (백 로그와 버그를 병합하려고 생각하고 있지만 지금은 신경 쓰지 않습니다)

비트 버킷 카드 예 (이 이미지는 내 프로젝트가 아닌 Bitbucket Cards 블로그에서 가져온 것이므로 열이 사용하는 열과 다릅니다.)

비트 버킷 카드를 사용하면 카드 열에서 발생하는 문제의 상태 및 종류를 선택할 수있는 각 목록에 대해 매우 간단한 필터를 설정할 수 있습니다. 따라서 open종류의 상태 문제 bug버그 열에 들어갑니다 .

열 정의 (이것은 내 프로젝트에서 가져온 것입니다. 그래서 버그 열에서 진행되는 것을 선택합니다)

정말 멋진 점은 한 열에서 다른 열로 카드를 끌어다 놓으면 카드가 나타내는 문제의 상태를 대상 열의 정의와 일치하도록 자동으로 변경한다는 것입니다.

Bitbucket Cards의 또 다른 좋은 점은 쉽게 시간 초과되지 않는다는 것입니다. 이것은 전체 설정의 목표가 쉽게 만드는 것이기 때문에 중요합니다. 따라서이 시스템은 저를 위해 일하는 대신 저에게 효과적입니다. 카드 페이지에 북마크를 열면 하루 종일 Chrome 탭에 열려 있습니다.

이것은 내 두 번째 목표를 처리합니다.

4 단계 : 버전 관리로 묶습니다.

Bitbucket 문제는 ​​(대부분의 경쟁사와 마찬가지로) 버전 제어와 깔끔하게 연결되어 있으므로 문제에 대한 작업을 마치면 "Whatsthing to whatsit. Fixs # 245"와 같은 메시지가 표시됩니다. 커밋 한 다음 푸시 한 다음 Bitbucket 카드 페이지를 다시로드하면 문제가 해결됨 열로 이동 한 것을 볼 수 있습니다. 시원한.

내 세 번째 목표가 완료되었습니다.

5 단계 : 문제를 쉽게 만들 수 있습니다.

이 전체 설정은 이미 설정하기가 복잡하고 프로세스에 다른 웹 앱을 추가하려는 이유가 있다고 생각합니다. 글쎄, 위의 주요 목표를 기억하십시오 : 텍스트 영역에 입력하기 전에 생각을 잃지 않도록 과제를 쉽게 추가하고 싶습니다. 내가 할 때까지의 코드.

이제 Bitbucket Cards를 사용하면 작업을 상당히 쉽게 만들 수 있지만 목표 # 1을 완전히 충족시키기 위해서는 클릭 / 스크롤이 약간만 발생합니다. 이슈 생성을 클릭해야합니다. 그런 다음 모달 편집기가 나타납니다. 이슈 제목을 입력 한 후 아래로 스크롤하여 종류 (버그 / 작업)와 우선 순위를 지정해야합니다. 그런 다음 만들기를 클릭하십시오.

대신 나는 taskrd 라는 두 번째 Bitbucket 앱을 사용하기로 결정했습니다 .

Bitbucket 로그인을 제공하여 taskrd를 설정하고 책갈피 및 탭에서 설정하고 Bitbucket 카드와 같이 하루 종일 열어 둘 수 있습니다. Taskrd에는 새 작업을 추가하는 훨씬 간단한 워크 플로가 있습니다. 작업을 입력하고 선택적 으로 종류와 우선 순위를 설정 한 다음 추가 버튼을 누르십시오.

tasrkd 인터페이스 (이 이미지는 Taskrd 블로그에서 가져온 것입니다)

이제 Bitbucket 카드 또는 Bitbuckets 자체 문제 입력 시스템을 사용하여 Taskrd를 설정하려는 노력이 가치가 없다고 주장 할 수 있습니다. 결국 Taskrd를 사용하면 브라우저에서 탭을 클릭하고 Bitbucket 카드가있는 내 페이지에서 다시로드를 클릭하여 Taskrd 앱에 추가 한 새 문제를 새로 고치십시오. 그러나 사실, 나는 일반적으로 모드 또는 다른 사람이라는 것을 알았습니다 .Bitbucket Cards를 사용하여 다음에하고있는 일을 정리하거나 버그 목록을 살펴 보거나 코딩 및 작업에 바쁩니다. / bugs는 나에게 일어날 때-빠른 발사 모드입니다. 이 두 번째 작업 모드의 경우 Taskrd는 훌륭합니다. 별도의 모니터에서 열어두고 작업하면서 문제를 빠르게 입력합니다.

목표 1 번을 다룹니다.

나의 마지막 목표는 쉬운 / 저렴한 설정이었습니다. 잘 싸다 :이 모든 것은 무료이다. Bitbucket에는 최대 5 명의 사용자를위한 무료 전용 리포지토리가 있으며 다른 앱은 무료입니다. 위의 내용을 기반으로 설정이 쉽지 않은 것처럼 보이지만 실제로 가장 복잡한 부분은 git을 설정하여 bitbucket 저장소로 푸시하는 것입니다. 아무것도 설치할 필요가 없었으며 두 앱을 모두 비트 버킷 리포지토리에 연결하는 것은 매우 쉽습니다. 카드 열을 내가 좋아하는 방식으로 설정하는 데 약간의 시간이 걸렸지 만 실제로 어렵지는 않았습니다.

이것을 다시 읽으면 Bitbucket의 실로 약간 벗어날 수 있지만 실제로는 의미가 없습니다. 몇 주 동안 다른 구성을 시도한 후 몇 년 동안이 작업을 수행 한 후이 프로세스를 사용하고 있으며 실제로 파고 들기 때문에 다른 사람들을 위해 배치하는 데 시간이 걸릴 것이라고 생각했습니다.


3

Eclipse에서 TODO 태그를 사용하는 데 익숙하다면 간단한 단계는 Mylyn 을 사용하는 것 입니다. 가장 기본적으로 간단한 할 일 목록입니다. 그러나 또한 컨텍스트를 작업과 연결합니다. 작업을 클릭하여 활성화하고 몇 가지 작업을 수행 한 후 다음에 활성화하면 Eclipse가 관련 클래스를 열고 관련 메소드를 표시합니다. 더욱 강력하게, 결국 다른 버그 추적 시스템으로 이동하면 Mylyn은 해당 시스템에서 작업을 가져와 IDE에 표시 할 수 있습니다.

요즘 대부분의 Eclipse 다운로드에는 Mylyn이 표준으로 번들로 제공됩니다. 작업 목록보기를 검색하고 작업 추가를 시작하십시오.


+1 Mylyn을 보았지만 Eclipse의 작업보다 더 도움이되지 않을까 걱정됩니다. 코드에서 직접 보이지 않는 버그는 셔플에서 길을 잃는 경향이 있으므로 Eclipse가 열리지 않을 때 버그를 추가 할 가능성은 적습니다. :)
bedwyr

TODO 태그를 사용하고 find / grep -o를 사용하여 할 일 목록을 만듭니다.
sal

3

Jira에 10 달러의 스타터 라이센스를 사용합니다. 싸고 이미 직장에서 잘 알고 있습니다.


2

여기 다른 사람들처럼 텍스트 파일이나 dvcs 호스팅 서비스에 내장 된 버그 추적기를 사용합니다.

그것은 많은 종류의 "개인 프로젝트"에 달려 있습니다. 그것은 오늘의 빛을 보게 될 것인가, 아니면 실험 일까? 이 프로젝트가 대중에게 사용되고 있습니까?

예를 들어, 개인 프로젝트 중 하나가 적당히 인기를 얻었고 만족도 얻기 사이트를 설정하면 실제로 효과가있었습니다. 실제로 "버그 추적"은 아니지만 버그 / 기능 요청에 효과적이었습니다.


2

Kinda는 아직 아무도 이것을 말하지 않았지만 분산 소스 제어의 일부로 작동하는 분산 버그 추적 솔루션이 있습니다. 즉, 버그 데이터베이스는 수정본 제어 코드의 코드와 함께 있습니다. 잘 알려진 구현에는 "Bugs Everywhere", Fossil 및 Ditz가 포함됩니다.

참조 https://stackoverflow.com/questions/773818/distributed-projectmanagement-bug-trackinghttps://stackoverflow.com/questions/1851221/distributed-bug-tracker-to-go-with-dvc?rq=1 토론을 위해.


1

개인 프로젝트에는 Omnifocus를 사용합니다.

업데이트 : 25/10/2010 즉시 수정할 수없는 버그를 발견하면 즉시 Omnifocus받은 편지함에 버그를 추가합니다. 그런 다음 나중에 리뷰를 할 때 버그를 수정하고 프로젝트에 추가해야 할 것으로 생각되는 모든 정보를 수집합니다. 작업 목록의 위치는 상대적 중요성을 나타냅니다.

나는 대부분의 관점에서 버그를 요구 사항 / 기능과 같은 방식으로 취급합니다.


2
응답을위한 Thx : 결함 추적에 특별히 사용하는 방법에 대해 자세히 설명 하시겠습니까?
bedwyr

업데이트 해 주셔서 감사합니다! 결함 관리에 사용되는 일반적인 할 일 도구를 보는 것은 흥미 롭습니다.
bedwyr

참고 : Apple 제품 만 해당
Mark C

Omnifocus는 Apple 제품이지만 Apple 이외의 개발에 사용합니다.
Henry


1

나는 내 TheKBase를 사용합니다 (OSX에 있기 때문에 내 기분에 따라 가상 컴퓨터 또는 모노의 .Net에서 사용합니다). 한 명의 동시 사용자 만 해당 : 여러 계층을 허용하므로 작업 관리자에서 정보 관리자로 이동하여 중간 단계가 없습니다. 또한 Github 의 오픈 소스 이며 무료입니다 (분명합니다).

궁금한 점은 여기에 지침이 있습니다 .


1

개인 프로젝트에 ToDoList 를 사용 합니다. 가볍고 무료이며 많은 기능이 있습니다. 팀 프로젝트의 규모가 어느 정도인지 잘 모르겠지만 혼자서 작업하는 것이 좋습니다. Visual Studio의 기본 제공 작업 목록을 오랫동안 사용하여 어떻게 살아남 았는지 잘 모르겠습니다.


소규모 개인 프로젝트에서는 ReSharper TODO 목록이 적합합니다.
아무도

1

JIRA와 Google 문서 및 스프레드 시트를 조합하여 사용합니다. JIRA 설치가 먼지보다 오래되어 더 새롭고 더 멋진 드래그 앤 드롭 인터페이스처럼 사용하기 쉽지 않기 때문에 다른 도구를 조사했습니다.

나는 Manymoon, Zoho Projects, Insightly, Redmine 및 Assembla를 조사했습니다. Assembla free Stand Up 도구 를 실험 해 보겠습니다 . 각 팀 구성원에게 3 가지 질문을하는 매우 간단한 3 개의 필드보고 인터페이스입니다. 지난 주에 무엇을 했습니까? 이번 주에 무엇을 하시겠습니까? 어떤 장벽이 있습니까?

결국 JIRA, Google Docs 및 Assembla Stand Up 도구를 사용하여 필요한 모든 것을 얻을 수 있다고 생각합니다.


1

Trac은 가볍고 사용하기 쉽고 구성하기 쉽기 때문에 Trac을 가장 좋아합니다. 그리고 통합 위키와 우아한 저장소 브라우저는 큰 장점입니다.

직장에서 우리는 JIRA를 사용하는데, 이는 또한 훌륭하지만 관리하기 쉽지는 않습니다. 그리고 나는 위키 (Confluence와의 통합이 그리 좋지는 않습니다)와 좋은 저장소 브라우저 (우리는 ViewVC를 가지고 있습니다)를 정말로 그리워합니다.


Trac은 설정하고 구성하는 악몽입니다.

1

지난 몇 년간 Trac을 사용해 왔습니다. Bugzilla와 JIRA도 사용했습니다. 개인 및 개인 컨설팅 프로젝트는 Trac과 관련이 있기 때문에 Trac과 관련이 있으며 개인 개발 환경에서 프로젝트를 진행하는 데는 노력이 끝나기 때문에 거의 노력이 필요하지 않습니다. SVN 또는 Git 및 Hudson (또는 지금 Jenkins)을 포함하여 필요한 모든 것과 trac가 연결되었습니다 .

일부 고객 프로젝트에서는 일반적으로 그들이 선택하는 것 외에는 선택의 여지가 없습니다. 최근에 버그 추적기가있을 때 놀랐습니다. 개인적으로 저는 Trac보다 OSS 커뮤니티의 더 나은 서비스를 기대하고 있습니다. 그것은 일을 끝내지 만 요즘은 그런 패치 워크처럼 보입니다.


Trac은 설정하고 관리하는 악몽입니다.

0

소규모 1 인 프로젝트에 공식적인 버그 추적을 사용하는 것이 중요하지 않습니다. 일반적으로 나는 (매우 짧은) 정신 목록을 유지하고 내가 알게되면 버그를 수정합니다. 물론 이것은 대규모 / 다 인간 프로젝트에는 적합하지 않지만 요점은 필요하지 않다는 것입니다.


3
그것은 부분적으로 문제입니다 : 정신 목록은 불충분 한 경향이 있습니다. 내 결함 중 많은 부분이 정신적으로 기록 된 다음 새로운 기능과 개선 사항이 적용됨에 따라 시간이 지남에 따라 손실됩니다.
bedwyr

@bedwyr 새로운 기능을 구현하기 전에 알려진 모든 결함을 수정하는 규칙을 고수한다면 이것은 문제가되지 않습니다.
Kevin Laity

@Kevin, 프로젝트의 최신 반복 작업을 수행하는 동안 이전 릴리스에서 결함을 찾을 수 있습니다. 이전 버전의 우선 순위가 낮은 코너 결함을 해결하기 위해 우선 순위가 높은 기능에 대한 개발을 즉시 중단 하시겠습니까? 그렇지 않은 경우 어떻게 추적합니까? 제 경우에는 정신 목록이 충분하지 않습니다.
bedwyr

@bedwyr 좋은 지적, 나는 그것이 선호의 문제라고 생각합니다. 우리는 작은 한 사람 프로젝트에 대해 이야기하고 있기 때문에 실제로 그 결함을 즉시 고칠 것입니다. 내가 큰 회사 환경에 있다면 다른 이야기.
Kevin Laity

0

ReSharper를 사용하는 경우 솔루션 TODO tracker의 모든 TODO, NOTEs 및 BUGs 목록을 표시하는가 있습니다. 또한 원하는 색상으로 코드에서 강조 표시됩니다. 나는 이것이 내 자신의 프로젝트에서 실제로 유용하다는 것을 알았습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.