敏捷转型16个月，总结期间得与失(2)

晨会，是跨职能团队进行沟通的标准活动，每天在固定的地点、固定时间花10分钟左右举行，是一种很有效的团队同步机制。然而晨会看上去简单，但是要开好，却没有那么容易。敏捷里面的推荐晨会内容主要包括以下三方面。

昨天做了什么？今天要做什么？有什么问题？

对于敏捷小白的我们，刚开始照本宣科的组织晨会，但是采用标准的模式，我们却始终都开不好这样的晨会，下面会详细的说说我们都遇到了哪些问题。

晨会沟通时，大部分信息对改善项目进展的实际意思很小，口水话太多。当一位同事在描述自己昨天做了什么，今天要做什么时，大部分人并不在意。大部分工程师晨会都是自顾自说，不关心自己表达的内容是否有效传递。推广晨会轮流组织时，发现大部分人并没有这个能力有效的组织晨会，并不太好实践。晨会讨论的内容很离散，看不到整个项目的进展。

2.2.1.怎么开好晨会

正如敏捷宣言里面提到的“个体交互胜过流程和工具”一样。晨会，需要将当前项目的进展透明到整个团队，并促使团队成员基于各自目前的情况，通过沟通及时主动的解决问题。那如何才能做到快速有效的沟通呢，我认为需要做到以下几点：

团队成员都清晰的知道项目的目标和当前的状态。项目中的各项工作内容都有清晰的优先级，以及明确的责任人和当前的进展信息。晨会有明确的规则，每个人都知道在何时做何事。参与晨会的每一个人都能随着轻松的了解到与他相关人员的任务进展状态。

要做到这些，当然就少不了一面合理的看板墙了。它是整个晨会的核心载体，晨会时，所有的项目成员都基于看板墙的信息进行讨论并更新看板墙的信息。

2.3.看板墙

看板墙，看似只是简单的将项目中要展示的信息帖到一个版本上面去，但是如果贴得不合理，整个晨会就会一团乱麻，思路离散，最终导致晨会的失败。接下来，我将谈谈我们看板的演进过程。

刚开始，我们采用上图那样的看板墙，纸片上仅仅写了用户故事，每天晨会的时候，大家围成一圈，按顺序每个人讲自己昨天做了什么，今天做什么，有什么问题。当发现某项用户故事改变了状态时，就挪动到对应的列里面去。

渐渐的问题就暴露出来，我们发现看板墙上的卡片会有很多，而且会越来越多，因为我们总是想做更多的用户故事，一旦某项用户故事在开发过程中受阻，我们就会考虑开展一项新的用户故事，我们不能接受一个人“闲下来”。另

外，由于每个人讲的内容，并没有和卡片直接关联起来，导致我们并不能很好的把讲的信息和看板墙结合起来，以至于看板墙成了一个背景，没有起到太多的实际意义，我们开始质疑，轮流讲问题是不是不合理，转变为由一个人主持，根据看板墙上的信息逐个询问探讨，为了实现轮流主持，我们定期换不同的人进行询问探讨，但是有时候有的人却完全不知道如何有效的主持，导致晨会下来的有效沟通很少。由于看板卡片上记录的信息很有限，卡片数量又比较多，以至于项目负责人都难以清晰的了解当前项目的进展，更别说其他团队成员了。于是我们把看板改成了下图的样子：

这样子，看上去比以前的看板清晰了一点，能比较清晰的知道目前视觉、软件、测试的任务情况，可惜还是存在不断的向后面推用户故事的问题，导致看板的在制品过多。

另外，还是存在部分用户故事较大，在某个位置停留过长时间的问题，并且我们并不能清晰的了解到该用户故事目前的进展情况。

这里附带提一下，总会有人提要把需求的粒度拆分得更小，把一个用户故事拆分到1到3天的工作量，可惜我们一直没有实现，或者我们勉强把一个大的用户故事拆分成了几个小的用户故事，但是在我们这种敏捷并没有完全转变过来的团队，我们还是喜欢一个需求完整的交付。因为只有这样我们的黑盒测试才能有效的测，不然会让测试重复测，浪费测试资源，前端需求对于一个没有做到发布状态的需求，也觉得不好体验。

为了有效的跟进较大的用户故事的进展，我们开始进行任务拆分，我们规定一项任务的粒度最大不能超过三天的工作量，我们趋向于团队成员尽量把任务都拆解到小于一天工作量的粒度，因为这样有利于我们每日晨会进行跟进，于是看板上的卡片就分为了两类，出现了下面的看板。

我们将看板上的卡片分为用户故事和与用户故事对应的任务，当所有与用户故事相关的任务都完成时，将用户故事挪到待发布中。用户故事与任务之间使用编号进行关联，这使得我们的晨会过程讨论的内容更加具体，而不是简单的汇报工作，项目进展情况也比以前更加清晰。

然而，问题依旧存在，当任务卡片较多时，任务与用户故事的对应关系找起来相对麻烦，不能一目了然的了解到用户故事的进展情况。同样的，这样的看板依旧会存在前端需求大量的向后端涌入，导致后端负荷过重，效率降低的情况。得益于精益的限制在制品概念，结合我们之前的各种经验，我们最终使用了下面这种看板墙。

在这个看板墙里，只有用户故事卡，用户故事卡上拆分了用户故事的不同任务，我们不再追求多个领域能针对一个用户故事并行开展任务，而是一个领域做完后，再流入到下个领域。表面上并行开展工作看起来效率更高，但是那样各领域信息并不一致，返工较多，反而导致效率低。由于任务和故事在同一张卡片上，我们可以从看板上一目了然的看到用户故事当前的状态。

另外，我们将卡片分为三种颜色，对应于三个优先级，这样大家在领取任务时，能更加自主。还有一点十分重要，每个领域我们根据他们的人数设置在制品限制，目前规定一个人同时开展的工作不能超过两项。我们由推的模式转变为拉的模式。这样能清晰的暴露领域边界的资源匹配情况，同时也能保护相关领域不至于任务过多引起混乱，进而导致效率降低。我们由要做更多的需求转变为“停止启动，聚焦完成”。

一个人的同时工作项不超过两项并不是一个标准答案，我们内部也未完全按照该标准执行。对于基本不会出现阻塞的领域，也许一项也是一个合适的选择。

2.4.版本规划

由于我们的产品包括iOS应用、Android应用、手表端、服务器、H5这样5个技术领域。在初期，我们遭遇了各领域互相依赖，因某个领域有bug未能及时修复，导致整体发布延期的问题，而且还经常发生。

编辑：未知