独角兽项目的那些事儿（DevOps之敏捷团队的迭代区间设计）

现在有一个人，你给他一个魔方，他得闭着眼睛玩魔方，

第一种场景：

让他自己转，很随机

大概需要花多少时间才能转到完成呢？

据模拟需要几亿光年，

第二种场景：

他每转动一次，

给出提示，这一次的转动是离得近了还是远了

大概需要花多久呢，

两分半钟。

这就是著名的魔方实验。

给我的启示是什么呢？

迭代反馈是宇宙神性法则。

敏捷本质上就是加快迭代反馈，

你听到迭代反馈都听得耳朵起茧子了，

你会想，我今天又要讲什么呢？

我想讲迭代反馈的关键在于正反馈的频率。

独角兽项目一开始的时候，我们选择了3周一冲刺，

三周的跨度和原来的工作比较接近，这是其一；

三周的时间可以前后预留时间做buffer，这是其二；

三周的时间15个工作日，

按照PMP的套路，一个工作报告40小时，

敏捷团队的dev tam正常情况3个人左右，

渐进明细的滚动计划，一开始计划三个工作包，

第一个工作包很明晰，第二个工作包相对明细，第三个工作包毛估估，

这是其三；

试运行了一年后，我们经历了17个迭代反馈，

大的趋势上来看，所有业务线基本能在day1需求就绪率到80%，

就达不到的sprint12之前的数据也进行问题归类，分析背后的故事是什么？

敏捷冲刺很关键的点就是day1的时候需求就绪率，这直接决定交付稳定性

结合数据展现的真实情况，试图分析问题现象的背后故事和和找出解决方案。

虽然试运行了一年，整体来看大家伙在day1的时候，做不到DOR

我就去看是不是backlog里面没有需要我们做的需求或要修复的bug

有意思的是有一半的团队在day1的时候需求就绪率在80%以下。

表象：大家效率高，平均待办需求数个

迭代收尾的时候，大家又手忙脚乱的，我在想是不是我的锅

然后我接着想，怎么打破这个怪圈，迭代前松后紧

如何让用户更快获得反馈？减少用户等待的时间，这取决于资源的忙碌程度。

那么问题就来了，

用户等待时间长跟敏捷团队的时间盒子有直接关系，

这就好比你和小伙伴去太二酸菜鱼或者奶茶店，

进入到店家的队列很长，

让你排队两小时才体验，你的体验很不好，

在不加人的情况下，有个办法可以提升体验，

店家减小店内排队的队列，只放你资源能够服务的人进来

这五个人等待的时间平均1分钟。

我的想法是怎么让用户已排期的需求等待时长更短

在组织能力无法瞬间提高的背景下，

对内和对外分别可做什么？

首先想到的就是缩短迭代的timbox。

有了思路后，我在想怎么去和各个业务线商量调整timebox

打动业务线的肯定是如何遵循帕累托原则，

仅仅用20%的功能满足用户80%的需求

这一块需要业务分析能力，合理的在timebox开启之前做好优先级排序

最为关键的就是需求老是变，我们开启冲刺的timebox后，需求变化请业务排到下个冲刺，一来是timebox区间短用户能承受，二来风险隐藏的可能性小

timebox短，在途的库存就很少，小批量的快速交付，最大的浪费就是库存

在交付中间，团队也要控制好WIP限制，找出资源的瓶颈，全局优化

敏捷交付是一整套组合拳，除了你所知道的5533，还有很多基本功要夯实。

当然了，你最后会问我们timebox调整了吗？并没有

不要问我为什么，哈哈，组织心智是真的最难改变的。

2022已经快过四分之一，

你的敏捷团队在资源效率和流动效率方面如何呢？