敏捷21天打卡-敏捷项目管理(终章)

软件项目管理的两大主流管理模式:传统项目管理(预测型项目管理)、敏捷项目管理;

传统项目管理(预测型项目管理):瀑布式、部分迭代开发模式,要求在项目一开始,需求足够明确、文档足够规范、迭代过程需求变更越频繁,其对项目造成的遭难往往越大。相信很多IT团队都尝试过,这里不赘述。

敏捷项目管理作为新兴的项目管理模式,简化了传统项目的流程,从繁琐的流程和详尽的文档中解脱出来。但并不代表敏捷不做计划,有很多人的观念“敏捷不做计划”这是错误,否“probacklog、scrum、看板、燃起图、燃尽图、用户故事等等”方法和工作又是为谁提供工作依据?敏捷即迭代、增量交付,其中代表XP、Scrum是用的最多的方法之一,其核心思想:拥抱变化,通过sprint迭代快速向客户交付可用的软件,并通过反馈来确定产品的方向,使产品利益最大化。

1.管理流程

完整的项目管理流程包含五个过程:启动、规划、执行、监控、收尾;

敏捷的项目管理框架:构想、推测、探索、适应、结束。

  • 构想阶段:确定产品的构想、项目范围、项目团队以及团队共同的工作方式。通常采用用户故事方式进行深挖;
  • 推测阶段:制定功能发布计划、里程碑和迭代计划,确保交付构想的产品(产品路线图-组件团队-项目章程-流程剪切)。通常采用故事作坊模式进行深挖和确定;
  • 探索阶段:在短期内提供可经测试的功能,不断的刺探市场\客户的反馈,减少项目的风险和不确定型;通常采用Scrum中的probacklog、看板、燃尽图、燃起图、速率等方式;
  • 适应阶段:审核当前交付的结果及当前团队的绩效、速率、通过故事点、MVP、sprint、每日站会、评审、回顾等方式来保障团队可持续性;
  • 结束阶段:终止项目,通过评审、回顾、发布来交流项目经验并庆祝;

传统项目(简称传统):对范围、速度、成本、质量、人力资源、沟通、风险、采购、干系人进行管理,每个环节都存在启动、规划、执行、监控、收尾。企图通过以不变应万变,软件行业属于高风险性行业,拥抱变化、适应变化才是一条好的路子。

敏捷型项目(简称敏捷):简化了繁琐的流程和详尽的文档,主张自组织小队、集中办公、面对面交流。以Scrum为代表:简单、持续集成、不断交付、价值优先、拥抱变化的原则面对激烈变化的市场和不断发展的技术。在敏捷中,项目被化成不同的等级:战略、产品、发布、迭代、每日站会。而交付也划分几个等级:必须有的、应该有的、可能有的、不会有的。通过迭代周期,对需求进行合理分割,并通过一个个基于时间盒的Sprint为发布做保障,降低软件风险及提高软件利益;

传统铁三角:范围、成本、进度(范围不可变)

敏捷铁三角:进度、范围、成本(进度不可变)

敏捷三角:价值、质量、三重约束(成本、进度、范围)

敏捷三角形:

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

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

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

二、风险控制

项目风险在任何一个项目中都存在,一旦发生,会对项目造成积极或消极的影响。

传统的项目管理:力求从源头杜绝风险,通过流程、详尽的文档来规划风险管理、识别风险、并对风险进行定性/定量分析,给风险出解决方案。软件行业存在不去定性,可能来自客户、市场、技术过时等突发因素,稳扎稳打的方式以无法支撑快速的变化和响应。

敏捷项目管理:敏捷项目管理不同于传统项目管理,开发评估时以工作量为导向而非时间为导向。在开发任务评估时采用相对估算而非绝对估算,其目的为风险预留对应的空间。同事Scrum集合一线人员、产品负责人、客户、利益相关者的参与,经验分享、集思广益将小型团队转化为独立的管理者,采用灵活机动的模式,更有利的解决问题。

总结:不管传统、敏捷,没有那个更好,只有符合当下团队的才是最好的。

举例:

甜甜圈为例:敏捷团队会快速向市场推出一个最低可用的产品,编写故事->迭代、交付->投放市场->收集反馈->更改计划->迭代,增量交付;依次类推;

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

原文地址:https://www.cnblogs.com/atun/p/12121420.html

时间: 2024-11-06 13:13:30

敏捷21天打卡-敏捷项目管理(终章)的相关文章

敏捷21天打卡--用户故事

在远古时代,文字没有出现之前.知识的传承靠口口相传,不管隔了多少代,其准确性很高.文字出现后,我们大脑中的这种技能反而逐步衰退.于是各种软件.各种方法充斥着我们,左右着我们.各位是否也有相同的想法?试想一下,上节课我们讲了什么?每次应允别人的承诺,我们转过头就忘记?比如忘记约会,忘记洗车.忘记写日报? “要想知道栗子的味道,你得咬一口”这个真理朴实,正确.当用户提出一款软件时,我们不要只想着从技术的角度,认为用户不专业,他的需求是错误的.如果他专业,就没我们啥事了.用户大脑中的需求是离散的,不可

