敏捷革命,终结996的工作方式

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

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

这本书里有一个研究是说,一个厉害程序员的效率可能是一个差的程序员效率的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 分钟解释敏捷开发的视频,已经把敏捷开发解释的很明白了。

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

waterfall

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

scrum

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

sprints

一个冲刺(sprint) 是一个短期的里程碑,通常在 1 ~ 4 周内。

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

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

sprints

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

具体流程来讲,

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 个角色

sprints

总结敏捷开发的 3 次会议

scrum meeting

总结整个流程

scrum workflow