在离岸开发中扩展敏捷开发

为了能够在离岸软件开发时仍然使用敏捷开发，你必须投入大量时间，保证即使在敏捷方法不能产生预期效果的情况下也可以实现敏捷实践。Xavier Rene-Corail 和 Ionuț Baloșin 认为，放弃敏捷开发并不是一个很好的选择，你需要通过回溯到敏捷原则，协作的方法来扩展敏捷方法，并让它们在分布式环境下也能有效运作。

Murex 的软件工程主管和敏捷推广人员 Xavier Rene-Corail，以及 Luxoft 的软件架构师和认证的 Scrum 教练 Ionuț Baloșin 在 XP Days Benelux 2016 大会上探讨了扩展敏捷的话题。InfoQ 以提问回答、总结和文章的形式报道了这次大会。

InfoQ 对话 Xavier Rene-Corail 和 Ionuț Baloșin，探讨了他们为什么决定采用敏捷方法，如何在分布式环境下运用敏捷实践，为什么人们选择在难以扩展敏捷方法的时候直接放弃敏捷方法，以及除了扩展敏捷实践还能做什么。InfoQ 还询问了他们如何在不同文化的企业中开展合作。

InfoQ：为什么你们决定采用敏捷方法？

Ionuț Baloșin：几年前，我参与了几个瀑布模型和迷你瀑布模型的项目。当时，遵照这个方法遇到的困难主要和采集利益相关者（特别是用户）的反馈相关，在大多数情况下，这些反馈会在大量开发完成之后，相当于是在非常晚的阶段才能采集到。此外，产品发布时间太晚，发布频率很低。所以我们决定做出一些改变，我们选择采用更敏捷、更实用的方法，帮助我们更快更好地对利益相关者的反馈做出回应。

Xavier Rene-Corail：在阅读《程序员修炼之道》（Hunt & Thomas）一书的时候，我第一次了解到了软件工艺，它回答了当时我对于编写整洁代码和测试的所有问题。然后按照作者的建议，我阅读了敏捷宣言。这些原则非常符合我当时的情况：尽管周围世界快节奏变化，但我们还在使用很长的开发周期。自此以后，每当碰到相同的情况，我都知道，我要使用敏捷方法。

InfoQ：能提供在分布式环境中使用敏捷方法的例子吗？

Rene-Corail：在 Murex 公司，产品部门分布在世界各地（巴黎、都柏林、贝鲁特）。我们会进行每日视频站会，我们在虚拟界面进行回顾，我们还会进行远程结对编程。在一个分布式团队中，大多数的敏捷方法都会面临到挑战。所以在开始时就会遇到同样的问题：“我们是单纯得放弃敏捷方法，还是投入一些精力，让它可以更加有效？”。我们经常面临这样的选择：“我们能在贝鲁特的开发人员不在场的情况下开站会吗？”或是“只为一个人做视频会议太浪费了，不是吗？”。做为 Scrum Master，你必须衡量敏捷实践的价值，并建议团队进行尝试，他们才会发现自己投入的额外精力是值得的。

Baloșin：灵活性的另外一个很好的例子是我们的组织方式。我们被分为各个团队，但如果当前团队不单独能完成项目的时候，我们可以随时邀请其他团队的成员加入我们。通过这样做可以加强各个团队之间的横向合作。

InfoQ：人们有时候会选择在遇到困难的时候直接放弃敏捷方法。能给一些例子吗？

Rene-Corail：恩，一个简单的例子就是“因为我们不在一个国家，所以我们不能做结对编程”。再举一些经典的例子，往往是规模相关的例子：“参与回顾的人太多了，我们取消这次回顾吧”，“太多人参加每日站会，这浪费了太多时间，因为不是每一个参与者都需要了解所有的信息”。

Baloșin：我们也遇到过因为不喜欢敏捷方法工作去做其他项目的人。这是一个极端的例子，所以并没有动摇我们使用敏捷方法的决定。相反，我们决定通过减少缺陷，让开发过程更加有效率的方式不断改进我们的敏捷实践。

