1.1 传统瀑布式的工作方式
有太多的项目面临这样的困境：进度落后，预算超标，质量低下，甚至最终成果不是客户想要的产品。造成这样的困境，并非因为相关人员不聪明，不是因为用错了技术，也不是因为缺少职业道德或外部竞争。
1.1.1 问题出在工作方式上。我们在投标前先坐下来审视所有的需求，然后开始规划如何开发一套能满足所有需求的系统。我们拥有很多才华横溢的员工，他们连续几个月去规划要做哪些事情，绘制出很多美观的图片，解释每一件必须要做的事，以环环相扣的方式展示整个项目的各个部分，即甘特图。随着产品复杂程度越来越高，甘特图甚至变成了一种艺术品，整个项目中的每一个步骤，每一个里程碑以及日期都详细地列了出来。这种图的确令人印象深刻，多方统一后，我们开始跟随甘特图进行工作。可惜这种图唯一的问题就在于，它们往往是错误的，无法真正得到落实。艾森豪威尔将军曾说“战斗规划是很重要的，可一旦第一枪打响后，你的规划就会烟消云散”。
1.1.2 有时报告本身的重要性甚至超越了事实的重要性。
1.1.3 如果报告与现实情况有差别，人们普遍认为问题出在现实上，而图表是正确的。
1.1.4 瀑布式的工作方式，通过大量文件和图表，希望实现项目管理的两个目标：可控性和可预测性。这种美好的设想往往不会变成现实。虽然付出了大量努力去规划细节，限制潜在变化，并预测未知因素，但试图把人类行为限制在图形和曲线里，本身就是一种愚蠢的做法。每一个项目都需要人们去发现新问题，激发自己的灵感。
1.2 一种新思维Scrum
1.2.1 Scrum，是敏捷开发流程，源于橄榄球运动的术语，原意是团队通力合作，在场地内传球。这个过程需要认真配合，信念一致和目标明确。究其本质而言，Scrum方法很简单，即检查与调整循环：无论什么时候启动一个项目，为什么不经常检查自己正在做的事情，是否朝着正确的方向前进？结果是不是大家希望看到的？是否有办法改善目标正在做的事情？如何才能做的更好？存在哪些潜在障碍？（从我目前的认知来看，敏捷开发很类似《快速软件开发》中描述的“渐进交付”和“螺旋形生命期”的配合。渐进交付的优点是通过每次迭代得到实时反馈，再在下一个交付期里调整和融合反馈意见，类似敏捷里说的冲刺和回顾；螺旋形生命期则是基于风险降低的考虑，类似敏捷里说的障碍。）
1.2.2 敏捷软件开发的价值：人胜过流程，可用的产品胜过面面俱到的文件，客户合作胜过合同谈判，应对变化胜过遵循计划。
1.2.3 基本流程(可类比PMP)
1.2.3.1 列出需求
可以采用用户故事的方式。
1.2.3.2 确定需求的优先顺序
谨记28原则。这一步比我们想象的更加困难，也更加重要。因为通常人们会说每一个需求都重要。这时你需要问自己，究竟哪些任务能给整个项目带来最大的价值。
1.2.3.3 明确和消除障碍
1.2.3.4 设计冲刺周期
确保每一次迭代都可以产出可以交付的产品。周期内的任务必须在规定期限内完成。
1.2.3.5 冲刺Sprint
冲刺结束的同时，展示给关心成果的人审阅并获取反馈。在冲刺时，明确每个任务只有两个状态：完成和未完成。
1.2.3.6 回顾
在每一个冲刺结束之前，还要聚在一起开个评估会，给产品负责人演示取得的成果，并接受评估意见。他们会评估列表上的任务完成了多少，是领取了太多任务还是领取得太少，这样大家对速度会有一个基本的认知。在评估成果时，不只是讨论过去做了什么，还会思考以下问题：接下来的冲刺如何更好的合作？上阶段出现了什么障碍？哪些障碍拖累了工作进度？
1.2.3 Scrum的强大之处，在于展示，即定期展示成果。
1.3 本章要点
1.3.1 规划是有用的，但盲目遵循规划则是愚蠢的。
1.3.2 检查与调整
每过一小段时间就停一停手里的工作，检查已经完成了哪些任务，看看有没有更好的方法。
