Minimum Visual Management for Aigle

Common Problems

每个开发团队都面临同样的需要回答的问题：

• 我们一共有多少工作量？
• 我们的速率是多少？
• 我们能否按时交付？
• 我们交付的质量如何？

如何能可视化的回答上面的问题，有没有参考的方案？

最小可视化管理

基于Scrum的Agile实现，可以通过下面的三个度量和可视化来解决上面的问题：

• Release Burn Up Chart
• Defect Trend
• Tech Debts Trend

这三个度量项可以相互制约和平衡，反应项目的进度和质量。这三个图的简化原型参考下图

这三个度量项可以相互制约：

• 如果团队速度快了，但没有严格控制质量，则
• 缺陷、技术债务积攒的就多

需要对Defects和Tech Debts设置一个控制线，如10。不同的阶段可能需要不同的控制线。

这些度量项就是团队的汽车仪表盘，要简单，但要能放映总体的项目情况。

Burn Up详解

有了Burn Up图是否就能准确的回答什么时候交付？

没有简单的答案。如果你们团队践行所有的工作都需要进行估计并在Backlog中管理，并有很好的模型来预测将来的缺陷数量和工作量。那答案可以是YES。但对于大多数的组织很难预测有多少Defects，需要花费多少时间来修复。

实际项目中结合Burn Up图的交付图，如下：

在Sprint 0 （Planning Sprint）大家会：

• 定义Release 范围
• 梳理Backlog，并估计 --> 得到初始工作量（Story Points) S1
• 估计团队速率

并根据以上估计信息，估计交付时间。

陷阱：

• 如果大家按照初始估计S1，估计速率，以R1为参考发布时间，项目团队将经历死亡行军

Why？

这源于开放的本质是：团队学习的过程，对构建系统需求和方案渐渐明晰的过程。在Sprint 0，团队对整体需求和方案有总体的认识，但还没有开展具体的工作，不能对细节有深入的理解。

项目实际的工作量（以Story Points为代理），会是以S2。 这中间工作量差异，我称其为Progressive Effort (渐进明晰工作量）。

为何这么拗口？

因为涉及向领导、跨部门进行解释。如果你说是需求蔓延的工作量，产品经理会说：需求不会有变更，这是一个团队留的Buffer吗？一旦，你让管理层、其他Cross Function 团队，认为大家在计划的时候，“偷偷”的放入了“安全BUFFER”，这需要花费很多的时间来消除误解，否则，其他人将不会信任Scrum团队。

这么拗口，就是要给大家一个问问题，解释的机会。下图是软件估计在不同阶段（以瀑布为模型）估计精度的说明。需要说明的是，大多数软件团队，的估计都是偏乐观的（低估工作量）

Progessive Effort(渐渐明晰工作量），就是团队随着对需求和系统设计的逐渐理解，会发现更多细节的工作和工作量，这些工作量总体上不是因为需求范围变动导致的，而是因为技术细节或业务潜在复杂度引入的。

建议：大家在Sprint 0时，一定要预估S2。如果预估，根据项目的复杂度和团队对业务的熟悉程度来判定。建议3~5%/Sprint的增长。

如果没有办法预估怎么办？

• 跑2个Sprint，根据这两个Sprint的数据来估计。

对于发布时间的估计，另外一个陷阱是：

• 没有将软件Hardening的时间机会进来

软件Hardening是什么？为何需要Hardening？

Sprint阶段，项目会聚集在Story上。当所有的Story都实现完毕后，从整体软件系统的角度还有很多的工作需要优化如：

• 系统稳定性不足，需要优化
• Log 不能很好的定位问题，需要整体的优化
• ... 这些都需要时间，这个阶段，就是要让系统稳定。避免在不稳定的系统上进行系统测试和缺陷的修复。一定要在一个文档的Baseline上进行系统测试。

此外，还有Qualification的时间需要预留出来。特别是对于像医疗器械等法规监管的产品，都需要正式的测试记录。因此需要计划出时间。

总结

产品的发布时间，由下面的3部分组成：

• Release Story 开发时间，
• Hardening 时间
• Qualification

没有仔细的整理，就先到此了。