敏捷开发的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
建立爱分享知识的氛围，鼓励写技术文章

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

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

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

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

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

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

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

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

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

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

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

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

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

敏捷开发的Scrum晨会实践相关推荐

《深入核心的敏捷开发：ThoughtWorks五大关键实践》读书摘记
深入核心的敏捷开发:ThoughtWorks五大关键实践肖然张凯峰简介价值驱动的精益研发转型实录愿景:打造招行端到端的精益研发管理体系,价值驱动.质量为先,以行业领先的科技能力驱动创新与变革 ...
敏捷开发和Scrum、Kanban、XP的关系与区别
目录前言一.敏捷是什么二.Scrum是什么三.Kanban是什么四.XP是什么五.敏捷开发和Scrum.Kanban.XP的关系六.总结前言敏捷经过20多年的发展,被广为人知,但是也 ...
浅谈敏捷开发及Scrum工具leangoo（三）
之前两篇有说到敏捷开发及Scrum的一些概念及实施,现在再来记录下我们在敏捷开发实施中使用的一些工具,主要说下leangoo 工具不是敏捷开发及Scrum的必须品,但有了工具,可以让敏捷开发更好的实施 ...
【IPD】敏捷开发与IPD结合的实践培训课程「3月11-12日」
课程名称敏捷开发与 IPD结合的实践 (Agile Development - IPD and Agile Development Practice ) 参加对象企业总工.技术总监.系统架构师.研 ...
【系统分析与设计】软件开发模式之敏捷开发（Scrum）分析
文章目录 1 敏捷开发 2 传统的开发模式和敏捷开发模式的对比 2.1 瀑布模型: 2.2 敏捷模型: 3 敏捷开发scrum的实施 4 敏捷工作件 5 敏捷管理实践 1 敏捷开发敏捷开发以用户的需 ...
团队如何实施敏捷开发以及Scrum电子看板工具
概述本场景描述的是针对10以下小型产品研发团队或小型项目的敏捷应用场景.Leangoo单团队敏捷开发项目模板是基于Scrum模型定义的,所以这里所说的单团队是指只有一个Scrum团队的场景. Scr ...
敏捷开发中Scrum方法
现代软件开发肯定是复杂的,因为到目前为止,还没有一种方法从根本上消除软件之前的依赖,软件随着规模的扩大,需求的不精确和不停的变更以及需求调研人员限于领域知识所限,无法抽像出客户的需求.从技术上来说,虽 ...
敏捷开发与Scrum区别（敏捷开发（Agile）教程）
敏捷是一种使用1至4周的短迭代的软件开发方法的迭代方法.由于敏捷方法,开发过程是一致的,以满足不断变化的业务需求.使用敏捷方法,软件分发(版本发布)紧凑,更少. Scrum是一个敏捷框架,可以帮助敏捷 ...
敏捷开发及Scrum介绍
敏捷开发(agile development)是一种以人为核心.迭代.循序渐进的开发方法.非常短的循环,使终端客户可以及时.快速地看到他们花钱构建的软件是一个什么样的结果. 1 历史背景 20世纪60 ...

敏捷开发的Scrum晨会实践

敏捷开发的Scrum晨会实践相关推荐

最新文章

热门文章