这次RSG又一次交付了极简质效体验工作坊。用时两个小时，没提前、没压堂，遵守时间盒。这次也是课上任务完成最好的一次，有两个团队避开了案例挖好的坑。

工作坊交付完就有人跟我反馈说有两个点记忆太深刻了。一个是可见才可管理，一个是Daily Scrum。因为太犀利。过去我们数是数，活动是活动，从来没有相互验证。很多问题到迭代快结束或者结束才能被发现，风险太高了，直接导致团队互相不信任，甩锅。

今天就借着回来的时间写写稳节奏这一板斧里这两件事。

可见才可管理

软件研发是个脑力活动。它很不容易被看到。所以经常有团队在进展管理的时候报的数据很虚无。比如代码进展70%……这个数据怎么来的呢？我们都知道是拍脑袋。能不能用？不能。什么时候能用？不知道。稳节奏很重要的一个问题就是采用一些“技艺”让结果可见，能够达到我们在定目标时确定的DoD（完成的定义），让工作可以被“计件”，可管理性就提升了。比如一个迭代，就是一个节奏内计划完成的业务目标一共有10个用户故事，如果达成了3个，满足DoD，那进展就是30%。很简单。这些可以给客户上线，可以作数，那些开发到所谓代码99%的，也不行，因为不能用。

怎么能被看到呢？我们有两个实践：

一个是单故事的Showcase。

一个是迭代结束后进行的迭代评审会。

Daily Scrum

过去有很多文章写怎么开站会。一天一次会，该问什么问题，如何如何。我们在极简质效里的实践更为简单直接。Daily Scrum，难道不应该是Daily的Scrum吗？那么一天的“承诺”也应该被判断是团队“勇敢”还是团队只是说说而已。只发誓，不被雷劈后面谁还会信守承诺呢？

极简质效里还是利用两个实践来解决这个问题：

一个是晨会，团队会在晨会承诺今年要交付几个用户故事。

一个是夕会，团队要在夕会中集中做单故事的Showcase。

如果夕会Showcase没过，你懂得的。

我们曾经有团队用过的一个规则：

Showcase通过，PO做20个俯卧撑

Showcase不通过，开发故事的同学做20个俯卧撑

如何？这种你会觉得质量差吗？

你可以怎么做

稳节奏里我们提供了一个迭代日历工具，大家可以参考执行。这样各个角色知道自己什么时间应该做什么事情。新成员进到团队跟着做就行了。久而久之，就形成了既交付成果又有节奏感的团队。

可能遇到的问题

你可能遇到的问题：

• 拆分的结果无法演示

• 开发时间很长，甚至跨迭代

• 其它关联系统没有准备好

• 技术上不支持

• ……

当然，这些都是有原因的。根据原因在于：

• 不会拆

• 对迭代目标确定的不好，比如迭代应该包含上下游联调完成

• 技术评审不到位，没有拆分技术故事

• ……

等等。当然，如果就是不会，没问题。找我们一起搞定。