【美】杰夫·萨瑟兰
本科时期学的是软件工程，除了学习基础的计算机知识外，软件工程和项目管理方面的内容也学了不少。当时有一门课讲的就是敏捷开发。那时候做项目少，课程学完了，除了记住一堆术语外，倒是没有很多的感触。
后来进入公司，做了大量的项目，再来看看敏捷开发，确实有了很多感想。《敏捷革命》这本书的作者是《敏捷软件开发宣言》的参与人之一，也是Scrum的创始人。作者的履历我没有细查过，按照书中的描述，当过军人，做过科研，成为商人，做过大量项目，总之是一个牛人了。最近有一个感悟，很多人解决了很多问题，总结出一套方案，给这套方案起了一个名字，然后开公司，售卖方案或者咨询服务。这是笔买卖，所以很多的方案总有吹嘘的成分，能不能带来帮助不知道，卖出去了就算成功了。现在看书的时候，我总会去思考一下是不是真的如同这个人所描述的，有如此的价值。
这本书我是建议阅读的，因为里面的很多思想与我目前的看法一致，其中里面有很重要的一个核心点：做事-反思与优化。Scrum将这个核心点进行拆解，并且提出了一些可行的方案来保证这个核心点的实现。其实曾子也说过：吾日三省吾身。反思与优化这个事情真的是很重要，能持之以恒坚持做这个事情的人更为难得。
Scrum阐述的是个理念，方案不重要，能够实现预期结果是最重要的。当然，如果自己没有足够的阅历和学识，先用作者提供的方案也不失为一个好方法。
这里提一点，Scrum不光适用于软件工程上，它适应于各个方面，因为任何事情只要能做到“做事-反思与优化”，总会有很大的提升。
那么作者是建议如何进行Scrum的呢？
1.挑选一位产品负责人
2.挑选一个团队
3.挑选Scrum主管
- 身份为项目负责人
- 负责每日例会、冲刺规划会、协调进度、帮助大家解决问题等
4.拟定待办事项清单，并确定优先顺序 - 将项目进行拆分为功能点
- 和产品负责人协商优先级，并和各个团队确认
5.改进和评估待办事项清单 - 最终和产品负责人、各个团队确定好待办事情清单
- 对清单上的内容进行打分，分数是工作大小的单位，打分可以使用扑克牌，取斐波那契数列，开发同学出牌，取平均值
- 如果已经确定了排期，可以把打分当做重新过排期的操作
- 使用斐波那契数列1 2 3 5 8，对应为半个理想人天，单个事情清单不易超过8
- 同一个功能块，至少需要2人出牌，开发人员走完所有功能
- 理论上每人每周处理10点左右
- 排期主要给外部同事看，我们也需要遵循这个时间点，保证时间点内完成。在内部，我们按照点数进行进展，点数理论上需要比排期更快
6.冲刺规划会
- 和各个组确定冲刺内容，并计算该冲刺内容的总分数
- 最好每个规划会都能提高完成分数
- 每一个冲刺循环时间长度固定，1个星期或者两个星期
7.工作透明化 - 将功能点设置为待办事项、在办事项、完成事项
- 每天及时更新大家的进度
8.每日立会 - 15分钟 - Scrum主管组织
- 一般问三个问题：昨天做了什么，今天打算做什么，有什么阻碍
- 更新事项状态
9.冲刺展示 - 给产品负责人展示成果
10.冲刺回顾 - 确定有哪些需要改善，确定一个点进行改善
- 检验改善
11.上一个冲刺阶段结束之后，立即开始新的冲刺阶段
上面讲述的流程实用性比较高，几乎可以直接拿来使用。不过有几个点可能需要注意一下
- 需要确保相关人员focus on这个项目，不要被其他项目打扰
- 分数的估算相对困难一些，需要和大家一起确定出比较好的方案
- 迭代一轮后产生的成果，需要测试或者产品同学进行检验，这就需要其他team的同学也是敏捷的。整个组织是否能支撑起敏捷需要通盘考虑。
最后，特别喜欢书中的一段话，这里送给大家：重要的从不是那些在一旁指手画脚的人，不是那些对别人的失败品头论足的人，更不是那些指责别人如何可以做得更好的人。荣耀属于那些真正站在竞技场里打拼的人：他们满面灰尘，浸透着汗渍和血迹；他们英勇无畏；他们一遍又一遍地犯错跌倒，因为这路上一定伴随着打击，即便如此他们依然奋力向前；他们理解何为执着和专注；他们献身于崇高的事业；在最好的情况下，他们最终品尝了伟大的胜利和成就；在最坏的情况下，即使他们失败了，至少他们也是伟大地倒下，因为那些自始至终从不知道胜利或者失败的、冷漠和胆怯的灵魂远远不能与他们相提并论。