敏捷外包的14条原则

文／Vikas Hazrati　译／金欣亮

虽然软件项目的外包趋势已经是一个不争的事实，但是还是有很多项目由于错误的外包而失败了。抛开诸多优势不谈，软件外包确实带来了额外的复杂性、风险以及消耗。本文将基于实际项目经验以及丰田公司的制造过程，讨论如何把外包变成一种成功的模式，我们将这种方法论称为 “精益敏捷外包”。

我们的目标是利用当地的广阔人力资源，更加高效、迅速地交付软件。鉴于Scrum和丰田模式在开发新产品上的成功表现，我们决定采用它们来进行外包项目管理。丰田原则可以很好地被应用到任何软件开发项目中。我们将在下面讨论丰田模式，以及如何使用这些原则让我们的外包过程“精益”起来。 这种保留了Scrum和丰田模式的工作方法，帮助我们每天都在提高。

采用此方法开发的项目，是一个中心社会保障机构的批处理系统。系统的工作流程是从税务部门获取老板和雇员的数据，校验这些数据，然后生成某人某一个阶段的收入申报资料。系统每个月要处理1600万条数据记录，每秒钟大约50条数据。

原则1：制定一个长远的价值观，并且坚持下去

我们开始外包项目的时候，心中存在一个信念：我们不仅仅是为了这一个外包项目而工作，而是心中有一个长远目标：通过努力，让我们成为最好的敏捷公司，并且拥有稳定的、可重用的外包模式。这种模式可以使得整个软件行业受益。我们不会采取任何危及项目质量的捷径。 我们会积极创新，改进工作方式，提高整个行业的敏捷外包项目成功率。

原则2：创建连续的工作流程，使问题浮出水面

我们决定全面采纳敏捷实践，并且不遵从任何以计划驱动的方法论。然而，没有计划很容易迷失方向，因此频繁的交流和持续集成就变得至关重要。我们定期派遣专员进行跨越地域的旅行，让业务知识和上下文不受地域的限制，通过电话和网络进行指导，并建立和加强信任关系。 沟通不是问题，因为我们的通讯工具时刻在线，拿起麦克风就可以跟远方的团队交流了。 对于多个地点的开发，我们都采用统一的代码库并进行持续集成。这样问题很快就能浮出表面，并很快得到妥善的解决。

原则3：使用“拉”模式来避免过度生产

依照上面的原则，我们决定采用利益相关者来“拉”的模式，而不是让团队去“推”。毕竟我们的意图是编写具有商业价值的代码，而不是为了完善代码库。如果“拉力”不是很强，我们就减少迭代的大小，或者利用剩余的时间进行重构，以提升开发过程和交付的质量，确保我们高质量地满足客户的需求。

原则4：平准化（heijunka）

丰田提出要减少资源的浪费（muda）、人员的过劳（muri）和分工的不均（mura）。 在外包项目中，它们的表现形式为：不必要的功能、过度的需求、在客户和团队间额外的抽象层；寻找不相关的信息；测试没能找出缺陷；与客户低效率的沟通。我们要谨记这些，它们是外包项目中最大的浪费。

在实际项目中，为了去除浪费，我们只开发本次迭代的用户故事，使用的故事卡片上也仅仅记录了足够开发使用的信息；我们根据用户故事进行编程，为了澄清业务细节，即使是离岸团队也可以直接跟客户取得联系；不管是开发人员测试还是客户测试，我们都秉承测试优先的做法。为了确保工作的平准化，我们总是根据团队的速度来衡量工作，并确保完成的用户故事数量没有不平衡的趋势。在软件项目中，使团队成员精疲力竭是最有害的行为！团队的速度决定了团队的工作量以及每个人的工作内容。

原则5：建立停下来解决问题的文化（自动化）

我们文化的提倡：如果产生了影响交付质量的问题，团队就要停下手中其他的工作并解决这些问题。

如果客户处的离岸团队觉得沟通效率低下，那么我们就用专门的机器来安装skype，并保持一直在线。使用skype提供的语音和在线视频聊天功能来相互沟通。一旦团队觉得sprint评估效率太低，没有达到当初预期的目标，那么我们会中止评估，进行头脑风暴，讨论如何才能做的更好，并按照一个既定的日程来指导我们减少在代码审查上花费的时间。 如果在持续集成或者性能测试环境设置上有问题，那么我们就要停下来修复它们，然后再进行其他用户故事的开发。 如果我们完成了很多用户故事，但是功能测试人员没有来得及进行测试，那么我们就等所有已开发的用户故事得到测试团队认可，然后再来开发新的用户故事。

所有这些这不仅仅是对策，也是预防措施。

原则6：标准化过程

标准化是支撑持续改进、雇员授权、规章制度和过程的基础，同时是支持组织学习的架构。我们创建的标准流程包括：使用TDD的开发、问题跟踪和解决、构建和测试等等。这并不是说这些流程都是一成不变的，它们一样是灵活且敏捷的。这些标准可以确保我们拥有稳定的平台，而且这个平台可以被团队不断完善。

原则7：使用可视化的管理来避免隐藏的问题

我们的格言是：每一件事情对团队成员都应该是可视的，当然对客户也是如此。

