자신만의 버그 추적 시스템을 구축하지 않는 이유 [닫기]

Question

나는 제품이 아닌 내부 도구로서 자체 버그 추적 시스템을 구축하려는 팀의 계획에 여러 번 직면했습니다.

내가 호의적으로 들었던 주장은 일반적으로 다음과 같습니다.

• 내부적으로 구축된 일부 웹 프레임워크 측면에서 '우리 자신의 개밥을 먹고 싶다'
• 고도로 전문화된 보고서가 필요하거나 고유한 방식으로 일부 기능을 조정할 수 있는 기능이 필요함
• 버그 추적 시스템을 구축하는 것이 어렵지 않다고 생각함

기존 버그 추적 시스템 구매를 지원하기 위해 어떤 주장을 사용할 수 있습니까?특히, 쉬워 보이지만 구현하기 어려운 기능, 또는 어렵고 중요하지만 종종 간과되는 기능은 무엇입니까?

Answer 1

먼저 이것들을 보세요. 오로 측정항목:

    Trac:  44 KLoC, 10 Person Years,   $577,003
Bugzilla:  54 KLoC, 13 Person Years,   $714,437
 Redmine: 171 KLoC, 44 Person Years, $2,400,723
  Mantis: 182 KLoC, 47 Person Years, $2,562,978

우리는 이 숫자로부터 무엇을 배울 수 있나요?우리는 Yet Another Bug Tracker를 구축하는 것이 자원을 낭비하는 좋은 방법이라는 것을 알게 되었습니다!

그래서 여러분만의 내부 버그 추적 시스템을 구축해야 하는 이유는 다음과 같습니다.

1. 10~20년 동안 모든 보조코더를 무력화해야 합니다.
2. 내년 예산 삭감을 피하기 위해서는 돈을 좀 쏟아야 합니다.

그렇지 않으면하지 마십시오.

Answer 2

나는 질문을 바꾸고 싶습니다.도대체 왜 자신만의 것을 만들고 싶나요?
추가 필드가 필요한 경우 수정할 수 있는 기존 패키지를 사용하세요.
특별보고?데이터베이스를 활용하여 만드세요.

어렵지 않다고 믿으시나요?그럼 시도해 보세요.사양을 설정하고 기능 목록과 시간이 늘어나는 것을 확인하세요.그런 다음 목록이 완성되면 직접 구현하기 전에 수정할 수 있는 기존 패키지를 찾아보세요.

간단히 말해서, 다른 바퀴에 맞게 약간의 조정이 필요한 경우 바퀴를 재발명하지 마십시오.

Answer 3

프로그래머는 자신만의 티켓 시스템을 구축하는 것을 좋아합니다. 왜냐하면 수십 개의 티켓 시스템을 보고 사용해 본 경험이 있기 때문에 모든 것을 알고 있기 때문입니다.그렇게 하면 그들은 안락한 영역에 머물 수 있습니다.

새로운 레스토랑을 확인하는 것과 같습니다.보람이 있을 수도 있지만 위험이 따릅니다.피자를 다시 주문하는 것이 좋습니다.

여기에는 의사결정에 관한 중요한 사실도 포함되어 있습니다.어떤 일을 하는 데는 항상 두 가지 이유가 있습니다.좋은 것과 옳은 것.우리는 결정을 내린 다음("우리 스스로 구축") 이를 정당화합니다("우리는 완전한 통제가 필요합니다").대부분의 사람들은 자신의 진정한 동기가 무엇인지조차 인식하지 못합니다.

그들의 마음을 바꾸려면, 당신은 공격해야 진짜 이유가 아니라 정당화.

Answer 4

여기서 발명되지 않은 증후군!

나만의 버그 추적기를 만드시겠습니까?자신만의 메일 클라이언트, 프로젝트 관리 도구 등을 구축해 보세요.

처럼 오메르 반 클로텐 라고 다른 곳에서는 지금 지불하거나 나중에 지불하세요.

Answer 5

구매도 빌드도 아닌 세 번째 옵션이 있습니다.거기에는 좋은 무료 것들이 많이 있습니다.예를 들어:

