首页>敏捷可以使人进步，真正的敏捷实践一定是共赢的。企业可以通过敏捷实践来提升业务应变能力和组织协作效率，团队能提升交付能力，而个人能获得更好的锻炼和成长机会。19年下半年开始，DP哥和某团队一起进行了敏捷实践，伴随着“见招拆招”的解决问题，小伙伴们也在共同成长，本文回顾了半年多来的敏捷实践经历，供大家参考，内容也经过了当事人许可和脱敏。
-
我们要建立透明，并且创立一个技术负责人与业务领导之间公开透明沟通的机会。 -
团队敏捷实践中，透明是核心。 -
做不到专注，自然也实现不了符合Scrum要求的迭代。 -
我们所有的进步，都是在Timebox里面主动有计划争取来的。 -
敏捷实践就像看病一样，是着急不得的，我们要先解决生死存亡的问题。
先说下背景。
某团队为了一个新业务，为了尽快验证业务和提高效率，抽调产品、研发、测试，组建Scrum团队，开始进行实践。
产品经理就是PO，技术团队有一个直接技术负责人，领导着技术梯队，有两名资深技术，主要承担设计工作，有一定职级，但不是领导。再下面就是程序员梯队，有骨干，有新人，也有兼职SM。数名测试人员也并入该团队。
设定了两周的节奏，第一是因为Scrum默认的迭代是两周，第二是公司的发布窗口为两周一次。
第一天把拆分好的需求给大家认领，经过一周研发，第二周提测，最后两天上线。
经过2-3个月的运转，实际上取得了很大的成绩，基本磨合完毕，也有了Scrum的过程，梳理了和其他团队的边界，因为他们是基于平台的新业务，和平台的核心模块必然有需要磨合的交集。他们还定义了还不错的看板，也有了关键过程的DOD，展现出了让其他团队的交付速度，从上级和外部的观感上，其实还不错，但这个节奏很有问题，团队内部也存在一些危机。
需求交付经常延期、导致脱离计划，业务领导会认为研发不靠谱，而研发团队加班严重，士气低落、人员动荡、出现了对敏捷的质疑，PO夹在中间，一方面看到团队很辛苦，不情愿给予过多压力，一方面不得不去向领导解释。而技术负责人面临着领导的压力，看到团队很辛苦，却又不知道该怎样改善。
继续访谈下去，就得到了以下内容。
这些问题里面，哪些问题是最要命的？
我认为，PO的质疑，老板的不信任，技术负责人与业务领导之间缺乏沟通是最大的问题，毕竟有级别和部门的区别，大家又都很忙，对于敏捷团队来说，这是生死存亡的问题。学PMP的同学知道有个干系人矩阵，业务领导是最重要的干系人。从敏捷三大支柱的角度来看，这是在重要干系人方面缺乏透明。
各种敏捷方法都有一个共同的基石，那就是经验性控制方法，或者叫经验主义，它的三大支柱是透明、检视、调整（或适应）。三大支柱里面，什么是核心，有人说调整或适应是核心，我认为透明是核心。有了透明，问题就容易暴露和解决。检视和调整都是在透明中实现的。
我们要建立透明，并且创立一个技术负责人与业务领导之间公开透明沟通的机会。
破局方法，建立一个业务看板。设立一个每周一次的业务站会。
这个看板由三个独立看板组成，业务其实不关心拆分，关心的是独立的功能，就是特性Feature，Feature可以拆分成若干的故事。因此这个看板的颗粒度是Feature,左边是业务feature落地状态的看板，分为idea、还在构思、待拆故事、设计研发、上线。每个都进行了基本定义。
业务方到底有什么想法，细化到什么程度，这些都要透明出来。
第二个子看板是是业务方对于Feature的上线期望，未来的1-2个月想实现哪些功能。
第三部分是需求明确和拆分情况看板。不是说需求太粗糙吗，到底是PO的问题还是研发的问题呢。让他们自己透明出来，我们给需求进行了三种定义（思路来源于“ACT敏捷教练工具箱”），
只有需求达到板砖级别才能进入研发设计流程。有争议就在这块板上讨论，PO把需求贴在板砖列，研发如果不同意，就移回沙子列，经过几回板砖攻防，就像右边的图，双方就会达成一致，需求也得到了澄清
这三个子看板其实互相独立，但有互相印证，很容易看到矛盾和问题。每周更新一次，就放在过道旁边，所有人的必经之路，业务领导、PO喝水上厕所都会看到，不由自主就会看几眼，如果有问题实时就能沟通讨论，PO来更新，每周四13:40-14:00开站会。们午休到13:30，下午开会一般14点开始。这个时候大家都有空。
业务领导，运营、PO、技术负责人，架构师，骨干，都要来出席这个站会。PO说说业务和需求情况，运营和业务领导进行补充和提出要求。技术负责人说说研发情况，并不聊太多细节。20分钟可以沟通很多情况。
这三个看板把1-2个月规划、目前需求所处的状态、需求的颗粒度就透明出来了。
这个看板和周站会受到了所有人的好评。仅仅开了两周之后，技术负责人就告诉我，他感觉好多了。给技术负责人和业务领导创造了直接沟通和澄清的机会，不用再找由头去尬聊了。PO也不用受夹板气了，有问题技术负责人直接澄清，尽快这个看板极大的直接将PO的工作成果透明在所有人包括领导面前，给了他很多压力，也是动力。
Idea和构思还是很多的，这都是还没考虑好的需求，下面这个也是需求期望计划的看板，未来的介个迭代堆满了想实现的需求。结果呢，经过几个月，我们发现完全没实现的需求和研发落地的需求基本上一样多。有一半的需求都被PK掉了啊。这个结果是让所有人吃惊的。
团队敏捷实践中，透明是核心，找到最核心的问题并透明出来，就促进了互信和理解一致。
但是加班和技术方案变更、压缩测试时间问题还没解决。
问题出在哪儿？Scrum要求迭代交付，设计、开发、测试都在Sprint期间完成，团队要专注于这个迭代。对于技术人员来说，如果不能专注，而是并行很多工作，工作效率和产能会衰减的很厉害。
第一天的TASK认领，TASK是架构师拆解的，而研发同学也需要消化，如果没有提前了解清楚，必然会有不同看法。讨论一天，再进行一些设计，可能第三天才能开始编码，第二周第一天就要提测，这个时候架构师又必须抽身去接触新需求，但是实际情况中他根本抽不开身的。研发在测试阶段要改问题，负荷很重，第2周第3天还要去参加架构评审，根本没有心思没有精力去听，往往是在上线以后才能腾出时间去了解需求，这样就没办法尽早对技术方案提意见，又没有了调整时间，只能往后压缩研发测试时间，又是恶性循环。影响到质量是必然的。
我们可以看到，根因是并行的东西太多，在制品（WIP）太多。2周的迭代，没办法专注。Scrum的价值观是什么？勇气、专注、承诺、尊重、开放。做不到专注，自然也实现不了符合Scrum要求的迭代。
我们的结论是，2周的迭代不适合当前的团队状况。要改成3周。那是不是延缓了交付速度啊？
业务方要的只是速度吗？他们期望的是稳定的节奏和预期，要的是质量，而不是一味求快。
我们要专注于一个迭代，而不是并行很多TASK，不要很多在制品。因此我们重新设计迭代节奏。
第一周先是评审，做设计和任务拆分，然后研发，测试。上线，最后一天再进行提前需求沟通，Refinement。安排的工作量略多余之前2周的量。一下子干掉了所有的跨迭代并行工作。做到了专注的迭代交付，形成了真正意义上的Timebox。
还有一个问题，公司的正常发布周期为两周，三周的迭代明显会发生冲突。敏捷实践是侵略式的变革，当需要别人改进的时候，就需要去“进攻”别人。我们去找运维沟通，说服他们配合，利用公司的紧急发布流程，制定了一个固定周期的发布计划，并承诺会严守这个周期，最终得到了他们的同意。
试运行了1-2个迭代后，大家的效率提高了，抱怨少了。不是单纯拉长了时间，而是实现了能够专注的Timebox。
敏捷原则第8条说的就是保持节奏。我一再强调节奏和Timebox，这是非常重要的一点。Timebox是敏捷团队能够实现改进和提高的重要基础。我们所有的进步，都是在Timebox里面主动有计划争取来的。
有了时间盒，我们就可以解决内部问题了。大家可以猜接下来会是什么问题。经验型控制法三大支柱：透明，检视和调整。怎么检视呢？最重要的手段，回顾会。回顾会有很多开法，一个大致的讨论就是“营造氛围、汇总信息、洞察问题、确定改进措施和责任人、结束回顾”。
我们组织了几次关键的回顾会，并在回顾会上给大家巧妙给大家挖坑，让大家自己往里跳。
首先让大家自由分组，每个人限时静默书写团队存在的5个问题，小组限时讨论出最严重的5个问题。总共10个问题，然后集体投票优先要解决的。因为研发占大多数，大家都认为需求问题的优先级别最高。提出了四个期望改善的问题，改善需求质量，改善需求沟通，改善需求评审结果反馈，及时明确需求范围。
找到问题了，怎么办呢，你们自己讨论，我不参与，我甚至主动离场。每隔10分钟去问下，问下讨论好策略了吗？如果没有，继续讨论，我继续离场。结果他们讨论了2个小时，最终拿出了他们自己的整改方案。建立准入准出标准，建立沟通机制，固定时间反馈评审结果，固定时间明确需求范围。
那么我继续挖坑，求大家明确行动项是什么、谁牵头去制定方案、谁去执行、谁来监督、什么时间完成、实现不了怎么惩罚。可以是俯卧撑100个，平板支撑，青蛙跳等等。
我做了个大大的看板，高1.2米，长3米。贴在过道的墙上，醒目极了。打印出很大的字，把改进目标、行动项、责任人、结果进展情况公示出来。每周都会过问情况，更新进展。这个时间大概是9月份。
过了一个月，这几个问题得到了明显改善：建立了需求准入标准，建立了需求确认的规则和时间点。效果还是很明显的，都是他们自己搞定的。
我们看第2幅图，这个大概是19年11月份，需求问题已经基本解决，这时候的问题是要严格执行需求准入标准和提高自测质量。我们可以看到，到这个时间阶段，一开始的士气低落、需求粗糙、并行task太多的问题已经基本解决，优先级别较高的问题已经是提高自测质量。
大家一定要记住，所有的问题都是在时间盒Timebox里面解决的。
当然我还要说明一点，问题有很多，分为组织的问题、团队的问题、个人的问题。组织问题比如说平台环境、关联系统，可能是我们解决不了的。解决不了我们就承认，与这个问题共存，但没必要拿这些问题当挡箭牌，成为不去解决其他问题的理由。我们要更多的去寻找那些我们能解决的。
团队终于进入常态了，但是还有个本质的问题。怎么样更好的激发战斗力。我们就想了个策略，和技术负责人沟通了很久，我们希望加速团队小伙伴的成长。
我们期望能够实现“项目内容交付、个人成长、团队成长”的多赢。
团队中，架构师以设计为主，也要编码；骨干以编码为主，也要承担部分设计。还有一些毕业不久的小朋友，还不能放手独立干活。
这个时候仍然是两名架构师为主来进行设计和工作分配，他们既要对接需求，又要设计技术方案，还要安排协调研发测试任务，更要确保迭代的结果交付，在从需求到研发落地的价值传递过程中，他们承担了关键环节，很辛苦，加班也很多，根本忙不过来。另一方面，这些相对年轻的骨干，毕业也有三五年以上了，架构师的活儿骨干也几乎能干，只不过是经验和火候还没那么好，他们应该更好的成长和积累经验，他们应该得到更好的锻炼。
另一方面，我们看这个表，第一周有明显的信息传递过程，信息每多一层传递，就多一层衰减、研发时间只有四天。其实可以挖一挖潜力，更加提高效率。如果可以减少信息传递，工作更加前置，就能提高效率。
再强调下，我们期望能够实现项目内容交付、个人成长、团队成长的多赢。通过和技术负责人和架构师反复沟通，讲团队动态成长，讲塔克曼理论，讲领导力建设，最终得到他们的支持，就开始了我们的迭代牵头人计划。
这个计划就是在每个迭代，从每个团队选出1名骨干作为这个迭代的Leader，也就是迭代的总负责人，负责任务拆解，需求对接，设计编码、测试协同、上线协同，也就是承担了以往团队Leader加上项目里面项目经理的活。由技术负责人和架构师给予帮助，确保效果，必要时进行兜底。
经过1-2个迭代的摸索，我们形成了新的流程：牵头人先牵头拆分任务，骨干们结对进行设计，大家共同对方案负责，第三天进行快速的计划会。这样，减少了信息传递和衰减，提高了大家的主动性，增加了研发编码时间，客观上提高了质量。这样的话，正常的发布就变成了水到渠成的事情。
大家忽然觉得，自己变得比以前从容了。
我们做过对牵头人的小伙伴做了访谈，作为牵头人，他辛苦不辛苦？很辛苦！爽不爽？很爽！小伙伴感慨非常多“以前老骂领导傻X，原来Leader真的不好当，感觉自己突然提高了一个段位”。
Scrum讲究自组织团队，团队讲究互相信任，互相支持，共同目标、信息共享，自由表达，这些说起来简单，做起来好难啊。作为一个对公司，对领导、对收入，对自己都不满，个性十足的20来岁奔三小伙，你凭什么让他自组织？我们可能给不了你足够高的薪水，但是我们希望给你机会，给你正确的做事方式，给你敏捷的认知，我们可以一起制定目标，给你实现目标的满足感。有一天，这儿满足不了你了，你走了，你也会感谢这个环境、感谢这个团队。
几个迭代过去，几名骨干得到了脱胎换骨的成长，把他们随便撒出去，就是一个不错的团队Leader，从另外一个角度，我们为组织快速培养了人才啊，往大了说，为社会贡献了力量。
半年多的时间过去了，团队确实成长了很多很多。有经验的朋友一定能看出来，这哪是敏捷，这不是小瀑布吗。我们的回答，是的。
这儿我们要明确的打个比方，敏捷实践就像看病一样，是着急不得的，我们要先解决生死存亡的问题。ICU里面不见得能治病，但能够尽一切可能保证先不再继续失血，保证能活下来，然后再看门诊或者进入普通病房，继续对症治疗。
这一页看似简单，但是是非常关键的一步，敏捷就是要激发起来大家的主观能动性，更好的交付，更好的提升团队和自己。现在团队已经激活了，战斗力强的不得了。
通过我们前一段时间的努力，能够建立稳定的专注的TimeBox，就说明能活下来了，有了条件在Timebox里面折腾了。就可以看门诊了，去头痛医头脚痛医脚。有同学问了，那没病之后怎么办，我们可以SPA啊，可以健身啊，可以提高免疫力啊，可以按摩松骨大保健啊。
小瀑布只不过是从ICU到门诊部到大保健过程中，我们早晚要解决的问题，就看是不是到了水到渠成的那一步。我们一再强调节奏和Timebox，Timebox是敏捷团队能够实现改进和提高的重要基础。我们所有的进步，都是在Timebox里面主动有计划争取来的。接下来，我们就要更加关注自身了。开始向小瀑布发起冲击了。
在最当初，是这样一种节奏，产品想着新的，研发做着当前的，测试测着之前提测的。研发工作存在大量的并行，至少要并行三种不同的任务。一边要应付评审，一边要写代码，一边要改测试测出的BUG，他无法专注，工作内容互相交叉影响，其实效率很低。
从价值流的角度，一个批次的需求，从开始设计算起，要经过3个周期，才能上线。
但是仍然是小瀑布。一个批次的需求都研发完了，统一进行提测。但是形成了稳定的Timebox。从价值流的角度，一个批次的需求，从开始设计算起，要经过2个周期，才能上线。
研发和测试是同步的，这意味着什么？一个批次的需求，可以拆分的更新，完成一点就能测试一点，测好就能上线。一个批次的需求，从开始设计算起，在第2个周期，能实现灵活上线。
这需要持续集成方面要取得很大的进步，需要形成可用的自动化测试体系，能够随时进行回归测试；具备自动发布能力，在工程领域DevOps方面要取得实质的效果。首先自动化测试是要提前写测试代码的，自动化配置发布也是脚本和代码，都要持续投入。
到目前为止，我们形成了稳定的时间盒，质量有了大幅提高，团队被激发了，有了更多的主观能动性，现在我们已经不再被动，而是有动力有精力去做点自己喜欢做的事情了。
研发和测试可以腾出部分精力去写自动化测试代码、可以去实践极限编程，因此我们给大家定了个名字，奔三计划。向着图三的方向去努力。
在稳定的时间盒里面，在满足组织要求的交付内容的前提下，我们提升团队的能力，提升自己的能力。这个就是敏捷团队的一个小目标。
在团队级别的敏捷实践中，
1、 我们要先找出生死攸关的问题，确保不再失血，能活下来。然后才能考虑别的。
2、 要推动透明，特别是在核心重要干系人之间，真实情况透明出来，问题可能就解决了。
3、 要形成Timebox,并在Timebox中实现专注，我们所有的进步，都是在Timebox里面主动有计划争取来的。
4、 解决问题要发动大家。大家提问题，大家想对策，大家一起解决。
5、 激发团队，如果你给不了更高工资，就加快他们的进步和成长，而不是压榨或瞎折腾他们。
6、 问题是不断涌现出来的，解决一个，新的问题就会浮现出来，但这就是进步的过程。先活着离开了ICU，再头痛医头脚痛医脚，去各个科室看医生，对症下药。身体没毛病了，可以去健身、按摩、SPA，心急不得，需要时间。
最后，总结几点：
1、 你知道世界上有轮子，面对不知道有轮子存在的人，你怎么样让他相信你？
2、 对方真的不知道有轮子存在吗？真的不知道方块有问题吗？为什么宁愿用方块呢？
3、 你考虑过换轮子的风险吗？有可能你不碰车子还能用，你一碰，车子就彻底不能用了。
换个方法问，你懂了敏捷的方法论，就一定可以成功实践吗？不一定的哦。
你不能站在上帝视角，你要放下一颗帮助别人的心，而是要和团队在一起，成为团队的催化剂。
我们觉得我们自己有两点体会，并时常用来提醒自己。
1、 提醒自己是不是再用方轮子拉车。
2、 不要以为自己懂了圆轮子，就想马上去换掉方轮子，实际世界远比教科书上复杂，要对现状充满尊敬和重视。
优培东方送你一张配置管理计划表：
项目名称： 准备日期：
配置管理方法：
| 构 件 | 确定原则 |
| 受控制的配置文档 | 确定原则 |
| 版本受控制文档 | 确定原则 |
配置管理角色和责任：
| 角 色 | 责 任 |
附上与配置控制过程相关的所有表格。
粤公安备案 44010602008731号