多一点设计，少一点烦恼

这是团队发生的一起事故。

需求是这样的，在用户个人中心，有一个将本地的视频上传到第三方存储库的需求，需求不复杂，但是出了很多岔子。前后经过大概三个多冲刺，时间跨度一个月，仍然有很多问题，没有发布。

验证阶段：开发人员是进行了前期验证的，将市面上的上传控件测试了一次，并有相关的demo，然而这个demo在后来并没有起到加快任务进度的作用，实际上，实验的demo，后端接口并不是需求相关的第三方api，开发人员并没有对 api作验证

构建阶段：没有相关设计，直接开始编码，开发人员对整个需求，所需要做的东西不了解，没有技术方案，只凭感觉开始了切图，编码，随后陷入了地狱，demo不能直接拿过来用，因为上传的地方并不是业务服务器，而是第三方存储。而第三方存储也没有api，几经沟通，给出直接用iframe嵌套页面的方案，这个方案验证也不行，因为有各种跨域，交互等问题，在多次调试，耗费时间快2周的时候，终于调出一个勉强能用的方案。不过地狱还是没有结束，仍然有一些需求没有确认，没有解决。

需求是会变的，这是铁律，产品人员的设计会根据市场的反馈发生改变，就算市场不变，整个团队成员对产品的理解会在不断的沉浸中加深理解，更加的适应需求，就像开发人员写一些功能的时候，经常会有重构重写的情况发生，这是好事，能提高代码的复用性，性能等，所以需求的变更是必然，有时候也是必要的。但不断变化的需求对开发人员来说，是一个极度讨厌的恶魔，它延误了进度，增加了成本，消磨了耐心，降低了成就。这就需要一个平衡，尽量少的需求变更来迭代更适应需求的产品。

敏捷是一个好方法，给了开发人员一个固定的冲刺时间，无打扰，无变更，所有的需求变更都在冲刺开始前确定，在冲刺结束之前，无反悔机会。除非结束冲刺，重新制定冲刺计划。但这条护城河不是咒语，喊一声敏捷就抑制了变更，这对开发提出了更高的要求：主动提前确认需求，提前做好架构，验证。否则，当发现技术方案有问题，无法实现，实现成本过大等需要变更的时候，主动打破计划的就不是产品，而是研发人员。这同样对项目是危险。

在这个失控中学到什么：

对开发人员来说，在冲刺开始之前，需要明确这次冲刺的目标是什么，我如何实现这些目标，以及验证相应技术方案，在方案仍然有疑问之前，绝不启动冲刺计划。在前期挣扎比在后期推倒对项目的影响要小得多。
对冲刺大师来说，大师是冲刺的守护，需要保证冲刺能正常顺利进行，尽量减少冲刺的风险，所以需要和开发人员沟通，确认所有需求，技术方案细节，然后才能放行，开始冲刺。
对团队来说，需求变更的最小代价是需求刚开始的时候，越往后成本越大，所以尽量保持目标的简短很重要，将大的需求，分解成小的冲刺目标，就算在冲刺周期内，也要保持持续交付，持续测试，继续验证的节奏。如有条件，可以做到每日发布，每日验证。
沟通在冲刺过程中是非常非常重要的，在冲刺遇到障碍时，大师要及时发现问题，协助成员解决，当发现项目失控，要想办法将冲刺拉到轨道上来，如有必要，重新评估任务，确认方案细节再重新开始冲刺。