评估个体和交互胜过评估流程和工具这一说法是有它背后的原因和意义的。流程和工具是对通用经验的提炼。随之而来的,对于一些不常见的经验,流程和工具就无法适应了。只有人可以。这就是个体和交互介入的时候了——搞清楚如何在不寻常的情况下取得进展。在面对新奇事物时,盲目遵循流程和工具,好比面对常规重复性事务时还坚持多样、辩论、谈判,和创造力一样是无意义的。

Kent Beck — 敏捷工具

如果决定将团队进行分布式管理,那你需要给他们配备一套工具,来让他们最大限度地提高沟通效率,这将需要一些时间来优化各团队之间的工作和沟通流程。

虽然工具并不是敏捷团队的首要关注重点,但是当你选择了一个正确的工具,它绝对可以让团队运作地更加高效、更加灵活,并且不会妨碍团队原本的工作流程。分布式的敏捷团队无法依靠便签纸,任务白板,或燃尽图来进行项目跟踪。他们需要一个强大的系统,以便在多个地点间共享这些条目和指标值。应选择一个能够支持跨地域分布式环境,并具有良好性能的工具。反之,不好的工具会降低团队对任务的处理速度,这会导致团队的挫败感。团队成员工作节奏也会变得怠慢,失去积极动力。

结论

分布式敏捷开发让企业进军新的全球市场,获得全球人才,同时又能降低成本成为可能。在做出决定之前,一定要清醒地认识到分布式团队的风险和回报。敏捷项目中成功的最关键因素之一,是团队成员之间必须保持高水平的沟通能力。如果你的团队是分布式的,他们必须在流程优化和实践改进上加倍的努力,以此来弥补在沟通上失去的优势。

要尽可能地把团队带到一起,尤其是在项目进行到关键节点的时候。用点时间来培养信任感并加强相互间的合作关系。敏捷开发是有一定难度的,需要很大的纪律性去遵循一些规则,对于分布式团队来说尤其如此。确保你有一个明确授权的人,来训练你的团队,并保证他们处于保持沟通状态的惯例。

敏捷团队是基于用户故事进行工作的,而非功能组件或实施任务。如果使用功能组件或团队纪律来组织分配团队工作的话,会很难把关注重点集中在真正重要的事情上。也就是,利益相关者及他们的需求。为分布式团队配备工具,将尽可能减少分布式过程中遇到的障碍,同时会让工作变得高效,有助于团队完成用户故事。整合的系统将从需求设计,开发及测试,为我们提供完整的可追溯性。最后,使用一个集成的wiki链接到任务和故事,来从各种各样的设计会议中即时转存成笔记。