最近我写了一篇文章，并用反问作为标题：“客户是否已经为敏捷做好准备？”这个想法来源于在软件开发组织已经遵循了瀑布方法学太久的事实，以至于它已经在客户，他们的规划管理办公室和IT部门的灵魂中根深蒂固了。
虽然敏捷正在成为“新标准”，而事实上它们并不想帮助任何人，除非整个生态系统理解并且适应它们。（幸运地是，如果说记住它很难，那么想要忘记它却更难。）所以，深思这些客户，我想到的是当我们期望他们参与到一个敏捷的框架重来管理一个项目的时候可能有更好的方法来与他们合作，尤其是当瀑布式仍然或多或少的不仅在他们的组织中根深蒂固，同样也经常在我们的内部一样根深蒂固。
现下有4种客户契约，我相信在项目的进程中带来益处：
1.使客户在早期就参与到项目中
当软件组织转变到敏捷的时候，他们总是使他们的员工参与到培训中，向他们全面地介绍敏捷以及在实践中帮助他们涉及了解到不同的角色。如果客户管理团队也和客户合作的话将会提供帮助，邀请主要股东，那些将要参与到项目中的人来参加到这些正式的课程中来。（如果这些外部的培训必须支付费用，那么客户团队需要和客户进行商讨——有些人可能会愿意为他们的员工买单。）
这样做的好处在于基于角色的培训可以帮助客户更加熟悉product owner的期望和活动。项目股东也将开始理解敏捷的流程。
2. 从一开始就遵循Scrum流程
大多数项目都有一个初期的“探索”阶段，一旦RFP（需求方案说明书）或者观念证据被接受，高级的需求需要被理解。这个阶段大致是一组讨论，最终成为一份份文档。然而，如果项目以以下的敏捷方法为目标，如果这个“探索”阶段本身遵循敏捷流程，那将会带来极大的好处。这个方法是利用短期的sprints，它可以在讨论下以流程为中心。在每个sprint结束后，sprint的演示将会是客户需求的展现，同时通过实施组织来收集和理解客户需求。
这样好处将会有两部分：第一，这样会降低高级需求分歧的机会。第二，对于客户和实施团队，Scrum方案从一开始就被正确地运用。
3. 强制制作sprint演示
这可能是说起来容易做起来难了。并且对方法学来说它并不是一个强制的步骤。如果任何代码或者设计必须向客户或者product owner演示时，作为人之常情，Scrum团队和ScrumMaster一定想将他们最好的一面展现出来。我当然不是在此暗示否则他们就会做出低劣的工作。我所提议的全部只是一个方案，演示每个sprint的最终结果。因为我直接观察到，每次想做演示是困难的。举个例子来说，演示可以是设计团队的工作，包括在决定最终设计之前考虑些什么，设计对于实际开发的影响，关于可扩展性或者效率等等，这个设计与其他设计相比较如何。我们可以从一个人的演示中得到创意。
这样做的主要想法是使客户参与到整个项目中来，使项目及客户的兴趣持续下去的同时，减少或者缓解在周期晚期发生任何不必要意外。
4. 获取正式的反馈
我实在不想这么说，但作为product owner，就我所阅读和实践的敏捷，在sprint演示后或者sprint回顾会议，我从未被问道过正式的反馈。但我相信如果product owner和客户都被要求填写一个简单的模板将会带来帮助。模板可以包括如下些样例：
演示话题
演示、sprint团队
假设或任何注意事项
反馈部分
这样做的想法是让客户团队中拥有演示话题的所有成员分享在sprint中他们认为什么是完成了的，它是否有被演示，或者在sprint回顾会议中仅做讨论。
正如演示影响Scrum团队的心理状态一样，在一轮轮的sprint后被问及分享他们的反馈需要客户承担许多责任。他们不得不参与，理解，以及知晓在sprint中团队完成了什么——或者没有完成什么。正式的反馈也可以当作正式的签署，并且他可以为整个项目团队提供一份简单的参考。
总而言之，因为软件开发的世界正在适应新的方法学，将客户融入进来将会为我们带来最大的利益。帮助他们改变以及一同适应，从而取得更好的结果。
作者:Shweta Darbha
原文来自http://www.scrumalliance.org/articles/418-bring-the-customer-along