我们也必须要考虑团队的可扩展性。关于这一点，我们会根据与会者和讨论的事件数重新组织会议，通过这样，可以避免一次又一次的 Scrum 和回顾会议（比如说每个团队都有自己的内部会议，之后还有所有团队代表集中在一起讨论内部会议得到的结论的回顾会议），后续会议等等。

InfoQ：在谈话中你们提到，你们不会放弃困难的敏捷实践，而决定扩展它。为什么会采用这种方法？

Baloșin：2008 年的金融危机对于软件开发市场产生了巨大的影响。考虑到经济、政治和技术的限制，我们没有许多选择，所以我们要获得更强大、更具有可扩展性的实践做法。要找到一种方法，可以支持分布式协作，提高我们的技术专长，并通过提供更灵活、更可预测的开发流程为技术创新腾出空间。

Rene-Corail：我们正在快速变化业务：Murex 正在为资本市场构建软件，在次贷危机之后，业务发生了很大的变化，越来越多的新规则迫在眉睫，还有很多新的技术挑战。在这种情况下，我们不可能回到瀑布模型。所以唯一可行的方法就是使用敏捷方法，即使是在看起来不能产生预期效果的情况下，比如分布式团队、离岸开发。

InfoQ：扩展敏捷方法有何成效？你从中学到了什么？

Rene-Corail：我发现它需要付出很多代价：我们有一个由三名开发人员组成的专门团队，负责支持这些适应实践（定制可视化管理、自动化测试框架扩展等等）的定制工具。我们甚至还需要举行比以前 SCRUM 更多的会议。然而，我学到了许多如何在不同困难的环境下协作工作的经验。最后，对我来说最重要的就是它非常有效！当你可以真正理解这些实践背后的原则时，你可以重塑它们、扩展它们来实现目标。比如说，我们曾经使用 BDD（行为驱动开发）。开发人员在实现故事之前先完成了 PO 给出的自动化验收测试。在离岸开发的情况下，PO 和开发人员的距离导致了它不能很好地运作：自动化验收测试不能百分之百反映 PO 预期的结果，所以即使它全部通过了，也不能满足业务需求。我们知道，实践的重要原则是保证 PO 和开发人员在编写用户故事的时候相互协作，而不仅仅是关于自动化测试的问题。由于距离的原因，我们缺少这种协作，所以我们调整了做法，PO 可以直接写自动化测试，允许 PO 和开发人员可以同时对同一对象工作和迭代，最终达成共识的业务需求，在转换的时候并不会损失任何东西。另一个例子是我们如何改进可视化管理实践的：经典的仪表板并没有提供有效的信息。所以过了一段时间后，就没有人再看仪表板了。因此我们回到了丰田生产系统的安东原则的基础，重新设计了自定义仪表板，当且仅当必须停止生产、解决问题的时候显示红色警报。

Baloșin：扩展敏捷并不容易，尤其是当碰到分布式开发或是团队成员来自不同文化环境的情况。在我看来，如果有需要创造意识和自我责任，如何与人沟通是最根本的。另外一个建议是制定健壮的工作协议，并和相关方共同创造和审查，而不是在一方不知情的情况下执行和强加条款，以便每个人能了解到他们的利益。

InfoQ：对于不同文化的公司之间需要进行合作，你们有什么建议？

Baloșin：首先，需要了解对方的文化以及对方的行为举止。其次，经常进行面对面会议，往来于各个企业也非常重要。当对于对方有一定了解之后，我们自然而然会倾向于以一种更加协作的方式一起工作。时区和文化的相似性也可能会带来其他挑战，但是如果前两个问题可以得到妥善的处理，这些挑战也能迎刃而解。

Rene-Corail：我想用一对舞伴来做比喻。首先，你必须自己训练，并接受由于和对方不熟悉所以在训练的开始可能会踩到对方的脚；通过逐步地练习，你就能开始适应这种情况。其次，你会被同步所迷惑；双方对于同样的情况会有相同的理解。可视化管理在其中起到了关键因素。最后，需要给对方留一些即兴创作的机会。如果一个团队（比如一个公司）决定一切，其他团队的创造性建议就不会被采纳。但如果领导可以给合作伙伴提供足够的创造空间，那么你们将共同创作出一些新的舞步，给出盛大的演出。

查看英文原文： Stretching Agile in Offshore Development