敏捷开发产品管理系列之114.docx
《敏捷开发产品管理系列之114.docx》由会员分享,可在线阅读,更多相关《敏捷开发产品管理系列之114.docx(34页珍藏版)》请在第一文库网上搜索。
1、敏捷开发产品管理系列之114敏捷开发产品互联网活动工作目录(+】本文是敏捷开发产品管理系列的第一篇。(序言及设立迭代目标,产品版本规划,产品用户群规划,新产品研发,预估会议,ProductServant,PrOdUCtOWner团队,产品线管理)序言之前的“敏捷开发用户故事系列”已经提到了微观层面的需求管理问题。由于敏捷开发的提出者与实践者要紧是开发团队及其领导,因此通常较少提及产品的整体规划、商业目标这些内容。本系列汇合了本人在做产品管理的时候的一些心得,与在与不一致企业交流、做互联网软件分析的时候的一些所得,与大家分享。本系列的顺序整体由微观到宏观排序,拟包含设立迭代目标,产品版本规划,新
2、产品研发,ProductOWner团队,产品线管理等话题。为何设立迭代目标之前笔者的博客中曾经两次提到关于迭代目标设立的话题。基于版本规划的迭代目标一次是关于“迭代期内无变更”,即由于产品应该预先设定商业目标与客户群,因此整体版本规划也应预先设定,继而能够分解出相对稳固的迭代目标。若能完成上述工作,则迭代期内尽管有微弱的变更,但迭代的总目标不可能发生大的变化,从而保证迭代期内整体开发内容的稳固。基于故事群的迭代目标第二次则是提到用户故事的组织时,引入了“故事群”的概念,即某个迭代不应该简单地开发“当前最重要的功能”,由于万一这些最重要的功能零散地分布在不一致的业务模块中,开发者就要同时面临同步
3、熟悉多个业务模块的逆境,前来评审的客户也会有如瞎子摸象通常只能看到多个局部的一角。相对容易开发的方式,是在一个迭代中,应该安排有关的一组故事,从而将开发与评审的焦点都集中在一起。这样开发出来的产品也不完整,但却相对完整地交付了一部分功能,比之零散功能还是更有价值。上述两种方法,一种基于外部的商业目标,一种基于内部的开发方便性,但都指向相同的结果。如何设立迭代目标会前准备迭代目标是提早设立的,早于计划会,甚至早于ProductOWner将有开发意向的BaCkIOg条目计划到迭代中。它实际上在做产品版本规划的时候,就应该捎带着被完成了。它常常是一句简单的描述,如“一个能登陆与显示故事列表的版本”。
4、在迭代计划会之前,ProdUCtoWner会审视这个迭代的目标,从而决定将什么故事置于本迭代中开发。事实上,若已经设定了多个迭代的目标,ProductOwner应该会同开发团队骨干,为未来23个迭代大致分配所需的用户故事,而不是赶在当前迭代前才匆匆分配。这个活动有利于开发团队骨干提早熟悉未来,从而在架构上做一些准备。长期存在的一个难以平衡的问题是:若在架构上做了过多的准备,若中间发生变更乃至放弃某些功能,这些准备会浪费;若架构上准备不足,不断迎来新功能又会导致过多的“重构”发生,也会造成浪费。为多个迭代设立目标能够有效地帮助开发团队做出切合实际的架构准备,将浪费降低到最低点。会后核对在计划会上
5、讲解故事、估算故事后,情况常常有所变动。这时候要从已经计划要开发的故事总结一下看看,是否与原先设定的目标相符。开发中跟踪在日常开发中ProdUetOWner常常提出变更,若变更符合目标甚至能更好地达成目标,则应该被积极地接纳;若背离了目标,则应该缓做或者重新考虑。若“被激励”的程序员有了奇思妙想的时候,团队同样应该冷静地思考,做出推断。“拥抱变化”与“迭代期内无变更”的矛盾事实上向我们揭示了敏捷开发中的一个重要原则:变化的是路径,不变的是目标。为每个迭代设立目标,非常好地让我们能够遵循这一点。敏捷开发产品管理系列之二:产品版本规划本文是一篇旧文,原名为“迭代期内无变更”与敏捷开发产品版本规划,
6、因符合本系列内容,做相应修改后重新编排发出。迭代期间无变更?支持派说:对,假如经常变,我们怎么开发啊。反对派说:不对,敏捷开发不能上来就确认了需求,要的就是在开发中逐步熟悉需求,怎么可能不变呢。只在开发层面,这个问题无解。让我们站在产品版本规划的高度来看这个问题。基于商业目标的产品版本规划下个产品版本(或者下个迭代)中到底应该有什么功能?最重要的功能?最基础的功能?当前可能实现的功能?已经弄清晰的功能?这些角度都是基于技术活动而非市场目标来制定的,都有其局限性。事实上,每个产品的版本都是企业的一步棋:在某个时间,推出某些功能,满足某些需求,获取某些客户,打败某些对手,取代某些产品。若认同了这一
7、点,则早在产品版本规划的时候,就应该确认此版本中应该大致包含什么功能,而非到迭代计划会议或者迭代中才会确认,更不可能在迭代中间发生变化。这样看来,“迭代期间无变更”指的是:“不应该到迭代开发已经开始了还没明确要开发什么功能”(What问题);而不是:”应该在迭代前把需求弄明确,一旦开发了就别改动了(HoW问题)。产品版本规划步骤图产品立项在这个时候大致规划出路线图,走多远,多久,走到哪里V1.0在这个时候明确规划处这个版本要做什么功能(未必到达故事点的粒度)Sprint1计划会在这个时候达到故事点的粒度,且从技术角度思考能够先做什么后做什么日常工作细化做成什么样子,随时能够变,但基本不可能大量
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 敏捷 开发 产品 管理 系列 114
![提示](https://www.001doc.com/images/bang_tan.gif)