敏捷开发&远程团队——你应该知道的六条生产力秘诀

几年前，定期和软件开发人员会谈是我重点关注的方面之一。然而，通过几次会谈，我发现，冗长的会谈并不是他们擅长的。那只会打乱他们编码的心境。但是，我也知道，我必须与内部的技术团队，这些开发人员保持同步：那是工作得以顺利开展的粘合剂。不久，我了解到了敏捷风格的会谈，我们开始在Google Hangout中召开虚拟会议，内容涵盖亮点、工作量分解、保持较好的责任感。

随着世界各地的组织都在尝试精益转型，现如今的分布式敏捷工作环境肯定在增加。敏捷开发和远程工程团队——两种不同的精益方法——在当今时代互相补充，所以，有理由把这两种方法结合在一起应对软件项目，让企业可以从全球雇用员工并以简洁的方式构建代码块。

你可能会问，这会带来什么？这会带来：

更快的生产周期
并行编码
持续部署的能力，而且障碍更少
降低职业倦怠的可能性

敏捷环境背后的思想是让集群团队或内部团队更有生产力。敏捷文化运转的基础是团队协作原则、持续学习&规划以及无障碍互动。随着企业发展到全球，扩展到不同的地区，团队变得越来越分散，来自竞争力较弱的市场的人才夜以继日地做着项目。使用敏捷实现远程团队之间的高效协作，作为新时代的其中一种开发模型，这已被证明是非常有效的。然而，敏捷开发和远程团队有时候会产生摩擦，变成不同类型的挑战，诸如：

与团队成员建立良好的关系；
跨时区协调；
在两个团队短暂同时在线期间组织会议；
在不同的开发文化之间协作。

为了减轻这种矛盾的状况，组织需要一种混合的敏捷开发方法，专门用于简化和支撑远程软件开发。这种方法可以帮助远程团队分清事情的优先级并变得更有生产力，而不会引入其他的矛盾。

面向分布式开发团队的六条生产力秘诀

1. 有意义的自动化

持续审核过程是工作中实现高生产力的关键。务必要根据情况审核你的过程，旨在找到一种解决方案，让过程尽可能地高效、简洁。投资一种综合应用程序，减少不同的过程所需要使用的不同应用程序，以便可以更快、更高效地执行任务，确保过程不重复。

当项目时间比较长，或者需要管理远程团队时，创建一种持续集成的文化就特别有价值。

自动化可以从多个方面节省时间：它可以快速跟踪整个交付过程并报告这个过程，赋予参与者责任感，它百分之百可用，这全都要感谢最新的技术进步。例如，Jira就是团队规划并构建优秀产品的一个跟踪器选项。许多团队选用Jira捕获并组织问题、分配工作及跟踪团队活动。无论团队在哪，它都能完成任务。

例：让我们看下德国汽车巨头奥迪在日常工作中是如何使用Jira的。

奥迪在全世界雇用了数以千计的工程师、设计师、软件开发人员和QA团队。但是，虽然奥迪的办公室遍布全球，它的研发中心（R&D）都在德国，雇用了6000多名员工。2007年，他们开始用Jira跟踪问题，用Confluence管理知识，如今，它们被用来支持所有的团队和项目——不管哪个部门。在路试场所，测试人员在试车过程中会把软件缺陷记录进Jira中。除了跟踪外，团队使用Confluence存储文档、部门协议、会议记录、政策法规，帮助企业保持高效、透明。

工具建议：

使用Google Drive作为文档库，进行文件共享
使用版本控制监控和推送代码（Bamboo、BitBucket）
使用Slack进行实时、有感染力的谈话——快速评审、修改、决策

2. 简化敏捷过程——把时间花在实际的工作上

成功的秘诀是简单，真的——少说，多做。许多敏捷团队都执迷于开发模型本身。敏捷模型是为了提高生产力，如果我们不能灵活的使用敏捷提升团队的优势，那么敏捷就是失败的。

例如，对于远程团队，距离会导致他们坚持到底，避免改善解决方案，以防出现挑战或障碍。这对整个团队而言是反生产力的。定期调度，每周或每天，这有助于保持团队对所分得的工作的责任感。让团队成员参与到决策，尽可能地确保他们的参与度与他们实现那个决策的占比相匹配。

组织会议的时候，确保那个时间点有利于相应的时区，并且要根据整个过程中员工的参与度优化会议时间。你还可以考虑轮转会议时间，不要让特定时区的团队总是承担调整到其他时区的责任。跟踪一下，看看这些会议对于生产力的影响，并相应地减少或增加频率。一旦项目结束，务必要在团队之间共享最终成果，突出每个团队的参与。