• 버그질라
• 트랙

학습 이외의 용도로 버그 추적기를 사용하는 것은 시간을 잘 활용하지 못합니다.

기타 링크:

• 세 가지 무료 버그 추적 도구
• 이슈 추적 시스템 비교

Answer 6

나는 그것이 돈 문제라고 말하고 싶습니다. 자신에게 좋다고 알고 있는 완성된 제품을 구입하는 것이(때로는 무료인 경우에도 구입하지 않는 경우도 있음) 직접 가서 개발하는 것보다 낫습니다.간단한 게임이다 지금 지불하세요 대 나중에 지불.

Answer 7

첫째, 자신만의 구축을 지지하는 주장에 반대합니다.

내부적으로 구축된 일부 웹 프레임워크 측면에서 '우리 자신의 개밥을 먹고 싶다'

물론 이는 왜 자신만의 웹 프레임워크를 구축하는지에 대한 의문을 제기합니다.가치 있는 무료 버그 추적기가 많이 있는 것처럼 가치 있는 프레임워크도 많이 있습니다.귀하의 개발자가 우선순위를 제대로 갖고 있는지 궁금합니다.회사에서 실제 돈을 버는 일을 하는 사람은 누구입니까?

좋습니다. 프레임워크를 구축해야 한다면 비즈니스에서 수익을 창출하는 데 사용하는 실제 소프트웨어를 구축하는 과정에서 유기적으로 발전하도록 하세요.

고도로 전문화된 보고서가 필요하거나 고유한 방식으로 일부 기능을 조정할 수 있는 기능이 필요함

다른 사람들이 말했듯이, 많은 훌륭한 오픈 소스 추적기 중 하나를 선택하고 조정하세요.

버그 추적 시스템을 구축하는 것이 어렵지 않다고 생각함

글쎄, 나는 내 첫 번째 버전을 썼다 버그트래커.NET 단 몇 주만에 사전 C# 지식 없이 시작할 수 있습니다.그러나 6년 2천 시간이 지난 지금에도 여전히 실행 취소된 기능 요청의 큰 목록이 있으므로 모든 것은 버그 추적 시스템에서 수행하려는 작업에 따라 달라집니다.이메일 통합, 소스 제어 통합, 권한, 워크플로, 시간 추적, 일정 예측 등의 정도버그 추적기는 주요 응용 프로그램이 될 수 있습니다.

기존 버그 추적 시스템 구매를 지원하기 위해 어떤 주장을 사용할 수 있습니까?

구매할 필요가 없습니다. 좋은 오픈 소스 제품이 너무 많습니다. 트랙, Mantis_Bug_Tracker, 내 자신의 BugTracker.NET 등이 있습니다.

특히, 쉬워 보이지만 구현하기 어려운 기능, 또는 어렵고 중요하지만 종종 간과되는 기능은 무엇입니까?

여러분 자신만을 위해 그것을 생성한다면 많은 지름길을 택할 수 있습니다. 왜냐하면 여러분은 일을 직접 연결할 수 있기 때문입니다.다양한 시나리오에서 다양한 사용자를 위해 구축하는 경우 구성 가능성에 대한 지원이 어렵습니다.구성 가능한 워크플로, 사용자 정의 필드 및 권한.

제가 생각하는 두 가지 특징은 좋은 버그 추적기에는 두 가지 모두가 있어야 합니다. 포그버그 BugTracker.NET에는 1) 수신 및 발신 이메일이 모두 통합되어 버그에 대한 전체 대화가 별도의 이메일 스레드가 아닌 버그와 함께 유지되며 2) 스크린샷을 버그 게시물로 전환하는 유틸리티가 있습니다. 단 몇 번의 클릭만으로.

Answer 8

나에게 가장 기본적인 주장은 시간 손실입니다.한두 달 안에 완료될 수 있을지 의문입니다.사용할 수 있는 좋은 버그 추적 시스템이 너무 많은데 왜 시간을 소비합니까?조정해야 하지만 쉽게 사용할 수 없는 기능의 예를 들어주세요.

