作为一个中年宅男，我总想把有限生命用来多看些东西，多写些代码，只与电脑打交道，避免与人打交道，对团队管理方式什么的基本不懂，总觉得管理别人就是浪费自己的时间，我更喜欢在别人的管理（关爱）下，毫无顾虑的写代码。 不过最近从朋友口中听到了敏捷开发的概念，就从京东凑单了一本

《敏捷革命：提升个人创造力与企业效率的全新协作模式》

这本书里有一个研究是说，一个厉害程序员的效率可能是一个差的程序员效率的10 倍，但一个好的团队与一个差的团队之间的效率差距可以达到 2000 倍。

也就是说即使把团队里所有的程序员都换成最牛逼的，也只能提升 10 倍效率，但如果可以把团队合作改进一点点的话，则在效率上会有非常大的提升。

虽然我本身对团队管理方法相关的东西不感冒，但回想过去 10 多年的程序员生涯里，我加入过很多团队，有高大上的外企，也有小黑屋式黑作坊，遇到过特别好的领导，也见过非常蠢的。见识过各种各样的管理方式，可惜始终没有机会加入一个特别高效的敏捷团队。

其实也不意外，目前全中国最有钱的公司如阿里腾讯，他们理应有最厉害的管理人才，可是也在奉行 996 的管理方式，以办公楼半夜还灯火通明为荣。先不说 996 是好是坏，在生理上，一个人一天的精力是有限的，强行把这个精力拉长到 12 小时，就注定是低效率的。作为硬件的身体撑 12 小时一般人还是可以的，但让大脑这个软件连续工作 12 小时是不现实的，这种低效率的开发方式与敏捷开发是相悖的。这本书第五章里有一节的标题就是工时越长，效率越低

...工作时间太长的人会开始犯错，正如我们先前提到的那样，改正错误可能会比创造新成绩花费更多的时间。工作超出负荷的员工比较不容易集中注意力，而且会影响别人也跟着分心，不久之后他们就会开始做出错误的决策。

我之前实验过番茄工作法，番茄工作法要求在工作时完全投入，测试下来，我每天平均能完成 10 个番茄钟已经谢天谢地非常满意了，不管那天在电脑前坐多久，我自己统计的每天有效工作大概都在 10 个番茄钟以内，一般只有 8 个。现在看到书中这个图，跟我认知也差不多，单纯的增加工作时长，并不能完成更多的工作量，反而会更少。

就像本书原版书名《The Art of Doing Twice the Work in Half the Time》（《事半功倍的艺术》）一样，我觉得所有的管理者都应该仔细学习学习敏捷开发方法，努力提高效率，把工时减半，避免进入无限延长工作时间的误区中。这本书中有大量转为使用敏捷开发而使项目成功的例子参考。

Scrum 方法要求参与者摒弃哪中只衡量工时的思维，因为工时只代表着一种成本。相反，我们应该更多的关注产出。为什么要关注一个人用多久才完成一项任务呢？只要关注完成任务的速度和质量就足够了，这才是唯一重要的事情。

那什么是敏捷开发呢？

敏捷开发其实很简单，在 youtube 上搜一下 scrum 关键字，会有一个 7 分钟和一个 10 分钟解释敏捷开发的视频，已经把敏捷开发解释的很明白了。

敏捷开发是相对于传统瀑布流式开发而提出的，瀑布流式开发是指预先把项目整体规划好，然后根据一步一步开发的模式。

而敏捷开发是免去了人类不擅长的规划步骤，先做出一个最小可用版本，然后不断重复增量迭代的开发方式，下图中每一列就是一次迭代

每一次迭代起名叫做一个冲刺（sprint）

一个冲刺（sprint） 是一个短期的里程碑，通常在 1 ~ 4 周内。

在一个敏捷开发项目里，有 3 个角色

• 产品负责人
• 敏捷大师
• 团队

产品负责人负责告诉团队“做什么”，而敏捷大师负责告诉团队“怎么做”。

具体流程来讲，

1）产品负责人是最了解客户需求的人，所以他来负责拟定一份可能进入最终产品的产品的功能需求清单（product backlog）

2）敏捷大师召集大家发起第一次会议，冲刺准备会议（sprint planning）

• 决定哪些需求可以进入这次的冲刺

• 评估需求的难度

  人类不善于评估任务时间，但可以分清任务难度，以最简单的任务为基准，使用斐波那契数字给每个任务一个评分

• 最终输出一份本次冲刺用户故事清单

用户故事 就是：

作为**_，我想要_，所以_**。

AS a ( role ), I want ( feature ), so that ( benefit )

3）正式进入冲刺阶段，团队开始开发

• 一个冲刺通常持续 1 ~ 3 周

• 工作透明化，用白板记录，确保了解所有人都在干什么

• 每天早上有 15 分钟的每日站会，团队成员轮流回答

  • 你昨天做了什么去帮助团队完成冲刺？
  • 今天打算做什么来帮助团队完成冲刺？
  • 遇到什么阻碍？

  注意任务不是自上而下的，而是自主决定自主完成

• 每天更新燃尽图，统计完成进度

4）完成一次冲刺，敏捷大师召集大家开冲刺回顾会议（sprint review）

• 把完成的功能给产品负责人看，不展示成果，就没有效果。

• 注意在流程改进上，不要责备某个人

  每个人都是制度的产物，scrum 方法会承认和接受这个现实，进而审视导致失败的制度，而不是非要找出一个人来承担责任

5）跳回 2） 循环

总结敏捷开发中的 3 个角色

总结敏捷开发的 3 次会议

总结整个流程