我们践行敏捷有一段时间了，为了考核每个敏捷团队的执行效果，有了大班，中班，小班的考核指标。自从被贴上“敏捷中班”标签那天起，我就想我注定有此”一劫“，不曾想即使中间请了一次假大家也没有忘记这件事，所以现在就有了这次活动分享。

敏捷是什么

敏捷是一种过程控制论，一种做事情的方法；

敏捷是一套工具集；看板、站会、用户故事等等都是它的工具。

敏捷是一种企业管理方式。可以通过敏捷的方式把大团队拆分若干个敏捷小组。

僵化、优化、固化

在带敏捷团队之前我都是用PMP里面的方法来实行团队项目管理，但是我本人却一直在经历着敏捷的方法，经历过这套敏捷方法的执行过程，正所谓“虽没有吃过猪肉，但见过猪跑”。所谓的僵化不是一个贬义词，是说这套东西已经有了那么一个理论高度了，站在它的肩膀上，继续看，继续做就可以。优化呢就是一个实践的过程，要知道梨子的味道就是亲口尝一下。可以尝试很多种方法，站会，回顾会，计划会等等。当不断的优化之后，则可以形成了一套固定的规则，比如站会的看板制度，这样把它固化下来。

空杯ALLIN.png

敏捷对我来讲就像一套独孤九剑，如果我全部练会，当然加上任督二脉被打通，所向披靡，但会是一个持续的较长的过程。可是如果我熟练掌握了里面的破剑式、破枪式，是不是也可以独步武林。那么在众多的各样招式中被我当前熟练应用的是看板和DOR、DOD。

站会

看板将所有的故事可视化，涵盖每个点也包括风险，躲也躲不了。说到看板那就不得提到站会。在这个活动上我们尝试了好多方式，起先是每个人来陈述他自己的故事，当然还是三个要素：事情、人、风险。这样一轮下来时间漫长，你可以控制每个时间点，但每个人的风格不一致。还有一个问题是大家围绕一圈陈述人往往忘记了更新工时，这个时候有说，好先进行下一个，站会后更新，实际上会后也没有更新。然后我们就尝试了SM来主导站会，SM一个人对着对应的故事来询问，注意是，询问这个故事的人、做的事情、有无风险。如果有风险换一种风险颜色的便签贴上去。当时把工时也更新了。这个是我目前感觉最好的方式。可能有人会说让每个人陈述是一个锻炼的机会，可是在敏捷里面锻炼的地方有很多，比如轮流主导站会，比如其他会议上等等。站会的主要目的是什么，经历过这么多次迭代站会，我认为只有一个重要的目的就是更新工时，确认风险。用特别颜色的便签将风险辨识出来，作为SM要协助去解决这些已经识别出来的风险。

DOR DOD

这是两个非常好的东西一个管输入，一个管输出。借助这两个东西可以掌控好产品的需求，控制产出的流出规范。我们在DOR和DOD的基础上又做了一个上线清单，因为我们发现线上问题大部分是有上线引起的，一个系统一年半载不上线，不变化基本不会有什么大问题出现。那么每次上线哪怕再简单的步骤我们也要清单记录出来，每执行一步标记完成。如下图

上线清单.png

质量铁三角

我们都知道做项目也好，敏捷也好，服务的目标都是达到或者提升迭代软件的质量。也就是在传统PMP的方式下或者当前的敏捷形式下都会围绕范围、成本、进度这个铁三角来展开活动。曾经有一段时间我以为我不再需要这个三角关系了，我敏捷了。但当我每次开迭代计划会议的时候，我要确定哪些故事在这个迭代进行，我何尝不是在进行范围的管理；当有人提出来这个故事可能在这次迭代完不成的时候，我是不是在考虑人员这个资源呢也就是成本；迭代进行中就不需关注进度了吗，实际每次站会也在做工时消耗的记录。所有的这些活动你都没有缺少。

质量三角.png

计划会议的范围管理

计划会议的目的之一就是确认范围，确认这个迭代的范围，也确认每一个故事的范围。但并不是确认范围这个动作完成就完事大吉了。持续活动就是要控制范围，控制范围的核心就是控制变更，迭代内是不可能不变更的，拥抱变化。导致范围蔓延的原因有很多比如业务方临时加的需求，老板的需求，也有研发自己提的锦上添花的需求。控制范围常用的手段比如你可以使用专家判断，专家不是固定，可以是虚拟，架构师、部门经理、总监都可以成为你的专家。也可以使用集体讨论，产品、研发、运营一起讨论确定，确实有影响用户使用流程，严重影响用户体验，及时响应变更，在这个迭代完成。

故事工时

要评估一个故事的工时需要经历哪些脑部运动，尤其是有相关联的故事。首先要定义故事的内容、再定义故事的范围，有关联的故事还要排序依赖关系，进而才能够制定每个故事的持续时间。评估工时是一个科学的过程，通过确定故事的范围，结合当前人员情况，再运用科学的方法比如类比法，三点估算法等等，综合得出的一个结果。但现实中反而是往往被一些拍脑袋的业务方或者不懂三七二一的项目经理强迫你立即出一个工时，那结果是你也拍脑袋出一个。

工时评估方法.png

可裁剪

上文有提到敏捷是一套工具集，这个工具集是可以裁剪的。并不要求你十八般武器样样精通，贴近实际紧紧抓住几个招式，熟练应用也能起到事半功倍的效果。比如你认为回顾会议每次时间实在漫长，那你可以裁剪，里面有个小环节是写下上个迭代你不爽的地方，那么并不是每次都不爽吧，那就可以两个迭代搞一次这样的环节。甚至你完全可以把回顾省掉，就搞一次评审会。我们的团队愿景是：持续开心，持续成就感的团队。开心成就感并不是说在回顾会上买些好吃的零食，大家其乐融融。更希望得到的是成长，我们做评审，每个人来演示一下这个迭代完成的效果，如果能请到外部专家就更好了，他们可以给一些建设性的建议，说不定醍醐灌顶的时刻就来了。 下面这个图里面的项目在不影响实际执行的情况下都是可以裁剪的。

可裁剪.png

关于运动

还记得我们持续开心，持续成就感的团队愿景，运动虽然不能使我们每天乐呵呵的开心但可以不至于让我们沮丧的度过每一天。我们游泳，跑步机比赛，每日俯卧撑。保持一个乐观的心态去耕耘每一天。“闲时运动，因为有时间。忙时要运动，可以放松减压。高兴时运动，让人更高兴。沮丧时运动，让人高兴起来。”共勉。

写在最后

独孤九剑也好九阳真经也罢，类比于敏捷中的各种工具招式，我们都需要内外兼修。外练招式，方法，内醒思想，感悟。在这些各种工具招式中也不是你方唱罢我登场，而是要结合实际，根据团队最适合的路径去裁剪。走适合自己团队特色的敏捷之路。

本文原创，转载请注明作者及出处，并附上链接https://www.jianshu.com/p/460d8b42f15a