中秋节刚过， 天气依然炎热。 计划会上team的成员吵得不可开交，空气温度持续上升，感觉就快要爆炸了。 原来针对一个用户故事， 大家在实现方案上有了分歧。 有的人觉得， 要做就要把功能做得完善，无论从界面还是后台性能上都要做到尽善尽美。但是如果做成一个各方面都完善的方案， 就不可能按照客户要求的时间交付。如果按照客户的交付时间， 就只能完成一些基本功能， 方案略显粗糙。这对于有些在技术上比较追求完美的技术人员来说，简直不可接受。
作为PO的老顽童， 听到这些情况， 镇定地说：“大家想把这个需求完成得漂亮， 这个想法我很理解，但是交付的时间点是不可能改变的。 交付时间是和客户沟通了几次后确定的， 他们几次都强调时间点不能变。大家把解决方案修改一下， 我们在性能上不需要这么快，因为目前的用户数量不多。另外， 界面上也尽可能简单实用，我们只要达到最基本的需求就可以了。按照这个要求，大家再重新估算一下时间吧。”
经过重新讨论和估算之后， 问题解决方案终于达成了一致。 可是， 讨论到第二个用户故事的时候，分歧又来了，这回是内部意见一致，一致反对老顽童把这个用户故事放在这个Sprint里。
通过对用户故事的拆分和估算，大家发现，按照目前的估算，交付时间是有些风险的。即使只开发基本功能，项目进行过程中也不允许team出现一点差错， 否则就无法按时交付。团队成员非常担心。
看到大家如此焦虑，作为Scrum Master的郭靖果断站出来，对PO周伯通说：“师叔啊，现在的情况你也看到了。根据目前的估算，我们这个Sprint完成交付是非常吃力的。如果强行把这个用户故事放在这个Sprint，不能按时交付的可能性挺大的。建议把交付的时间推迟到后面的Sprint。您看呢？”老顽童捋了捋胡子，寻思着：“这个用户故事是前几天客户发邮件提到的，他们似乎要得很急，说要下下周上线…….” 一抬眼，看到大家期待的目光都落在自己的身上。 马上了清了清嗓子，“这个问题，我已经了解了，因为这个用户故事是客户发邮件过来的，似乎很紧急。但是具体情况，我还没有和他们具体沟通。既然team反对，我需要和客户开个沟通会，然后再做决定吧。我们先继续讨论。”
计划会顺利地进行下去了。下午，客户沟通会的结论通知到团队，客户同意延期交付。
郭靖悄悄跑到周伯通面前，竖起大拇指：“师叔啊，您最近在敏捷项目的表现可以打满分啊，晚上我请您喝酒？”
“臭小子，就你嘴甜……晚上准备好十斤茅台哈！咱们不醉不归，哈哈哈” 说完，扬长而去。
郭靖笑眯眯地望着老顽童的背影，抑制不住心中的喜悦，赶紧打电话给黄蓉，把计划会发生的故事讲给了黄蓉听。
黄蓉听了也不禁感慨万千：“一年多的敏捷项目，PO，Scrum Master和团队都成长了。恭喜你们成功地处理了范围蔓延的问题……”
造成范围蔓延的原因有两个方面：
- 一是来自团队内部。
- 二是来自团队外部（高层、客户、发起人或其他干系人）。
来自团队内部原因造成的范围蔓延称为“镀金”，来自团队外部原因造成的范围蔓延称为“范围潜变”。
镀金往往是项目人员为了“讨好”客户而做的不解决实际问题、没有应用价值的项目活动。开发人员为产品添加了一项需求说明中没有提到的功能，他认为“用户肯定会喜欢的”。这就是所谓的“镀金问题（gold plating）”。用户通常并不关心额外的功能，在这方面花时间纯粹是浪费。开发人员和需求分析员不应擅自添加特性，应该把创意和备选方案提交给客户，让他们做决定。开发人员应该力求简洁，而不是自作主张去超越客户的需求。
客户时常强调用户界面这类看来很酷却对产品没多少实际价值的特性。开发任何功能都要耗费时间和金钱，应该让投入能够产生最大价值。要避免镀金问题，就应该追溯每项功能的来源，弄清楚为什么添加该功能。收集需求时，使用用例方法，有助于着重考虑可实现商业任务的功能需求。
范围潜变是指客户不断提出小的、不易察觉的范围改变，如果不加控制，累计起来导致项目严重偏离既定的范围基准，导致项目失控和失败。
使客户满意的核心原则之一是“谨慎承诺和交付更多”。当我们过度承诺和交付不足时，我们最终会遇到失望、不满的客户。心怀不满的客户会导致更多的客户投诉和客户流失。短期营业额增加将导致长期的业务萎缩。面向客户的客户投诉处理者非常清楚这些危险，但公司的营销部门也必须要求销售人员以最好的方式介绍公司。
在整个组织中，所有直接与客户打交道的团队成员都需要遵守纪律，以避免过度承诺的陷阱。以下三个策略可以帮助您避免过度承诺，并建立一个快乐的客户基础。
- 保持内部沟通畅通
- 与客户沟通他们的期望
- 对进展情况保持透明
本章作者：张思琪（LilyZ）
敏捷教练
上海DevOps社区组织者
中国DevOps社区志愿者
参考资料：https://blog.csdn.net/qq_30215957/article/details/104545763
