1) The bugtracker screenshots shows data that end-users can relate to. If you see a screenshot with states, buttons and text that is similar to what you need, it feels comfortable. There are fewer things to check, than if the screenshot doesn't show anything that relates to what you want the software to do.
2) Integration with your existing tools. Things are much easier when things are integrated, right?
However, sometimes we need to make a choice, between what is right to do, and what is easy to do. If you can save 100 mandays by investing 10 mandays, it becomes a no-brainer. Well, if you can convince yourself, that the most tempting screenshot does not represent the right solution. It also requires that you know the alternatives, and most software developers never heard about process management tools like Joget or Bonita.
We have a list of possible tools to choose between, but we have not decided, yet. If you know good process management and production planning tools that make Bugzilla, Jira, Mantis, Team Foundation Server and Redmine look old, leave a comment.
11 comments:
Recently we choose FogBuz + Kiln from http://www.fogcreek.com/. Why ? Because we can test it freely for a lng time and because it's Mercurial compatible.
Good luck. You will spend more time trying to build process than building applications. That's why "limited scope" applications are often good. You don't spend time trying to adapt them to your workflow, you just use them "as is".
Anyway "defect tracking" is not a "generic" process and requires itself its own workflod. "Software defect tracking" is a category on its own. Well designed specialized tools often help more than more generic ones. Believe me, you will end up rebuilding Bugzilla or Mantis in a generic process management tool.
LDS: Our company and QA demands have grown quite a bit, and now have requirements similar to many large companies.
Any company where the management is involved in risk assessment or quality in software development, needs to have many strict procedures. You can either enforce them using an MSWord-based library of quality manuals, that every software developer needs to know by heart and make them all swear to do everything by the book, or you can require them to sign off somewhere every time an issue is forwarded to the next step. You also need mechanisms to elevate special circumstances to review meetings. Many bugtrackers fall short of these requirements, and therefore, the workflow is often handled outside the bugtrackers.
Here is a Youtube video that might inspire you about the complexity of automating processes:
http://www.youtube.com/watch?v=LuS7cFkiZ7o
To me, it does not seem overkill, especially compared to writing and maintaining a lot of manuals in Word. If you want to keep your company dynamic and prepared for growth, the costs of re-educating your software development team every time you change your quality manual, must also be compared to the costs of changing a process in an automated tool.
I was not saying process management is bad. I was just saying specialized tools are not bad also.
Generic tools developed to handle everthing from needles to Space Shuttles usually are so generic that companies spend a lot of time and money (especially when specialized consultants are hired) to custom tailor them that I wonder if they are written to bring more revenues that way (already seen it too many times).
Before reinventing the wheel in a generic tool I prefer to look for a specialized one. Preferably one that is designed enough well to be able to talk to other systems, but very good at handling its own tasks without extensive customizations. I've seen enough "jack of all trades and master of none" systems.
You can fasten a screw with a piece of metal, but usually the proper screwdriver is better.
@Unknown: I have looked at FogBugz. It definitely beats several other bugtracker tools, but it definitely seems to have most focus on bugfixing and less on developing new stuff. We don't mind to pay money for the software, or for help maintaining it, as long as it can document to us in an overview, that feature XYZ is blocked because 3 issues for that feature didn't get a specs approval that is required before programmers start touching the issue.
Maybe you should also check out SpiraTeam. At work we recently switched to it (from FogBugz).
Personally, I'm not a.huge fan of this type of UI, but all in all I think SpiraTeam ticks many of your boxes.
Bummer that i cannot edit comments.. Here's a link to the featurelist of spirateam: http://www.inflectra.com/SpiraTeam/Features.aspx
Well, at work, we have evaluated several tools, fogbugz included, ending up with AxoSoft Ontime.
It covers well defects management, as well as agile-like sw dev projects and related tasks, functionality and documentation...
With latest 11.xx edition there is 2-users free edition in case you need evaluation first...
Cheers, B.
We need to have 20-30 users on this system, and growing - but I guess 2 users is good enough for testing :-)
After reviewing a lot of tools, I have come to the conclusion, that our tool will need to have:
* Users and user groups
* Issues with full read/only log of all changes and configurable parameters
* Most configurable issue parameters may not be freely editable, but only via custom workflow forms, that are not available for everybody but ensure that the process follows the rules. Access to workflow forms is based on user groups.
* Configurable overviews are a must - this includes configuring what fields to show and what records to show
* A bundle-table that bundles issues is nice to have but not required, if only the system conforms with the customizability requirements.
A few new requirements were added:
* Full version control of workflows is a mandatory requirement
* If the tool has been validated by the vendor, we don't have to do that.
Post a Comment