题
计划非常困难。我们自然而然地估计自己的未来,许多认知偏见加剧了这个问题。小组计划甚至更难。不完整的信息,对情况的观点不一致以及沟通问题加剧了困难。
敏捷方法为组织团体计划提供了一个框架 - 所有人(用户故事)可见,将其分为较小的块(冲刺),并提供回顾性分析,以便您更好地计划。但是,找到支持这些实践的好工具很棘手。
您使用哪些软件工具来实现这些目标?您为什么使用该工具?成功有什么 你 有特定工具吗?
其他提示
我们使用Redmine-> http://www.redmine.org/
我们将所有开发人员与支持电话一起记录在那里,以便我们可以看到有多少时间可以自由地分配给我们最新的开发。这很有用,因为它与我们的电子邮件系统和我们的版本控制系统(在我们的情况下,但与他人一起使用)都很好地联系在一起。
易于开箱即用(用Ruby编写,将在大多数小型服务器上运行),并带有一些易于安装和使用的功能相当强大的插件。
可以回答吗 没有任何?
您似乎暗示了成功的敏捷计划所需的软件工具。我不同意。如果您的团队正确使用Scrum或XP(“通过书”),则不必使用任何软件工具进行计划。
在许多情况下,将软件工具添加到敏捷过程中只是一种避免不得不处理与沟通不良或信任有关的实际潜在问题的方法。这些问题最好通过其他方式解决。
我的建议是不用任何数字工具开始,只有以后将它们添加 真的 了解为什么您需要它们。
(分布式团队是一个特殊情况)
我将从Jira开始。 Jira是一个出色的错误跟踪工具。 GreenHopper是一个附加组件,使团队能够开始与敏捷合作。由于它不是从头开始设计为敏捷工具的,因此某些过程感到尴尬。该工具也很耗时且难以使用。但是,它是非常可定制的。通常,感觉就像是您必须将敏捷流程塞入的工具。
拉力赛是从头开始设计的,以成为敏捷工具,并显示出来。它遵循许多敏捷过程非常好,并且可以补充该过程。我在一个极其敏捷的组织中使用了此工具,它使我们能够跟踪涉及多个敏捷团队的跨团队依赖性和复杂的项目。跨团队协调是其他工具所努力的事情,但是Rally做得很好。此外,Rally拥有出色的基于Web服务的API。它使我的团队可以使用Rally作为我们的后端编写一些自定义软件,并生成一些自定义报告。
我们使用TFS来源控制和工作项跟踪(不幸的是),我使用 Telerik工作项目经理 为了帮助我记录冲刺计划,并保持任务板的同步。如果您被迫使用TFS,那么Telerik会使痛苦减轻。
我们使用一个名为的问题跟踪器 合身 (我像外包承包商一样为这家公司工作,所以我可以选择使用什么)。相比之下,Fogbugz很昂贵。它的占地面积很小,基于网络,便宜,并且可以做通常的事情。我看了Redmine,这是一个很棒的包裹,但管理层对仍在流血边缘的开源软件包感到不安。
对于像问题跟踪器这样的工具,我不想将其维护或升级或自定义:我只是想让它立即工作并保持这种状态。