敏捷开发的Scrum晨会实践

hursing所在的公司推行敏捷开发有两年多了，其中最让人直接感受到的就是scrum晨会。从生搬硬套到过程创新，令大家由抵触变成积极响应，这个过程真的很花费心思。

11年12月，hursing开始在自己的团队推行晨会。当时团队是刚成立的，很小，包括hursing自己在内的2个老人+2个新人，基本上hursing得指导所有的事情。事实上，团队小到不开晨会hursing也知道他们在做什么，所以晨会的内容更多是反馈他们遇到的还未解决的问题以及提出对编码过程的改善意见，然后hursing做一些指导和纠正。这个阶段，整个团队是在确定自己的风格和目标，探索一个合适的行为准则。

在此过程中，发现一个有用的技巧：团队的人应该坐成一堆，而不是一排。即 工位安排坐成背靠背（或者没有障碍的面对面），而不要一字排开地坐。这样每个人坐着说话就行，整个团队的人都能听见。有了这个便利性，平常大家也更乐于沟通，甚至可以就在座位上开晨会，足够放松。有事的话大吼一声就行，完全不用邮件或即时通讯工具。需要当面沟通的话，双脚一瞪，凳子就滑到那边去了，立刻可以交谈。如此一来平常的事务大家都知道，晨会上自然也能更简短地叙述。

不过，座位的事情hursing没法自己决定，不久就在10年1月听组织安排，大家坐散了。然后团队再加了新人，变成6个。于是大伙得找会议室来开晨会。因为平常的沟通不便，大家在晨会的发言变多了，此时限制大家发言的内容有了必要。当时对scrum也没那么多的认识，基本上是说“昨天做了什么，今天要做什么，目前有什么问题”。这是老三点，有点“俗”，但是也不会错，只是不是很适合实际的工作节奏。

以上算是对scrum最初的探索。

12年中，调岗换组，直到10月开始再次对一个团队拥有一些掌控权。这个团队很复杂，非常有挑战性。团队共11人，分别来自4个不同业务的组织（分由4个leader打绩效，不包括hursing），而且负责同时开发两个项目。hursing被指定为团队的接口人，一开始还真觉得头疼，因为团队连个晨会都没有，4个组织的人是跟各自的leader一起开晨会的。通过积极的反馈与沟通，最终是本团队的人一起开晨会、但由于人员组织的复杂性，开始的时候晨会的形式也很特别：

• 每周只是一三五开。因为彼此的工作相关性不是很大，而且晨会有比较多的时间是hursing在宣讲项目事宜
• 不用把技术点说得很细。因为其它组织的人可能听不懂，这是浪费时间。只要提出了问题，由各个组织内部解决就行了，有执行困难的话才由hursing出面直接找leader帮忙。
• 今明两天要做的事情在晨会说完后要写在白板上，下次再擦掉写新的。这里没有用传统做法，即纸贴ToDo、Doing、Done，因为那样不环保，且字小，不直观，都是给自己看的，别人看不清；让别人也能看清，那就有种无形的监督作用。团队的负责人可以知道整体的状况并随时跟踪进度，并且下次晨会的时候，各人可以回顾一下执行得怎么样。

一开始，大家都不是很适应，因为各自负责的模块差别很大，组织间有不同的业务术语，听不懂跨组别的信息。为了解决这个矛盾，在晨会之外，hursing推动了跨组织的知识交流活动。

• 每个组织出人，介绍自己该组织负责的模块的主流程，并且对跟别的模块有交互的部分着重描述。
• 跨组织安排工作。主要是帮忙解bug，不承担开发任务，这样可以互相熟悉业务。
• 推动跨组织的代码review
• 建立爱分享知识的氛围，鼓励写技术文章

随着分享次数的增多，也增加了不少人性化的配套，如会议上会有零食吃，大家投票决定买什么；有专人负责培训分享的事务，从订会议室到备份文档、做会议记录等都不用演讲者操心了。

经过两三个月的磨合，解决了互相听不懂技术问题的矛盾后，晨会的内容也逐渐回归正轨，重点变成：

1. 前两天做了什么，所属的任务完成了百分之多少（标在白板上）
2. 做的工作有哪些会影响别人或需要别人配合，提出来协商
3. 对于正在解决的棘手问题，大家有什么建议

另外，晨会主持人要把项目的时间表和当前阶段写在白板上，大家能每次开晨会都看到，自然地知道紧急性。

一些有意义的小技术点和经验总结，都用邮件分享，不占晨会时间。

后来还做了个改进，把每个人身上的未解决bug数量标在白板上的每人名字旁边（就像iOS的未读信息角标），这样大家能看到谁名下的bug最多，多的人会自觉地争取把这第一的名号给去掉。

至此，那时候的晨会可谓相当高效。

再后来，团队解散，hursing又调岗了，这是个更大的团队 （16人）。团队的状况其实也算复杂，虽然是同一个项目同一个组织，但业务上会分三大块，彼此较少联系，也会存在听不懂的状况。不过hursing不是负责人，也腹黑地想看看反面的例子，所以没推进什么改善，一旁观察后总结出这些问题：

• 晨会主持人很少做改进工作，谁做得不合理也没人提点
• 各人的发言没有预先经过组织，随想随讲，思路混乱，停顿较长
• 过长的讨论没人打断，每人平均发言1.5分钟，有时候整个晨会接近半个小时
• leader当成听报告会，乐于听到很详细的技术处理过程，有些点还会追着细问
• 大家听不懂以后，经常开小差，看着别的地方也有，私下讨论的也有
• 人多了，围成的圈很大，有些人说话声音小，部分人听不见（建议每人都走出来背靠白板面对所有人来讲，leader站在最远的地方）

除了问题各个击破，特别的改进建议是：分批/分组开晨会，每批 不要超过10个人，人员是工作更加紧密相关的，leader可以各批都参加。这在别的部门以有应用，效果不错。

最后就是，主持人必须带头做好示范。最重要的是，作为第一个发言人，要笑着说话，奠定整个晨会的基调很重要。

总结地说，晨会开得怎么样，还是得看负责打绩效的那个人的态度。团队的核心永远是管理者本身，其风格怎样，团队的运作风格也会怎样。无论要求团队成员如何如何自管理，始终还是要得到首肯的。

有一点很重要，也是最实际的，如果晨会开得不好也不碍事（啥叫碍事就见仁见智了），那就随便吧。