菜鸟教练的第一次登场
转载：https://mp.weixin.qq.com/s?__biz=MzkwNTI2NjAxMA==&mid=2247483784&idx=1&sn=e713e57c7f30155a8e7e5efceb407b8f&chksm=c0fb17bdf78c9eaba4e8bdc80b964636def6d6164a7a3983f56f192d3f5c2c7448c9a1b66642&cur_album_id=1979309913222742017&scene=189#wechat_redirect
作为Scrum Master，在团队中的存在感不需要很强烈，更多的时候需要引导团队成员自发的去进行各项活动，SM在导引结束后，就可以适当的退出，相信团队的力量。在活动的组织过程中，需要时刻关注倾听，及时给听众一些反馈，必要的时候可以建立一个问题区，适当的时间给客户解答。”
本文结构如下，希望能够帮助你阅读。
01 项目背景
最近在做项目调研时，遇到一个比较好玩的项目（简称A项目）。此项目基本上处于无监管的状态，由于没有交付的压力（内部系统），所以大家对项目的进度也都不敏感。经过访谈和了解后，总结了项目存的几个比较突出的问题： 项目进度不可控：从项目立项到MVP版本交付，项目整体进度一再往后延期，团队以周报的方式向上反馈。但没有描述清楚项目的整体进度如何，因为是内部项目，所以上一层领导也没太在意。 项目计划不可用：MVP版本规划了太多的内容，导致研发时间较长，项目计划多次变更，原来的计划已经严重偏离，团队成员对交付时间变的不敏感。 信息传达不透明：团队成员都在埋头苦干，努力完成各自的任务。对于这个项目的愿景、整体规划都不清晰。对于项目的长期规则和近期目标都不了解，接下来要实现哪些功能，并不明确。
02 敏捷能给团队带来什么
有利的条件在于，现在整个中心都处于敏捷化转型的大方向上，和领导沟通确认后，可以在A团队进行敏捷相关的尝试。那么，哪些敏捷的活动可以帮助到这个团队呢？在专业人士的指导和梳理下，明确了三个活动可以帮助到A团队：用户故事地图、看板及迭代活动。 用户故事地图：可以帮助团队成员及领导清晰地知道这个产品的定位是什么，将来会包含哪些功能，能够给用户解决什么问题。而且通过不断检视用户故事地图，大家可以群策群力，为产品的发展提供自己的建议 引入迭代活动：基于Scrum的实践，引入2周一次的迭代活动，尽快交付价值，获取反馈。同时也让项目的交付变得更加清晰，锻炼团队的研发速率。 看板可视化：每个迭代的内容通过看板可视化出来，让站会变得更可视化，大家可以更聚焦于团队的交付件。也能更不清晰的反馈出每个人的工作进展情况。
03 敏捷理论导入培训
A团队对于敏捷的认知并不清晰，所以在开始改动前，需要和团队对齐思想，讲解敏捷的相关基础知识。于是我这个菜鸟教练就开始入场了（额，好歹也是ACP和DOM的拥有者，不能怂）。组织了两场理论培训，主要是关于Scrum和用户故事的理论知识讲解。这里就不全量展开写了。列下几个核心的PPT和大家分享下（有敏捷经验的可以略过或者回复一起讨论）
传统项目管理的铁三角和敏捷项目管理的铁三角不同。在传统项目的管理中，范围和成本是相对固定，交付时间充满不确定性，项目交付时间越长，风险越容易被隐藏。而在敏捷的项目管理中，强调的是价值导向，质量优先，对交付的范围是可变的。因为交付周期短，功能延期一个迭代（一般是2周）交付，客户一般情况下是可接受的。同时因为交付频率高，可以快速刺探到客户的反馈，及时修正，提高用户对产品的感知度。当然，并不是所有的项目都适合用敏捷的模式来玩，此处无意引战。
上图是标准Scrum的流程和角色。这个不展开说，大家可以找出图中我们常说的“3355”对应的内容分别是什么么？最后一个5是：“勇气、承诺、专注、开放、尊重”，是敏捷活动的基石。
这页PPT的信息量非常的大，不同的角色都可以从这个图中找到自己关心的信息。简单的解读下：
- PO规划“做对的事”与Team实现“把事做对”，在Scrum的角色分工中，PO负责确认什么是对的事，也就是产品需要实现哪些功能，解决哪些用户的真实场景。而研发的同学负责如何把确定的事做对，快速的交付到用户手中。这两者信息的最终对齐体现在迭代计划会上（在迭代期间PO和Team可以反复沟通确认，最终在迭代计划会上达成共识）
- 在迭代周期中，PO需要在第一周根据团队的研发速率，梳理出下个迭代的大致用户故事，并与核心研发沟通技术实现是否存在问题，并在第一周的周五完成原型设计并召开需求梳理会，和团队第一次对齐需求；并在第二周完成UI设计（若是技术需求可不用）
- 对于研发人员来说，在2周的迭代周期内，大约有6天的时间用于编码及修复问题，在这个过程中，测试要及早介入，增量测试，并提供必要的自动化测试手段以保证代码在持续集成的过程中质量可控。在第二周的周三完成代码封版并进行回归测试。整体研发过程需要有配对的GIT分支管理模型、DevOps工具链等一些工程能力的支持。这个有机会在后续的文章中和大家一起分享。
- 在PPT的左下角，关于几个会议的核心输出内容，大家也可以关注下。
理论的内容最终还是需要落地到每个人手上，为了更好的实践敏捷，我们需要做好一些底层能力的建设。如上图PPT中提到的代码分支模型、快速响应的持续集成等等
是不是很惊喜？一个用户故事的拆分可以扩散出那么多信息。不要被吓到。在实际的应用中，故事的拆解在满足INVEST原则后，一般只会有两个要求：组内成员明白它表达的意思是什么，以及在2~3个工作日内可交付即可。没有必要太过于遵循模板。
04 用户故事活动开展
在同步完理论信息后，就需要动手练习了。于是又组织了一场共创活动，团队一起来共创用户故事地图及看板内容，提升团队成员对项目的认知程度。对于这个活动，我心里还是比较怂的。主要是控场经验不足。这种活动和分享PPT有很大的不同在于，分享PPT,只要按照自己的思路表达出内容，在适当的时候关注听众的反馈即可。而活动则需要全程控场，避免尴尬和冷场。所以在事前做了一份比较细的Excel表格，每个节点需要干什么都罗列出来了（还做了PPT作为引导，怕自己记不住流程）。具体的活动过程在这里就不展开了，下面放两张现场图。
关于看板的一些相关信息，可以参考我的另一个文章：关于看板的思考与总结活动总结：
- 作为Scrum Master，在团队中的存在感不需要很强烈，更多的时候需要引导团队成员自发的去进行各项活动，SM在导引结束后，就可以适当的退出，相信团队的力量。
- 在活动的组织过程中，需要时刻关注倾听，及时给听众一些反馈，必要的时候可以建立一个问题区，适当的时间给客户解答。
- 活动过程中，每个小活动的衔接段过渡要更自然些，可以设计一些过渡小活动。
05 敏捷理念的理解
这段时间一直在向敏捷圈中的顶级教练（小林姐，尹学罡老师）沟通和学习，对敏捷的看法也有更深入的了解。例如，敏捷活动本质上就是更精细化的项目管理，通过一些手段可视化的手段，让信息的表达更加透明。引入敏捷活动，并不一定会提高团队的产能，相反，可能还会降低一些预期（相应的工程能力的提升，无论是否是敏捷活动都会提升效率，所以不包含在敏捷活动中）。但是引入敏捷，可以用120%的投入，来避免可能的200%、300%的返工（因为小步快跑，可以快速获得用户反馈，做得不对，可以及时改。而瀑布模式下，到项目后期才会引入客户验收，如果出现返工，代价太高）。
