多一点设计，少一点烦恼
date: 2015-04-17 15:32:50
这是团队发生的一起事故。
需求是这样的，在用户个人中心，有一个将本地的视频上传到第三方存储库的需求，需求不复杂，但是出了很多岔子。 前后经过大概三个多冲刺，时间跨度一个月，仍然有很多问题，没有发布。
验证阶段： 开发人员是进行了前期验证的，将市面上的上传控件测试了一次，并有相关的demo，然而这个demo在后来 并没有起到加快任务进度的作用，实际上，实验的demo，后端接口并不是需求相关的第三方api，开发人员并没有对 api作验证
构建阶段： 没有相关设计，直接开始编码，开发人员对整个需求，所需要做的东西不了解，没有技术方案，只凭感觉 开始了切图，编码，随后陷入了地狱，demo不能直接拿过来用，因为上传的地方并不是业务服务器，而是第三方存储。 而第三方存储也没有api，几经沟通，给出直接用iframe嵌套页面的方案，这个方案验证也不行，因为有各种跨域， 交互等问题，在多次调试，耗费时间快2周的时候，终于调出一个勉强能用的方案。不过地狱还是没有结束，仍然有 一些需求没有确认，没有解决。
需求是会变的，这是铁律，产品人员的设计会根据市场的反馈发生改变，就算市场不变，整个团队成员对产品的理解会 在不断的沉浸中加深理解，更加的适应需求，就像开发人员写一些功能的时候，经常会有重构重写的情况发生，这是 好事，能提高代码的复用性，性能等，所以需求的变更是必然，有时候也是必要的。但不断变化的需求对开发人员来说， 是一个极度讨厌的恶魔，它延误了进度，增加了成本，消磨了耐心，降低了成就。这就需要一个平衡，尽量少的需求 变更来迭代更适应需求的产品。
敏捷是一个好方法，给了开发人员一个固定的冲刺时间，无打扰，无变更，所有的需求变更都在冲刺开始前确定， 在冲刺结束之前，无反悔机会。除非结束冲刺，重新制定冲刺计划。但这条护城河不是咒语，喊一声敏捷就抑制了 变更，这对开发提出了更高的要求：主动提前确认需求，提前做好架构，验证。否则，当发现技术方案有问题， 无法实现，实现成本过大等需要变更的时候，主动打破计划的就不是产品，而是研发人员。这同样对项目是危险。
在这个失控中学到什么：
- 对开发人员来说，在冲刺开始之前，需要明确这次冲刺的目标是什么，我如何实现这些目标，以及验证相应 技术方案，在方案仍然有疑问之前，绝不启动冲刺计划。在前期挣扎比在后期推倒对项目的影响要小得多。
- 对冲刺大师来说，大师是冲刺的守护，需要保证冲刺能正常顺利进行，尽量减少冲刺的风险，所以需要和开发 人员沟通，确认所有需求，技术方案细节，然后才能放行，开始冲刺。
- 对团队来说，需求变更的最小代价是需求刚开始的时候，越往后成本越大，所以尽量保持目标的简短很重要， 将大的需求，分解成小的冲刺目标，就算在冲刺周期内，也要保持持续交付，持续测试，继续验证的节奏。 如有条件，可以做到每日发布，每日验证。
- 沟通在冲刺过程中是非常非常重要的，在冲刺遇到障碍时，大师要及时发现问题，协助成员解决，当发现项目 失控，要想办法将冲刺拉到轨道上来，如有必要，重新评估任务，确认方案细节再重新开始冲刺。