一、是什么影响了我们的交付效率？

经历敏捷有一段时间了，一直在想，敏捷到底什么，给我们带来了什么好处？看板、回顾会议、迭代、产品backlog等实际使用的工具或方法，与敏捷宣言、敏捷12条原则又是什么关系？
回想敏捷教练刚到公司时做了一个调查，其中一项是一个需求的实施周期有多长，有三个选项：1周以内，2-3周，4周以上。最终大家统一意见是2-3周可以完成，敏捷教练说这个交付效率很高啊，一般互联网公司也就只能达到2-3周，很少公司可以在1周以内，我们已经相当敏捷了。
WHAT？我们真的已经敏捷了吗？NO!所有人在评估实施周期的时候，都加了几个条件：
1.需求已经澄清
2.需求不再变化
3.专职做这个需求
问题来了，这些条件能满足吗？以我多年从业经验来看，从来没有满足过，顶多满足其中一两个条件，所以2-3周永远只是理想的交付效率。那实际交付效率又如何呢？只能让数据来给我们答案，结果统计了几个需求的各项时间以后发现，最短的一个需求消耗59天，最长的达到300多天，平均下来需要100多天。事实总是那么的出人意料，又让人无法反驳。那么，问题来了：时间都去哪了？
为找到原因，我们确定需求实施的几个关键时间点：
1、浮现：也就是业务第一次提出一个想法；
2、到达：业务提交正式需求；
3、分析：业务与技术沟通实施方案；
4、开发：设计技术方案、开发、单元测试；
5、测试：组件组装测试、用户验证测试
6、上线：需求正式投产
统计数据显示，开发平均2-3周，测试平均2-3周，上线平均1-2周，浮现、到达和分析阶段时间波动幅度较大，成为影响交付效率的关键。有意思的是，开发平均2-3周，与调查的时间一致，原来是理解上的不一致，技术理解的实际上是开发效率，而非交付效率。那浮现、到达和分析阶段为何时间波动幅度很大呢？这三个阶段主要是业务、技术及其他关联方对需求的方方面面进行沟通，让所有人都达到自己认为需求已明确的过程，可以统称为需求澄清阶段。而需求澄清，实际上是一个不断在沟通中实现信息对齐的过程，也就是说，关键在于沟通。再反观开发，技术开发人员之间沟通；测试，开发人员与测试人员之间沟通；上线，开发人员与运维人员之间沟通，等等等等。突然发现，沟通无处不在，沟通效率是整个交付效率之关键！

二、敏捷对交付效率提升真的有帮助吗？

看板

进入敏捷团队以后，上来便是设计看板，将所有需求按用户故事拆分，使用绿色便签贴与看板上，将行动项使用黄色便签贴于用户故事上，将问题和阻碍项使用红色便签贴于用户故事上。看板也在使用过程中不断更新，目标就是将所有事项在看板上进行可视化。原来需要通过周报、日报、询问等方式获取的信息，现在从看板上就能清楚的知道团队内每个成员、每个用户故事的状态，无形中提升了整个团队的沟通效率。

站会

然后是设立每日站会，每天早上15分钟，所有人在看板前面简单叙述一下自己昨天做了什么，今天准备做什么，遇到的风险和问题是什么。一个简短的站会，实际上就是团队内部的一个信息对齐。如果一个成员的任务依赖另外一个成员，站会的时候就可以关注到另一个成员的状态，提前发现潜在风险和问题并干预，而不是等到问题出现再想办法解决（此时已经影响到交付效率）。原来，站会也是在提升着团队内的沟通效率。

迭代

之后是设立迭代。每两周一个迭代，每个迭代开始一周前设置需求梳理点，用于检查需求澄清情况，迭代第一天筛选进入当前迭代的用户故事，迭代最后一天进行回顾会议。原本需要通过告知方式让每个人了解什么时间之内该完成什么事，运行几个迭代以后，转变为每个团队成员自己清楚什么时间该干什么事，激发个体的同时，也降低了沟通成本。

回顾会议

最后是在每个迭代最后一天进行回顾会议，回顾会议固定主题有两个：
1.这次迭代有哪些做的好的地方，我们需要坚持；
2.这次迭代待改进的地方，及其解决方案。
回顾会议让我们在实践中发现问题，解决问题，不断提升交付效率。

三、敏捷宣言及其原则给我们的启示

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。

个体与互动高于流程和工具，其中的“互动”便是沟通。
客户合作高于合同谈判，实际是沟通机制的转变。

业务人员和开发人员必须相互合作，项目中的每一天都不例外。

只有相互合作，才能快速有效的沟通

不论团队内外，传递信息效果最好效率也最高的方式是
面对面的交谈。

该原则直接给出了沟通的最佳解决方案！

四、实践经验

4.1 最差用户故事与最好用户故事
曾经有一个最差用户故事是A贷的支用方式，我们以往的所有贷款，都是自主支用方式，客户可以随时支用前到自己账户上，然后用于需要的地方，该方式对客户来说，无疑是最自由的。然而A贷基于风险及其贷款用途等方面考虑，需要支持受托支付，从客户贷款支用到指定对方账户上。看似简单的一个用户故事，由于交易线很长，涉及系统众多，又需要符合监管要求，前后咨询了十几个技术人员，消耗将近一个星期时间，终于确定技术方案，然后进入开发阶段。由于方案不具备普适性，一直仅用于A贷。
后来有一个最好用户故事是B贷的支用方式，B贷是基于订单的受托支付。此次将支用涉及到的几个核心技术人员，集中到了一个黑板前，历经一个小时的头脑风暴之后，最终决定使用扫码支付，该方案完全符合用户操作习惯，普适性强，获得技术、业务一直认可。

4.2 日常办公
刚开始工作的时候，特别喜欢使用RTX等即时通讯工具进行沟通，不太敢使用电话等方式，那时手头事情不多，大多是些不紧急的，基本上也能应付。
然而，工作多年以后，自己了解的东西越多，承担的任务也越来越多，即时通讯工具经常发现，你发一个消息后，过半天别人才理你，然后你再过段时间才看到消息，如此，经常一个简单的时间，可能需要沟通一上午，甚至更长时间。无奈之下，很多时候就只能电话沟通，结果任务完成速率大大提升。
经历敏捷转型之后，了解到最高效率的沟通是面对面的，因此，现在的我，只要人在相同办公地点，我基本上选择直接过去找他/她。当前我手里有一个项目正处于验收阶段，需要准备一大堆验收材料，而这些以前从来没有弄过，于是就拿着电脑直接跑到相关人座位旁边办公，现在基本已经搞清楚该如何着手准备，各项材料时限要求也掌握。

4.3 迟迟立不下来的项目
前端时间，有一个项目需要立项，结果立项材料改了几十稿，历经了两个多月，依然无法上项目审核会。经研究决定，派人出差至北京，现场与审核材料的人沟通，现场改材料，结果经过一个多星期的修订，材料终于符合条件，顺利通过项目审核会。

五、总结

敏捷就是在实践中不断提升交付效率让客户满意，而提升交付效率的关键就是提升沟通效率。