敏捷项目管理21天学习计划--终章

83 阅读 0 评论 55 点赞

我是靠谱客的博主无私皮带，最近开发中收集的这篇文章主要介绍敏捷项目管理21天学习计划--终章，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

软件项目管理的两大主流管理模式：传统项目管理（预测型项目管理）、敏捷项目管理；

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

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

1.管理流程

完整的项目管理流程包含五个过程：启动、规划、执行、监控、收尾；
敏捷的项目管理框架：构想、推测、探索、适应、结束。
构想阶段：确定产品的构想、项目范围、项目团队以及团队共同的工作方式。通常采用用户故事方式进行深挖；
推测阶段：制定功能发布计划、里程碑和迭代计划，确保交付构想的产品（产品路线图-组件团队-项目章程-流程剪切）。通常采用故事作坊模式进行深挖和确定需求；
探索阶段：在短期内提供可经测试的功能，不断的刺探市场客户的反馈，减少项目的风险和不确定型；通常采用Scrum中的probacklog、看板、燃尽图、燃起图、速率等方式；
适应阶段：审核当前交付的结果及当前团队的绩效、速率、通过故事点、MVP、sprint、每日站会、评审、回顾等方式来保障团队可持续性；
结束阶段：终止项目，通过评审、回顾、发布来交流项目经验并庆祝；

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

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

传统铁三角：范围、成本、进度（范围不可变）

敏捷铁三角：进度、范围、成本（进度不可变）

敏捷三角：价值、质量、三重约束（成本、进度、范围）

敏捷三角形：

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

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

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

二、风险控制

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

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

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

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

举例：

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

sprint