I'll relate my experience, hoping it will be helpful.
We started piloting Scrum using cards on a wall. We figured we would switch to a tool once we started doing it for real. We set up our defect tracker (Redmine) with User Story and Tasks, and have a way to create a burndown in each project. What we found, however, is that you don't really get the transparency of a physical information radiator. People walk by the card wall and can see the team progress. Very few will check the web site as often as they inspect the card wall. So currently, we do the card wall for the current Sprint and track the Sprint in Redmine, which gives us historical information.
As we scaled up to more teams than we have wall space for, we realized we're going to need a tool that can work like a card wall and be a 'real' agile tracker. So we looked at several tools, and our short list included Version One, Rally, and Mingle. Either of these products might be best for you, but ultimately we chose Mingle for various reasons.
The one thing I worry about is the loss of the card walls. It's hard to explain the transformative value that these public information radiators have had. The teams get lots of visibility from the Product Owners as well as management and other stakeholders. I worry that the visibility will be lost if we switch to using solely the tool. I may have to build dashboards that go up on wall-mounted monitors, acting as a high-tech version of the card walls. One thing we did do was procure some touchscreen whiteboards that will allow teams in standups to move virtual cards in a familiar way, using the tool's drag-and-drop card wall interface. I'm hoping this will allow us to retain the team communication and interaction benefits we've seen when gathered around a card wall.
We are using PivotalTracker (http://pivotaltracker.com) in our projects. It is a lightweight and easy to use tool. It works in the cloud, so creating an account and setting up a project is a matter of minutes. User story and bug entering is quite easy. The tool supports a standard workflow of tasks consisting of Not Started, Started, Finished, Delivered, Accepted and Rejected states.
I haven't tried fogbugz yet but I used JIRA, Greenhopper and VersionOne before PivotalTracker. The downside of all these tools against PivotalTracker is that using them brings you too much overhead. You have to setup and maintain them. You have to configure them. And because they are harder to use, they require more time for daily usage. I have seen that developers hesitate to use these tools because they create too much friction. IMO PivotalTracker is the best tool in this respect.
The downside of PivotalTracker is that it gives only a few configuration options. It doesn't allow you to customize workflows. It doesn't have much user authorization options. But in our case it suits very good to our needs.
This might be a non-answer to some extent, but I hope it will still be informative and add value.
I've been on multiple teams using various tools including physical boards and Greenhopper. Other agile teams in my department have used and evaluated various other options. If you are talking about finding the most efficient way to manage the team within a sprint (as opposed to release planning, backlog grooming, etc) I've come to the following conclusion: Nothing is going to be a great fit unless you wrote the tool yourself or use a speadsheet. Yes, a spreadsheet. It's the most flexible option I've come across. We use a fancy one with burndown charts and such, but it works great.
Any tool you find now which may be a perfect fit will eventually end up not doing something you want. Here is an example from my own recent experience:
We were working to bring down the length of time it takes to report status during out daily scrum meeting. The challenge was that developers have a tendency to go into a detailed explanation of issues they've encountered while working on a task. We try to postpone those discussions until after the scrum meeting. It was hard to do until we started simply highlighting any items in the spreadsheet we need to discuss further. This let us move on with the meeting but not lose track of issues that need to be discussed. It was effortless to introduce this into our process precisely because we were using a flexible tool like a spreadsheet. The tool didn't stand in the way of improving our process.
As for defect tacking, most of the teams in my department use JIRA.
发布评论
评论（3）
我把我的经历说一下，希望对大家有帮助。
我们开始使用墙上的卡片来试点 Scrum。我们认为，一旦我们真正开始这样做，我们就会转向使用工具。我们使用用户故事和任务设置了缺陷跟踪器 (Redmine)，并有一种方法可以在每个项目。然而，我们发现你并没有真正获得物理信息辐射器的透明度。人们走过卡墙，可以看到团队的进展。很少有人会像检查卡片墙那样频繁地检查网站。因此，目前，我们为当前 Sprint 制作卡片墙，并在 Redmine 中跟踪 Sprint，这为我们提供了历史信息。
随着我们扩展到的团队数量超出了墙壁空间的容纳范围，我们意识到我们将需要一种可以像卡片墙一样工作并成为“真正的”敏捷跟踪器的工具。因此，我们研究了几种工具，我们的简短列表包括版本一、集会，以及 混在一起。这些产品中的任何一个可能最适合您，但最终我们出于各种原因选择了 Mingle。
我担心的一件事是卡墙的丢失。很难解释这些公共信息辐射器所具有的变革价值。团队从产品负责人、管理层和其他利益相关者那里获得了大量的可见性。我担心如果我们转而仅使用该工具，可见性将会丢失。我可能必须构建安装在壁挂式显示器上的仪表板，充当卡片墙的高科技版本。我们所做的一件事是购买一些触摸屏白板，使站立会议的团队能够使用该工具的拖放卡墙界面以熟悉的方式移动虚拟卡。我希望这能让我们保留聚集在卡片墙周围时所看到的团队沟通和互动的好处。
不管怎样，祝你的任务顺利！
I'll relate my experience, hoping it will be helpful.
We started piloting Scrum using cards on a wall. We figured we would switch to a tool once we started doing it for real. We set up our defect tracker (Redmine) with User Story and Tasks, and have a way to create a burndown in each project. What we found, however, is that you don't really get the transparency of a physical information radiator. People walk by the card wall and can see the team progress. Very few will check the web site as often as they inspect the card wall. So currently, we do the card wall for the current Sprint and track the Sprint in Redmine, which gives us historical information.
As we scaled up to more teams than we have wall space for, we realized we're going to need a tool that can work like a card wall and be a 'real' agile tracker. So we looked at several tools, and our short list included Version One, Rally, and Mingle. Either of these products might be best for you, but ultimately we chose Mingle for various reasons.
The one thing I worry about is the loss of the card walls. It's hard to explain the transformative value that these public information radiators have had. The teams get lots of visibility from the Product Owners as well as management and other stakeholders. I worry that the visibility will be lost if we switch to using solely the tool. I may have to build dashboards that go up on wall-mounted monitors, acting as a high-tech version of the card walls. One thing we did do was procure some touchscreen whiteboards that will allow teams in standups to move virtual cards in a familiar way, using the tool's drag-and-drop card wall interface. I'm hoping this will allow us to retain the team communication and interaction benefits we've seen when gathered around a card wall.
Anyway, good luck with your quest!
我们在项目中使用 PivotalTracker (http://pivotaltracker.com)。它是一个轻量级且易于使用的工具。它在云端运行，因此创建帐户和设置项目只需几分钟。用户故事和错误输入非常容易。该工具支持标准任务工作流程，包括“未开始”、“已开始”、“已完成”、“已交付”、“已接受”和“已拒绝”状态。
我还没有尝试过fogbugz，但在PivotalTracker 之前我使用过JIRA、Greenhopper 和VersionOne。所有这些针对 PivotalTracker 的工具的缺点是使用它们会给您带来太多的开销。您必须设置和维护它们。您必须配置它们。而且由于它们更难使用，因此日常使用需要更多时间。我发现开发人员不愿意使用这些工具，因为它们会产生太多摩擦。 IMO PivotalTracker 是这方面最好的工具。
PivotalTracker 的缺点是它只提供了几个配置选项。它不允许您自定义工作流程。它没有太多的用户授权选项。但就我们而言，它非常适合我们的需求。
We are using PivotalTracker (http://pivotaltracker.com) in our projects. It is a lightweight and easy to use tool. It works in the cloud, so creating an account and setting up a project is a matter of minutes. User story and bug entering is quite easy. The tool supports a standard workflow of tasks consisting of Not Started, Started, Finished, Delivered, Accepted and Rejected states.
I haven't tried fogbugz yet but I used JIRA, Greenhopper and VersionOne before PivotalTracker. The downside of all these tools against PivotalTracker is that using them brings you too much overhead. You have to setup and maintain them. You have to configure them. And because they are harder to use, they require more time for daily usage. I have seen that developers hesitate to use these tools because they create too much friction. IMO PivotalTracker is the best tool in this respect.
The downside of PivotalTracker is that it gives only a few configuration options. It doesn't allow you to customize workflows. It doesn't have much user authorization options. But in our case it suits very good to our needs.
这在某种程度上可能不是答案，但我希望它仍然能提供信息并增加价值。
我曾在多个团队中使用过各种工具，包括物理板和 Greenhopper。我部门的其他敏捷团队已经使用并评估了各种其他选项。如果您正在谈论寻找在冲刺中管理团队的最有效方法（而不是发布计划、待办事项整理等），我得出以下结论：
除非您自己编写该工具或使用电子表格，否则没有什么是非常适合的。是的，电子表格。这是我遇到过的最灵活的选择。我们使用带有燃尽图等的精美图表，但效果很好。
您现在找到的任何可能非常适合的工具最终都不会做您想要的事情。这是我自己最近经历的一个例子：
我们正在努力缩短每日 scrum 会议期间报告状态所需的时间。挑战在于，开发人员倾向于详细解释他们在执行任务时遇到的问题。我们尝试将这些讨论推迟到 Scrum 会议之后。在我们开始简单地突出显示电子表格中需要进一步讨论的任何项目之前，这很难做到。这让我们可以继续会议，但不会忘记需要讨论的问题。正是因为我们使用了电子表格等灵活的工具，所以毫不费力地将其引入我们的流程中。该工具并没有妨碍我们改进流程。
至于缺陷修复，我部门的大多数团队都使用 JIRA。
This might be a non-answer to some extent, but I hope it will still be informative and add value.
I've been on multiple teams using various tools including physical boards and Greenhopper. Other agile teams in my department have used and evaluated various other options. If you are talking about finding the most efficient way to manage the team within a sprint (as opposed to release planning, backlog grooming, etc) I've come to the following conclusion:
Nothing is going to be a great fit unless you wrote the tool yourself or use a speadsheet. Yes, a spreadsheet. It's the most flexible option I've come across. We use a fancy one with burndown charts and such, but it works great.
Any tool you find now which may be a perfect fit will eventually end up not doing something you want. Here is an example from my own recent experience:
We were working to bring down the length of time it takes to report status during out daily scrum meeting. The challenge was that developers have a tendency to go into a detailed explanation of issues they've encountered while working on a task. We try to postpone those discussions until after the scrum meeting. It was hard to do until we started simply highlighting any items in the spreadsheet we need to discuss further. This let us move on with the meeting but not lose track of issues that need to be discussed. It was effortless to introduce this into our process precisely because we were using a flexible tool like a spreadsheet. The tool didn't stand in the way of improving our process.
As for defect tacking, most of the teams in my department use JIRA.