研发效能认证学员作品：如何做好敏捷实践丨IDCF
作者：徐渊峰（现就职兴业数字金融服务（上海）股份有限公司 研发管理部）
研发效能（DevOps）工程师（中级）认证、A-CSM认证、ITIL4 认证、信息系统项目管理师
引言
有句话是这么说的：“做一件事，一百个人有一百个看法。”说的很有道理啊，那么我们延伸到敏捷，每个敏捷教练都有自己的敏捷玩法，每个团队有每个团队特有的敏捷实践的开展方式，每个具体实践有各种各样的执行方式。由此可能还推出来各种各样的说法，什么定制化、千人千面。看着非常的有道理，似乎敏捷是可以随意变化，有无数种玩法。从我个人的角度，我认为这在某种程度上是错误的。
我来先说说，大家可能会把敏捷四会通过不同的组织形式来运作，然后说我这个方法多么多么契合我的团队，多么多么提升效率，觉得非常的伟大。我想回应的是：没有一个会比严格按照固定流程和规则来的更有效率。
举个可能不那么恰当的例子，军人是我认为最有效率的职业和一群人，在某些方面可能缺少了一定的活力，但人家就是高效，人家通过一系列的规定、制度以及强有力的执行来做到了这些。收回话题我们来提到敏捷，我就举一个例子，绝大部分超过10人的团队，站会必然能超过15分钟，而大家想出了各种方式去研究站会怎么开，怎么提高积极性等等。似乎都是在往更好的方式去走，但很多都是舍本求末。
思考一下，最基础的敏捷实践是不是已经告诉你怎么开了？每天站会每个人就干两件事情。
1、移动自己的任务板/故事板。
2、讲一下昨天做完了什么，今天要做什么，有什么问题。
试想一下，如果团队严格参照这种做法，这两件事情一个人加起来需要1分钟么？前者用个15秒，后者人一分钟差不多200字，一句话20字，45秒说8句话讲不明白么？为什么人家最基础的敏捷入门就告诉你这么做了，你的敏捷团队却做不到？
仔细想想这个问题，大家都觉得自己是特殊的那一个，自己的团队多么稀有，事情怎么复杂，事实呢，不完全是这样的。官方给的方案就是通过了大量的样本和试验，总结而来的，而我们，在做不停的定制的时候，实际上是在一个个雷趟过去。我们真正应该要做的，是围绕敏捷的基础指南去适当的通过少量且必要的额外手段达到目标，而非刻意去通过一系列的锦上添花的手段增加整个敏捷实践的复杂度。
所以，我带的站会，其实不准备那么多套路，只是采用一些规则，去让这个最简单的流程得到保障。其他的敏捷实践，逻辑是一样的。
大师们已经准备好了标准的建议和方法来告诉你怎么做，只是你觉得你与众不同而已。
组建一个敏捷团队
想要搞敏捷实践，首先得有个敏捷团队，根据个人经验，在最最理想的情况下，一个敏捷团队呢，应该人数在7-13人，都在一起办公，100%为专职人员，但实际上，这些可能都不完全符合，比如我们一个大的产品有30号人，又分属于各个地点，同时还有别的活儿要干等等，无论团队是怎样的，这在根本上不影响我们做敏捷，我们还是尽量朝着敏捷去做。
常规的情况下，敏捷团队有三个大角色，产品经理PO、敏捷教练SM、开发团队DT，那么在DT里面有技术领导者、开发、测试、分析人员，其实在DT里讲究的是通才型专家，但是很不幸，目前很多团队的成员达不到对应的水平，习惯上也沿用了传统项目的人员划分方式。所以我们的组建，仍旧优先使用这种方式去找到对应的I型人才，这边可以顺便讲下I型人才和T型人才【1】。
I型人才：有些人在一个领域非常专业，但是，在这个领域之外，他却很少做出贡献。在敏捷领域，这种人被称为“I型人才”，就像字母“I”一样，这种人有深度，但却缺乏广度。现有的大部分团队，其实仍旧属于这一个范围。这个本身也没有问题，毕竟通而不精和精而不通的人才里，我个人更多的倾向于专业性。
T型人才：在具备一项擅长的专业化技能的同时，还拥有多种技能的工作经验，而不是单一的专业化。由于密切协作和自我组织，敏捷团队成员才能够敏捷开发并迅速完成工作，而这就需要使互相帮助成为常态。敏捷团队成员都要致力于培养这样的特质。
一切开始的计划会
计划会是迭代的开始，正常情况下，我们在计划会上，就确定了这个迭代我们要做什么，然后，我们就可以按部就班地敏捷运作了，这里又出现了一个问题，敏捷是种精神，是种思想，按部就班真的合适么？那不就是一种套路了么，就成为了和传统管理等值的性质了么？答案是合适也不合适，敏捷有的精神不仅仅是那么几个，探索也是精神之一，那么团队是在做什么，是在找到最适合自己团队工作的方法，每一个实践过程的最优解，就比如敏捷四会，是大家总结下来的常规最优解，一个团队应该在每个迭代里去做这些事情。话说回来，那么敏捷的计划会上我们要做什么呢，首先，PO要从PB里按价值从高到低进行排序，然后和DT一起进行用户故事沟通，DT进行估点，团队根据速率，从高到低理出80%-90%这次迭代的用户故事，并将这些挪到SB里，随后PO再准备20-30%的非紧急用户故事作为备选故事点，那么这块为什么这么设计呢，首先，每次的估点不一定是完全准确的，其次，DT可能需要有一些其他事需要在这个迭代里完成，所以团队选出80%-90%，而PO选出的20%-30%，也是为了避免大家评估错误或者团队速率提升导致没有用故事可做的情况发生。
那么我们总结下来就是，计划会干这么几件事情，PO排序讲故事->DT估点->PO理出备选，会议结束，看上去很简单，那么实际上的计划会，大家很难开成这样，一般都是PO说这ABCDE五个故事一定要干完的，团队在有限程度内去考虑能不能干完，当然这种考虑仍旧是估点，所以目前的计划会还是着重于故事讨论和估点。
然后讲一下故事认领吧，在很多团队里，把故事认领放在计划会上执行，大家分好说谁做哪个故事，甚至没有认领，直接进行分配，这种方式呢，本身不太推荐，比较违反团队的自组织和主观能动性，还存在一定的上下级关系（无论在什么样的企业里，总归存在若有若无的）来破坏这个结构。我们还是建议把所有的故事扔在SB里，大家做完一件自己主动拿一件。
简单又不失重要的站会
站会，形式非常简单，但是意义非常重大，在站会上，我们通常围绕着一块看板，无论是电子的还是实体的，然后大家就轮流讲昨天干完了什么，今天要干完什么，有什么问题，非常简单的一件事，但是站会很容易开歪了。开歪方式有几种：
1、大家按照固定的顺序讲，其他人在同时可能发呆、玩手机等等。
2、把站会开成了跟领导的工作报告会。
3、在会上讨论描述内容时引出的各种问题。
那么从这里我们要考虑，开站会的意义是什么，为什么要开站会，同样的三个事情，写个日报不香么？我从我个人的理解讲下站会的意义。
1、站会是大家互相一起沟通的渠道，敏捷讲究的是团队式成长，而不是个人式成长，团队的进度需要大家在站会上进行共享，遇到问题也可以一起进行解决。加强团队之间的互动。
2、站会其实着重体现了公开和勇气吧，有个成语叫做难以启齿，站会因为向善原则，所以不存在说让大家出丑的意思，就是为了让大家主动地说出自己的工作内容，也是养成自我成长的习惯。
那么说到底，站会具体怎么开才能达到站会应有的效果，并且产生上面的问题，这里有几种维度和对应的方法，我简单罗列按人和按故事，需要注意的是，这是在出现问题时的解决方案之一，而不是必要内容。
按人：最常见的就是按人的形式，大家一个接一个，这里推荐的是不规则CUE法，拿一个网球、毛绒玩具或者沙袋皆可，SM从任意一个人开始来，前者讲完后随机扔给下一个人，不允许扔给讲过的人，不允许扔给相邻的人，扔错了或者接不住的人参与惩罚措施，比如做5个深蹲，唱2句歌词等等，这种简单避免了大家不专注听讲发呆的，再多了就违背向善原则了。我们在看这个玩法的时候，会觉得挺幼稚的，但是在我个人实验的事实效果上，惊人的好，我总结下来这叫做人性，首先站会怎么开都是开，开的开心点大家也开心，其次，丢沙包丢手绢这种游戏，非常能激起大家的童心，小时候也是这么玩的，哪怕自己在刚开始会觉得幼稚，团队扔起来之后，因为从众原则等原理，很快就会陷进去。
按故事：这种其实比较少见，主要体现在，首先一个故事是结对开发，而且一个人同时有多个故事，那么逐故事讲可能会更加有脉络，但是这样相对其实违反了一个人同时只干一件事的原则，而且相对开会会略显乏味。暂时其实没有想到特别好的解决方法，如果一个团队因为各种各样的原因必须按故事来讲，那只能从其他方面想办法调动积极性。
讲到这里，还有会涉及到看板上故事和任务的移动，这里也分为两种，一种叫做会前移动，一种叫做会中移动，不推荐会后移动。那么这两种有什么区别呢？
会前移动：大家在站会前完成自己负责的故事和任务务移动，站会上统一讲，单人负责看板，这种更加适合人比较多的团队，因为多人调整会比较麻烦，耗费大量的时间，缺点是直观性不强，感受冲击度不够。
会中移动：大家在站会中轮到自己讲的时候，挪动自己的故事和任务，这种适合12人以内的团队，直观性强。
无论是哪种移动方式，一旦确定了，大家需要遵守，不然整体站会的节奏会比较混乱，同样可以有对应的趣味性措施来保证卡片的完整性，比如没有及时的估点，没有指派给自己，没有移动等等。
站会就先写到这里了。
似乎可有可无的验收会
验收会，被称作似乎可有可无，为什么呢，这个可有可无是形式上的，而不是逻辑上的。我们知道，敏捷要求的是每天其实都有一个产出，然后每个迭代都能交付出可执行的交付物，那么怎么认定是可执行的，需要验收，讲到验收，那么肯定会有对应的动作，最标准的呢，叫做验收会，验收会怎么开呢，首先当然是环境的准备，所有已实现的故事对应的代码，需要被整合到一个可运行的环境，而不是说PO验这个功能登这个负责的童鞋的电脑，验那个登那个的，同时呢，DT应该确保，这个环境能完美的运行，说白了，这个验收，就正式决定了是否达到了下发发版的条件。
环境准备完了，那么就要恭请PO来验收了，这个会，可能是PO最有地位的一个会议，因为在计划会上，可能被DT怼做不了那么多，在迭代中被拒绝新增用户故事等等，但是在这里，PO可以横一点，就可以搁那一坐，然后指点江山，用户故事的承诺人一个个献上自己的成品进行演示，PO就喝着茶，说着这个准了，那个不行。是不是很有画面感和生动性。
还存在一种不开验收会的方式，那种呢，叫做实时确认，也就是当一用户故事发布在稳定的测试环境上后，可以叫做准生产或者UAT环境等等，邀请PO直接过来看是不是符合预期，满足验收条件，这种呢，少了一个仪式感，但是加强了实时性，所有的内容不必等到接近SPRINT尾声的时候来做，更高提升了互动。
充满惊喜的回顾会
回顾会，就像一个项目结束一样，正常是值得庆祝的一件事，所以整体的走向应该是欢快的，哪怕迭代失败了，我们也不应该过于悲伤。
在我个人理解里，回顾会应该是对DT最最轻松的一个事情，同时，也是需要SM最最上心的一件事情，回顾会开的好不好，完全决定了下个迭代里DT的精神状态。回顾会是Scrum团队检视和调整工作实践的机会[2]，那回顾会的目标是什么呢，是帮助团队总结这个迭代，并且在下个迭代做的更好。
仍旧是先讲下回顾会需要做的几个事情，1、回顾这个迭代的整体进程，2、找到这个迭代里做的好的需要保持的，3、找到下个迭代里可以做的更好的。4、提升认同感。是不是非常简单，归根到底是这四件事，但是，还是那句话，知道要做这四件事情，但是怎么做好这四件事情？不同阶段的团队应该怎么做好这四件事情？
其实一个团队，从初建到成熟，需要至少5个迭代的时间，而成熟到卓越，则可遇而不可求，那么每个迭代的开法都会有所不同，为什么叫充满惊喜，因为最开始完全不一样啊，DT根本不知道你SM想玩什么套路。
我们按照成熟度10%-30%-50%-70%-90%比例来说吧。
10%的时候，SM的关注点应该在于破冰，所做的活动应该围绕于怎么建立起大家的关系，怎么认识别人，这个时候需要一些互动性、团队性非常高的游戏，去建立一个团队凝聚力。
30%的时候，可能人与人之间有一定的认识，但是不全面，SM需要做的是促进人与人之间的沟通，并且建立起单个人在团队中的位置。
50%的时候，这个时候大家已经有一定的配合，也会存在一定的冲突，或者不一定叫冲突，比如大家对于事物的理解、处理方式不同引起的分歧，这个时候SM需要在平时去观察发现，在回顾会上试着解决这样的问题。
70%的时候，应该在回顾会上引导大家寻找一个真正凝聚的方向，团队模式，成为一个目标一致、有团队节奏的团队。
90%的时候，那已经达到卓越的门槛，在这种情况下，SM只需要做好大方向的把控，细节团队自己会调整的。
然后讲讲比较常规的回顾会方式方法吧。
首先带上一些道具，比如笑脸、平脸、哭脸，让大家先反馈下这个迭代的内心看法，是开心还是一般还是不开心，根据整体反馈临场可以调整一下后续节奏，然后通过SM在整个迭代内的对人的观察和对进度、内容等数据的总结，把整个迭代的心路历程追溯一下，让大家整体进行回忆，期间的问题、冲突、里程碑都可以一一道来。
开完这个场，无论这个迭代是成功或者失败的，我们都需要通过一定的方式方法去引向一个正向的气氛，那么常规手段，就是做个游戏或者活动，那种成本不高，控制在20分钟时间范围内的，游戏可以有很多，这边仍旧说个最通用的，比如感谢环节、迭代之星、成长之星的活动，简单地说就是每个人说出这个迭代里最想感谢/共享最大/成长最多的人，以及为什么选择的原因（通过一件记忆最深刻的事），然后对票选结果进行累计，可以按迭代奖励，也可以按累计奖励，这个活动第一个方面是建立个人成就体系，尤其是被感谢，我认为这个是最必不可少的，曾经有人在事后这么对我说过：“我真的没有想到我做的这件事情你能记在心里，而且对你有所帮助，很感谢你能看到我的付出并予以认可。”第二个方面是形成团队工作文化，逐渐从原先传统项目中单兵作战互不干涉演进为团队合作，哪怕不是结对开发，至少人与人之间形成了交流。
完成气氛的调度后，我们就需要开始总结迭代了，也就是做哪些值得保留，哪些需要在下个迭代里做的更好的，这个时候就是暴露问题的时候，很多时候，大家把回顾会最终开成了指责会，都在追究这个迭代出现的问题是谁的责任，这样本质上很没有意义，因为那是过去的时间，基于过去，发展未来才是敏捷所要做的。我们只需要在回顾会上正视出现的问题、分歧、争议，从而考虑怎么去改进，而不是去做零和来判断是非。这里需要SM有一些沟通技巧，比如我们在讨论这次出现了某个影响比较大的BUG，我们只需要说，在这个迭代里，某个同学搞出了一个很厉害的BUG，差点把自己玩脱了，我们看看以后怎么可以去避免这种问题的发生？显而易见，大家都知道是谁搞的，但是用某个同学，就降低了个人针对性。而用很厉害的BUG把自己玩脱了，说明了问题的严重性，但又没有去说造成了多大的负面影响。大家听完这句话，通常就那么会心一笑去关注怎么避免，而当事人也觉得是在就事论事而不是就事论人。
那么大家经过一系列的讨论之后，我建议采用团队公约的形式去决定未来怎么做。对应的具体方式是，由每个团队成员写出该保持的和下个迭代需要做的更好的，然后大家对所有选出的进行投票，每人选择3条，最终TOP3纳入团队公约，下次回顾会照旧，同时引入退出公约机制，大家每次还可以择1条认为不合理/不可行的，超过60%的人投票则移出公约。这么做的道理首先是，SM或者PO或者领导觉得对的事情，第一他不一定是对的，第二这不是大家自己想出来的没有认同感，第三这是上级要求的自带抗拒心理，就算当场接受了，下个迭代也不会自发好好实行，不信的可以试哦。而通过票选，很明显的，首先这是大家自己提的，其次这是大家自己选的，自己打自己脸还是很没意思的。从这里也可以看到自组织的能量。至于为什么是TOP3，不是TOP4,TOP5呢，第一，基本上TOP3可以保证过半数，第二，一次立太多的规矩没意义，变动太大，而且没有可持续性，一般有个10条公约也就差不多了，10条公约历经4-5个迭代，基本团队也开始步入稳定期，后续可以再投入别的娱乐方式。
尾声
敏捷有很多可以展开的，比如敏捷的来源，在科技和社会的发展，敏捷是必然会产生的。比如当领导们和存在时代差距的人认为敏捷是炒作出来概念的时候，如何通过日常瀑布工作模式的演进，最终变成了敏捷。又比如敏捷和科技、社会的发展是相辅相成的，在科技领域架构的演进、框架的演进、基础设施的演进，到社会发展上企业的演进、价值观的演进、人类的演进，处处都能看到敏捷的思想。又比如如何做好一位敏捷教练，会开四会就是好的敏捷教练了么，如何践行“中正开合”的敏捷教练要求等等限于篇幅就不一一展开了。
希望大家能在实践敏捷之道时，可以时刻站在更高的维度去看待问题，引导和帮助整个团队变得更好。
引用
[1]《Agile Practice Guide》
[2]《Scrum官方指南2020中文版》