Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
There's not a lot to add to the subject really.
I am after a free task board/ burndown reporting tool for Windows.
If you're willing to host your tool,
TargetProcess
(http://www.targetprocess.com/)
XPlanner(http://xplanner.codehaus.org/)
If not,
Pivotal Tracker (http://www.pivotaltracker.com/)
ScrumWorks (http://danube.com/scrumworks/basic)
All are either free or have a free version.
Depending on your real needs, solutions range from :
hand-written cards complemented with a manually drawn burndown chart as big visible chart as recommend by Ilja
spreadsheet-based list with automatic burndown graph generation (example)
online tools such as scrumy, scrumpad and skinnyboard
local application with web access
free ScrumWorks basic, Icescrum2
or commercial ScrumWorks Pro ProjectCards, or, as Eliza recommended, TargetProcess
Remember however the Agile manifesto is recommending to favor "Individuals and interactions over processes and tools".
I'd recommend starting small, perhaps with a spreadsheet if you insist on automatic burndown charting.
Check out SeeNowDo at www.seenowdo.com
It's a free online taskboard for distributed Agile teams. It's pretty cool and provides convenient features like 'always-on' and 'instant-sync' capability. It also has some cool ways of managing the taskboard layout once you have alot of tasks on it. Best of all, it's completely free.
Apparently I got to disclose I built this product
You might want to try: http://www.burndown-charts.com
It's a free webapp for managing burndown charts. You create a team and a sprint and you are ready to go. Enter your tasks once they are done. Perfect for when you still want to keep a board and/or post-its. You can add teammates to your team if you need.
You're not going to spend an hour figuring out how to use it.
That is exactly what Scrumy.com is. It is a whiteboard with sticky notes. The pro version has a burndown.
Try Mingle. It is free for upto 5 users.
Open Source app: http://taskboard.cognifide.com/
Fast, tidy tool :)
EDIT
Ok, we are working on something that does just what you asked and way more:
Actionable metrics
Powerful analytics
All this on a slick Dashboard
It's meant to eliminate the use of excel sheets to build your own reports by hand.
It's a far better solution and it is in beta right now.
Sign up and participate in the beta to make sure your features are well covered!
http://www.in-sight.io
Well, without knowing more about your situation, I have to highly recommend a wall of index cards and a handdrawn chart on flip chart paper. Works much better than any software in the standard situation.
If you really have to use software, there is none that I could recommend unreservedly, let alone a free one. You might want to keep in mind that some of the commercial ones are free for open source or academic projects, too. Which one's right for you will depend, besides other things, on how much you want it to define your process.
You might consider creating your own solution using a spreadsheet.
That way you get low overhead on data entry and as much reporting capabilities as you want, without having an external tool define your process.
Especially on single-person projects (as this appears to be from the comment on Ilja Preuß's answer), I find that a simple spreadsheet actually works better for me.
I keep all my tasks in one workbook, and the formulas that pull out interesting data and calculations in a separate workbook.
I made a basic plugin that can be inserted in google wave and be used as a taskboard. More details in http://agilebooknote.blogspot.com/2009/11/taskboardy-available.html.
Cheers,
-fede
I'm a fan of google docs because of the simplicity and also because I can give access to my team so that they can update their tasks on a daily basis. The template I use and a tutorial on how to use it is available at
Burn Down Chart Tutorial: Simple Agile Project Tracking
I know this is old thread, but I came across this question looking for something similar. I signed up for AgileZen (http://www.agilezen.com/) and it's actually quite good.
I wanted something free that my wife and I could use for personal/home stuff. It's free if you're willing to have only one project (I call it "Home") and one other collaborator (my wife). It's a pretty good solution for us.
I promise I have no affiliation with them! Except that I now use their product.
If your project is open source, non-profit or a classroom you can get free access to Atlassians' JIRA + Greenhopper (and other tools) for agile project management. Otherwise small teams can get access for a nominal fee.
see http://www.atlassian.com/software/greenhopper/overview and http://www.atlassian.com/software/jira/overview.
See http://www.atlassian.com/software/views/open-source-license-request if your an open source project.
http://www.atlassian.com/software/views/community-license-request if you are a non-profit
and
http://www.atlassian.com/survey/classroom-license-request if your a classroom.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I know slightly close questions have been asked before but this question is a bit different.
We are a start-up company with a very limited budget and we are looking for a completely free Agile software development process tool without any limitation on the number of users. We don't want to have a limitation for the number of users because there could be a lot of people who would do small tasks for us and if they pass the number of user limit all of a sudden we'll have to pay a lot of money for the tool monthly.
It would be very useful if it could support:
Kanban board
Task hierarchy (so that you can define cards within cards)
Hosting the tool online (not download)
Commenting system
Different roles
Swimlanes
I have checked a lot of those tools here:
http://agilescout.com/best-agile-scrum-tools/
but I didn't find any that is absolutely free for unlimited users. Some of them also don't have a Kanban board. I checked Agilefant but its online version is going to be paid from 2014. I also checked Stackoverflow for this but none of the questions were targeting "completely free tools".
Your help will be greatly appreciated.
Trello.com Trello is free for unlimited users. Period.
You almost definitely don't need "Sub-cards". Use the checklists instead, or if you REALLY need sub-cards, don't have a parent sub-card. Just name the tickets something like "Epic - Story A" or "Story - task Z" or whatever.
Another idea is to create two boards (did I mention you can have unlimited boards for free too?). One for your epics and one for your stories. Call one your product management board and the other your sprint board, or whatever you like.
I'm not sure what you need different roles for - but, people aren't crazy - they know their job. As a startup if you already have problems getting people to not do crazy things (Where you need to restrict their permissions) you have much much bigger issues.
The point is that you need a SMALL tool to help you track stuff. Not a super rigid tool that makes you work in a super specific way. As a new (I assume?) startup, you should let your process grow into a tool. Don't beef up your process to fit a tool.
Back in 2010 we had the same problem and i successfully employed GoogleDocs with our small Agile Development team (8 Devs in 3 Countries).
GoogleDrawing will serve in the exact same way as a physical Scrum board would, with all the upsides of full flexibilty and also the downsides of zero automation but with the big additional upside of being virtual and accessible from anywhere with an internet connection.
It also was used for the retrospective at the end of each Sprint
GoogleSpreadsheet was used for a concise list of all the tickets from our bug tracking system (Redmine, manually transfered) and also for the (manually updated, albeit with formulas to calculate the progress) burndown chart.
The combination of these different elements is actually quite powerful, as you have the full flexibility over the content and its representation and can have your team communicate via VoIP while all are looking at the same documents and can modify them in real-time.
Here an example of the docs used in a sprint (all sensitive data removed):
Scrum board Example (GoogleDrawing)
Retrospective Example (GoogleDrawing)
Burndown Chart Example (GoogleSheet, formulas to automate calculation)
Ticket list from Bugtracker (GoogleSheet)
As mentioned before, the only downside is the fact that you have to invest some time to maintain and prepare the data for each sprint, but for us that was hugely outweighed by the flexibility and accessibility that the Team of GoogleDocs + VoIP gave us.
You can check out https://kanbanflow.com
It's free for now because it's in beta and they say there is no time limit. It behaves very similar to AgileZen
I second the google doc, or you could use an online collaborative board that multiple people can edit.
Or you can host a more robust excel doc in skydrive from MS. I haven't tried that yet.
Mura.ly is another one that I am playing with currently. It has unlimited collaborators, though I think you would probably have to invite them everytime?? with a free account.
Hope that helps!
Try http://www.icescrum.org . It is free to use. And it has lot of cool features. Perfect for scrum teams.
EDIT: Kanbanize is a commercial product and offers a 30 day free trial.
Disclosing: I am a co-founder of http://kanbanize.com/
Mark, I understand your desire to find the perfect application with all these features inside, but I really doubt that you will get it for free. There's a bunch of super cool apps (including Kanbanize) out there, but none of them is completely free.
Be careful what you call a Kanban board and what not, though. Trello is definitely NOT a kanban system (no WIP limits, no analytics, etc.). It is a great visual management system, but not a Kanban one.
Finally, to answer your question, tools that deserve attention in my opinion are:
Kanbanize (of course), LeanKit, KanbanTool, Kanbanery and probably a few others. My personal bias is that LeanKit is the most advanced to date followed by Kanbanize and KanbanTool.
I hope that helps.
One possibility would be to use a Google Drawing, part of Google Drive, if you want a more visual and easy-to-edit option. You can create the cards by grouping a color-filled rectangle and one or more text fields together. Being a sufficiently free-form online vector drawing program, it doesn't really limit your possibilities like if you use a more dedicated solution.
The only real downsides are that you have to first create the building blocks from the beginning, and don't get numerical statistics like with a more structured tool.
Although, I'm a big fan of Kanban Tool service (it has everything you need except free of charge) and therefore it's difficult for me to stay objective, I think that should go for Trello or Kanban Flow. Both are free and both provide basic features that are essential for agile process managers and their teams.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
We do distributed agile development and could really us a solution like story cards on a wall/board, only on a webpage where you could easily drag and drop them. Any suggestions? Thanks.
Trello is perfect for something like this. It's very simple, yet flexible. It's like a simpler version of PivotalTracker, mentioned above.
Its been a while since this was asked, but the best option out there in my opinion is http://www.Sprint.ly
Really powerful. Really beautiful. Really User Story focused!
I've used Eidos. I think it's the best if you want to use in Agile project (I've used it for real 3-4 projects for the real customer). Eidos team keep developing to serve human's need in Agile project. I think they invite beta users to test now. If you have problems about co-located team, this tool is quite useful (I prefer physical thing anyway if my team is co-located)
Me using Eidos, it's easier than Jira and focus more in Agile than Trello.
Not drag and drop, but I find basecamp very nice for agile development.
http://basecamphq.com
See if scrumy suits.
It's a tool roughly based on scrum. You create stories from them assign tasks to a story board assign them to people. In fact it is exactly what you've asked for! :)
You can set up a free project and play around with it.
Screenshot here
For User Stories, I find Pivotal Tracker to be awesome. It automatically fits user stories into each iteration based on computed velocity. Implements just enough workflow so everyone understands what they're responsible for. And is one of the cleanest, nicest implementations I've seen. (Although AgileZen is up there too... that app is gorgeous - but I just didn't gel with it in the same way)
However the drag-drop in PivotalTracker is limited to User Story-level objects. You don't move tasks around. For a more this-sprint/iteration task board, Scrumy is probably the one to go for.
Mingle may be something to explore and see if it'll work for your situation.
maybe a Bit oversized for your purposes, but targetprocess is a nice full blown project Management Software. It has a nice Kanban Board which fulfills your stroyboard requirement including Drag&Drop. It is free for up to 5Users.
I have used xPlanner before successfully.
http://www.xplanner.org/
Also, I have seen peole use Google Sites for similar effect. Either is drag and drop though
You could try using http://www.cardmeeting.com/
Take a look at Assembla tickets and its agile planner, it is a way to go.
Drag & Drop for:
to make tickets and user-stories
to sort tickets inside a milestone
to sort user stories
to move stories/tickets between milestones
sorting will be available on Monday(26 Oct) with next release as they promised.
Finally distributed agile development is a way that Assembla is doing their client jobs.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
We are an all Unix shop (Solaris, Linux). This last product cycle I returned to a project lead capacity, and needed to produce a schedule. I asked what tools my managers would accept, and was surprised to hear "text files". My teammate and I gamely tried this, and probably worse, HTML tables, to track the tasks we wanted to size. It was pretty painful.
We then tried a few tools. MrProject is buggy, limited and crashes too frequently. My manager swears that Microsoft Project is inflexible. Whenever they needed to change a task, reassign a resource or rebalance, it generally hosed their plan. So I started looking around on the Internet for a Linux-capable project planning tool. One that sounded interesting is TaskJuggler. It's neat in that the inputs are declarative files. I feel like I'm building a makefile for a project.
However. I have a limited amount of time to devote to evaluating this tool and it seems pretty complex. Before diving into the next product cycle, I'd like to know if TaskJuggler is robust enough, flexible and capable of handling multi-month, multiple resource projects with frequent changes. So I'm calling on all engineers who have had experience with this tool to share their insights. Thanks!
There is nothing free in project management, and managing a complex project with software is inevitably complex. The real question is, does the chosen tool help with this?
Task Juggler has a learning curve, and in the end is suitable for someone who doesn't mind reading the manual (an absolute necessity for this tool) and isn't tied to graphical input. Task Juggler requires that you think about your project and structure it in a meaningful way. It is helpful if you do a diagram in advance (many TJ users make mind maps and there is a tool out there somewhere to generate TJ input statements from a FreeMind mind map). It is also very helpful if you organize your input file in some meaningful way, making things easy to find.
That said, once you get going, creating a project with TJ is super fast. You don't need to bother with a million dialog boxes, you just tell TJ what you want in TJ's text language.
But all of that aside, what I like about TJ (and hated at first, coming from a legacy of other more traditional tools) is that it ensures that your schedule makes sense. OpenProj happily schedules resources at 300% and more. TJ will give you an error and make you fix it. Yes, it's annoying. But the end result is that you have a project schedule that makes sense and can actually be executed. Imagine that!
As I started out by saying, nothing's free. TJ requires study and some effort. The reward is rich and copious reporting, all the information you need to manage your project to cost and schedule, and the enforcement of a logical, reliable approach to scheduling and resource allocation. And it doesn't cost $499 or whatever MSP goes for --- it's free.
I have been using taskjuggler for the past 4/5 years now (4 projects with an average duration of a year or more). I find it very useful to create my initial estimates of
how long the project will take
When will each resource group be freed.
What if we added more resources with varying level of experience and efficiency to different domains of the project.
Typically the kind of stuff that upper management will ask you about your schedule can be generated much faster and at a more accurate granularity compared to doing something similar using MS Project or other GUI based tools.
Till recently I was using taskjuggler to get my initial schedule and using ms excel to track the project.
This is the first time I am using task juggler to actually track the project on a weekly basis. and so far the results look good.
TaskJuggler's syntax is rather easy, but do take your time to read the documentation.
My experience with TJ:
very powerful and expressive syntax
useful for detailed calculation of large projects
However in reality a manual planning takes into account many implicit constraints, which TJ requires to be made explicit in order to obtain realistic scenario's. This is of course true for every planning tool, but I found it rather cumbersome to add and edit manual constraints in large projects in TJ... Therefore I found it less suited for project tracking and rescheduling afterwards.
I now use OmniPlanner, which is a far simpler tool than TJ and MSProject but turns out to suit my needs (especially in tracking, analysis and reporting).
I am using Taskjuggler to develop a very detailed task manager for big movie productions. It's brilliant cause of it's syntax and csv outputs.
I have been using it for 1w and love it.
The acceptance test, so to speak, is if you find text/coding more expressive than UI based input.
If you do feel comfortable expressing your thinking in a structured language but prefer/expect UI then do not spend time with TaskJuggler.
See http://www.pegasoft.ca/coder/coder_july_2008.html for these remarks like
"Don't expect a nice user interface with an "Add Task" button here."
"Even reports must be designed in it's awkward, C-like language"
If that is how you think then do not spend time with TaskJuggler.
TaskJuggler is (almost) a DSL for planning.
If you do not know what a DSL is then do not spend time with TaskJuggler.
Or learn about DSLs. :-)
For the rest, try it because it might just put planning in your own hands and take it away from the hands of people who demand it from you only to ask for status.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I'm supposed to learn how to use LabVIEW for my new job, and I'm wondering if anybody can recommend some good books or reference/tutorial web sites.
I'm a senior developer with lots of Java/C#/C++ experience.
I realize that this question is perhaps more vague than is intended on stack overflow, so how about this? Please answer with one book or web site and a brief description. Then people can vote up their favourites.
It will take some training and some time to learn the style needed to develop maintainable code.
Coming from Java/C#/C++, you probably have a good idea of good software architecture. Now you just need to learn the peculiarities of LabView and the common pitfalls.
For the basics, National Instruments offers training courses. See if your new employer can send you to a Basics I/II class to get your feet wet. They offer some online classes as well. Following classes, you can sign up to take tests for certification.
Get an evaluation copy of Labview from National Instruments; they have a well maintained help file that you can dive right into, with example code included. Look at "Getting Started" and "LabVIEW Environment". You should be able to jump right in and become familiar with the dev environment pretty quickly.
LabVIEW, being graphical is nice, but don't throw out your best practices from an application design point of view. It is common to end up with code looking like rainbow sphaghetti, or code that stretches several screens wide. Use subvi's and keep each vi with a specific purpose and function.
The official NI support forums and knowledgebase are probably the best resources out there at the moment.
Unofficial sites like Tutorials in G have a subset of the information found on the official site and documentation, but still may be useful for cross reference if you get stuck.
Edit: Basics I/II are designed to be accessible to users without prior software development experience. Depending on how you feel after using the evaluation version, you may be able to move directly into Intermediate I/II. NI has the course outlines available on their website as well, so you know what you're going to cover in each.
LabVIEW for Everyone is recently revised and quite comprehensive. Other than the free stuff available on the Web, this is probably the best place to start learning the language.
The LabVIEW Style Guide is a great book on how to organize and arrange your code and files for maximum benefit.
Object oriented programming is a recent addition to LabVIEW. The LVOOP white paper explains much about how it works and why the way it is the way it is.
It's a bit out of date, but LabVIEW Advanced Programming Techniques by Bitter, Mohiuddin and Nawrocki is still full of useful stuff.
The National Instruments forums are a great place to go for basic help. The LabVIEW Advanced Virtual Architects (LAVA) is the community forum for advanced topics.
Tutorials in G, also check out the webring.
-Adam
The official NI support page and support forums are hard to beat.
It really helps having a guru around for LabVIEW.
'Arc the daft' pretty much nailed exactly what one should try to do to learn LabVIEW. However, I would not skip Basic's I and II. The classes do teach basic programming concepts and are geared to non-programmers, however they do cover the IDE extensively. The LabVIEW IDE is strange coming from a text based language and spending the time in the class learning it with an instructor can really accelerate your learning.
I would skip Intermediate 1 if you are a seasoned developer. Intermediate 1 tries to teach software engineering practices in the span of a three day course. If you are studying to get your CLD you need to know the course and the terminology for the exam, otherwise I wouldn't spend my time or capital in the course.
Subscribe to the Info-LabVIEW mailing list. It's got a lot quieter in recent times as the NI and LAVA forums have grown in popularity, but it's still read by some very experienced and helpful people, including people at NI, and if you can't find what you need elsewhere then a good question will usually get a good answer.
The NI style guide, as already mentioned, is a good reference - re-read it as you learn about more of the things it covers, it contains some densely packed good advice.
Personal top tips: look at the supplied example code (although it's not necessarily perfect); learn to use queues and notifiers as soon as possible; don't dive in to using event structures and control references until you've figured out what you can and can't do without them; and start small and simple - you should find it easy to reuse this code later on by repackaging it into subVI's as the scope of your ambitions increases. And have fun!
For me the best way to learn LabVIEW was by analyzing the in-build examples. The best forums are NI Developer Zone Community and LAVA Forums
LabVIEW is really easy to work with but the tricky bit is to know how to design your application so that it will not becaome a spaghetti. Once you get the basics (e.g. LabVIEW Introduction Course) learn how to use design patterns, events, queues, typedefs and references. Use modular architecture, avoid big structures, try 'writing' your code in small window.
It is also important to know the differences between LabVIEW versions (full/pro, and ver 7.1.1, 8.2, 8.5, 8.6, 2009), how to use version control system with the vi's (binary files), and how to keep your files in project so that you can easily reuse any code and be "DRY" (don't repeat yourself), how to build executable and what LabVIEW RunTime Engine it needs (for customers), what is DAQmx and how to use it, what are VISA drivers and which version is correct for you settings, how to use Measurements & Automation program..
When I started with LabVIEW a few years ago I was given a link to the LabVIEW Graphical Programming Course. It covers the basics and having a sound knowledge of other programming languages I think helped me pick things up quickly.
I would start with the LabVIEW wiki.
Specifically, LabVIEW Tutorial. There are lots of online references and links to LabVIEW reference books. Welcome to the world of LabVIEW!
I would suggest you start with LabVIEW for Everyone. Its a good book which covers the basics of LabVIEW well.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Several times now I've been faced with plans from a team that wants to build their own bug tracking system - Not as a product, but as an internal tool.
The arguments I've heard in favous are usually along the lines of :
Wanting to 'eat our own dog food' in terms of some internally built web framework
Needing some highly specialised report, or the ability to tweak some feature in some allegedly unique way
Believing that it isn't difficult to build a bug tracking system
What arguments might you use to support buying an existing bug tracking system? In particular, what features sound easy but turn out hard to implement, or are difficult and important but often overlooked?
First, look at these Ohloh metrics:
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
What do we learn from these numbers? We learn that building Yet Another Bug Tracker is a great way to waste resources!
So here are my reasons to build your own internal bug tracking system:
You need to neutralize all the bozocoders for a decade or two.
You need to flush some money to avoid budget reduction next year.
Otherwise don't.
I would want to turn the question around. WHY on earth would you want to build your own?
If you need some extra fields, go with an existing package that can be modified.
Special report? Tap into the database and make it.
Believing that it isn't difficult? Try then. Spec it up, and see the list of features and hours grow. Then after the list is complete, try to find an existing package that can be modified before you implement your own.
In short, don't reinvent the wheel when another one just needs some tweaking to fit.
Programmers like to build their own ticket system because, having seen and used dozens of them, they know everything about it. That way they can stay in the comfort zone.
It's like checking out a new restaurant: it might be rewarding, but it carries a risk. Better to order pizza again.
There's also a great fact of decision making buried in there: there are always two reasons to do something: a good one and the right one. We make a decision ("Build our own"), then justify it ("we need full control"). Most people aren't even aware of their true motivation.
To change their minds, you have to attack the real reason, not the justification.
Not Invented Here syndrome!
Build your own bug tracker? Why not build your own mail client, project management tool, etc.
As Omer van Kloeten says elsewhere, pay now or pay later.
There is a third option, neither buy nor build. There are piles of good free ones out there.
For example:
Bugzilla
Trac
Rolling your own bug tracker for any use other than learning is not a good use of time.
Other links:
Three free bug-tracking tools
Comparison of issue tracking systems
I would just say it's a matter of money - buying a finished product you know is good for you (and sometimes not even buying if it's free) is better than having to go and develop one on your own. It's a simple game of pay now vs. pay later.
First, against the arguments in favor of building your own:
Wanting to 'eat our own dog food' in terms of some internally built web framework
That of course raises the question why build your own web framework. Just like there are many worthy free bug trackers out there, there are many worthy frameworks too. I wonder whether your developers have their priorities straight? Who's doing the work that makes your company actual money?
OK, if they must build a framework, let it evolve organically from the process of building the actual software your business uses to make money.
Needing some highly specialised report, or the ability to tweak some feature in some allegedly unique way
As others have said, grab one of the many fine open source trackers and tweak it.
Believing that it isn't difficult to build a bug tracking system
Well, I wrote the first version of my BugTracker.NET in just a couple of weeks, starting with no prior C# knowledge. But now, 6 years and a couple thousand hours later, there's still a big list of undone feature requests, so it all depends on what you want a bug tracking system to do. How much email integration, source control integration, permissions, workflow, time tracking, schedule estimation, etc. A bug tracker can be a major, major application.
What arguments might you use to support buying an existing bug tracking system?
Don't need to buy.Too many good open source ones: Trac, Mantis_Bug_Tracker, my own BugTracker.NET, to name a few.
In particular, what features sound easy but turn out hard to implement, or are difficult and important but often overlooked?
If you are creating it just for yourselves, then you can take a lot of shortcuts, because you can hard-wire things. If you are building it for lots of different users, in lots of different scenarios, then it's the support for configurability that is hard. Configurable workflow, custom fields, and permissions.
I think two features that a good bug tracker must have, that both FogBugz and BugTracker.NET have, are 1) integration of both incoming and outgoing email, so that the entire conversation about a bug lives with the bug and not in a separate email thread, and 2) a utility for turning a screenshot into a bug post with a just a couple of clicks.
The most basic argument for me would be the time loss. I doubt it could be completed in less than a month or two. Why spend the time when there are soooo many good bug tracking systems available? Give me an example of a feature that you have to tweak and is not readily available.
I think a good bug tracking system has to reflect your development process. A very custom development process is inherently bad for a company/team. Most agile practices favor Scrum or these kinds of things, and most bug tracking systems are in line with such suggestions and methods. Don't get too bureaucratic about this.
A bug tracking system can be a great project to start junior developers on. It's a fairly simple system that you can use to train them in your coding conventions and so forth. Getting junior developers to build such a system is relatively cheap and they can make their mistakes on something a customer will not see.
If it's junk you can just throw it away but you can give them a feeling of there work already being important to the company if it is used. You can't put a cost on a junior developer being able to experience the full life cycle and all the opportunities for knowledge transfer that such a project will bring.
We have done this here. We wrote our first one over 10 years ago. We then upgraded it to use web services, more as a way to learn the technology. The main reason we did this originally was that we wanted a bug tracking system that also produced version history reports and a few other features that we could not find in commercial products.
We are now looking at bug tracking systems again and are seriously considering migrating to Mantis and using Mantis Connect to add additional custom features of our own. The amount of effort in rolling our own system is just too great.
I guess we should also be looking at FogBugz :-)
Most importantly, where will you submit the bugs for your bug tracker before it's finished?
But seriously. The tools already exist, there's no need to reinvent the wheel. Modifying tracking tools to add certain specific features is one thing (I've modified Trac before)... rewriting one is just silly.
The most important thing you can point out is that if all they want to do is add a couple of specialized reports, it doesn't require a ground-up solution. And besides, the LAST place "your homebrew solution" matters is for internal tools. Who cares what you're using internally if it's getting the job done as you need it?
Being a programmer working on an already critical (or least, important) task, should not let yourself deviate by trying to develop something that is already available in the market (open source or commercial).
You will now try to create a bug tracking system to keep track of the bug tracking system that you use to track bugs in your core development.
First:
1. Choose the platform your bug system would run on (Java, PHP, Windows, Linux etc.)
2. Try finding open source tools that are available (by open source, I mean both commercial and free tools) on the platform you chose
3. Spend minimum time to try to customize to your need. If possible, don't waste time in customising at all
For an enterprise development team, we started using JIRA. We wanted some extra reports, SSO login, etc. JIRA was capable of it, and we could extend it using the already available plugin. Since the code was given part of paid-support, we only spent minimal time on writing the custom plugin for login.
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.