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

序文

之前的“敏捷开发用户故事系列”曾经提到了微观层面的需求管理问题。由于敏捷开发的提出者和实践者次要是开发团队及其领导，因此普通较少提及产品的全体规划、商业目标这些内容。

本系列汇集了本人在做产品管理的时候的一些心得，以及在与不同企业交流、做互联网软件分析的时候的一些所得，与大家分享。

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

为何设立迭代目标

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

基于版本规划的迭代目标

一次是关于“迭代期内无变更”，即由于产品应该事后设定商业目标和客户群，因此全体版本规划也应事后设定，进而可以分解出绝对稳定的迭代目标。

若能完成上述任务，则迭代期内虽然有微弱的变更，但迭代的总目标不会发生大的变化，从而保证迭代期内全体开发内容的稳定。

基于故事群的迭代目标

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

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

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

怎样设立迭代目标

会前预备

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

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

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

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

长期存在的一个难以平衡的问题是：若在架构上做了过多的预备，若两头发生变更乃至放弃某些功用，这些预备会浪费；若架构上预备不足，不断迎来新功用又会导致过多的“重构”发生，也会形成浪费。为多个迭代设立目标可以无效地协助开发团队做出切合实际的架构预备，将浪费降低到最低点。

会后核对

在计划会上讲解故事、预算故事后，事情常常有所变动。

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

开发中跟踪

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

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

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

为每个迭代设立目标，非常好地让我们能够遵照这一点。

文章来源：blog.csdn.net/cheny_com/article/details/6912278