敏捷开发产品管理系列之1

精品文档---下载后可任意编辑敏捷开发产品管理系列之一：序言及设立迭代目标敏捷开发产品互联网活开工作目录(?)[+]本文是敏捷开发产品管理系列的第一篇。〔序言及设立迭代目标，产品版本规划，产品用户群规划，新产品研发，预估会议，Product Servant，Product Owner 团队，产品线管理〕序言之前的“敏捷开发用户故事系列〞已经提到了微观层面的需求管理问题。由于敏捷开发的提出者和实践者主要是开发团队及其领导，因此一般较少提及产品的整体规划、商业目标这些内容。本系列聚集了本人在做产品管理的时候的一些心得，以及在与不同企业沟通、做互联网软件分析的时候的一些所得，与大家分享。本系列的顺序整体由微观到宏观排序，拟包括设立迭代目标，产品版本规划，新产品研发Product Owner 团队，产品线管理等话题。为何设立迭代目标之前笔者的博客中曾经两次提到关于迭代目标设立的话题。基于版本规划的迭代目标一次是关于“迭代期内无变更〞，即由于产品应该预先设定商业目标和客户群，因此整体版本规划也应预先设定，进而可以分解出相对稳定的迭代目标。假设能完成上述工作，那么迭代期内尽管有微弱的变更，但迭代的总目标不会发生大的变化，从而保证迭代期内整体开发内容的稳定。基于故事群的迭代目标第二次那么是提到用户故事的组织时，引入了“故事群〞的概念，即某个迭代不应该简单地开发“当前最重要的功能〞，因为万一这些最重要的功能零散地分布在不同的业务模块中，开发者就要同时面临同步了解多个业务模块的困境，前来评审的客户也会有如瞎子摸象一般只能看到多个局部的一角。相对容易开发的方式，是在一个迭代中，应该安排相关的一组故事，从而将开发和评审的焦点都集中在一起。这样开发出来的产品也不完整，但却相对完整地交付了一局部功能，比之零散功能还是更有价值。上述两种方法，一种基于外部的商业目标，一种基于内部的开发方便性，但都指向相同的结果。怎样设立迭代目标会前准备迭代目标是提前设立的，早于方案会，甚至早于 Product Owner 将有开发意向的 Backlog 条目方案到迭代中。它实际上在做产品版本规划的时候，就应该捎带着被完成了。精品文档---下载后可任意编辑它常常是一句简单的描述，如“一个能登陆和显示故事列表的版本〞。在迭代方案会之前，Product Owner 会审视这个迭代的目标，从而决定将哪些故事置于本迭代中开发。事实上，假设已经设定了多个迭代的目标，Product Owner 应该会同开发团队骨...