记一次当ScrumMaster的心得总结

背景：敏捷开发中，我们引入了ScrumMaster（以下简称“SM”）。在整个项目的推进和管理起到了至关重要的作用，以下是本人在工作中的一些心得总结，欢迎大家交流。

一、SM对本次Sprint的做概述

这次迭代与之前的不同之处：

• 坚持每日早会（包括测试阶段），并提前提醒开发团队做好准备。
• 发送邮件时为防止同志相关人员遗漏，推动运维建立有车来邮件群组。并@大家，选择邮件时注意选择相关人员，主送和抄送。项目开发成员12名，根据邮件内容相关性抄送其他人，注意邮件礼仪。
• 早会形式变化：不一定要天天在会议室打开电脑过项目进度。本次迭代中，在必要时过一下，这只是手段，不是目的。目的在于督促大家及时更新TAPD状态,站在管理的角度了解任务的开发进度。换角度去看待为什么要及时更新。以后在大家轮值SM岗位时，会更有体会。

• 早会场所的变化：前两个迭代的早会 是在会议进行的，会出现步伐不统一，站位不统一，本次迭代中就参考Dip项目组的站会做法，在座位上进行，依赖于项目的数据上下游汇报流程，从服务器端开始，前端结束。这样也有利于大家快速了解项目情况和相关性任务情况。（其实当初座位的安排也是出于方便项目高效交流来设计安排的）

  TAPD使用上的调整变化：

  • TAPD中项目任务的建立

    之前按照先功能后各端（故事板）的设置，本次迭代开发根据当前开发现状做了细分调整。

    本次迭代，就和Mark商量并建立了各端的项目开发任务：移动端、系统后台、商户后台。

    以后大家先按约定的规则做，再根据实际情况调整。

  • TAPD中“完成度”设置 由于本次迭代涉及很多的电商后台系统设计，有些模块的开发时间不好评估，开发进度如果按之前的设置，可能一直是开发中。从项目管理的角度看上去，感觉项目没进度，这样不方便大家尽量准确了解整体进度。于是引入了 “完成度”设置。开发中的完成度也可以做到尽可能准确的评估。

  • TAPD升级成企业版本后，可以设置预估工时和时间花费，在项目完成度根据填写工时自动计算。

待提高：

1. 第一次当SM经验不足，有些时间点的节奏和流程不够熟悉;
2. 其他由各们同事提出改进建议。

二.各位同事总结本次 Sprint 的情况及建议

对PM的建议

本次迭代现状：由于时间不够充分(特殊原因)、设计与产品职责未分离、产品逻辑较复杂、产品经理岗位缺失。

出现问题：本次迭代需求文档缺乏、逻辑细节缺乏、产品模型缺乏。

解决方法建议：需求阶段时间需更充分、与团队多沟通、设计与产品职责分离（产品经理岗位或UI设计岗位可考虑尽快补充一名）。

对SM的建议

在提测、验收阶段 及时去跟进项目进展，尽量保持在现场，应对突发情况，及时去推动解决。

对开发的建议

做得好的地方：服务器在开发环境挂了的情况很少了， 有改进。

需要改进建议：逐步加强团队磨合、加强消息响应度。

其他：

1.需求评估细节与时间的平衡

产品评审阶段 有很多细节是无法提前感知到的，只有在项目推动时才会出现，新增或是bug的优化建议，会额外增加工作量或开发时间。

2.个人任务开发时间与项目时间的平衡

如陪产 、家人生病、 感冒发烧、突发事件等特殊情况的需要的时间处理

小结：

• 需要拿捏好时间规划与实际开发现状的平衡点
• 加强沟通，有问题及时提出，大家一起商讨解决方案。

对测试的建议

• 测试阶段重视自测，注意测试细节。
• 上线前的资源准备时及时更新相关配置文件。
• 代码更新的约定：早、中、晚更新或一天两次更新代码， 重新构建。

  由测试人员提醒开发人员代码及时更新、构建，大家及时响应，配合测试完成阶段性测试。

  注：下个迭代开始试运行更新代码约定。

• 在以后测试中，测试人员针对问题的提出，添加“发生在”字段，方便定位问题，如问题出现在产品需求、H5、Android 或是iOS端。方便开发完成后用数据去回顾开发流程上的问题，有针对性的流程改进。
• TAPD 的测试中的设置建议：在提交测试中的“处理人”一栏，我们团队统一意见， 有默认值且指定某一成员，如指定测试人员。

沟通中消息同步的问题

微信群公告 、@到个人、邮件、主动走动沟通，根据个人习惯通知到位就行。

三、探讨开发团队的建设问题

• KPI与OKR （指标与目标）

  “以关注程序员为例，如果我们关注目标，我们会想接下来我们应该做什么事情，是要解决产品的卡顿问题，还是引入大数据来做精准推荐;如果关注指标，因为我们的工作是编程，那我们就会想哪些指标可以衡量编程工作呢？我们想到的是代码行数、Bug数、单元测试覆盖率等等。”

• 技术文化：技术分享会、Code Review、技术博客、WIKI完善等等
• 公司文化活动建设： 如团建、打球活动等如何有效开展建议
• 2019年开发团队年终总结回顾

其他开发团队的优缺点总结：：

1. 信息不对称的问题 ，需要加强沟通;
2. TAPD 流程的问题 及时更新状态 ;
3. 思维碰撞，对产品的有新的看法 提出建议 多去碰撞;
4. 夹带特性 是禁止的。