敏捷开发中，需求优先还是开发优先

       当一个团队采用敏捷开发后，项目负责人和管理层，会自然而然的希望团队能正确交付可执行产品的同时，也能提高交付的效率。但实际项目执行的过程中，往往遇到设计团队和开发团队互相抱怨的情况。产品负责人在计划会的时候，会向团队讲解备选的需求故事。由于客户的需求可能更多是一个想法，技术如何实现，最后的产品会用何种方式来表达，可能都还是比较模糊的。产品负责人更多关注，以客户价值导向的角度来介绍Story。

       那么开发团队就会比较紧张了，虽然期望的需求功能表述完毕了，也理解了。但因为开发团队已经习惯了拿到比较明确的需求，包括技术架构、模块拆分、函数接口定义等等，然后再做进一步的任务派发。面对全新Story形式的需求，该如何处理？因此希望需求优先。而设计团队认为敏捷能够成功的前提是整个团队能完全致力于项目的开发。能够快速响应需求的开发，才能让整体的项目进展实现敏捷，因此希望开发优先。

       但也有人提出，一旦开发团队的方向出现变化，会导致项目的崩溃；因为需求总在变化。双方总在这种环境下争执，到最后项目不了了之。眼见竞争对手的产品面市了，团队还在忙着相互较真。敏捷环境下遭遇的这些问题，也使得不少团队既羡慕于其他团队的敏捷方式，又担忧自身上敏捷方式后，潜在的风险问题而犹豫不前。

       其实敏捷环境中，团队间相互寻找一种适合团队的敏捷策略，调整对应的管理办法，可能最终的效果会更好。现实项目中，应当鼓励团队对敏捷的指导思想，灵活创新思考，不用太过于条条框框，教科书般的作为指导团队的教条。

敏捷思想： Leadership（领导力） + Innovation（创新）

       基于这2个思想，让我们再来回到之前的问题，“需求优先”还是“开发优先”。有时候对于技术和设计都比较成型的idea，比如对于原有产品做一些扩展性、易用性的新功能，我们还真的希望“需求优先”。通过借助于需求空间的系统化管理，能更好的对原始需求进行拆分、细化、量化。对于还未打算进入开发实施阶段的需求，甚至都不用将SPEC从需求空间分配到ProductBacklog。这个时候，“需求优先”来的更好。而对于一些创新性的功能模块，新版本，甚至新产品，有时候根据实际情况，还真的需要“开发优先”，虽然会有一些代价。但创新，本身就带有颠覆性的浪漫，这样才会有意想不到的 “火花” 迸发。

       这就好比我们想要做一个移动电话的产品，刚开始我们的 idea 就是希望实现一个能让双方远距离无线交流的产品。因为面对的是一个全新的产品，完全没有参考信息，产品软硬件该如何实现，如何表达？很多时候，受限于一定的因素，确实很难对需求一次性表述清楚，也没有人能回答最优的设计。一味的追求“需求优先”，希望完善所有的设计后，再推送开发团队实现，常常会绕进“闭门造车”的窘状，甚至难产。这种时候，适当的“开发优先”，就来的更好。以移动电话来说的话，采取“开发优先”，让开发团队根据需求，在Sprint 1 周期中，完成最基本的远程通话功能。然后开发团队开动自己的大脑，创新、创造，实现了这个功能，向产品负责人做了交付。可能交付的产品，很难看，也很不好用，但它确实能支持通话的功能。有了这个能通话的原型的好处是，产品负责人能邀请项目干系人、客户等利益相关者，评审体验后，向设计团队反馈想法和想到的新需求。带来的好处是，设计团队将在原型的基础上逐渐绽放思想，继续创新idea，创造诸如拨号功能、来电显示、自定义铃声等等“火花”。“开发优先”的原则，反过来驱动了“需求优先”。这些推进的需求改进，通过“开发空间”反馈回“需求空间”，从而让团队从“需求”层面上，促进“需求模型的改进”。改进后的需求模型，继续通过Story的分配形式，传递到开发团队的Sprint 2周期中；形成 “需求空间” 二次反馈到 “开发空间” 的过程。这个过程，又是“需求优先” 原则，进一步驱动“开发优先” 原则的实践。

       通过这一系列的过程中，带动了整个开发团队的创新思维。正因为开发团队，在整个过程中，充分理解客户的需求，并且从技术层面促进了创新，才不断实现各种创造性的产品表达。而传统的开发方式，设计人员看到的需求，往往是对客户原始需求的一次表达，经过整理形成二次表达文档后传递给了开发人员。开发人员再对需求的二次表达，按照自己的理解，进行具体的实现；开发团队往往更愿意只停留在和自己相关的阶段性内容，缺少对客户需求真正的思考和理解，按部就班的味道更重一些。

参与过实际项目管理的同事，往往都有以下类似的感受：

1.    最终用户的理解和开发团队的理解决定了最初的需求模型

2.    开发团队的理解往往是对用户体验解释的简单机械映射

3.    概念模型和理想的用户需求理解往往存在差异

4.    缺乏权威引导的一个妥协的模型可能是错误的

       而我们知道，设计人员和开发人员的大脑习惯总是存有区别的，总是一个更多使用右半脑，一个更多使用左半脑。使用Story的需求表达方式，让设计人员和开发人员对需求能更好的保持在同一个层面的理解。同时在“开发优先”的原则下，势必就推动了开发人员技术创新，以及重新对需求的理解和创造思考。创造性思维中的“知觉”和“一闪念”是极其重要的，这一个“火花”往往孕育一个新的思想。

通过 “需求优先” 和 “开发优先” 原则相互协作的办法，不断推动 “需求模型的改进” 是创新和提高团队生产力的关键。因此放入到一个Sprint中，分配给开发团队的需求包括：

• 已充分理解的需求
• 待理解的需求

       这样带来的好处是，“需求优先”和“开发优先”共同激发了整个团队创造产品功能的“智慧”，同时这些“智慧”的创造过程，通过“需求空间”+“开发空间”被合理的进行管理。未来当项目团队人员进行扩展，或者变动的时候，项目管理层也不至于担忧相关人员离开后，整个过程的经验积累无法追溯和查找。敏捷开发的交付物（可执行的软件），让用户能更早的体验、理解原始需求，反过来也更好的促进了需求的改进；同样可执行的软件也促进了开发的技术创新。而一切的过程，整体来看，又是需求驱动的敏捷方法。它不但能提高软件开发过程的有效性，更能提高团队的创新和其他能力。

现在你说说，你的团队喜欢 “需求优先”，还是 “开发优先” 呢？：-）