敏捷实践(5) - 敏捷开发=快

不少人认为敏捷开发就是意味着快，实际上敏捷开发一点也不快，甚至更慢。但要说它快，也没错，它的快并不是体现在开发进度上。

开发进度

从开发进度上来说，敏捷的进度反而更慢, 更慢，更慢，来看看我们的开发团队每天实际的工作有哪些？

• 对PO给出的用户故事进行评审(INVEST原则)
• 为用户故事编写验收标准, 并通过PO的评审
• 编写验收标准自动化测试脚本
• 编写自动化单元测试用例
• 编写自动化功能测试用例
• 编写自动化集成测试用例
• 编写跨系统边界的自动化集成测试用例所需的用例数据支持接口
• 编写功能实现
• 确保本地能通过上述测试
• 持续重构确保代码符合代码规范 (通过Rubocop的扫描)
• 提交代码合并请求并确保通过持续集成(Jenkins CI)
• 代码合并请求后，自动化部署至相应环境
• 配置任务，每天自动跑全回归(APP, API, 后台管理...）
• 每周至少一轮人工手动全回归测试
• 迭代交付演示
• 自主任务管理

我们只有开发团队这一角色，并没有专门做架构设计，测试的角色与人员。

开发人员的自我工作占比评估，编写功能代码部分仅占到一天工作量的40%甚至更少一点。

注意，我们每天的工作时间为 7.5 小时，并且，强制不加班，不加班，不加班。
至于为什么这样做，以后专门写这方面的内容分享。在这里只说，我们不加班的有效产出比以往加班的产出还要好。believe or not, up to you.

我们每个迭代，PO都会根据实际产能去调整我们的计划，整个团队在按照稳定可靠的速率交付增量。

我敢肯定，绝大部分团队的快速推进做法, 至少在三到六个月内，项目进度能甩我们好几条街。但是，在追求相同的质量标准和完成标准的条件下，未来六个月到十二个月，我们能追上并且甩他们的几条街。

快速拥抱变化？

这点是真的，但是拥抱变化并不意味着乱变、频繁的变。变化太频繁，PO应当去面壁思过，好好冷静一下。

敏捷总会老生常谈的说 敏捷可以快速试错，实际上我更倾向用快速纠偏与快速评估这个描述。

在我看来，敏捷的最大受益者是公司，老板，出资人。为什么这么说？
我们是两周一个迭代，每个迭代严格按照前面的工作去执行。在每一个迭代交付是，我都会同老板一起评估，来回答如下几个问题：

• 我们的交付是否符合预期？
• 产品的特性是否符合预期？
• 产品的特性与预期不符，这个产品有无继续的必要？
• 如果有继续下去的必要，接下来产品特性需要做哪些调整？
• 团队是否健康？是否愿意继续投钱这个团队？
• 期望团队未来有哪些改进？

当然，上面这些是需要勇气的。

也就是说，每个月老板都有两次机会，了解产品、项目的情况，并决定值不值得继续投钱。

出现不利情况，发现产品没希望或者团队不行，能够及早止损。而不是一味投入投入，等到发现不行的时候，投入已巨大时，是继续投入呢，还是中止呢？

• 中止意味着巨大的投入打水漂；
• 继续投入，还需要投入多少，多长时间，可能翻身，可能损伤更大，心里完全没底，宝宝心理苦啊；

出现有利情况，产品可行，根据实际用户反馈，我们可以把资金投入在对用户最有价值的需求上。

因此，敏捷的快，在于快速盈利与快速止损上。

当然，这些是建立在敏捷的价值观之上的：

• **勇气 - Courage **
• **开放 - Open **
• **承诺 - Commitment **
• **专注 - Focus **
• **尊重 - Respect **

努力做一个有价值追求的有逼格的TALENT吧。