《敏捷项目管理》阅读笔记 Part1：理解敏捷

《敏捷项目管理——从入门到精通实战指南》[美]马克·C·莱顿（Mark C. Layton） 著

Part1：理解敏捷
共包含如下章节

• 第1章 项目管理现代化
• 第2章 敏捷宣言与原则
• 第3章 为什么敏捷工作更有效

通过阅读Part1，可以知道：为什么敏捷流程能够比传统的项目管理流程运行得好

项目管理的背景：

• 项目的资源总是有限的
• 项目总是被赋予高度的期望

项目管理的目标：使项目成功
项目管理的意义：提高项目的成功率

然而，产品范围有如下特点：
很少使用和从未使用的软件特性占到64%。

传统项目管理与敏捷理念的比较

———以下为文章摘录———

敏捷项目如何运作

敏捷方法：经验控制法——根据实际项目中的实际观测而做出决策的流程。

敏捷要求：

• 透明性：每一位敏捷项目成员都知道即将做什么以及项目进展如何。
• 经常性检查：投资于产品并运行项目的人应该定期评估该产品和流程。
• 适应：对细小问题做快速调整。

敏捷宣言

可工作软件：能够工作的软件才是项目根本。
完工定义（DoD）：至少是已开发、已测试、已集成和已归档。

敏捷12原则

1. 我们最优先考虑的是尽早和持续不断地交付有价值的软件，从而使客户满意
2. 即使在开发后期也欢迎需求变更。敏捷过程利用变更可以为客户创造竞争优势
3. 采用较短的项目周期（从几周到几个月），不断地交付可工作软件
4. 业务人员和开发人员必须在整个项目期间每天工作在一起
5. 围绕富有进取心的个体而创建项目。为他们提供所需的环境和支持，信任他们所开展的工作
6. 不论团队内外，传递信息效果最好且效率最高的方式是面对面交谈
7. 可工作软件是度量进度的首要指标
8. 敏捷过程倡导可持续开发。发起人、开发人员和用户能够长期维持稳定的开发步伐
9. 坚持不懈地追求技术卓越和良好的设计，从而增强敏捷能力
10. 以简洁为本，最大限度地减少工作量
11. 最好的架构、需求和设计出自于自组织团队
12. 团队定期反思如何能够提高成效，并相应地协调和调整自身的行为

客户满意度的敏捷原则：1、2、3、4

策略：

• 在每次迭代中，首先产出最高优先级特性
• 理想情况下，把产品负责人和其他项目团队成员集中在一起办公
• 把需求分解成能够在8周（理想情况下，也可以4周）或更短时间内交付的不同特性组
• 让书面需求越少越好，推进更加积极有效的面对面地沟通
• 当每项特性完成时，获得产品负责人的批准
• 定期回顾/检查特性列表以确保最有价值的需求始终具有最高的优先级

质量的敏捷原则：1、3、4、6、7、8、9、12

策略：

• 定义“完成“什么意味着，在项目之初就使用该定义作为高质量代码的标杆
• 通过自动化方式每天进行积极的测试
• 根据需要，仅构建那些必须的特性
• 评审代码并进行精简（重构）
• 只展示已经被产品负责人验收过的功能代码
• 在每天、每个迭代以及整个项目中设置多个反馈时点

团队工作的敏捷原则：4、5、6、8、11、12

策略：

• 集中办公：把开发团队集中在同一个地点
• 团队集中在利用合作的同一物理环境中，如配有白板、彩色笔和其他有助于开发和传递想法的出卷工具的一个团队房间
• 创建一个鼓励项目团队成员说出他们想法的环境
• 尽可能面对面沟通，如果通过交谈就能处理的问题就不要采用发电子邮件的方式
• 如果需要，当日就澄清所有的疑问
• 鼓励开发团队自己解决问题，而不是让经理为开发团队解决问题

项目管理的敏捷原则：2、8、10

策略：

• 支持开发团队
• 制作“刚好够”文档
• 精简状态报告，是开发团队能够短时间就把信息推送出去，而不是让项目经理花费大量时间来提取有用信息
• 最小化非开发任务
• 树立信心，认为变更时正常且有益的，而不是要惧怕和躲闪的东西
• 采用准时机制（Just-in-time，JIT）的需求细化方式，使变更干扰或浪费工作的程度最小化
• 与项目开发团队合作，建立显示的进度计划和目标
• 保护项目团队远离组织安排的、与项目目标无关的工作，这些工作可能影响面项目目标的完成
• 理解工作与生活的适当平衡是高效开发的组成部分

附加白金原则

• 抵制形式化
• 团队思考与行动
• 可视化（图表）而非书写（文字）

作为敏捷结果的变更

• 改变了对项目管理流程的态度
• 改变了对知识员工的态度
• 改变了业务团队和IT团队的关系
• 纠正了对待变更的态度