좋은 버그 추적 시스템은 개발 프로세스를 반영해야 한다고 생각합니다.매우 맞춤화된 개발 프로세스는 본질적으로 회사/팀에 좋지 않습니다.대부분의 민첩한 관행이 선호됩니다. 스크럼 또는 이런 종류의 것, 그리고 대부분의 버그 추적 시스템은 그러한 제안과 방법과 일치합니다.이것에 대해 너무 관료주의적이지 마십시오.

Answer 9

버그 추적 시스템은 주니어 개발자를 시작하기에 좋은 프로젝트가 될 수 있습니다.코딩 규칙 등을 교육하는 데 사용할 수 있는 매우 간단한 시스템입니다.주니어 개발자가 이러한 시스템을 구축하도록 하는 것은 상대적으로 저렴하며 고객이 볼 수 없는 것에 대해 실수를 할 수 있습니다.

쓰레기라면 그냥 버려도 되지만, 사용한다면 이미 회사에 중요한 일이라는 느낌을 줄 수 있습니다.주니어 개발자가 전체 수명 주기와 그러한 프로젝트를 통해 얻을 수 있는 지식 이전의 모든 기회를 경험할 수 있도록 하는 데에는 비용을 지불할 수 없습니다.

Answer 10

우리는 여기서 이것을 했습니다.우리는 10년 전에 첫 번째 글을 썼습니다.그런 다음 기술을 배우기 위한 방법으로 웹 서비스를 사용하도록 업그레이드했습니다.원래 우리가 이렇게 한 주된 이유는 버전 기록 보고서를 생성하는 버그 추적 시스템과 상용 제품에서 찾을 수 없는 몇 가지 다른 기능을 원했기 때문입니다.

우리는 이제 버그 추적 시스템을 다시 살펴보고 있으며 Mantis로 마이그레이션하고 Mantis Connect를 사용하여 자체 사용자 정의 기능을 추가하는 것을 진지하게 고려하고 있습니다.자체 시스템을 구축하는 데 드는 노력의 양은 너무 큽니다.

FogBugz도 살펴봐야 할 것 같습니다 :-)

Answer 11

가장 중요한 것은 버그 추적기가 완료되기 전에 버그 추적기를 어디에 제출할 것인가입니다.

하지만 진지하게.도구는 이미 존재하므로 바퀴를 다시 만들 필요가 없습니다.특정 특정 기능을 추가하기 위해 추적 도구를 수정하는 것은 한 가지입니다(저는 트랙 전에)...하나를 다시 쓰는 것은 어리석은 일입니다.

지적할 수 있는 가장 중요한 점은 그들이 원하는 것이 몇 가지 전문 보고서를 추가하는 것뿐이라면 기초적인 솔루션이 필요하지 않다는 것입니다.게다가 "홈브루 솔루션"이 가장 중요한 부분은 내부 도구입니다.필요한 대로 작업을 수행한다면 내부적으로 무엇을 사용하고 있는지 누가 신경 쓰나요?

Answer 12

이미 중요한(또는 가장 중요하지 않은) 작업을 수행하는 프로그래머로서 이미 시장(오픈 소스 또는 상용)에서 사용할 수 있는 것을 개발하려고 시도하여 벗어나서는 안 됩니다.

이제 핵심 개발에서 버그를 추적하는 데 사용하는 버그 추적 시스템을 추적하기 위해 버그 추적 시스템을 만들어 보겠습니다.

첫 번째:1.버그 시스템이 실행되는 플랫폼 (Java, PHP, Windows, Linux 등)을 선택하십시오.당신이 선택한 플랫폼에서 사용 가능한 오픈 소스 도구 (오픈 소스로 상용 및 무료 도구를 의미)를 찾으십시오.귀하의 필요에 맞게 사용자 정의하는 데 최소한의 시간을 투자하십시오.가능하다면 사용자 정의에 시간을 낭비하지 마십시오.

