浅谈敏捷项目管理
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
• 根据项目的特点，制订不同的项目管理的方针政策
原则六:简单有效
• 简单就是美 • 每一个活动是否都有价值? • 每一个文档是否都有价值? • 每一个度量数据是否有价值? • 是否有更简单有效的管理方法?
原则七:选择称职的项目经理
• 要公正无私 • 要有良好的职业道德 • 要具有管理的基本技能与知识 • 要具有很好的沟通与表达能力 • 要有很强的分析问题解决问题的能力 • 要懂技术，不要求精通，但是要全面 • 要谦虚，不能不懂装懂 • 要平易进人，不要摆架子
原则四:实时控制原则
逐日跟踪
• PM检查过了? • 是否自检过了? • 是否测试过了? • 是否纳入CM库了?
每日联调
原则五:分类管理
对于不同的软件项目其项目目标差别很大，项目规 模也是不同的，应用领域是不同的，采用的技术路 线差别也很大，因而，针对每个项目的不同特点， 其管理的方法、管理的侧重点应该是不同的。
反 • 在实践中我们应该如何运用80思 20定律？
软件项目管理的七个基本原则
原则一:四要素的平衡原则
原则二:高效原则
• 要选择精英成员 • 目标要明确，范围要清楚 • 沟通要及时、充分 • 要在激励成员上下工夫 • 要有充分的技术复用
原则三:分解原则
化繁为简，各个击破
• 大项目组分成几个小项目组 • 长周期分解为几个阶段 • 定义生命周期模型 • 进行WBS分解 • 版本化发布
浅谈敏捷项目管理
目录
• 软件开发的七个基本定律 • 软件项目管理的七个基本原则 • 敏捷开发的基本概念 • 为什么用敏捷 • 敏捷的基础知识 • 总结
软件开发的七个基本定律
1:10:100定律
需求错误导致的成本是修复程序错误成本的100倍
反 • 1 我们有哪些措施预防需求的错误？ 思 • 2 我们有哪些措施发现需求的错误？
敏捷开发的基本概念
理解敏捷
敏捷开发是…
“一种以人为核心、迭代、循序渐进的开发方法 ! ”
在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目 的成果都经过测试，具备可视、可集成和可运行使用的特征。
理解敏捷
敏捷开发核心价值观是什么呢？ 答案是：
沟通，简单，反馈，勇气
理解敏捷
敏捷宣言
敏捷开发的核心思想是：以人为本，适应变化。
管理层
- 公司管理层（比如总裁办公室等） - 垂直职能经理层（比如开发经理等）
Scrum物件
Product Backlog
- 所有需要完成的产品清单，包括优先级、商业诉求，PO负责
Sprint Backlog
- 由团队主动选择完成的每个Sprint需要完成的Story列表 - 每个Story包括了需求、优先级、工作量 - 一旦确定，不亦更改
• 敏捷开发中更加强调沟通，沟通成本会增加
• 敏捷开发对人员的要求更高，学习成本会增加
• 快速的迭代使重构工作量增加
• 信息的透明性要求较多的数据收集，使成本增加
正确认识敏捷开发的目的
敏捷开发是解决什么问题的呢？它是解决企业效益（ROI，投资回报率）最大化的 问题，评价敏捷开发的成功与否要从转型后企业效益的整体提升情况评价，而不能 单单从主观判断上看开发人员完成的功能数量与速度来评价，敏捷开发主要从以下 方面来帮助企业提升整体效益：
敏捷能不能提高“开发效率”？
敏捷开发不是用来解决所谓的“开发效率”问题的，如果真是开发效率可以从人的 技能培养、流程优化、工具改进等方面来提升，而跟敏捷开发本身没太大关系，敏 捷反而会降低所谓的效率。因为这里的“效率”被理解为相同的人，在更短的时间 内开发完成既定的功能，或者在相同的时间内能够开发更多的功能。原因如下：
反 • 1 在实践中，我们是否经常通过给项目组增加人手
思
的方式加快进度？ • 2 有哪些合理的加快进度的措施？
80-20定律
Boehm提出的有关软件项目管理的 “二八定 理”，构成了现代软件管理过程框架的理论基 础
• 80%的缺陷是由20%的构件引起的 • 80%的软件废品和返工是由20%的缺陷引起的 • 80%的资源是由20%的构件消耗的 • 80%的工程活动是通过20%的工具完成的 • 80%的进展是20%的人完成的
反 • 1如何规避帕金森定律？ 思 • 2如果整个项目有20%的缓冲时间，你会如何分配这
20%的缓冲？
布鲁克斯定律（Brooks’ Law）
人月=人*月，但是：月≠人月/人 投入更多的人到一项延迟的工作上，可以导致该项工作更加延迟 Barry Bohem：可以将软件开发进度压缩25%，但是不能再多了 200/20/6X现象：人数增加1倍，工期缩短20%，缺陷增加6倍
的条目 • Scrum Team将Backlog条目分解成小任务，并评估完成每个条目需要的概
时间 • Product Owner和Scrum Team共同调整和决定下一个Sprint Backl仪式 – 每日站立会议
最好在每天早上，时间控制 在15分钟 每天在同一时间、同一地点 三个问题：昨天完成了什么； 今天计划做什么；遇到哪些 障碍 Scrum Master更新燃尽图 谁都可以参加，但只允许团 队成员发言，其他人只能旁 听
• 2 我们在需求开发、设计过程中为了降低维 护的成本采取了哪些措施？
Weinberg可靠性零定律
如果一个系统不要求是可靠的，那么它能够满足任何 的其他目的
换句话说，如果对实际工作的程序没有要求，那么你 能满足任何设置的编程交付期
反 • 在限定了资源，而项目工期又比较紧张时，我们
思
通常牺牲了什么？我们是否真的加快了进度呢？
向PO和利益相关人演示工作成果（可运行的软件） 团队自我管理、持续改进
一般由5-9名跨功能领域人员组成 坐在一起工作 有共同的目标，共担责任 团队成员严格遵守团队规则
非Scrum角色 - “鸡”
利益相关者（客户，供应商）
- 产品使用者、项目相关者 - 仅在Sprint回顾展示中参加会议 - 经理 - 设置环境的产品开发组织
• 拥抱变化 • 快速响应 • 快速将功能推向市场变现 • 在有限的资源条件下，做最值得做的事
拥抱变化
• 唯一不变的就是—变化 • 长期的计划很难制定得可行 • “人月神话”只是个神话，需求的变化不可避免 • “人”本身就是变化的因素
快速响应
• 市场环境的变化需产品服务及时响应 • 传统方式变化的成本奇高
• 3 我们的质量成本是如何分布的？
改进质量的途径- 尽早消除缺陷
缺陷数
需求
设计
编码
单元测试 集成测试 系统测试 交付使用
在总体注入缺陷相同的情况下，尽早地消除缺陷可以使交付 产品的质量大大提高
1:2定律
在开发中，每花费1美元，在维护中就得花费2美 元，因此要注意度量改进维护的度量元
反 思
• 1 在我们公司的项目中维护成本与开发成本 的比例是多少？
迭代
每2-6周
新的功能 增量
可运行的软件
迭代规划会议 Sprint Plan
一般不超过8小时。 前4个小时：产品负责人向团队展示 最高优先级的产品，团队则向他询问 产品Backlog的内容、目的、含义及 意图。 后4小时：团队计划本Sprint的安排
迭代复审会议 Sprint Review
一般4个小时，由团队成员 向产品负责人额其他利益 相关人展示Sprint周期内 的产品开发情况
清单和优先级
除了客户需求之外，内部任务如 重构、持续集成环境搭建等也由 PO纳入统一管理
辅导团队正确应用敏捷实践 引导团队建立并遵守规则 保护团队不受打扰 推动解决团队遇到的障碍 激励团队
不命令和控制Team
Team（开发团 队）
负责产品需求 实现
负责估计工作量并根据自身能力找出最佳方案去完成 任务且保证交付质量
迭代回顾会议 Sprint Retrospective
一般3个小时， Scrum Master将鼓 励团队在SCRUM过程框架和实践范 围内，对开发过程做出修改，使它 在下一个Sprint周期中更加有效和 令人愉快
产品负责人
Scrum主管
开发团队
Scrum要素
Scrum的角色
Scrum角色分类 - 各种“猪”
敏捷开发流程
产品订单 Product Backlog
迭代订单 Sprint Backlog
高优先级
工作项 分解
Daily SCRUM
每24 小时
每日站立会议 Daily Scrum Meeting
在简会上，每个成员主要回答三个问题; –自上次SCRUM简会后的一天了（昨天）， 你做了什么? –从现在到下次SCRUM简会的一天里（今 天），你要做什么? –在实现SCRUM及项目目标的工作中，你遇 到哪些困难吗?
备注
Scrum物件-SprintBacklog
拆分Backlog
一个Item拆分成若干个 Task
估算故事点
每个Task的故事点不超过 8小时的工作量
Scrum物件-Sprint Burn down
横轴
时间(天)
纵轴
故事点
更新
每日站会后
Scrum看板
Scrum仪式 - sprint计划会议
• 每个Sprint开始前召开，参加人员有PO、SM、ST和其他感兴趣的人 • Product Owner按重要性从产品Backlog中挑选待加入Sprint Backlog中
Scrum角色职责
角色名称 角色定义
角色职责
注意事项
Product Owner 确保Team做正 （产品负责人） 确的事
Scrum Master 确保Team正确 （Scrum教练） 地做事
代表利益相关人（如用户、Marketing、用服、管理 者等），对产品投资回报负责
确定产品发布计划 定义产品需求并确定优先级 验收迭代结果，并根据验收结果和需求变化刷新需求
Product Owner
- 传递来自市场的声音、提升项目的回报 - 确定产品Backlog中的优先级 - 从产品的角度确保团队工作方向
Scrum Master
- 管理Scrum流程，确保Scrum运转 - 确保每个Sprint目标的实现与产出，不受外界干扰
团队
- 由5-9人组成（开发，测试等）、评估每个Sprint工作
Scrum仪式 – sprint评审会议
了解
相关人员获得团队和项目最新进展的直接印象
反馈
客户或Product Owner对阶段性成果提出反馈
激励
演示可以工作的软件，鼓舞团队士气
原则
我们交付的是可以工作的软件，而不是口头的功能完成
Scrum仪式 – sprint回顾会议
• 上个Sprint哪些地方做得好，继续保持 • 上个Sprint哪些地方做得不好，改进措施 原则：
当前市场环境要求能在成本可控范围内，产品和服务能及时响应市场多变的 需求
快速将功能推向市场变现
• 成为第一，胜过做得最好 • 敏捷真正的价值在于能快速交付，赢得市场契机
在有限的资源条件下，做最值得做的事
• 因为Backlog的每一项都具有按唯一优先级顺序 • ROI是评价需求优先级的唯一指标
敏捷的基础知识
1:3:9定律
随着软件系统规模的增大，其成本成倍增长，呈现 1:3:9的关系，称之为软件产业的非规模经济现象
反 • 1 我们如何降低软件的开发成本？
思
• 2 为什么提倡采用迭代的生命周期模型？ • 3 为什么提倡小项目、小团队？
帕金森定律（Parkinson’s Law）
工作总是用完所有可利用的时间（Work expands to fill the time available） 如果你给自己安排了充裕的时间从事一项工作，你会放慢你 的节奏以便用掉所有分配的时间 容易达到的目标将使员工工作上变得松懈
Sprint Burn down
- 显示工作量趋势变化的图表 - 每天由Scrum Master更新
Scrum物件-product backlog
ID
一个唯一的标示
名称
简单描述
重要性
相对值(10和11没有区别)
故事点
相对值(10点的工作量是5 点的两倍) 也可以用人天来估算
完成定义
如何演示 性能指标数据
谁在用敏捷
为什么用敏捷
传统瀑布型开发模式风险
• 用户只有 等到开发 后期才能 看到结果
早期的错误 要等到后期 测试才能发
现
敏捷更符合软件开发规律
传统开发
敏捷开发 • 软件更像一个活着的植物，软件开发是自底向上逐步有序的生长过程，类似于植物自然生长 • 敏捷开发遵循软件客观规律，不断的进行迭代增量开发，最终交付符合客户价值的产品
原则六:简单有效
• 简单就是美 • 每一个活动是否都有价值? • 每一个文档是否都有价值? • 每一个度量数据是否有价值? • 是否有更简单有效的管理方法?
原则七:选择称职的项目经理
• 要公正无私 • 要有良好的职业道德 • 要具有管理的基本技能与知识 • 要具有很好的沟通与表达能力 • 要有很强的分析问题解决问题的能力 • 要懂技术，不要求精通，但是要全面 • 要谦虚，不能不懂装懂 • 要平易进人，不要摆架子
原则四:实时控制原则
逐日跟踪
• PM检查过了? • 是否自检过了? • 是否测试过了? • 是否纳入CM库了?
每日联调
原则五:分类管理
对于不同的软件项目其项目目标差别很大，项目规 模也是不同的，应用领域是不同的，采用的技术路 线差别也很大，因而，针对每个项目的不同特点， 其管理的方法、管理的侧重点应该是不同的。
反 • 在实践中我们应该如何运用80思 20定律？
软件项目管理的七个基本原则
原则一:四要素的平衡原则
原则二:高效原则
• 要选择精英成员 • 目标要明确，范围要清楚 • 沟通要及时、充分 • 要在激励成员上下工夫 • 要有充分的技术复用
原则三:分解原则
化繁为简，各个击破
• 大项目组分成几个小项目组 • 长周期分解为几个阶段 • 定义生命周期模型 • 进行WBS分解 • 版本化发布
浅谈敏捷项目管理
目录
• 软件开发的七个基本定律 • 软件项目管理的七个基本原则 • 敏捷开发的基本概念 • 为什么用敏捷 • 敏捷的基础知识 • 总结
软件开发的七个基本定律
1:10:100定律
需求错误导致的成本是修复程序错误成本的100倍
反 • 1 我们有哪些措施预防需求的错误？ 思 • 2 我们有哪些措施发现需求的错误？
敏捷开发的基本概念
理解敏捷
敏捷开发是…
“一种以人为核心、迭代、循序渐进的开发方法 ! ”
在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目 的成果都经过测试，具备可视、可集成和可运行使用的特征。
理解敏捷
敏捷开发核心价值观是什么呢？ 答案是：
沟通，简单，反馈，勇气
理解敏捷
敏捷宣言
敏捷开发的核心思想是：以人为本，适应变化。
管理层
- 公司管理层（比如总裁办公室等） - 垂直职能经理层（比如开发经理等）
Scrum物件
Product Backlog
- 所有需要完成的产品清单，包括优先级、商业诉求，PO负责
Sprint Backlog
- 由团队主动选择完成的每个Sprint需要完成的Story列表 - 每个Story包括了需求、优先级、工作量 - 一旦确定，不亦更改
• 敏捷开发中更加强调沟通，沟通成本会增加
• 敏捷开发对人员的要求更高，学习成本会增加
• 快速的迭代使重构工作量增加
• 信息的透明性要求较多的数据收集，使成本增加
正确认识敏捷开发的目的
敏捷开发是解决什么问题的呢？它是解决企业效益（ROI，投资回报率）最大化的 问题，评价敏捷开发的成功与否要从转型后企业效益的整体提升情况评价，而不能 单单从主观判断上看开发人员完成的功能数量与速度来评价，敏捷开发主要从以下 方面来帮助企业提升整体效益：
敏捷能不能提高“开发效率”？
敏捷开发不是用来解决所谓的“开发效率”问题的，如果真是开发效率可以从人的 技能培养、流程优化、工具改进等方面来提升，而跟敏捷开发本身没太大关系，敏 捷反而会降低所谓的效率。因为这里的“效率”被理解为相同的人，在更短的时间 内开发完成既定的功能，或者在相同的时间内能够开发更多的功能。原因如下：
反 • 1 在实践中，我们是否经常通过给项目组增加人手
思
的方式加快进度？ • 2 有哪些合理的加快进度的措施？
80-20定律
Boehm提出的有关软件项目管理的 “二八定 理”，构成了现代软件管理过程框架的理论基 础
• 80%的缺陷是由20%的构件引起的 • 80%的软件废品和返工是由20%的缺陷引起的 • 80%的资源是由20%的构件消耗的 • 80%的工程活动是通过20%的工具完成的 • 80%的进展是20%的人完成的
反 • 1如何规避帕金森定律？ 思 • 2如果整个项目有20%的缓冲时间，你会如何分配这
20%的缓冲？
布鲁克斯定律（Brooks’ Law）
人月=人*月，但是：月≠人月/人 投入更多的人到一项延迟的工作上，可以导致该项工作更加延迟 Barry Bohem：可以将软件开发进度压缩25%，但是不能再多了 200/20/6X现象：人数增加1倍，工期缩短20%，缺陷增加6倍
的条目 • Scrum Team将Backlog条目分解成小任务，并评估完成每个条目需要的概
时间 • Product Owner和Scrum Team共同调整和决定下一个Sprint Backl仪式 – 每日站立会议
最好在每天早上，时间控制 在15分钟 每天在同一时间、同一地点 三个问题：昨天完成了什么； 今天计划做什么；遇到哪些 障碍 Scrum Master更新燃尽图 谁都可以参加，但只允许团 队成员发言，其他人只能旁 听
• 2 我们在需求开发、设计过程中为了降低维 护的成本采取了哪些措施？
Weinberg可靠性零定律
如果一个系统不要求是可靠的，那么它能够满足任何 的其他目的
换句话说，如果对实际工作的程序没有要求，那么你 能满足任何设置的编程交付期
反 • 在限定了资源，而项目工期又比较紧张时，我们
思
通常牺牲了什么？我们是否真的加快了进度呢？
向PO和利益相关人演示工作成果（可运行的软件） 团队自我管理、持续改进
一般由5-9名跨功能领域人员组成 坐在一起工作 有共同的目标，共担责任 团队成员严格遵守团队规则
非Scrum角色 - “鸡”
利益相关者（客户，供应商）
- 产品使用者、项目相关者 - 仅在Sprint回顾展示中参加会议 - 经理 - 设置环境的产品开发组织
• 拥抱变化 • 快速响应 • 快速将功能推向市场变现 • 在有限的资源条件下，做最值得做的事
拥抱变化
• 唯一不变的就是—变化 • 长期的计划很难制定得可行 • “人月神话”只是个神话，需求的变化不可避免 • “人”本身就是变化的因素
快速响应
• 市场环境的变化需产品服务及时响应 • 传统方式变化的成本奇高
• 3 我们的质量成本是如何分布的？
改进质量的途径- 尽早消除缺陷
缺陷数
需求
设计
编码
单元测试 集成测试 系统测试 交付使用
在总体注入缺陷相同的情况下，尽早地消除缺陷可以使交付 产品的质量大大提高
1:2定律
在开发中，每花费1美元，在维护中就得花费2美 元，因此要注意度量改进维护的度量元
反 思
• 1 在我们公司的项目中维护成本与开发成本 的比例是多少？
迭代
每2-6周
新的功能 增量
可运行的软件
迭代规划会议 Sprint Plan
一般不超过8小时。 前4个小时：产品负责人向团队展示 最高优先级的产品，团队则向他询问 产品Backlog的内容、目的、含义及 意图。 后4小时：团队计划本Sprint的安排
迭代复审会议 Sprint Review
一般4个小时，由团队成员 向产品负责人额其他利益 相关人展示Sprint周期内 的产品开发情况
清单和优先级
除了客户需求之外，内部任务如 重构、持续集成环境搭建等也由 PO纳入统一管理
辅导团队正确应用敏捷实践 引导团队建立并遵守规则 保护团队不受打扰 推动解决团队遇到的障碍 激励团队
不命令和控制Team
Team（开发团 队）
负责产品需求 实现
负责估计工作量并根据自身能力找出最佳方案去完成 任务且保证交付质量
迭代回顾会议 Sprint Retrospective
一般3个小时， Scrum Master将鼓 励团队在SCRUM过程框架和实践范 围内，对开发过程做出修改，使它 在下一个Sprint周期中更加有效和 令人愉快
产品负责人
Scrum主管
开发团队
Scrum要素
Scrum的角色
Scrum角色分类 - 各种“猪”
敏捷开发流程
产品订单 Product Backlog
迭代订单 Sprint Backlog
高优先级
工作项 分解
Daily SCRUM
每24 小时
每日站立会议 Daily Scrum Meeting
在简会上，每个成员主要回答三个问题; –自上次SCRUM简会后的一天了（昨天）， 你做了什么? –从现在到下次SCRUM简会的一天里（今 天），你要做什么? –在实现SCRUM及项目目标的工作中，你遇 到哪些困难吗?
备注
Scrum物件-SprintBacklog
拆分Backlog
一个Item拆分成若干个 Task
估算故事点
每个Task的故事点不超过 8小时的工作量
Scrum物件-Sprint Burn down
横轴
时间(天)
纵轴
故事点
更新
每日站会后
Scrum看板
Scrum仪式 - sprint计划会议
• 每个Sprint开始前召开，参加人员有PO、SM、ST和其他感兴趣的人 • Product Owner按重要性从产品Backlog中挑选待加入Sprint Backlog中
Scrum角色职责
角色名称 角色定义
角色职责
注意事项
Product Owner 确保Team做正 （产品负责人） 确的事
Scrum Master 确保Team正确 （Scrum教练） 地做事
代表利益相关人（如用户、Marketing、用服、管理 者等），对产品投资回报负责
确定产品发布计划 定义产品需求并确定优先级 验收迭代结果，并根据验收结果和需求变化刷新需求
Product Owner
- 传递来自市场的声音、提升项目的回报 - 确定产品Backlog中的优先级 - 从产品的角度确保团队工作方向
Scrum Master
- 管理Scrum流程，确保Scrum运转 - 确保每个Sprint目标的实现与产出，不受外界干扰
团队
- 由5-9人组成（开发，测试等）、评估每个Sprint工作
Scrum仪式 – sprint评审会议
了解
相关人员获得团队和项目最新进展的直接印象
反馈
客户或Product Owner对阶段性成果提出反馈
激励
演示可以工作的软件，鼓舞团队士气
原则
我们交付的是可以工作的软件，而不是口头的功能完成
Scrum仪式 – sprint回顾会议
• 上个Sprint哪些地方做得好，继续保持 • 上个Sprint哪些地方做得不好，改进措施 原则：
当前市场环境要求能在成本可控范围内，产品和服务能及时响应市场多变的 需求
快速将功能推向市场变现
• 成为第一，胜过做得最好 • 敏捷真正的价值在于能快速交付，赢得市场契机
在有限的资源条件下，做最值得做的事
• 因为Backlog的每一项都具有按唯一优先级顺序 • ROI是评价需求优先级的唯一指标
敏捷的基础知识
1:3:9定律
随着软件系统规模的增大，其成本成倍增长，呈现 1:3:9的关系，称之为软件产业的非规模经济现象
反 • 1 我们如何降低软件的开发成本？
思
• 2 为什么提倡采用迭代的生命周期模型？ • 3 为什么提倡小项目、小团队？
帕金森定律（Parkinson’s Law）
工作总是用完所有可利用的时间（Work expands to fill the time available） 如果你给自己安排了充裕的时间从事一项工作，你会放慢你 的节奏以便用掉所有分配的时间 容易达到的目标将使员工工作上变得松懈
Sprint Burn down
- 显示工作量趋势变化的图表 - 每天由Scrum Master更新
Scrum物件-product backlog
ID
一个唯一的标示
名称
简单描述
重要性
相对值(10和11没有区别)
故事点
相对值(10点的工作量是5 点的两倍) 也可以用人天来估算
完成定义
如何演示 性能指标数据
谁在用敏捷
为什么用敏捷
传统瀑布型开发模式风险
• 用户只有 等到开发 后期才能 看到结果
早期的错误 要等到后期 测试才能发
现
敏捷更符合软件开发规律
传统开发
敏捷开发 • 软件更像一个活着的植物，软件开发是自底向上逐步有序的生长过程，类似于植物自然生长 • 敏捷开发遵循软件客观规律，不断的进行迭代增量开发，最终交付符合客户价值的产品