文档介绍：敏捷开发产品管理系列之一:序言及设立迭代目标敏捷开发产品互联网活动工作目录(?)[+] 本文是敏捷开发产品管理系列的第一篇。( 序言及设立迭代目标, 产品版本规划, 产品用户群规划, 新产品研发,预估会议, Product Servant , Product Owner 团队,产品线管理) 序言之前的“敏捷开发用户故事系列”已经提到了微观层面的需求管理问题。由于敏捷开发的提出者和实践者主要是开发团队及其领导,因此一般较少提及产品的整体规划、商业目标这些内容。本系列汇集了本人在做产品管理的时候的一些心得, 以及在与不同企业交流、做互联网软件分析的时候的一些所得,与大家分享。本系列的顺序整体由微观到宏观排序, 拟包括设立迭代目标, 产品版本规划, 新产品研发, Product Owner 团队,产品线管理等话题。为何设立迭代目标之前笔者的博客中曾经两次提到关于迭代目标设立的话题。基于版本规划的迭代目标一次是关于“迭代期内无变更”,即由于产品应该预先设定商业目标和客户群,因此整体版本规划也应预先设定,进而可以分解出相对稳定的迭代目标。若能完成上述工作, 则迭代期内尽管有微弱的变更, 但迭代的总目标不会发生大的变化, 从而保证迭代期内整体开发内容的稳定。基于故事群的迭代目标第二次则是提到用户故事的组织时, 引入了“故事群”的概念, 即某个迭代不应该简单地开发“当前最重要的功能”,因为万一这些最重要的功能零散地分布在不同的业务模块中,开发者就要同时面临同步了解多个业务模块的困境, 前来评审的客户也会有如瞎子摸象一般只能看到多个局部的一角。相对容易开发的方式, 是在一个迭代中, 应该安排相关的一组故事, 从而将开发和评审的焦点都集中在一起。这样开发出来的产品也不完整, 但却相对完整地交付了一部分功能, 比之零散功能还是更有价值。上述两种方法,一种基于外部的商业目标,一种基于内部的开发方便性,但都指向相同的结果。怎样设立迭代目标会前准备迭代目标是提前设立的,早于计划会,甚至早于 Product Owner 将有开发意向的 Backlog 条目计划到迭代中。它实际上在做产品版本规划的时候,就应该捎带着被完成了。它常常是一句简单的描述,如“一个能登陆和显示故事列表的版本”。在迭代计划会之前, Product Owner 会审视这个迭代的目标,从而决定将哪些故事置于本迭代中开发。事实上, 若已经设定了多个迭代的目标, Product Owner 应该会同开发团队骨干, 为未来 2 ~3 个迭代大致分配所需的用户故事, 而不是赶在当前迭代前才匆匆分配。这个活动有利于开发团队骨干提前了解未来,从而在架构上做一些准备。长期存在的一个难以平衡的问题是: 若在架构上做了过多的准备, 若中间发生变更乃至放弃某些功能, 这些准备会浪费; 若架构上准备不足, 不断迎来新功能又会导致过多的“重构”发生, 也会造成浪费。为多个迭代设立目标可以有效地帮助开发团队做出切合实际的架构准备, 将浪费降低到最低点。会后核对在计划会上讲解故事、估算故事后,事情常常有所变动。这时候要从已经计划要开发的故事总结一下看看,是否与原来设定的目标相符。开发中跟踪在日常开发中 Product Owner 常常提出变更,若变更符合目标甚至能更好地达成目标,则应该被积极地接纳;若背离了目标,则应该缓做或重新考虑。若“被激励”的程序员有了奇思妙想的时候,团队同样应该冷静地思考,做出判断。“拥抱变化”与“迭代期内无变更”的矛盾其实向我们揭示了敏捷开发中的一个重要原则: 变化的是路径,不变的是目标。为每个迭代设立目标,非常好地让我们能够遵循这一点。敏捷开发产品管理系列之二:产品版本规划本文是一篇旧文,原名为《“迭代期内无变更”与敏捷开发产品版本规划》,因符合本系列内容,做相应修改后重新编排发出。迭代期间无变更? 支持派说:对,如果经常变,我们怎么开发啊。反对派说: 不对, 敏捷开发不能上来就确认了需求, 要的就是在开发中逐步了解需求, 怎么可能不变呢。只在开发层面,这个问题无解。让我们站在产品版本规划的高度来看这个问题。基于商业目标的产品版本规划下个产品版本( 或下个迭代) 中到底应该有什么功能?最重要的功能?最基础的功能?当前可能实现的功能?已经弄清楚的功能? 这些角度都是基于技术活动而非市场目标来制定的,都有其局限性。其实, 每个产品的版本都是企业的一步棋: 在某个时间, 推出某些功能, 满足某些需求, 获取某些客户,打败某些对手,取代某些产品。若认同了这一点, 则早在产品版本规划的时候, 就应该确认此版本中应该大致包含哪些功能, 而非到迭代计划会议或迭代中才会确认,更不会在迭代中间发生变化。这样看来,“迭代期间无变更”指的是:“不应该到迭代开发已经开始了还没明确要开发什么功能”( What 问