敏捷开发产品管理系列之一：序言及设立迭代目标

本文是敏捷开发产品管理系列的第一篇。（序言及设立迭代目标，产品版本规划，产品用户群规划，新产品研发，预估会议，Product Servant，Product Owner团队，产品线管理）

序言

以前的“敏捷开发用户故事系列”已经提到了微观层面的需求管理问题。因为敏捷开发的提出者和实践者主要是开发团队及其领导，所以通常较少说起产品的总体规划、商业目标这些内容。

本系列聚集了本人在作产品管理的时候的一些心得，以及在与不一样企业交流、作互联网软件分析的时候的一些所得，与你们分享。

本系列的顺序总体由微观到宏观排序，拟包括设立迭代目标，产品版本规划，新产品研发，Product Owner团队，产品线管理等话题。

为什么设立迭代目标

以前笔者的博客中曾经两次提到关于迭代目标设立的话题。

基于版本规划的迭代目标

一次是关于“迭代期内无变动”，即因为产品应该预先设定商业目标和客户群，所以总体版本规划也应预先设定，进而能够分解出相对稳定的迭代目标。

若能完成上述工做，则迭代期内尽管有微弱的变动，但迭代的总目标不会发生大的变化，从而保证迭代期内总体开发内容的稳定。

基于故事群的迭代目标

第二次则是提到用户故事的组织时，引入了“故事群”的概念，即某个迭代不该该简单地开发“当前最重要的功能”，由于万一这些最重要的功能零散地分布在不一样的业务模块中，开发者就要同时面临同步了解多个业务模块的困境，前来评审的客户也会有如瞎子摸象通常只能看到多个局部的一角。

相对容易开发的方式，是在一个迭代中，应该安排相关的一组故事，从而将开发和评审的焦点都集中在一块儿。这样开发出来的产品也不完整，但却相对完整地交付了一部分功能，比之零散功能仍是更有价值。

上述两种方法，一种基于外部的商业目标，一种基于内部的开发方便性，但都指向相同的结果。

怎样设立迭代目标

会前准备

迭代目标是提早设立的，早于计划会，甚至早于Product Owner将有开发意向的Backlog条目计划到迭代中。它实际上在作产品版本规划的时候，就应该捎带着被完成了。

它经常是一句简单的描述，如“一个能登录和显示故事列表的版本”。

在迭代计划会以前，Product Owner会审视这个迭代的目标，从而决定将哪些故事置于本迭代中开发。

事实上，若已经设定了多个迭代的目标，Product Owner应该会同开发团队骨干，为将来2～3个迭代大体分配所需的用户故事，而不是赶在当前迭代前才匆匆分配。这个活动有利于开发团队骨干提早了解将来，从而在架构上作一些准备。

长期存在的一个难以平衡的问题是：若在架构上作了过多的准备，若中间发生变动乃至放弃某些功能，这些准备会浪费；若架构上准备不足，不断迎来新功能又会致使过多的“重构”发生，也会形成浪费。为多个迭代设立目标能够有效地帮助开发团队作出切合实际的架构准备，将浪费下降到最低点。

会后核对

在计划会上讲解故事、估算故过后，事情经常有所变更。

这时候要从已经计划要开发的故事总结一下看看，是否与原来设定的目标相符。

开发中跟踪

在平常开发中Product　Owner经常提出变动，若变动符合目标甚至能更好地达成目标，则应该被积极地接纳；若背离了目标，则应该缓作或从新考虑。

若“被激励”的程序员有了奇思妙想的时候，团队一样应该冷静地思考，作出判断。

 

“拥抱变化”与“迭代期内无变动”的矛盾其实向咱们揭示了敏捷开发中的一个重要原则：变化的是路径，不变的是目标。

为每一个迭代设立目标，很是好地让咱们可以遵循这一点。