部门研发敏捷转型，做为主要的参与者，经常有人问我什么是SM，根据中文拼音输入法打出来的有神马、傻冒、师妹、圣母、水母、死猫……英文全拼是Scrum Master，字面上理解是敏捷专家，实际上就是负责敏捷方法落地的推动者和实施者。近期跟着敏捷教练和一帮SM菜鸟打了一阵子酱油，壮着胆子说说个人对SM工作的理解，就当抛砖引玉吧。
首先，什么样的人适合做SM？第一要排除团队中的业务专家和技术专家，所谓道不同不相为谋，他们太忙了，而且兴趣点也不在这里；其次排除刚入职几天的新警察，人都没认全，组织会议这么简单的事估计都能弄出幺蛾子来；再次排除团队内沟通能力不强、绩效偏低、人际关系不行的人，至于为什么，动动脚趾头就能知道；那么剩下的就是善于沟通和表达、积极热情、能和大家打成一片、处于团队中上等层次的成员，当然美女最好，因为性别的优势很难让其他人say no，所以让她们来尝试组织敏捷的落地会更顺畅。
那么SM如何开展工作呢？根据书上说的、教练教的、自己实践的，总结了下面最基础的checklist：
1、首先给自己的团队取个名字吧，想一句口号，让大家每天刚上班就能融入团队氛围，算是文化建设吧；
2、牵头组织确定团队的迭代周期，一般为2周，起止时间最好避开周末，同时计算下一个迭代周期的有效工作时间，注意排除节假日、加班时间、团队成员请假时间；
3、督促BA（Business Analysis 业务分析师）在迭代开始前根据PB（Product Backlog用户故事）拆解SB（Sprint Backlog 迭代任务）并进行优先级排序，同时在迭代计划会之前发布，通过需求梳理会或小范围讨论让团队成员都能理解SB；
4、迭代周期开始时，组织召开计划会，明确迭代目标，并评估工作量，注意评估工作量不应由团队负责人直接指定和安排，而是通过3人以上同时评估得出，如果差异较大需要当场PK以消除分歧；迭代周期内的工作量对每个人来说不一定“刚刚好”，SM可以根据团队的实际情况适当预留一些时间做为临时插入任务的缓冲或解决故障的花费；评估完成后形成迭代计划进行跟踪；
5、布置看板（KANBAN）没有固定的格式，但是需要把所有迭代周期内的任务通过便签全部上板，注意写明负责人和完成时间（也可用磁钉代替），注意同时组织团队完成DOD（defination of done 完成定义）并写在大白纸贴在墙上，每日站会的时候大家都可以随时看到并加以对照；
6、每日站会最好安排在早上刚上班的时候，时长最好不超过15分钟，团队成员挨个说三件事：昨天做了什么、今天要做什么、有什么困难和问题；注意不要讨论，容易发散导致站会时间不受控，困难和问题可以会后由相关的人讨论解决；
7、迭代末期组织验收会，邀请外部专家（PO、市场、部门领导等）甚至客户参与，秀出团队在该迭代周内的主要工作和成果，听取外部意见并加以改进，如果得到良好口碑还会增强团队凝聚力和自豪感；
8、迭代周期结束前组织回顾会（部门领导最好回避），通过头脑风暴和投票筛选出该周期内做的好的与不好的事项，每个不超过3项，对于做的不好的，也给出改进建议，写在大白纸贴在墙上，督促团队成员持续改进。
SM的工作看起来简单，做起来却不容易，更多的是组织和沟通的工作，如何把这些事情踏踏实实的做起来，带领团队高效的运转起来，是对SM的长期考验。