엔터프라이즈 개발팀의 경우 우리는 지라.우리는 추가 보고서, SSO 로그인 등을 원했습니다.JIRA는 이를 가능하게 했고 우리는 이미 사용 가능한 플러그인을 사용하여 이를 확장할 수 있었습니다.코드는 유료 지원의 일부로 제공되었으므로 로그인을 위한 사용자 정의 플러그인을 작성하는 데 최소한의 시간만 소비했습니다.

Answer 13

무료/오픈 소스를 다운로드하기보다는 다른 사람들의 의견을 토대로 구축하세요.다운로드한 다음 자신의 필요에 맞게 완전히 수정하는 것은 어떻습니까?나는 과거에 그렇게 하도록 요구받았다는 것을 알고 있습니다.저는 Bugzilla를 설치한 다음 회귀 테스트와 테스트 보고를 지원하도록 수정했습니다(이것은 수년 전의 일입니다).

더 둥근 바퀴를 만들 수 있다고 확신하지 않는 한 바퀴를 재발명하지 마세요.

Answer 14

가장 큰 걸림돌 중 하나는 데이터 모델/워크플로우에 대한 고민일 것입니다.나는 이것이 시간이 걸릴 것이라고 예측한다 긴 특정 상황에서 버그에 어떤 일이 일어나야 하는지, 실제로 버그를 구성하는 요소는 무엇인지 등에 대한 많은 논쟁이 필요합니다.몇 달 동안 논쟁을 벌이는 대신, 사전 구축된 시스템을 출시한다면 대부분의 사람들은 이미 결정된 결정이 무엇이든 상관없이 시스템을 사용하는 방법을 배우고 최대한 활용하게 될 것입니다.오픈 소스를 선택하고 필요할 경우 나중에 언제든지 조정할 수 있습니다. 많이 처음부터 직접 굴리는 것보다 빠릅니다.

Answer 15

이 시점에서 버그 추적/티켓팅에 대한 큰 새로운 방향이 없으면 단순히 바퀴를 다시 발명하는 것입니다.일반적으로 다른 사람들이 모두 생각하는 것 같습니다.

Answer 16

귀하의 토론은 버그를 구성하는 것부터 시작하여 적용할 작업 흐름으로 발전하고 소프트웨어 엔지니어링 프로젝트를 관리하는 방법에 대한 대규모 논쟁으로 끝납니다.정말로 그걸 원하시나요?:-) 아뇨, 그럴 생각은 없었어요 - 가서 하나 사세요!

Answer 17

대부분의 개발자는 자신이 다른 누구도 갖고 있지 않은 고유한 능력을 갖고 있으므로 어떤 방식으로든 고유한 시스템을 만들 수 있다고 생각합니다.

99%는 틀렸습니다.

귀하의 회사에 1%의 직원이 있을 가능성은 얼마나 됩니까?

Answer 18

나는 이 논쟁의 양쪽 입장에 있었기 때문에 여기서는 조금 두 가지 입장을 취하겠습니다.

저는 어렸을 때 자체 버그 추적 시스템을 구축하려고 노력했습니다.나는 기성품이 할 수 없는 모든 일을 강조했고 경영진에게 이를 맡겼습니다.그들은 팀을 이끌기 위해 누구를 선택했나요?나!팀 리더가 되어 디자인부터 도구, 인력까지 모든 면에서 목소리를 낼 수 있는 첫 번째 기회가 될 것이었습니다.나는 매우 기뻤다.그래서 제가 추천하는 것은 이 프로젝트를 추진하는 사람들의 동기를 확인하는 것입니다.

이제 나는 나이가 들었고 또 같은 질문에 직면하게 되었기 때문에 방금 FogBugz를 선택하기로 결정했습니다.필요한 작업의 99%를 수행하며 비용은 기본적으로 0입니다.또한 Joel은 귀하가 특별하다고 느낄 수 있도록 개인 이메일을 보내드립니다.그리고 결국에는 그것이 문제가 아닌가? 개발자들은 이것이 자신들을 특별하게 만들 것이라고 생각하는가?

Answer 19

모든 소프트웨어 개발자는 자신만의 버그 추적 시스템을 구축하고 싶어합니다.우리가 할 수 있기 때문이야 확실히 우리는 도메인 전문가이기 때문에 이미 존재하는 것을 개선합니다.

