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