帮助敏捷团队交付价值的工具

Question

我的敏捷团队正在跟踪XP的实践，如对编程(J2EE)、每周45个工作小时、TDD等。您是否有任何开放源代码工具(开发、测试和构建集成)和模板(用户故事、烧毁图表)的建议，以使我的团队能够专注于业务价值交付。我是迭代经理，我们已经尝试过Hudson、Junit和Selenium。

Answer 1

在不重述敏捷组织的所有细节的情况下，我只想说，在我看来，对于成功的敏捷项目，最重要的是：

• 沟通--你可能在某个地方读到过，这是事实:敏捷是关于沟通的。这一切都是基于这样一个事实:用户经常更新(如果他们真的参与写故事，甚至参与设计验收测试，那就更好了)，但同时也给他们带来了频繁的虚弱(每次迭代后发布)，以及团队内部的交流:对对编程、每日站立、迭代计划会议、回顾会议等。我发现，一个宝贵的沟通工具就是故事板:尽管我们都在尝试在线版本，但我们总是回到物理板上。没有什么比能够手动处理卡片来移动它们，在你工作的时候挑选它们，以及在董事会周围举行站立会议，每个人都能看到人们在谈论什么，并决定一天该做什么。
• 在开发方面，最重要的是测试。以非常高的覆盖率为目标(理想情况下是100%，但最重要的是功能覆盖)，这是以安全高效的方式启用重构(在敏捷开发中至关重要)的唯一方法。理想的测试覆盖范围有三层测试：
  • 验收测试(理想情况下由用户编写)可能会使用JBehave或FITness这样的工具来赋予用自然语言编写故事的能力，同时动态地针对您的生产代码运行。因此，这些测试/故事也用作项目的文档。向用户和访问者提供视觉反馈非常有价值，并提醒您代码所做的一切。你正在做的所有故事都应该有至少一个测试，这样你就知道什么时候完成了这个故事:当验收测试(S)通过的时候。
  • 系统/集成测试:这些测试旨在确保项目中的所有组件(数据库、web服务器等)。可以很好地交互(这包括对db实体的CRUD测试)。
  • 单元测试，最好使用TDD (理想的BDD)来设计系统的细节。使用JUnit和模拟框架(我最喜欢的是JMock v2)

而且还

• 灵活性。不要像书中所写的那样盲目地遵循XP或Scrum。尝试不同的方法，每次几个星期，看看什么对你的团队有效，提高你的效率，不要害怕采取或放弃实践。这一切都是关于实用主义和你的团队的工作。例如，我一直在项目中，我们每天交换一对，每隔几天，甚至每隔几个小时。什么是对您最好的将取决于您的项目，您的用户，以及团队中的开发人员的速度。试试看，然后再做决定。当你觉得这样做有好处的时候，随时可以改变。使用回顾会议(每个月或几个月)来讨论哪些是有效的，哪些是无效的，并从每个人那里得到反馈。讨论团队如何看待各种实践是非常重要的。邀请一些用户，以及一些外部观察者。令人惊讶的是，一个对你的项目一无所知的人有时会对你可能遇到的问题做出贡献，并带来一个非常有趣的新观点。

还有几件事在过去很好地为我们服务：

• 始终维护一个非常详细的发布说明文档。理想情况下，您的用户可以参考(通过网站或wiki)，它显示了迭代后发布迭代的内容。尽可能频繁地链接到该文档。敏捷项目的发展非常迅速(如果您在每次迭代之后发布)，有时会让用户或相关系统感到困惑，因为他们不习惯这种发布的速度，并且期望“大爆炸”的发布频率较低。教育他们。
• 总是喜欢灵活的(基于电子表格的？)衡量和报告的方法:每天维护一张烧毁图表是非常好的，在停顿期间可以使用，以查看您在估计故事方面有多好(这不是衡量开发人员生产力的一个指标，在XP中，假设每个人都尽了最大努力)。

Answer 2

我们结合使用FogBugz和Stefan Rusek的优秀看板。FogBugz处理票证跟踪，烧毁图表(和更多)，最近他们增加了窑，这是一个集成的，托管的汞。

• http://www.fogbugz.com

另外，虽然我还没有尝试过，但我了解到一些我认识的聪明的Java人对JBehave感兴趣，这是一种面向Java的BDD框架。

• http://www.jbehave.org

我完全同意纪尧姆更彻底的回答。不过，我想补充一件事，尽管我有说显而易见的话的危险：

为了敏捷地工作，你必须写用户故事来表达你想要的功能。也许我真正的意思是，您不能只让人们编写旧的功能规范，并期望敏捷工作。用户故事确实是整件事情的基本组成部分。