敏捷21天打卡--Scrum角色

Scrum团队由一名产品负责人.开发团队.Scrum Master组成.Scrum团队是跨职能的自组织团队,团队成员自己选择如何以最好的方式完成工作,而不是由团队之外的人来指导.理论上来讲,团队拥有完成工作所需的全部技能,不需要依赖团队之外的人. Scrum团队迭代增量式交付产品,通过这种方式最大的获得反馈的机会,增量式交付”完成“产品保证一个可以工作产品的. 产品负责人PO:Product Owner角色定义,产品负责人的职责是将开发团队研发的产品价值最大化,为产品回报率负责,负责维护Prpd

敏捷21天打卡--Scrum活动

Sprint(冲刺)是Scrum的核心,持续时间为一个月或更短的时间,在这个时间内构建一个完成.可用的和潜在可发布的产品增量.在整个开发过程期间,其长度应保持一致,前一个Sprint完成后,新的下一个Sprint紧接着就开始,有点像接力棒的游戏. Sprint计划会议:会议时间不要过长,不要为了会议而会议.通常一个月内的,上线为8小时或更短:依次类推.其主要目的是确定每个参会者都理解会议的目的.敏捷教练要确保会议梳理举行并教导敏捷团队遵守时间盒规则.包含几点:这次做什么?如何完成所选的工作?期间

敏捷21天打卡-精益产品开发最佳实践 之 “AB测试"

”一个错误的背后往往存在一个正确的假设,对假设的肯定程度越高引发的错误越严重!“ 从上章节中“MVP”中一文中我们了解到,最低限度的可用的产品是MVP的精髓,其目的在于迅速验证产品的可用性及市场用户的反馈:不能市场用户需要一辆汽车,我们给对方一辆自行车,典型的违背市场的原则. 伟人曾说过“实践出真知”,对于软件行业亦是如此,有了最低限度的可用产品,这是就需要收集市场的反馈,根据反馈调整产品策略,A/B测试是众多工具/方法中的一种. “推出一个代步工具.节约用户上下班时间,从而让用户有更多的时间来

敏捷21天打卡-AARRR模型

介绍下AARRR模型,AARRR模型是Acquisition(获取).Activation(活跃).Retention(留存).Revenue(收入).Refer(传播)的缩写,对应了产品生命周期的每个阶段.而无论是那个阶段,都是围绕着中间的用户展开,为用户提供有价值的产品和服务. 获取:对于一款产品,首先要获取用户,即拉新.如果没有新用户,产品就如一潭死水,即为死水,何来繁荣之说. 活跃:产品有了用户之后,就要考虑如何让用户活跃起来.”久别重逢的老友聚会,缅怀过去光辉岁月之时,有人提议创建个群

21天敏捷打卡--敏捷方法实现

常用的敏捷实践包含:精益.看板.Scrum.XP极限编程.水晶.DSDM动态系统开发.FDD功能驱动开发.AUP敏捷统一过程.OpenUP. <敏捷实践指南>将敏捷方法和看板方法是为精益方法的子集.因为他们都符合精益思想的具体实例,都反映了“关注价值”.“小批量”.“消除浪费”. 精益软件开发LSD TPS 面对场景 解说 原则 解说 过度 对员工和生产/研发过程施加不必要的额外压力 消除浪费 无法带来价值的事务就是浪费 违规 不切实际的需求导致过生产/研发程中的不均匀 尽快交付 短期迭代或小

敏捷开发讲义---如何打造敏捷团队

PPT下载链接:http://pan.baidu.com/s/1bncprTd 敏捷开发分享讲义-修改版 第1页:个人信息 就不做自我介绍了,我的基本信息就在PPT第一页.7月26日,也就是上周六,我和会成参加了一天的培训,关于敏捷开发的.参加这次培训我们俩主动申请的,因为这次培训适合的听众除了中高层领导.项目经理.产品经理之外,还适合有软件经验希望往项目管理方向发展的人士."不想当项目经理或者项目主管的IT屌丝是真屌丝",不想成为真屌丝,所以参加了培训.但这次跟大家分享是被婷姐逼的(

【敏捷开发】详解敏捷测试

 敏捷软件开发是目前十分流行,并在业界逐步推广的软件开发模式. 不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法. 其中,敏捷测试部分也同以往的软件测试流程有所不同.这对测试人员提出了新的要求,带来了新的挑战. 第一部分:敏捷软件开发简介 敏捷软件开发(Agile Software Development)初起于九十年代中期.最早是为了与传统的瀑布软件开发模式(waterfall model)相比较,所以当时的方法叫做轻量级方法(Lightweight methods).二十世纪初

敏捷读书会; 最美的敏捷来自于.....无私的分享

最美的敏捷来自于.....无私的分享? "敏捷读书会" 将无私的分享: 敏捷好书精彩内容 敏捷实践, 工具读书心得 敏捷读书会活动 期待你的分享; 期待你的扫一扫......