개발자 시간 측면에서 비용 대비 가치가 거의 없습니다.그냥 사세요 지라.

버그 추적 시스템에 대한 추가 보고서가 필요한 경우 기본 데이터베이스에 직접 액세스하여 이를 수행해야 하는 경우에도 이를 추가할 수 있습니다.

Answer 20

문제는 당신의 회사가 당신에게 무엇을 하도록 돈을 지불하는가입니다.당신만이 사용할 소프트웨어를 작성하는 것입니까?당연히 아니.따라서 버그 추적 시스템을 구축하는 데 드는 시간과 비용을 정당화할 수 있는 유일한 방법은 무료 버그 추적 시스템을 사용하는 데 드는 비용보다 비용이 적게 드는 것입니다.

이것이 의미가 있는 경우가 있을 수 있습니다.기존 시스템과 통합해야 합니까?(시간 추적, 추정, 요구 사항, QA, 자동화된 테스트)?캡처하기 어려운 특정 데이터 요소가 필요한 SOX 규정 준수와 관련된 조직의 고유한 요구 사항이 있습니까?

프로젝트 사이에 심각한 "다운타임"을 초래하는 극도로 보수적인 환경에 있습니까?

이러한 유형의 질문에 대한 대답이 '예'라면 반드시 "구매" 대 빌드 논쟁에서 빌드라고 말할 것입니다.

Answer 21

"매우 전문적인 보고서가 필요하거나 고유한 방식으로 일부 기능을 조정할 수 있는 기능이 필요한 경우" 가장 좋고 저렴한 방법은 기존 버그 추적 시스템 개발자에게 문의하는 것입니다.해당 기능을 응용 프로그램에 추가하고 전 세계에 사용할 수 있도록 비용을 지불하십시오.휠을 재발명하는 대신 휠 제조업체에 비용을 지불하여 스프링 모양의 스포크를 삽입하면 됩니다.

그렇지 않고 프레임워크를 선보이려고 한다면 모두 좋습니다.관련 면책조항을 입력하시기 바랍니다.

버그 추적 시스템을 구축하는 것이 어렵지 않다고 믿는 사람들은 폭포수 SDLC를 엄격하게 따르십시오.모든 요구 사항을 미리 파악하세요.그것은 그들이 복잡성을 이해하는 데 확실히 도움이 될 것입니다.이들은 일반적으로 검색 엔진을 구축하는 것이 그리 어렵지 않다고 말하는 사람들입니다.텍스트 상자, "검색" 버튼, "I'm Feeling Lucky" 버튼, 그리고 "I'M Feeling Lucky" 버튼만 있으면 2단계에서 완료할 수 있습니다.

Answer 22

일부 오픈 소스 소프트웨어를 있는 그대로 사용.확실히 버그가 있으며 아직 존재하지 않거나 버그 수정이 보류 중인 버그가 필요할 것입니다.그것은 항상 발생합니다.:)

오픈 소스 버전을 확장/사용자 정의하는 경우 이를 유지해야 합니다.이제 테스트에 도움이 될 것으로 예상되는 애플리케이션 돈 버는 애플리케이션 지원하는 데 부담이 될 것입니다.

Answer 23

내 경험에 따르면 사람들이 자신만의 버그 추적 시스템을 작성하는 이유는 다음과 같습니다.

1. 그들은 상대적으로 구축하기 쉽다고 생각되는 시스템에 비용을 지불하고 싶어하지 않습니다.
2. 프로그래머 자아
3. 기존 시스템이 제공하는 경험과 솔루션에 대한 일반적인 불만.
4. 상품으로 판매하고 있어요 :)

나에게 있어 대부분의 버그 추적기가 실패한 가장 큰 이유는 최적의 사용자 경험을 제공하지 못했고 유용성에 최적화되지 않은 시스템을 많이 사용하는 시스템으로 작업하는 것이 매우 고통스러울 수 있다는 것입니다.

나는 또 다른 이유가 우리(프로그래머) 중 거의 모든 사람이 언젠가 자신만의 맞춤형 CMS 또는 CMS 프레임워크를 구축한 이유와 같다고 생각합니다(유죄).당신이 할 수 있기 때문에!

