本文总结了开发团队中,在引入Scrum Master角色后在团队中是如何做的，以及在一个版本迭代后的复盘总结。方便今后在工作中随时查阅，希望对你有所帮助。
0.相关术语解释：
PM :是Project Manager的缩写，项目主管或项目经理，主要负责统筹规划项目进度及产品生命，其工作职能直接对公司高层负责。作为项目的管理者，PM通常会参与到一个或多个项目的管理与决策工作中。
TL: 是Team Leader的缩写，主要负责整个项目的统筹，安排等。细分之下有移动端 团队Leader,服务器团队Leader 或整个开发团队的Leader等等。
PO: Product Owner的缩写，字面意思是产品或业务负责人，即熟悉该产品所有业务相关的逻辑、流程、设置等方面事宜的人员，一般可由产品经理担任，也可由熟悉业务的开发人员担任。
PRD: Product Requirement Document 的缩写，即产品需求文档。
Scrum：是迭代式增量软件开发过程，通常用于敏捷软件开发。
1.什么是Scrum Master?
敏捷开发中的SM即Scrum Master，字面意思是敏捷专家或者敏捷大师，即熟悉敏捷开发模式及敏捷实施流程的人员。一般可由敏捷团队当中的开发负责人担任，部分能力很强且懂技术的产品经理也可担任这个角色，因涉及到工作量评估和分派等工作，最好都是由技术能力较强的人员担任。
2. Scrum Master的职责？和PM有什么区别？
以下Scrum Master 简称为SM。
SM的职责：
简单来说主要有：组织会议、早会、临时沟通会、Sprint Review等等，重在协调资源 ，推动项目进度。
为了确保scrum被理解和正确使用并使得Scrum的收益最大化。主要职责如下：
1、保证团队资源合理利用；
2、保证各个角色及职责良好协作；
3、解决团队开发中的障碍；
4、作为团队和团队外部的接口，协调解决沟通中的问题；
5、保证开发过程按计划进行，组织Scrum Planning Meetings（Sprint计划会议）, Daily Stand-up Meeting（每日站会）, Sprint Review Meeting（Sprint评审会）和 Sprint Retrospective Meeting（Sprint回顾会）。
区别：
在Scrum指南中，唯一一个经过授权的角色理论上应该是PO。然而在Scrum中，SM在团队中是没有授权的，换句话说，敏捷项目团队既没有Manager也没有Leader。PM都是经过在项目层面上经过授权的，SM的职责是确保scrum的正确使用并使得Scrum的收益最大化，SM可以兼职，所以我们团队实行了SM 轮值。
3. 实际迭代开发中我们是怎样做的？
本次迭代开发我们仍然采用了敏捷开发，同时实行了 SM轮值的实行办法，以项目迭代为周期，做为一个迭代的项目负责人组织开发工作。
会议主题：总结复盘本次开发中的经验和需要改进的地方。
参与人员：产品经理、UI设计、移动端开发（Android、iOS开发、H5开发）、服务器开发、团队负责人、担任本次的SM。
以下是对最近一次迭代开发任务做一次总结复盘。
3.1.关于PM
开发任务需求及开发时间的确定
开发任务需求一般来源于市场或上级Boss。角度不同，需求和实际开发中的安排也不同，上级希望多、快、好、省，尽快看到产品实现。而实际开发落地得根据目前的开发情况来定，此时对上级的需求PM需要好好评估，可以对需求分阶段拆解，首先满足主要需求，突出产品特色，对一些现阶段不是很重要的开发任务可以放到二三阶段，对上级沟通时要表达出对未来产品的规划，先实现主流需求，即先搭建产品体系，再完善细节，一步步稳步推进。PM要抗住压力，根据公司实际情况来合理与上级沟通。
需求尽量详尽，增加交互设计；
需求详细的同时，不要过度设计，简单功能复杂化，细节和需求做到均衡，时间允许的情况下，做出高保真原型设计及交互设计。
以User Story（用户故事）为单位输出PRD；
产品需求最好以故事用例来体现，方便用户、开发团队理解，让开发人员到底要做啥。
需求评审前至少提前4小时将PRD发给项目组提前查阅，期间与项目组成员沟通完成答疑；
评审会议鼓励大家多提问，对于疑问点一定要有结论（无争议或确定最终回复时间）。
3.2.关于UI设计
如果开发时间充分，可添加设计交互设计，这个也可以是产品需求阶段实现，做一个高保真的交互设计。
另外关于视觉呈现和需求的平衡，允许有调整的地方，如果在实现某一个功能上，在时间和开发资源消耗过多的情况下，不一定要坚持按UI设计效果实现，希望能适当兼顾开发人员的开发习惯，如兼顾Android和iOS 开发设计规范和用户正常的使用习惯，不过度在一个简单的小功能上过度创新。
关于移动端Android端的设计规范不在此展开讨论，如大家有疑问可在文末留言讨论。
3.3.关于服务器后端开发人员
团队开发中，前端和后端 同步 开发，不可避免会出现服务器崩溃的问题，一般由于服务器要时常部署重启所致。
另一原因，由于服务器的内存不足等原因，几个项目的内存占有率太多，无法及时释放，所以开发中，服务器时常崩溃无响应。
解决办法：
根据公司需求及实际情况，适当增加服务器存储空间;
开发中，经常检测服务器是否崩溃，及时重启，同时在开发中告知开发人员，服务器要重启，保持信息同步。
开发中为了保持信息同步，可以这样做：
后端人员在必要的停服时刻，需要口头通知前端开发人员;
后端服务开发同学，必须保证服务挂掉可以自动重启，比如，使用 supervisor 进程管理；
后端服务开发环境实现 CI（持续集成），即：当某个 feature 提交后，即可自动重新编译并 supervisor 运行;
3.4.关于移动端开发
开发人员之间要互看代码Code Review,行成良好的代码风格。相互学习，共同进步。
iOS和Android发现两端的差异性后，应及早提出并统一；
3.5.关于测试
测试人员，在tapd的缺陷创建时，必须与需求进行关联；
先发送“提测邮件”，再正式进行测试，提测邮件也需发送给产品和UI，并提醒他们验收。
测试时，除了功能测试，UI测试也得同步进行，开发该Bug的同时也把UI细节优化了。
测试用例
测试驱动开发，需求评审通过后，测试用例应该及时编写出来，尽早进行测试用例评审，这样可以及时消除大家对需求理解上的偏差，这个环节其实很重要，大家往往容易忽略，一个合格的测试人员不仅仅是简单的进行功能测试，开发之初的测试用例建立有助于开发团队保持信息同步，尽早发现需求背后的问题，尽早解决，问题越到最后，解决越耗时，还会影响项目进度。
举个栗子，测试人员根据产品需求整理了一个测试用例，以思维导图形式呈现效果，如下图所示：
小结：及时建立测试用例，尽早评审，保持信息同步。
3.6.关于验收
测试收尾阶段，PM及时验收，反馈产品的使用问题。细节问题交给测试人员跟进。
3.7 关于SM
SM需要单独创建迭代版本，组织技术评审会议（排期），尽量以Story为单位设置任务点，大家一起创建任务清单，推动大家完成任务评估并提前设置好起止时间；工期与公司要求冲突的，反馈给PM，商讨应对方案（赶工、延期、缩减需求范围）；
SM组织每日站立会，建议提前5分钟通知大家思考下会议发言内容，会议期间轮流发言（期间不要打断，发言完成后再提问）；结合tapd故事墙（看板）进行例会；帮助大家养成及时关闭任务的习惯；
SM是上帝视角，是组织者，不要做裁判；充分调用项目全员的参与度，鼓励大家积极发言，尤其是偏内向、习惯被动沟通的同事；
SM要做好周知工作，让项目相关方（业务、PM、团队内部）充分了解本次迭代的上线时间、期间进度、风险。
如果没有和团队商议，请不要代表团队做任何承诺。哪怕是一个很小的需求变更，都需要和团队沟通后确定。
时间管理：管理和开发时间的平衡建议三七分，管理工作比较繁琐，会消耗大量碎片化时间，因此在开发任务中不要分配优先级过高的任务给SM。
4.关于协同管理工具的使用
4.1 tpad
PM任务的在tpad建立和分配
任务建立时 可以按功能模块划分，先建立功能点，在功能点下建立二级子需求，分别建立如Android、iOS端、服务器端开发子需求，这样做 方便建立关联任务，及时追踪任务进度。
举个栗子：
在''里程及保养信息'功能点中建立三端(Android、iOS、服务器网关端)的开发任务，关联同一个任务。
开发人员的任务认领、时间评估与开发中的状态更新
开发人员认领任务后，及时变更开发人员，评估开发时间，开发中及时更新任务状态
关于开发任务时间的评估
需求评审进行前，可以先将PRD发出来，进行技术调研，方案选择，在评审时评估时间更准确。
4.2 蓝湖
蓝湖,PM喜欢用的产品原型设计协作平台之一，需求变更时 会 及时在线同步更新。
4.3 磨刀
磨刀，UI喜欢用的产品设计协作平台之一，UI 变更时会及时在线同步更新。同时也支持在上面标注 ，方便开发人员查看开发中用到的UI细节， 如用到的颜色值、距离，以及交互细节等等。
Tips:目前移动端用的这就这个平台协同开发，设计稿以iOS的尺寸 375x1334尺寸，一稿两用，支持Android和iOS平台，以单位px标注单位。
5.关于项目组沟通
沟通会一直贯穿整个开发周期，在时间紧，任务重的情况下，如何有效沟通 是整个团队都需要持续精进的地方。
1.关于需求的沟通
需求任务发起之初，以邮件、在线电子文档，如 Web离线查看文件和Axure原始文档查看PRD(产品需求说明书文档)。在正式召开需求评审前前，项目组最好能提前看下相关文档，有疑问尽早记下来，需求评审中如果涉及到的信息比较多，会议时间长 往往会忽略很多细节，所以在需求评审中鼓励大家一定要集中精力并对需求尽可能刨根问底，对于疑问点一定要有结论（无争议或确定最终回复时间），否则在开发过程中，遇到问题再来讨论调整会耽误的时间更多。反观以前的开发迭代，因需求的复杂程度不同，有争议不可避免，我们只能在开发中多磨合尽量减少。
2.关于开发中的每日站例会
早会的目的 不要拘泥于形式，不仅仅简单汇报一下Done、Doing、To Do。 除了汇报当前自己的开发任务与进度外，有问题最好及时抛出来，此时SM会协调推动，保证项目按进度走。
早会召开前后，及时同步更新tapd的状态。
3.开发中的沟通
开发期间遇到的问题需要PM答疑或者涉及到需求改动的点，一定要在tapd留痕并@相关人，做到信息同步，避免只做口头沟通、避免只有部分人了解需求变更；
建议SM确定一个沟通频次，例如每隔50分钟与上下游进行讨论，50分钟内做开发与记录问题，避免频繁打断相关人的开发思路；
如果不能做到按功能点交付测试，那么在集中提测阶段，建议每日两次站立会，提升bug修复效率。
4.关于加班时沟通
如前端任务重时需要加班，而服务器开发人员工作不重时 下班就收工了。这时前端开发人员有服务器方面的问题时，往往得不到及时响应，所以服务器开发人员最好能留一个能及时响应，此时开发人员，可以留下来学习或者打游戏都是允许的，只要能及时响应前端开发人员联调服务器，保持一个良好的开发氛围很重要。
6.关于团队开发小结
1.各个开发人员，关注好开发的上下游，及时主动告知项目情况，注重交流的专业性和效率性。
2.拥有产品思维，站在用户角度考虑问题，及可能全面，有问题及时提出，大家共同解决。
以上，是关于SM职责的思考和Sprint Review中的总结思考，希望对你有所帮助。如有疑问，欢迎大家留言讨论。
参考资料：
