如何真正实践敏捷？

Agile 这个字，大概 20 年前（约 2000 年初）被发明出来。十年前开始在中文圈开始有团队采用，推了很多年，最近一两年似乎终于普及，终于变成一个开发圈的 buzzword。

我自己用了敏捷做产品近十年。写过非常多敏捷的文章（这个博客有很多，就不赘述了）。然而真正掌握精髓（真的用敏捷技巧开到风上，开发出赚钱且热卖的产品）是最近这几年的事。

敏捷的误区

我发觉很多人，对于敏捷的定义，有非常狭小的看法。举几个反例：

• 以为敏捷就是不写规格，快速的执行
• 以为敏捷 = Scrum （一敏捷框架），没有执行好 Scrum = 敏捷失败，投入不够多
• 以为敏捷就是日日 Daily Standup，日日算 Story Points 以及画 Burndown chart

虽然行动貌似变快了，但事实上可能是以时速 140km/h 开进沟里翻车。

什么是真正的敏捷？

我认为真正的敏捷是这样的，真正的敏捷是：

认真解决核心问题

• 正在实做的项目，有没有解决真正现实生活中，发生的问题
• 正在实做的工程细节，有没有继续围绕著第一层的需求转
• 有什么最快的第一性（原理）解决方法，可以直接在时间限制内直接灭火。
• 重点不是规格，而是必要性的 Story 实践。

团队进度公开透明

• 团队里面大家对自己负责的工程模块，进度透明，错了可以马上修正
• 没有「研究中」这个字，只有「试过了哪些方法，哪些可行哪些不可行」
• 有公德心的与队友开放起协作接口与文件

不谈业绩 / 增长 / 省成本 都是耍流氓

做产品谈的

• 第一就是解决用户问题
• 第二就是从产品上赚到钱
• 第三就是产品能够持续增长
• 第四就是可以节省团队成本

当一个团队说著自己敏捷。实际上都是在用假的行政手段逼迫团队假协做，假装自己在干活，假装 Standup 念经可以解决团队核心价值观严重冲突的问题，假装 issue tracking 上一直有票解，实际把底层架构一层可以解的架构包了三层解是在推进进度。快速写了一个精致UX结果没人懂怎么用。

完工日就是产品死亡日。这一类的敏捷都是假敏捷。