자체 버그 추적 시스템을 구축하지 않는 이유
이제 여러 번 나는 제품이 아니라 내부 도구로 자체 버그 추적 시스템을 구축하려는 팀의 계획에 직면했습니다.
내가 호의적으로 들었던 주장은 일반적으로 다음과 같습니다.
- 내부적으로 구축 된 웹 프레임 워크 측면에서 '우리 개밥 먹기'를 원함
- 고도로 전문화 된 보고서가 필요하거나 일부 기능을 고유 한 방식으로 조정할 수있는 기능이 필요합니다.
- 버그 추적 시스템을 구축하는 것이 어렵지 않다는 믿음
기존 버그 추적 시스템 구매를 지원하기 위해 어떤 주장을 사용할 수 있습니까? 특히 어떤 기능이 쉽게 들리지만 구현하기 어렵거나 어렵고 중요하지만 종종 간과되는 기능은 무엇입니까?
먼저 다음 Ohloh 메트릭을 살펴보십시오 .
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를 구축하는 것이 자원을 낭비하는 좋은 방법이라는 것을 알게되었습니다!
내부 버그 추적 시스템을 구축해야하는 이유는 다음과 같습니다.
- 10 ~ 20 년 동안 모든 bozocoder를 무력화해야합니다.
- 내년에 예산 감소를 피하기 위해 약간의 돈을 플러시해야합니다.
그렇지 않으면하지 마십시오.
질문을 뒤집고 싶습니다. 도대체 왜 당신이 직접 만들고 싶습니까?
추가 필드가 필요한 경우 수정할 수있는 기존 패키지를 사용하십시오.
특별 보고서? 데이터베이스를 탭하여 만드십시오.
어렵지 않다고 생각하십니까? 그럼 해보세요. 사양을 지정하고 기능 및 시간 증가 목록을 확인하십시오. 그런 다음 목록이 완료된 후 직접 구현하기 전에 수정할 수있는 기존 패키지를 찾으십시오.
요컨대, 다른 휠이 맞추기 위해 약간의 조정이 필요할 때 휠을 재발 명하지 마십시오.
프로그래머는 자신의 티켓 시스템을 구축하는 것을 좋아합니다. 수십 개를보고 사용했기 때문에 모든 것을 알고 있기 때문입니다. 그렇게함으로써 그들은 편안한 지대에 머물 수 있습니다.
새로운 레스토랑을 확인하는 것과 같습니다. 보람이 있을지 모르지만 위험이 따릅니다. 피자를 다시 주문하는 것이 좋습니다.
거기에는 의사 결정의 큰 사실도 숨겨져 있습니다. 항상 무언가를해야하는 두 가지 이유가 있습니다. 좋은 이유와 올바른 이유입니다. 우리는 결정을 내린 다음 ( "우리 스스로 구축") 정당화합니다 ( "우리는 모든 권한이 필요합니다"). 대부분의 사람들은 자신의 진정한 동기를 알지 못합니다.
그들의 마음을 바꾸려면 정당화가 아닌 실제 이유 를 공격해야합니다 .
Not Invented Here 증후군!
나만의 버그 추적기를 만드시겠습니까? 자신 만의 메일 클라이언트, 프로젝트 관리 도구 등을 구축해보십시오.
으로 오메르 반 Kloeten 말한다 다른 곳에서, 지금 또는 급여 나중에 지불합니다.
세 번째 옵션은 구매도 빌드도 아닙니다. 거기에는 좋은 무료 파일 더미가 있습니다. 예를 들면 :
학습 이외의 용도로 자신의 버그 추적기를 롤링하는 것은 시간을 잘 활용하지 않습니다.
기타 링크 :
나는 그것이 돈 문제라고 말할 것입니다. 당신이 알고있는 완제품을 사는 것이 당신에게 좋다고 (때로는 공짜 인 경우에는 사지 않는 경우도 있음) 혼자 가서 개발하는 것보다 낫습니다. 그것은 간단한 게임이다 지금 지불 대 이상 지불 .
첫째, 자신을 구축하기위한 주장에 반대합니다.
내부적으로 구축 된 웹 프레임 워크 측면에서 '우리 개밥 먹기'를 원함
물론 그것은 왜 자신의 웹 프레임 워크를 구축하는지 의문을 제기합니다. 가치있는 무료 버그 추적기가 많이있는 것처럼 가치있는 프레임 워크도 많이 있습니다. 개발자의 우선 순위가 똑바로 있는지 궁금합니다. 회사에서 실제 돈을 벌 수있는 일을하는 사람은 누구입니까?
좋습니다. 프레임 워크를 구축해야한다면 비즈니스에서 돈을 벌기 위해 사용하는 실제 소프트웨어를 구축하는 과정에서 유기적으로 진화하도록하십시오.
고도로 전문화 된 보고서가 필요하거나 일부 기능을 고유 한 방식으로 조정할 수있는 기능이 필요합니다.
다른 사람들이 말했듯이 많은 훌륭한 오픈 소스 추적기 중 하나를 잡고 조정하십시오.
버그 추적 시스템을 구축하는 것이 어렵지 않다는 믿음
글쎄요, 저는 C #에 대한 사전 지식없이 시작하여 몇 주 만 에 제 BugTracker.NET 의 첫 번째 버전을 작성했습니다 . 그러나 지금은 6 년이 지난 지금도 취소 된 기능 요청의 큰 목록이 남아 있으므로 모두 버그 추적 시스템이 원하는 작업에 따라 다릅니다. 얼마나 많은 이메일 통합, 소스 제어 통합, 권한, 워크 플로, 시간 추적, 일정 추정 등. 버그 추적기는 주요 주요 응용 프로그램이 될 수 있습니다.
기존 버그 추적 시스템 구매를 지원하기 위해 어떤 주장을 사용할 수 있습니까?
구매할 필요가 없습니다. 좋은 오픈 소스가 너무 많습니다 : Trac , Mantis_Bug_Tracker , 저의 BugTracker.NET 등이 있습니다.
특히 어떤 기능이 쉽게 들리지만 구현하기 어렵거나 어렵고 중요하지만 종종 간과되는 기능은 무엇입니까?
자신만을 위해 생성하는 경우에는 여러 가지 지름길을 사용할 수 있습니다. 많은 다른 시나리오에서 많은 다른 사용자를 위해 빌드하는 경우 구성 가능성에 대한 지원이 어렵습니다. 구성 가능한 워크 플로, 사용자 정의 필드 및 권한.
좋은 버그 추적기에는 FogBugz 와 BugTracker.NET의 두 가지 기능이 있어야 한다고 생각 합니다. 1) 수신 및 발신 이메일을 모두 통합하여 버그에 대한 전체 대화가 별도의 이메일이 아닌 버그와 함께 유지되도록합니다. 스레드 및 2) 단 몇 번의 클릭만으로 스크린 샷을 버그 게시물로 전환하는 유틸리티.
저에게 가장 기본적인 주장은 시간 손실입니다. 한두 달 안에 완료 될 수 있을지 의심 스럽습니다. 좋은 버그 추적 시스템이 너무 많을 때 시간을 보내는 이유는 무엇입니까? 조정해야하고 쉽게 사용할 수없는 기능의 예를 들어주세요.
좋은 버그 추적 시스템은 개발 과정을 반영해야한다고 생각합니다. 매우 맞춤화 된 개발 프로세스는 본질적으로 회사 / 팀에 좋지 않습니다. 대부분의 애자일 관행은 스크럼 이나 이러한 종류의 것을 선호 하며 대부분의 버그 추적 시스템은 그러한 제안 및 방법과 일치합니다. 이것에 대해 너무 관료적이지 마십시오.
버그 추적 시스템은 주니어 개발자를 시작하기에 좋은 프로젝트가 될 수 있습니다. 코딩 규칙 등에서 교육하는 데 사용할 수있는 매우 간단한 시스템입니다. 주니어 개발자가 그러한 시스템을 구축하도록하는 것은 상대적으로 저렴하며 고객이 보지 못하는 것에 실수를 할 수 있습니다.
쓰레기라면 그냥 버릴 수 있지만 사용한다면 이미 회사에 중요한 일이 있다는 느낌을 줄 수 있습니다. 주니어 개발자가 전체 수명주기를 경험할 수 있고 그러한 프로젝트가 가져올 지식 이전 기회를 모두 경험할 수있는 비용을 부과 할 수는 없습니다.
우리는 여기서 이것을했습니다. 우리는 10 년 전에 처음으로 썼습니다. 그런 다음 기술을 배우는 방법으로 웹 서비스를 사용하도록 업그레이드했습니다. 이 작업을 처음 수행 한 주된 이유는 버전 기록 보고서와 상용 제품에서 찾을 수없는 몇 가지 다른 기능도 생성하는 버그 추적 시스템을 원했기 때문입니다.
우리는 이제 버그 추적 시스템을 다시 살펴보고 있으며 Mantis로 마이그레이션하고 Mantis Connect를 사용하여 자체 사용자 지정 기능을 추가하는 것을 진지하게 고려하고 있습니다. 우리 자신의 시스템을 롤링하기위한 노력의 양이 너무 큽니다.
FogBugz도 살펴 봐야 할 것 같아요 :-)
가장 중요한 것은 완료되기 전에 버그 추적기에 대한 버그를 어디에 제출할 것인가?
하지만 진지하게. 도구는 이미 존재하므로 바퀴를 재발 명 할 필요가 없습니다. 특정 기능을 추가하기 위해 추적 도구를 수정하는 것은 한 가지입니다 (전 Trac 을 수정했습니다 ). 하나를 다시 작성하는 것은 어리석은 일입니다.
당신이 지적 할 수있는 가장 중요한 것은 그들이 원하는 것은 몇 가지 전문 보고서를 추가하는 것뿐이라면 기초적인 솔루션이 필요하지 않다는 것입니다. 게다가 "귀하의 홈브류 솔루션"이 중요한 마지막 위치는 내부 도구입니다. 필요한 작업을 수행하는 경우 내부적으로 사용하는 것을 누가 신경 쓰나요?
이미 중요한 (또는 가장 중요하지 않은) 작업을 수행하는 프로그래머가되어 시장에서 이미 구할 수있는 (오픈 소스 또는 상업용) 무언가를 개발하려고 노력하여 일탈해서는 안됩니다.
이제 핵심 개발에서 버그를 추적하는 데 사용하는 버그 추적 시스템을 추적하는 버그 추적 시스템을 만들려고합니다.
첫째 : 1. 버그 시스템이 실행될 플랫폼 (Java, PHP, Windows, Linux 등)을 선택합니다. 2. 플랫폼에서 사용할 수있는 오픈 소스 도구를 찾습니다 (오픈 소스, 저는 상용 및 무료 도구를 의미 함). 3을 선택했습니다. 필요에 맞게 사용자 지정하는 데 최소 시간을 투자하십시오. 가능하다면 커스터마이징에 시간을 낭비하지 마십시오.
엔터프라이즈 개발 팀의 경우 JIRA를 사용하기 시작했습니다 . 우리는 몇 가지 추가 보고서, SSO 로그인 등을 원했습니다. JIRA가 가능했고 이미 사용 가능한 플러그인을 사용하여 확장 할 수있었습니다. 코드가 유료 지원의 일부로 제공되었으므로 로그인을위한 사용자 지정 플러그인을 작성하는 데 최소한의 시간 만 소비했습니다.
Building on what other people have said, rather than just download a free / open source one. How about download it, then modify it entirely for your own needs? I know I've been required to do that in the past. I took an installation of Bugzilla and then modified it to support regression testing and test reporting (this was many years ago).
Don't reinvent the wheel unless you're convinced you can build a rounder wheel.
I'd say one of the biggest stumbling blocks would be agonising over the data model / workflow. I predict this will take a long time and involve many arguments about what should happen to a bug under certain circumstances, what really constitutes a bug, etc. Rather than spend months arguing to-and-fro, if you were to just roll out a pre-built system, most people will learn how to use it and make the best of it, no matter what decisions are already fixed. Choose something open-source, and you can always tweak it later if need be - that will be much quicker than rolling your own from scratch.
At this point, without a large new direction in bug tracking/ticketing, it would simply be re-inventing the wheel. Which seems to be what everyone else thinks, generally.
Your discussions will start with what consitutes a bug and evolve into what workflow to apply and end up with a massive argument about how to manage software engineering projects. Do you really want that? :-) Nah, thought not - go and buy one!
Most developers think that they have some unique powers that no one else has and therefore they can create a system that is unique in some way.
99% of them are wrong.
What are the chances that your company has employees in the 1%?
I have been on both sides of this debate so let me be a little two faced here.
When I was younger, I pushed to build our own bug tracking system. I just highlighted all of the things that the off the shelf stuff couldn't do, and I got management to go for it. Who did they pick to lead the team? Me! It was going to be my first chance to be a team lead and have a voice in everything from design to tools to personnel. I was thrilled. So my recommendation would be to check to the motivations of the people pushing this project.
Now that I'm older and faced with the same question again, I just decided to go with FogBugz. It does 99% of what we need and the costs are basically 0. Plus, Joel will send you personal emails making you feel special. And in the end, isn't that the problem, your developers think this will make them special?
Every software developer wants to build their own bug tracking system. It's because we can obviously improve on what's already out there since we are domain experts.
It's almost certainly not worth the cost (in terms of developer hours). Just buy JIRA.
If you need extra reports for your bug tracking system, you can add these, even if you have to do it by accessing the underlying database directly.
The quesion is what is your company paying you to do? Is it to write software that only you will use? Obviously not. So the only way you can justify the time and expense to build a bug tracking system is if it costs less than the costs associated with using even a free bug tracking system.
There well may be cases where this makes sense. Do you need to integrate with an existing system? (Time tracking, estimation, requirements, QA, automated testing)? Do you have some unique requirements in your organization related to say SOX Compliance that requires specific data elements that would be difficult to capture?
Are you in an extremely beauracratic environment that leads to significant "down-time" between projects?
If the answer is yes to these types of questions - then by all means the "buy" vs build arguement would say build.
If "Needing some highly specialised report, or the ability to tweak some feature in some allegedly unique way", the best and cheapest way to do that is to talk to the developers of existing bug tracking systems. Pay them to put that feature in their application, make it available to the world. Instead of reinventing the wheel, just pay the wheel manufacturers to put in spokes shaped like springs.
Otherwise, if trying to showcase a framework, its all good. Just make sure to put in the relevant disclaimers.
To the people who believe bug tracking system are not difficult to build, follow the waterfall SDLC strictly. Get all the requirements down up front. That will surely help them understand the complexity. These are typically the same people who say that a search engine isn't that difficult to build. Just a text box, a "search" button and a "i'm feeling lucky" button, and the "i'm feeling lucky" button can be done in phase 2.
Use some open source software as is. For sure there are bugs, and you will need what is not yet there or is pending a bug fix. It happens all of the time. :)
If you extend/customize an open source version then you must maintain it. Now the application that is suppose to help you with testing money making applications will become a burden to support.
I think the reason people write their own bug tracking systems (in my experience) are,
- They don't want to pay for a system they see as being relatively easy to build.
- Programmer ego
- General dissatisfaction with the experience and solution delivered by existing systems.
- They sell it as a product :)
To me, the biggest reason why most bug trackers failed was that they did not deliver an optimum user experience and it can be very painful working with a system that you use a LOT, when it is not optimised for usability.
I think the other reason is the same as why almost every one of us (programmers) have built their own custom CMS or CMS framework at sometime (guilty as charged). Just because you can!
I agree with all the reasons NOT to. We tried for some time to use what's out there, and wound up writing our own anyway. Why? Mainly because most of them are too cumbersome to engage anyone but the technical people. We even tried basecamp (which, of course, isn't designed for this and failed in that regard).
We also came up with some unique functionality that worked great with our clients: a "report a bug" button that we scripted into code with one line of javascript. It allows our clients to open a small window, jot info in quickly and submit to the database.
But, it certainly took many hours to code; became a BIG pet project; lots of weekend time.
If you want to check it out: http://www.archerfishonline.com
Would love some feedback.
We've done this... a few times. The only reason we built our own is because it was five years ago and there weren't very many good alternatives. but now there are tons of alternatives. The main thing we learned in building our own tool is that you will spend a lot of time working on it. And that is time you could be billing for your time. It makes a lot more sense, as a small business, to pay the monthly fee which you can easily recoup with one or two billable hours, than to spend all that time rolling your own. Sure, you'll have to make some concessions, but you'll be far better off in the long run.
As for us, we decided to make our application available for other developers. Check it out at http://www.myintervals.com
Because Trac exists.
And because you'll have to train new staff on your bespoke software when they'll likely have experience in other systems which you can build on rather than throw away.
Because it's not billable time or even very useful unless you are going to sell it.
There are perfectly good bug tracking systems available, for example, FogBugz.
I worked in a startup for several years where we started with GNATS, an open source tool, and essentially built our own elaborate bug tracking system on top of it. The argument was that we would avoid spending a lot of money on a commercial system, and we would get a bug tracking system exactly fitted to our needs.
Of course, it turned out to be much harder than expected and was a big distraction for the developers - who also had to maintain the bug tracking system in addition to our code. This was one of the contributing factors to the demise of our company.
Don't write your own software just so you can "eat your own dog food". You're just creating more work, when you could probably purchase software that does the same thing (and better) for less time and money spent.
Tell them, that's great, the company could do with saving some money for a while and will be happy to contribute the development tools whilst you work on this unpaid sabbatical. Anyone who wishes to take their annual leave instead to work on the project is free to do so.
ReferenceURL : https://stackoverflow.com/questions/62153/reasons-not-to-build-your-own-bug-tracking-system
'programing' 카테고리의 다른 글
| Android에서 라디오 버튼을 설정하는 방법 (0) | 2021.01.16 |
|---|---|
| 원격 git 저장소에서 최신 커밋의 SHA를 얻는 방법은 무엇입니까? (0) | 2021.01.16 |
| div 요소를 편집 가능하게 만들려면 어떻게해야합니까 (클릭 할 때 텍스트 영역처럼)? (0) | 2021.01.16 |
| instanceof-호환되지 않는 조건부 피연산자 유형 (0) | 2021.01.16 |
| Android : MediaPlayer setVolume 함수 (0) | 2021.01.16 |