第一部分 理解敏捷
第1章 项目管理现代化
1.理解为何项目管理需要变革
在敏捷项目管理方式之前的瀑布式项目管理因为在项目的需求、设计、开发、集成、测试、部署阶段，只有前一个阶段完成后，才能进入下一阶段，导致在项目初期做了看起来需要的功能，随着技术的发展，出现了范围膨胀（软件投产后实际被使用到的特性比例很低），造成了大量资源的浪费。
2.了解敏捷项目管理
（1）敏捷项目管理遵循敏捷宣言和敏捷原则
（2）敏捷项目的运作方式：将整个项目按照迭代的方式（按优先级分解成更小的片段后）执行每个阶段。
第2章 敏捷宣言与原则
1.定义敏捷宣言与敏捷12原则
（1）敏捷宣言
What：一份对核心开发价值的刻意精简的表述，聚焦于人、沟通、产品、灵活性。
敏捷软件开发宣言
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。
How：
a.个体和互动高于流程和工具：即以人为本，强调每位成员和整个团队的价值，精简流程并使之直接支持产品创造，令人们更专注于参与、沟通、创新、解决问题；
b.工作的软件高于详尽的文档：首先，根据完工定义，只有生产出来能够投入使用了的产品或模块才能作为完成标准；另一方面，应专注于支持产品开发所必需的文档，这些文档要精简、易维护、及时发现潜在问题。其中在编写文档时，可以用“5Why”方法（至少问五次为什么需要该文档）进行自查。
c.客户合作高于合同谈判：不像传统方法中在开始时就与客户谈判全部合同细节，而是在项目进行时让客户向伙伴一样参与进来，时时跟进、变更。
d.响应变化高于遵循计划：不盲从于长期计划，而是在每个阶段关注变更，快速响应客户、产品用户和市场，这种方式也降低了变更的成本和风险 。
（2）敏捷12原则
2.附加白金原则
抵制形式化
团队思考与行动
可视化而非书写
（1）抵制形式化
Why：即使是最敏捷的项目团队也可能遇到如，等到安排好的会议才讨论本来可以很快解决的简单问题，等过度形式化的情况。
How：经常质疑形式化和没必要的华丽展示；
减少组织层级，尽可能去掉项目团队的头衔；
避免美工方面的投资；
确定并引导那些可能对负责工作成本的展示有要求的干系人。
（2）团队思考与行动
What：抛开个体的立场和绩效指标，整个团队有主人翁意识并对目标和承诺的时间负责。
Why：让团队整体更富有成效。
How：结对开发并经常交换伙伴，开发+开发or开发+策划等；
用“产品开发者”头衔代替不同头衔；
只在项目团队层级汇报项目，反对创建细分团队的特别管理报告；
以项目绩效指标替代个体绩效指标。
（3）可视化而非书写
Why：亲手体验效果>图形化演示（图表、草图、建模等等）>文字表述，我们和客户都能更好地结合内容和概念。
How：在工作环境中保证绘图工具随手可得；
使用模型而非文字来沟通概念；
使用图表、图形和仪表板汇报项目状态。、
3.理解敏捷改变了什么
（1）对项目管理流程的态度
传统——方法论者开发出一套用于所有条件下的通用流程；
敏捷——过多的流程是问题而非解决方案，没种场合都会有起正确的流程和数量。
（2）对知识员工的态度
传统——开发团队成员时可任意支配的资源；
敏捷——同样产品、不同成员将创造不一样的结果，那些用技能、天资和创新的个体将使得每个项目有所不同；
（3）业务团队和IT团队的关系
传统——业务和IT相分离；
敏捷——组成同一个项目团队，拥有同等参与度和目标；
（4）对待变更的态度
传统——视变更为一种需要避免或最小化的问题；
敏捷——变更能确保大部分好的想法得到实现。
4.敏捷石蕊测试
（1）我们此刻的所作所为是否能够对尽早的和持续的交付有价值的软件提供支持？
（2）我们的流程是否欢迎变更并能够从变更中获得好处？
（3）我们的流程是否能够引导并支持可工作软件的交付？
（4）开发人员和产品负责人是否每日在一起工作？客户和业务干系人是否与项目团队紧密工作？
（5）为促进工作开展，我们的环境是否给予开发团队所需的支持？
（6）我们面对面的沟通是否比电话和电子邮件沟通更多？
（7）我们是否通过所开发的可工作软件数量来度量进展？
（8）我们是否能够长期维持这样的前进步伐？
（9）我们是否支持考虑未来变更的卓越技术和良好设计？
（10）我们是否最小化了不必要工作量——换言之，为实现项目目标只做尽可能少的必要的工作？
（11）这个开发团队是否是自组织与自管理？他们是否有迈向成功的自由？
（12）我们是否进行定期的反思并相应的调整我们的行为？
