Being Agile! 日常必用的三个迭代空间数据-京东云开发者社区

#### 前言：透明化的意义 
行云看板是各部门为交付用户价值而协同的工具，通过需求在各个部门流转的各种指标的记录和展示，进行进度跟踪，风险预测，瓶颈定位，并依次来调整我们的行动，这是敏捷透明化可视化的重要实践。

**透明化 是敏捷建设最先需要考虑的话题，也是敏捷转型初期最先被感受到的好处之一。**连续举办14年的敏捷状态调查报告中，透明度一直位居”敏捷带来的好处“前三甲。

![](//img1.jcloudcs.com/developer.jdcloud.com/b44c941b-8a5b-4691-b269-4bb792449c2b20210114113324.png)

透明化有很多好处，它展示了需求从业务方提出、产品收口、研发测试、UAT验收、到最终的上线，停在了那个环节，每个环节用了多长时间，究竟经历了多少天最终上线，或者没有上线。他让不同部门之间的协同变得透明，暴露需求流通不畅的情况，团队依次改进各个环节的时长，最终改善LeadTime 前置时间。

##### 需求交付前置时间 Lead Time（需求交付时长）：需求从提出到最终完成上线所需要的时间，这个指标直接影响用户体验。

当然所有这一切的大前提是：
**团队实时（每天）按照实际情况更新行云看板，也就是说行云数据是如实反应需求流转情况的，如果做不到这一点的话，对于这些数据的分析和解读就变得没有意义了。**

#### 数据一：团队整体迭代情况 
![](//img1.jcloudcs.com/developer.jdcloud.com/e37da439-b7d0-4c0a-8cc0-eb10ff59af6c20210114113434.png)

##### 1.1 空间汇总：整个团队的迭代情况
 **空间汇总示例一：**
 
 ![](//img1.jcloudcs.com/developer.jdcloud.com/af55ee5d-30c0-4afd-b922-fe58e976ab5d20210114113539.png)
 
**上图中活跃迭代有3个：**
- 目前的现状是，UAT的时间很难控制，测试多数跨迭代，研发团队只能留着已经是过去时的迭代，等到测试做完，UAT做完后上线，再关掉（归档）迭代。
- 这不是真敏捷，但即便如此，也比瀑布模式好很多。下一步优化的方向是把开发和测试放在同一个迭代中完成，终极的目标是一个需求的开发、测试、和UAT在同一个迭代中完成，达到一个迭代中100%的需求完成。
- 如果活跃迭代多于5个，就要看一看究竟发生了什么情况，是忘了归档，还是业务产品侧UAT规划不够，导致多个迭代并行呢？

**未完成卡片有327个，对于一个不到十人的团队来说，太多了**
- 未完成的卡片包括，已经开始了但是还没有完成的卡片，和放在Backlog“需求池”内等待开发的需求卡片。无论哪种卡片数量多，都不是好事。
- 已经开始，但是没有完成的卡片数量太多的话，会给交付和质量带来很大的风险
① 并行的任务太多，会带来协同成本的攀升
② 研发人员在多个任务之间切换，也会分散注意力，这在效率上是一种浪费
③ 在仔细分析以后，有没有发现有一些需求其实没有太多商业价值，可以降低优先级放到下一个迭代，或者根本不用做呢？
④ 或者团队目前处于救火状态，根本忙不过来呢？

- Backlog中的需求卡片数量太多，可能因为
① PO（产品同学）过早的细化了遥远的需求。PO只需要细化最近至多两个迭代的需求即可，太远的保留粗颗粒度就可以，这样才能从容的面对变化。

**现在大家明白了，数据能够告诉我们哪里出了问题，但是却不能告诉我们是什么引发了这些问题，这需要团队和教练一起仔细的观察和分析，只有表示出了造成问题的根因，才能有针对性的解决问题，有的放矢。**

##### 1.2 卡片数量：整个团队空间的卡片在各个流转状态的数量
当未完成的卡片非常多的时候，就需要关注一下，这些卡片都停留在哪些状态上；使用行云默认的卡片流转状态做统计：准备，评审，就绪，设计，开发，测试，发布。。。可以非常清晰的看到每个阶段驻留的卡片数量。

** 卡片数量示例一：**

![](//img1.jcloudcs.com/developer.jdcloud.com/ada52a0b-21ca-4b9f-a5fd-058bda6f905720210114114013.png)

- 开发阶段24个，测试9个，当24个任务流转到测试端的时候，会不会造成拥堵呢？
- 经过分析，如果最终定位到了测试是需要改进的地方，在资源有限的情况下，可以增加自动化测试，或者培训开发人员做单元测试（测试开发共担质量），这些都是加快测试，行之有效的敏捷实践。

#### 数据二：燃尽图跟进迭代进展
从“团队空间” -> “计划&跟踪” 进入，可以选择不同的迭代进行展示，如下图

![](//img1.jcloudcs.com/developer.jdcloud.com/5216cae1-da6f-4869-a72a-ad6392ae7da920210114114115.png)

下面仔细解读“燃尽图”、和“新增卡片和完成卡片”。
##### 2.1 燃尽图：迭代过程中每日的剩余工时的展示
燃尽图是Scrum敏捷管理实践的测量指标；如果团队使用Scrum，需每日关注燃尽图，根据趋势预见风险，并且及时调整，保证迭代目标达成。
迭代的第一天，行云收集当前迭代的所有计划工作量，一直到迭代结束的那天，拉一条斜线，形成下图中的蓝色基线。
绿色是当前迭代所有任务的剩余工时（或者剩余任务数量，可配置），如果绿色曲线上有小黑点，代表那天有卡片工作量的更新，行云会自动计算新的剩余工作量，形成绿色的曲线；如果没有小黑点，则代表当天没有更新，两天以上不更新的情况是不正常的。

** 燃尽图示例一：**

![](//img1.jcloudcs.com/developer.jdcloud.com/b737fd13-1713-4ec8-8398-dc3b83ad3b7320210114114223.png)

- 上图燃尽图的非常健康
- 绿色曲线是团队所有任务的剩余工作量之和，一直在蓝色参考线的上下游动，说明团队每日关注燃尽图，并依次调整当日计划，最终完成了所有需要的任务，迭代目标被达成，。
- 绿色曲线上的小黑点，每天都有体现，说明团队每天都在更新行云。

**燃尽图示例二：**
 
 ![](//img1.jcloudcs.com/developer.jdcloud.com/c1b43d36-afb6-467b-ad68-b013c7b7204720210114114331.png)
 
 - 随着时间的推移，没有做完的工时竟然越来越多，哪里出了问题？
- 还有，可以看到7月28号当天并没有设置基线，这是迭代开始的第一天，团队没有把计划工作量更新到行云里，有可能是因为做完评估后没有更新到行云，也有可能是团队根本没有开计划会。总而言之没有了参考线，自然也无法给团队以参考，后面就是凭借感觉行事，或者辅助其他工具，比如存在自己电脑里或存在joySpace里的xls表格，xls表格更多是单边管理事务的工具，不方便团队协同，更加无法记录历史数据，形成趋势分析。

#### 数据三：任务状态图跟进迭代稳定性
##### 3.2 新增卡片与完成卡片
“新增卡片和完成卡片”监控迭代过程中进入团队的工作以及完成工作。这个图可以很好的帮助团队观察迭代计划的有效性和迭代的稳定性。
严格地说，在迭代计划会上，团队应把交付这个迭代目标的卡片都拆解完毕；在迭代中新增卡片的情况一般有：
- 新增了需求
- 需求拆解不完整，边做边增加新任务
- 测试任务在中途加入
- 其他临时开发任务
任务应像水池的进水管和出水管一样，有进有出，且流量差不多，水池的水才不会溢出或者干涸。
进入团队的卡片和完成的卡片是同样的道理，需要保持一个相对的平衡，才能维持一个可持续化的、良性的节奏。

** 新增卡片与完成卡片 示例一：**

![](//img1.jcloudcs.com/developer.jdcloud.com/8b68ba16-913a-4b10-97a1-46b3e2f4b3c820210114114532.png)

- 上图中团队在不同的时间有不同数量的新增卡片（因为蓝色曲线上有小黑点），新增卡片有可能来自于产品，也有可能来自于研发自己，但是整个迭代只有很少数量的卡片完成，说明这个迭代的交付并不多。
- 实线部分代表迭代范围内的时间（7月27号到8月7号），虚线部分不属于这个迭代，如果严格按照迭代内交付计算的话，那么这个迭代没有任何的卡片的完成。
- 上图中有一个非常错误的行云使用方式，那就是在迭代结束后还在新增卡片，这完全没有迭代的概念了。
- 目前的情况是，一个子需求（开发测试UAT）很难在一个迭代中完成，这很有可能是这个迭代没有任何卡片完成的原因。
- 对于在迭代结束时还没有完成的卡片，建议移到下一个迭代，跟新加入的任务一起管理，而不是留在当前迭代中，理论上团队最好只维护一个活跃迭代，这样做有以下好处，
① 团队能够做到专注和聚焦
② 所有的事务都被放在了一个迭代当中，那么就能看到团队的整体情况，团队有多少事务并行，研发测试每个人有多少任务并行等
③ 未完成事务成为新任务的阻力这个现象被更加明显的暴漏出来，那么为了解决这个问题，团队需要思考如何加快一个卡片的开发测试和UAT，如何能在一个迭代中完成，最终缩短需求的leadtime。

**新增卡片与完成卡片 示例二：**

![](//img1.jcloudcs.com/developer.jdcloud.com/519212b2-08be-49de-b4f4-d2dfefd8633a20210114114707.png)

- 上图中在迭代之外有完成的卡片（有可能是因为测试在迭代内没有完成，也有可能是因为UAT在迭代内没有完成），但团队并没有把未完成的卡片移到下一个迭代中跟新加入的任务一起管理，而是仍然留着在了当前迭代中，这也是为何团队有多个迭代的原因。
- 相对于示例一这中做法有了很大的改善，因为迭代之外不再有新增的卡片了。
- 但是它仍然不完美，完美的做法应该是开发、测试、UAT在同一个迭代中完成（具体看上图示例一的解释）。但目前还有比较远的距离，团队可以先讨论如何让同一个卡片的开发和测试在同一个迭代中完成。

**新增卡片与完成卡片 示例三：**

![](//img1.jcloudcs.com/developer.jdcloud.com/e82cf199-c6b2-47e8-b772-69b920792ac120210114114822.png)
- 上图的表现很“魔性”
- 整个迭代，以及迭代之后的时间里，没有任何的卡片完成，却有很多的新增卡片，这是个不受待见的迭代啊，究竟发生了什么？卡片被移到了下一个迭迭代了吗？还是这个迭代被取消了？

#### 总结 
团队除了每日关注燃尽图，卡片状态图，根据情况做出及时的调整之外，还可以定期在回顾会议上讨论累积流图，新增卡片与完成卡片，卡片状态停留时长散点等，如果有些问题一直出现，那么需要引起我们的重视，
- 比如测试测试资源不足的问题，可以加强单元测试，以及自动化测试的建设；
- 比如并行事务太多的问题，可以加强业务收口，倒逼业务产品发掘真正有价值的需求，从而形成有规律的迭代；还可以采用“单件流”的理念，聚焦需求的流动效率，优化需求的流动。
- 比如前置时间太长（业务提出需求 到 上线的时间）的问题，那么究竟是研发测试的时间长，还是业务到排期的时间长呢，这些数据和图表都可以给我们答案，让我们定位出改进点。

**最后再强调一句：**
##### 这些数据的分析都基于一个大前提，行云看板能够如实反应需求的流转过程。如果这些数据不能反应真实情况，那么这些数据分析和解读就没有意义了。所以敏捷转型的第一步，也是最重要的一步，先做好透明化的建设，然后根据数据测量进行持续优化。

------------

###### Being Agile 京东物流技术发展部效能提升部
###### 作者：效能提升部 侯秦
![](//img1.jcloudcs.com/developer.jdcloud.com/e2f94d78-ec7c-46a8-9eff-d768e618fac820210114121317.png)