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

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

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

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

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

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

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

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

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

　　原则4：平准化（heijunka）

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

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

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

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

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

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