Answer 24

나는 그렇지 않은 모든 이유에 동의합니다.우리는 한동안 거기에 있는 것을 사용하려고 노력했고 결국 우리 자신의 것을 작성하게 되었습니다.왜?주로 기술 인력 외에는 누구와도 참여시키기에는 대부분이 너무 번거롭기 때문입니다.우리는 베이스캠프도 시도해 보았습니다(물론 베이스캠프는 이를 위해 설계되지 않았으며 그 점에서는 실패했습니다).

우리는 또한 고객에게 매우 효과적인 몇 가지 고유한 기능을 고안했습니다.한 줄의 자바스크립트로 코드에 스크립트를 작성한 "버그 보고" 버튼입니다.이를 통해 고객은 작은 창을 열고 신속하게 정보를 입력하고 데이터베이스에 제출할 수 있습니다.

그러나 코딩하는 데는 확실히 많은 시간이 걸렸습니다.큰 애완동물 프로젝트가 되었습니다.주말 시간 많음.

확인하고 싶다면: http://www.archerfishonline.com

피드백을 원합니다.

Answer 25

우리는 이것을 해냈습니다 ...몇 번.우리가 자체적으로 구축한 유일한 이유는 그것이 5년 전이었고 좋은 대안이 별로 없었기 때문입니다.하지만 지금은 수많은 대안이 있습니다.자체 도구를 구축하면서 배운 가장 중요한 점은 작업에 많은 시간을 할애해야 한다는 것입니다.그리고 그것은 당신이 당신의 시간에 대해 비용을 청구할 수 있는 시간입니다.소규모 기업에서는 자체적으로 모든 시간을 소비하는 것보다 청구 가능한 한두 시간으로 쉽게 회수할 수 있는 월별 요금을 지불하는 것이 훨씬 더 합리적입니다.물론 어느 정도 양보해야 하지만 장기적으로는 훨씬 더 나아질 것입니다.

우리는 다른 개발자들이 우리 애플리케이션을 사용할 수 있도록 하기로 결정했습니다.에서 확인해보세요 http://www.myintervals.com

Answer 26

왜냐하면 트랙 존재합니다.

그리고 새로운 직원이 버리지 않고 구축할 수 있는 다른 시스템에 대한 경험이 있을 경우 맞춤형 소프트웨어에 대해 교육해야 하기 때문입니다.

Answer 27

왜냐하면 판매할 목적이 아닌 이상 청구 가능한 시간이 아니거나 심지어 매우 유용하기 때문입니다.

예를 들어, 아주 좋은 버그 추적 시스템이 있습니다. 포그버그.

Answer 28

저는 몇 년 동안 스타트업에서 일했습니다. 모기, 오픈 소스 도구를 기본적으로 그 위에 정교한 버그 추적 시스템을 구축했습니다.우리는 상용 시스템에 많은 돈을 지출하지 않고 우리 요구 사항에 정확히 맞는 버그 추적 시스템을 얻을 수 있다는 주장이 있었습니다.

물론 이는 예상보다 훨씬 어려운 것으로 드러났고 개발자에게는 큰 방해가 되었습니다. 개발자는 코드 외에 버그 추적 시스템도 유지해야 했습니다.이것이 우리 회사의 멸망에 기여한 요인 중 하나였습니다.

Answer 29

단지 "개밥을 스스로 먹기" 위해 자신만의 소프트웨어를 작성하지 마십시오.더 적은 시간과 비용으로 동일한 작업을 수행하고 더 나은 작업을 수행하는 소프트웨어를 구입할 수 있는데도 더 많은 작업을 생성하는 것입니다.

Answer 30

그들에게, 좋습니다. 회사에서는 잠시 동안 비용을 절약할 수 있으며 귀하가 무급 안식년을 보내는 동안 기꺼이 개발 도구를 제공할 것입니다.프로젝트에 참여하기 위해 연차 휴가를 사용하고 싶은 사람은 누구나 자유롭게 사용할 수 있습니다.