说我们都遇到了哪些问题。
晨会沟通时，大部分信息对改善项目进展的实际意思很小，口水话太多。
当一位同事在描述自己昨天做了什么，今天要做什么时，大部分人并不在意。
大部分工程师晨会都是自顾自说，不关心自己表达的内容是否有效传递。
推广晨会轮流组织时，发现大部分人并没有这个能力有效的组织晨会，并不太好实践。
晨会讨论的内容很离散，看不到整个项目的进展。
怎么开好晨会？
正如敏捷宣言里面提到的“个体交互胜过流程和工具”一样。晨会，需要将当前项目的进展透明到整个团队，并促使团队成员基于各自目前的情况，通过沟通及时主动的解决问题。
那如何才能做到快速有效的沟通呢，我认为需要做到以下几点：
团队成员都清晰的知道项目的目标和当前的状态。
项目中的各项工作内容都有清晰的优先级，以及明确的责任人和当前的进展信息。
晨会有明确的规则，每个人都知道在何时做何事。
参与晨会的每一个人都能随着轻松的了解到与他相关人员的任务进展状态。
要做到这些，当然就少不了一面合理的看板墙了。它是整个晨会的核心载体，晨会时，所有的项目成员都基于看板墙的信息进行讨论并更新看板墙的信息。
2.3. 看板墙
看板墙，看似只是简单的将项目中要展示的信息帖到一个版本上面去，但是如果贴得不合理，整个晨会就会一团乱麻，思路离散，最终导致晨会的失败。
接下来，我将谈谈我们看板的演进过程：
刚开始，我们采用上图那样的看板墙，纸片上仅仅写了用户故事，每天晨会的时候，大家围成一圈，按顺序每个人讲自己昨天做了什么，今天做什么，有什么问题。当发现某项用户故事改变了状态时，就挪动到对应的列里面去。
渐渐的问题就暴露出来，我们发现看板墙上的卡片会有很多，而且会越来越多——因为我们总是想做更多的用户故事，一旦某项用户故事在开发过程中受阻，我们就会考虑开展一项新的用户故事，我们不能接受一个人“闲下来”。
另外，由于每个人讲的内容，并没有和卡片直接关联起来，导致我们并不能很好的把讲的信息和看板墙结合起来，以至于看板墙成了一个背景，没有起到太多的实际意义。
我们开始质疑，轮流讲问题是不是不合理？后来转变为由一个人主持，根据看板墙上的信息逐个询问探讨。
为了实现轮流主持，我们定期换不同的人进行询问探讨，但是有时候有的人却完全不知道如何有效的主持，导致晨会下来的有效沟通很少。
由于看板卡片上记录的信息很有限，卡片数量又比较多，以至于项目负责人都难以清晰的了解当前项目的进展，更别说其他团队成员了。
于是我们把看板改成了下图的样子：
这样子，看上去比以前的看板清晰了一点，能比较清晰的知道目前视觉、软件、测试的任务情况；可惜还是存在不断的向后面推用户故事的问题，导致看板的在制品过多。
另外，还是存在部分用户故事较大，在某个位置停留过长时间的问题，并且我们并不能清晰的了解到该用户故事目前的进展情况。
这里附带提一下：总会有人提要把需求的粒度拆分得更小，把一个用户故事拆分到1到3天的工作量，可惜我们一直没有实现。
或者我们勉强把一个大的用户故事拆分成了几个小的用户故事，但是在我们这种敏捷并没有完全转变过来的团队，我们还是喜欢一个需求完整的交付——只有这样我们的黑盒测试才能有效的测，不然会让测试重复测，浪费测试资源，前端
