不少人认为敏捷开发就是意味着快，实际上敏捷开发一点也不快，甚至更慢。但要说它快，也没错，它的快并不是体现在开发进度上。
开发进度
从开发进度上来说，敏捷的进度反而更慢, 更慢，更慢，来看看我们的开发团队每天实际的工作有哪些？
- 对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吧。
