大概进入新公司的一个月左右，另外一个团队因为质量和情报共享的问题，想导入Scrum来解决问题。
在我看来scrum并不会解决问题，但是使用scrum会让问题迎刃而解。
所以我同意带队进scrum，可是我不保证能解决问题。
团队组成 TechLeader，Manager，DEV（5）QA（2）SRE（2） Manager 是 SM 和 PO的合体. THAT IS Bad prcatice.
- 召集团队所有成员做了一个开始scrum的kickoff
- 为什么使用scrum
- scrum是什么
- scrum要做什么
- scrum的目标
pre - 做好所有会议的agenda模版 - 准备会议agenda - 准备demo环境来做review会议 - 准备故事来做planning会议
-
开始第一次review和planning
- review：把将要release的功能，bugfix展示给PO看，听取意见，决定是否release
- planning：
- review会议后大家觉得发布流程和branch战略是很不明确的。就此讨论了大概2个小时。这不再agenda里
- 因为团队是职能划分的，对point的定义，意见不同意。日后衡量velocity，需要看breakdown，所以先按照3h/point。
- 问题
- 能力不一样，估计的point内，能力差的人很难完成，能力好的人能快完成
- 职能不一样，front无法估计backend，backend无法估计sre，等等
- 平均值的point不可信，point决定不应该是多数派，做的人来决定point会比较好
- 花费较长时间在解释怎么做，做什么。对feature要达成统一认知，比较难控制时间。
- 问题 SRE和QA是否该参加估算point
-
开始sprint
- sprint开始第三天，manager预警：task没有进展，没有看到预期生产性。
- scrum主推组会议：上周3才planning，开始才3天，这个预警的问题处在其他地方。
- story定义模糊，Gloal没有，状态没有。
- Daily上没有明确确认blocker，SM没有去解决blocking。
- 虽然估算了point，但是对实现方面还是没有认识全面。
- 全能问题，backend的程序员去做frontend，毕竟需要学习和话费更多时间。
-
重开planning和KPT
- 1 的planning只是针对优先级高的bug来做，缺少高优先的feature
- KPT主要是走流程，让大家总结一下，过去7天里的scrum。果然大家还是提出了很多问题和建议
- 职责范围
- 开会时间过长
- 估算point和能力差异之间该如何权衡
- 文档模版，release，spec等
- 开始估算Feature
- Feature没有事先分享
- Feature的提问，PO没有充分认识。导致无法解释明白就开始估算。无意义的估算。
-
重开Sprint
- Manager开始第二次预警，开发速度没有改变，Task没有被搞定。
- 压力来自于 PM
- Scrum成果没有总结，Blocking没有扫清，整个团队几乎没有主动性。遇到问题，都是在等他人来注意，来解决。
- 改善Daily，SM去扫清blocking，推动团队。加强自我管理意识。
- Manager开始第二次预警，开发速度没有改变，Task没有被搞定。
-
我退出指导Scrum
- 工作原因，指导内容已经没有了，剩下就看团队自己了。
- 团队需要内部解决形成一个自理团队
- TechLead 成了PO
- SM并不是manager
- 对于Board的清理和管理，还是各自干才有参与感。
- 配合问题，需要提高自我修养
- Manager问题，没有起到调和作用。
- Scrum预热不充分
- 过早的组织分层
- 对开发流程，整体结构不了解。带着走了一些弯路
- 带入了不相干的人，导致讨论过程中被跑题
- 还是对Scrum认识太肤浅