敏捷等于没有文档吗?—敏捷项目管理VS传统项目管理

------敏捷项目管理学习过程记录和心得

前阵子,一个负责产品开发的负责人,给我说,他对正在进行的产品交付项目的要求是:能够在短期内看到成果;可以随时快速的清楚进展;不需要那么多“没必要”的设计文档,却迟迟看不到交付的功能;能够随时对成果展示的不满足项进行变更。

嗯,那你们就最需要使用敏捷了,恰好现有软件系统从固定的功能变更为可配置的系统,需要重新开发,那么就一起开始实践吧。

1)先要弄清楚CMMI(该公司使用CMMI)和敏捷的主要区别,CMMI面向的是活动,敏捷面向的是特性(功能);CMMI是按照活动和阶段进行,一次交付,增加新功能再做新的开发。敏捷是按照sprint进行多次迭代开发,可以先做最小可用软件(MVP),进行成果展示后,再根据特性优先级进行持续的迭代开发。

2)MVP怎么设计呢?使用快捷的方式,现有产品已经定制开发完成,那么可以快速的识别特性点,提取几个典型的用户,提炼几个典型的流程,使用用户故事地图的方式进行优先级排序,定义出MVP及后续的特性迭代计划,即多个sprint冲刺计划。

3)讨论出交付计划后,对特性进行小的任务项的分解,以一个工作日为单位进行,在显目的地方设计看板的位置,将特性图和任务项分别贴上去,进行每日站会,确保每天都有交付,在短时间内可以快速实现第一个sprint的交付。

4) 持续sprint……

那么,完整的敏捷项目到底什么样的?它和传统项目具体有哪些区别呢?

图1,敏捷成熟度金字塔分别从理念、组织风格、改进性、目标、适应性、实践对敏捷项目进行说明。

敏捷等于没有文档吗?—敏捷项目管理VS传统项目管理_第1张图片
敏捷成熟度金字塔

敏捷项目和传统项目的区别主要是哪些呢?

传统项目管理通常采用的是瀑布式、部分迭代开发模式,需求足够明确、文档足够规范,迭代过程中需求变更越多、越晚,对项目影响越大,会影响到项目的交付质量。

敏捷项目管理欢迎需求变更,在客户需求不明确的时候,以在较短的周期内开发出可用的软件为目标,来帮助客户描述自己的需求。

一.从管理流程来看

项目管理流程可以总结分为五个过程组: 启动、规划、执行、监控、收尾,敏捷项目管理框架是:构想、推测、探索、适应、结束,和PMBOK知识体系项目管理五大过程组一一对齐。

*构想阶段:确定产品的构想、项目范围、项目团队以及团队共同的工作方式。(产品愿景-组建团队-项目章程-流程裁剪)

*推测阶段:制定基于功能发布计划、里程碑和迭代计划,确保交付构想的产品(产品线路图-产品待办列表-产品发布计划)

*探索阶段:在短期内提供经测试的功能,不断致力于减少项目风险和不确定性。

*适应阶段:审核提交的结果、当前情况以及团队的绩效,必要是做出调整。

*结束阶段:终止项目,交流主要的学习成果并庆祝。

1、 传统项目管理

传统的项目管理要对项目的所有过程进行管理和风险把控,并要求在不同环节的有文档输入和输出,每个环节都存在启动、规划、执行、监控和收尾。一旦出现规划以外的变更,都需要经过批准后才能执行改变。

2、 敏捷项目管理

敏捷项目管理主张团队内部的面对面沟通和交流(讲故事),以 Scrum 为代表,简单、持续集成、不断交付、价值优先、拥抱变化的原则在面对时刻变化的市场经济和不断发展的技术时变得十分友好。 敏捷项目中,项目管理计划分不同的等级,可以用一个洋葱图来表示,也就是洋葱计划图,如下图2:

敏捷等于没有文档吗?—敏捷项目管理VS传统项目管理_第2张图片
洋葱计划图

战略和投资规划在敏捷项目管理的最外层,由更广泛的组织管理系统来处理。由外往内,不断切分项目计划,最后实现最小周期的可行性版本迭代(或者MVP)。对复杂或不明确的客户需求进行合理的分割,最终实现总体上的统一。

敏捷三角形的演变过程(摘自《敏捷项目管理》书籍P12-13页):

敏捷等于没有文档吗?—敏捷项目管理VS传统项目管理_第3张图片
敏捷三角形

敏捷三角形:

1、价值目标:提供可交付的产品

2、质量目标:提供可靠的、适应性强的可交付产品

3、约束目标:在可接受的约束内,实现价值和质量目标

有了这个理念,敏捷和传统项目管理就可快速实现融合,传统项目管理多一些授权,多一些拥抱变化,就可以向敏捷靠近,敏捷多一些体系化,就可以向项目管理延伸,二者是一个融合的过程,这将是一个趋势。

二.从风险控制环节来看

风险即不确定性,一旦发生,会对项目造成积极或消极的影响,如范围、进度、成本和质量。

传统项目管理要求在规划过程中规划风险管理、识别风险,对风险进行定性/定量分析,给出风险应对方案。因为风险的不确定性,要求项目风险管理必须给未知风险或者已知却又无法主动管理的风险分配一定的资源储备。

传统项目管理要求持续跟踪风险登记表,并且记录风险应对措施在处理已识别风险及其根源方面的有效性,完成风险再评估和风险审计,直到风险被降到最低。

敏捷项目管理不同于传统项目管理,一方面开发评估是以工作量为导向而非时间导向,为风险留足了应对空间,且每个sprint冲刺周期较短,即使出现部分风险,相对来说对于已交付成果来说,变更相对较少;另一方面,敏捷项目管理在项目没有正式结束前,交付的可用软件是允许风险存在的,并且是根据风险的优先级来进行排期修复。

三.从企业项目管理来看

项目管理模式:外瀑布内敏捷(有人称为“信封法”) ,目前对于外部交付项目大部分对于文档交付和阶段点交付需求较多 ,而在行业需求方面,却需要在竞争中追求最大范围的满足行业需求。在客户不能接受 Scrum 时,通常会选择外瀑布内敏捷的项目管理模式,满足双方的利益。

四.传统 VS 敏捷 ? 适者生存

敏捷项目管理只是一个灵活的实践框架,提供的是一套清晰的游戏规则,根据不同的环境可以提供一系列不同的途径。

传统项目管理却是一套中央集权制管理法,要求按计划行事,任何环节发生变更都必须获准后才能进行改变。

不管是传统的瀑布式开发管理还是敏捷迭代式管理,没有哪个好与不好,只有在不同的项目环境中哪个更适合。

当然最终的趋势是互相兼容,优势互补,最新的CMMI2.0版本就已将敏捷包含入内,同样,敏捷也将精益的管理思路做了结合。

最后,以传统项目和敏捷项目的管理思路进行沙盘演练,对餐厅进行点菜,过程根据口味的需求进行反复变更,模拟后会对两个项目管理方式的区别会更为深刻。

你可能感兴趣的:(敏捷等于没有文档吗?—敏捷项目管理VS传统项目管理)