我们在Jira里面为客户现场和离岸团队创建了公用的产品功能清单，公用的燃尽图和问题日志。客户可以使用它来了解产品的问题，甚至查看我们每天的详细状态。使用Cruise Control可以让我们方便地了解构建的状态。每次构建结束，一个小兔子玩具会报告构建的成功与否。

墙和白板可以向客户展示足够的信息。他们可以走到墙或者白板面前，10分钟的时间，他们就能获得足够的信息。

我们还在wiki上创建了一个虚拟的团队公告板，把所有的可视化信息都保存进去。之后把有用的打印出来，贴到团队的墙上。

原则8：采用适合团队成员和过程的技术

真正的精益项目有2个关键特性：其一，它传递给开发人员最大数量的任务和职责，从而生产出有业务价值的产品。其二，它有着一个缺陷跟踪流程，保证在缺陷发生时立即处理。

一个敏捷团队最重要的资产是团队成员，我们应该让团队成员采用最适合的技术而不是听从某些技术鼓吹者的最佳实践。例如，我们把整个表现逻辑从Struts迁移到Spring MVC，是因为后者在当前的背景下更加实用，并且这个迁移的决定是由整个团队共同提出的。当团队拥有自主权的时候，也是他们能够做出最好的决定和承诺的时候。自组织的团队知道如何采用适合的技术和流程来适应每一个成员。

原则9：从团队内部发掘领导者

人比体制更重要已经是广为人知的概念。 我们致力于从团队内部来提拔外包项目的领导者。我们会让客户现场或者离岸团队中的一部分人去参加Scrum master培训，而不是从其他地方请来Scrum master。毋庸置疑，这些人肯定是最了解团队的人。

原则10：发掘杰出的团队成员

无障碍的沟通、高效的团队协作、形式追随功能的团队、良好的收入、顶级的工具、舒适的工作环境、劳逸结合的生活、持续的进步、岗位的轮换。 所有的这些在正确的精神指导下，将会创建明星团队。

对于一个高效的跨地区团队而言，健康的交流是核心。为此，我们在项目早期会有很多探访，目的是创建良好的关系，然后用定期的探访来维持这种关系。

提出问题、谈论困难、担心无法按期限完成工作，或者对于来自上级的指令给出不同的解决方法。人们经常因为这些行为遭到责难。使团队变得更加积极主动是一场艰苦的战斗，需要花费很多的时间。因此我们鼓励多问问题。 一旦人们意识到他们有自由，同时也有责任来做决定的时候，他们会进一步做出贡献，并因此成为杰出的团队成员。

原则11：与合作伙伴和供应商建立长期的合作关系

公平和互相尊重的商业关系，是和合作伙伴和供应商长期合作的关键。 我们根据这个精神对客户公开wiki和Jira，同时也对负责该项目其他模块的软件商公开。 这可以使我们清楚了解谁在做什么，并且能够同利益相关者和供应商一起来制定明确的期望。 这样做的好处是：我们建立了信任关系，保持了透明度，而且没有隐瞒任何事情。

这不仅仅提升了我们外包的可信度，从长远来看，能为软件行业提供一个扩大合作伙伴的成功实践，对软件行业来说也是有积极帮助的。通过燃尽图和Sprint迭代的记录，我们与合作伙伴互相了解和学习。

原则12：身体力行

亲临现场是了解真实的情况的最佳方式。所以我们团队中没有只说空话的设计师和架构师。无论他曾经担任过什么其他的角色，每个人都要写代码，这没什么可商量的。 这有助于我们条理分明地为自己和他人分派任务，根据实际的资料请教专家，分析并理解当前的形势以及解决方案。

原则13：充分评估各种方案，达成共识之后迅速执行

我们积极地遵循一条原则：在充分考虑各种方案之前，不会选定任何方向。但是一旦我们选择了正确的道路，我们就加速并且持续地走下去。

好几次我们都试图对各种各样的issues寻求替代解决方案，比如如何使外包团队理解荷兰语文档。我们应该手动翻译还是使用一个能翻译60%内容的工具？最后我们决定让荷兰团队根据他们的文档在Jira上创建一些issue，离岸团队来研究这些issue，并且对此进行提问。这种方法非常迅速并有效。

原则14：通过深刻的反思和持续的改进，成为好学的组织

正是这条最重要的原则帮助我们达到了今日的高度。我们执行严格的迭代评价，深刻反思，对好的方面进行坚持，对可以提高的地方进行改善，从而使得迭代越来越好。我们渴求不断地且及时地征求客户和团队的反馈，从而高效地达到软件的最终目标。 除此之外，当遇到任何问题的时候，我们会一直询问“为什么”5次，直到弄清了问题的根源为止。

总结

在本文的最后，我想说：“我们仍然还在学习”。“精益生产”已经被成功地应用于软件外包行业，但是仍然可以改善。丰田原则一旦应用于软件外包，将会给现有的软件外包模式带来显著的变化。我们将会通过不断的改进，最终达成我们的目标——白盒精益敏捷外包。这种模式下外包的透明度和质量都将会达到极致。

最后对外包行业提一个建议：在遵循Scrum和丰田原则的时候，不要试图稀释其中的“精华”，把它们应用到你的工作上去，然后等着奇迹发生吧。