image.png
经过Sprint 1第一周的事件，ScrumMaster按照约定闭上嘴，往后退，安静的做一个引导流程的ScrumMaster，让团队按照自己的意愿走。
Sprint 1的第二周，团队小伙伴，很愉快的玩下去，"顺利" 完成第一个Sprint。
Sprint 1 的表现：
- 急着动手实现，没有严格按照约定对用户故事拆解验收标准。
- 没有明确的验收标准，随着时间的推移，记忆会发生变化，成员也就没有路标来提醒是否跨越边界。
- 工作边界模糊，无法有效聚焦，成员相当部分精力去做了不在Sprint 1原先计划的工作，原来商定的范围的东西却没有完全做好。
- 幸运的是，测试人员通过自动化验收测试，把开发人员交付的每个功能，反向补充验收标准。
- PO在验收的时候，满意度给了 80% 。
- Sprint结束，团队不清楚自己的产能情况。还是靠测试人员从她的自动化测试用例中反向统计出来。(是否真实反映, 不去较真了，有已经比没有强 😂)
- Sprint 1 实现了用户侧的MVP, 从零开始拉通了整个业务流程👍👍。
8. 整个团队，尤其是主力人员，表现非常进取👍👍
Sprint 1 回顾会
引导团队自己发现问题，团队按照自己的意愿，暴露自己愿意暴露的问题，回避了一些不愿承认的问题。
Sprint 2 计划会
PO给了更多规模的用户故事，由于这些故事，都没有预先拆解/明确验收标准，团队也还没接受Sprint1的经验教训，照单全收。
ScrumMaster提醒团队和PO，是否确认真的能完成这些范围？团队认为估算是无法准确，既然不能准确，估不估没什么区别，还不如做到哪算哪，反正大家不偷懒就行。
就这样愉快的结束了Sprint 2计划会。
Sprint 2 的一个技术目标，就是希望通过引入领域模型来更好的面向业务组织架构设计。
担任架构设计的架构师，比较大胆和进取，更是想一步踏进CQRS + Event Sourcing的领域，忽略了两个关键因数:
- 团队是否具备CQRS + Event Sourcing的能力和意愿？
- NodeJS的世界，是否有如JAVA世界的框架可用？
ScrumMaster从一开始就表明意见，不建议一步到位，进入CQRS + Event Sourcing. 即使 MVC + Service + DomainModel，已经是非常大的进步了。
意见是否采纳，还是团队自己去决定，风险也应当自己去承担。
Sprint 2 团队继续愉快的玩耍下去。
ScrumMaster提醒存在的风险:
- 由于交付规模更大，团队已经不再想浪费时间整理验收标准。那么每个用户故事的完成边界在哪？
- 架构风险
- 交付风险
团队的反应就是，少整这些没用的东西，干活更重要。
既然许多东西都可以丢弃，玩流程还不简单？
So ScrumMaster在Sprint 2的第二周，直接引导UI来兼任初级的流程ScrumMaster, 负责每天的Stand Meeting，顺便也为公司储备ScrumMaster人才 😁 。
Sprint 2结束的那一天，正好ScrumMaster需要外出去参加 ThoughtWord十周年的雷达大会。 因此，评审会 与 回顾会 由 "初级流程ScrumMaster" 来组织。
以下，ScrumMaster缩写为 SM , "初级流程ScrumMaster" 缩写为 SM Jr.
当然，SM 提前引导 SM Jr. 与团队清楚:
会议需要提前做好哪些准备工作？
实现什么目标？
注意什么事项？
SM安心去参加雷达大会。
Sprint 2 的表现:
- 实际完成的规模，确实比 Sprint 1有提升。
- PO对交付的反馈，满意度下降为 75%。
Sprint 2 的回顾部分内容
sprint2_retro.png
(注: SM在Sprint 1计划的时候, 引导PO与团队如何识别出最小化的用户侧全流程MVP, 因此Sprint 1的交付，是可以演示的完整业务流程。在Sprint 2的计划时，PO与团队按照自己的意愿玩，结果就是，Sprint 2没能把后台管理的全流程业务与之闭环。
意味着，按照PO与团队现在的玩法，至少是4个Sprint后，才能真正给用户体验并收集反馈。正因为未能及早引入用户提供反馈，PO与团队对于后端连许多应当在项目一开始就分析好的用户角色与流程都不清楚。披着Scrum皮的Waterfall 😂😂😂😂~~~
而如果是遵照SM的节奏引导，在Sprint 2结束时，就能完成整个业务从前到后的闭环，便立刻就可以引入用户(终端用户，后端用户)提供反馈, 这才是 敏捷 的实践。)
事实证明，没有SM，团队也能玩好Scrum的这些过程。再次说明，Scrum就是这么简单。
SM 补充了几个问题给团队思考：
-
Sprint 2 交付的范围比Sprint 1多，但PO的满意度却从 80% 下降为 75% ，原因是什么？
-
为何每个Sprint团队都不能明确知道自己交付能力是多少？ 完全依赖 Betty 的统计，这个统计正确度如何？是否能真实的反映团队的交付规模？
- 每个Sprint的交付规模，是PO决定，还是团队决定？
实际上，以上问题，团队都不愿做出回应。
Sprint 3 计划会
由于习惯性的需求没有提前梳理，计划会实际变成需求整理会。
梳理完后，SM提了问题。
SM：根据 Sprint 2 的实际表现，Sprint 3 的规模，我们真的能吃下来吗？
团队：那也得做呀。
PO：团队需要加把劲，还没怎么加班呢，加加班应该可以完成吧。
SM：团队真的可以吗？要不要重新谈范围？
团队：不需要，努努力试试。
SM：本次PO与团队期望达到什么样的满意度？
团队：希望达到80%。
SM：意思是我们能完成80%, 剩下的20%不一定能完成，并且很大几率不能完成？
团队: 是。
SM: 我们是否可以调整范围，把价值最低的20%拿掉，然后承诺100%完成剩下的范围？这是最低完成承诺，我们在目标完成后，依然可以挑战那原来的20%。
团队：玩数字游戏么？那没什么意义。反正我们全力做就是了。
SM: 那我们预期完成的80%有哪些？
团队：？？？？？？
SM：好吧，开心就好，请继续!
。。。。。。。
Scrum 不是你的亲妈
作为团队教练，放置了一面面镜子给团队，让团队多角度理解自己。
.
问题：天天说团队需要镜子镜子，请问教练是否也需要镜子？需要的话，镜子在哪？
.
网友评论