例：在采用新的业务实践方面，Amazon一直是潮流的引领者，其中一个值得一提的举措是，他们大范围地采用Scrum。这对公司来说非常有效，它促成了去中心化的决策灵活性，使得团队可以用一种简洁、非官僚的方式创建、交付、运营高质量的软件。在Amazon，Scrum实现是自下而上的，这让他们的团队可以在发现需求时直接响应，消除了障碍。

3. 日常的力量——创建一种仪式，把它变成习惯

本质上讲，敏捷允许团队随着原型的发布、评估针对短期规划开发项目的细节和活动，但长期活动更具普遍性。

敏捷是指快速执行、快速发布。没什么完美。这是对的。因此，你每天做什么决定了你会交付什么。完成每天的目标或者迷你可交付成果对团队而言是一个巨大的激励促进，会让团队觉得离最终目标更近了。

工具建议：

Basecamp 3：Basecamp一直是我们同外部客户通信的工具。新版本还多了一点功能，而不再只是一个消息发送渠道——Basecamp 3提供了“待办”特性，可以帮助团队轻松地自动化日常任务。

4. 一切都关乎冲刺

有调度很好，但不要让会议占用团队的工作时间。

简洁明了是最最重要的，因此，冲刺务必要短，这会带来更高的生产力，要让团队能够快速发布。毕竟，这不只关乎发布和生产力，这关乎让团队变得真正的敏捷、永不停滞的理念。冲刺更短，规划就更现实，因为那是基于当前的情况。

工具建议：

把类似Jira这样的工具和Slack集成，让你可以把Jira里的重要事件通知自动推送到Slack频道。这使得团队成员实时更新冲刺进展，而不必因为等待响应而陷入停滞。

5. 制定一个连接各团队的项目路线图

罗马不是一天建成的——需要时间、精力和大量的集思广益！类似地，你需要制定一个项目路线图，因为那是你要和敏捷团队传达的行动计划——不管他们在哪——让他们知道产品或解决方案如何随着时间演化。

分布式团队意味着时段不同，这让计划变成了一项挑战，因为你无法像了解身边的团队那样了解一个远程团队。在这种情况下，类似滚动计划这样的方法可能更有效，对于时间上比较近的事情就详细地计划，而时间上比较远的事情就在较高的层面上计划。这样一份在多个敏捷团队之间共享的计划将为团队的日常工作提供一个关键的上下文，并对竞争环境的变化作出响应。你所要做的是把它分解到月、周、天。定义每天的可交付物，因为你每天交付的东西对于最终目标的实现很重要。

例：一个敏捷工作生态系统可以推动一种分布式团队文化，就像现如今的几个行业巨头所证实的那样。以微软为例，他们甚至已经把敏捷模型成功地运用在企业层面上。

但是，在开始的时候，它也有自己的瓶颈，确实对质量和过程产生了不利的影响。不过，他们使用类似SAFe这样的第三方框架解决了在把敏捷运用到企业级项目上时产生的问题。他们开始时先制定规划和架构，然后构建一个特性，最后解决代码。他们使用Telemetry跟踪系统运行，并自动测试。借助敏捷软件开发，微软成功地把发布周期从数月缩减到数周，更快地响应了客户的需求。

6. 度量、改变、发布

不能只部署，还要度量。往往，最不经意的事情会发生。当那样的事情发生时，你需要改变策略、行为等。成为敏捷团队意味着你应该能够做任何需要做的事。这会带来变革。根据数据和度量指标制定下一步的路线图。

对于敏捷和精益过程，基本指标有提前期、循环时间、团队速度、打开/关闭比。这些指标可以辅助规划，帮助制定合理的过程改善决策。如果这些参数中的任何一个超出了预期范围或者趋势令人担忧，那么不要假设原因。和团队一起，公开把它找出来，一起做决定解决那个问题。

小结

敏捷团队的概念慢慢的扩展成了企业敏捷性。敏捷是一个很棒的软件开发模型，因为它聚焦于自管理团队、自治以及可视化到按优先级排序的待办事项列表。敏捷扩展的过程似乎也很简单：如果它在一个部门里有效，那么你就可以把它运用到所有现有的团队和部门，从而构建一个敏捷企业生态系统。请记住，世界很小，即使是对分布式团队也是如此——而大量的通信平台，如Slack、Jira、Skype，让这个世界变得更小了。促成同样密切的沟通是保证分布式团队敏捷过程的关键所在。

本文转载自infoq网站文章《敏捷开发&远程团队——你应该知道的六条生产力秘诀》，个别词有调整，版权归infoq所有，如需转载请联系infoq，原文链接：http://www.infoq.com/cn/articles/remote-team-productivity-hacks