平安集团是国内少有的，具备成体系的敏捷教练队伍的企业，从上到下拥有很好的敏捷土壤。再介绍一下我自己，我有十几年的工作经验，最初几年是做程序员，后来转向了项目管理和技术团队的管理，长期服务于外资银行和金融互联网的企业，我曾经在日本生活过很多年，非常熟悉传统的软件研发流程，也算是比较成功的 it项目管理者。我
可以非常准确的挖掘客户需求，管控项目成本，管理团队，把成果物非常高品质的交付给客户。
但是后来
我发现了一个问题，我不知道我交付的成果物能否为客户带来价值，项目结束结项以后，团队可能就会解散重组，我也没有办法持续地去帮助团队的成长。
针对这两点我曾经非常的苦恼，后来就开始逐步学习敏捷的理论，毫不回头的走向了敏捷实践。
今天我和大家分享两部分内容，第一部分是
在敏捷实践里，个人应该树立怎样的目标。
第二部分我会用我自己的一个比较接地气的案例，来分享
针对团队级别的敏捷实践，我怎样去具体解决一些常见的难点问题。
用这个案例来分享我的思路和认知，希望能给大家带来一些参考。也希望能够帮大家少走一些弯路。
第一部分，我们现在是身处复杂的互联网时代，非常复杂，也被称为乌卡时代，典型的案例小黄车ofo，几年的时间里跌宕起伏，让人叹为观止。
我们眼见他起高楼，眼见他宴宾客，眼见他楼倒了，留下一片片单车坟场。有太多的钱打了水漂，谁应该为浪费负责呢？你能看得懂吗？类似的例子实际上很多，这个时代它有一个什么特点呢？企业的或者是组织的决策者发现做决策越来越困难。
实际上在我们互联网的大背景下，各行各业都面临着行业转型。在当前的生态系统里面，企业几乎是无法规划自己的命运，对于什么是价值、市场机会在哪儿的判断，似乎已经超过了决策者的理解范围。在这个时代，你的企业甚至不知道谁是对手，不知道从哪里冒出了一个对手就不明不白地把你给颠覆了。
这种案例实际上有很多，面对这种瞬息万变的市场，大家越来越拿不出方案来，大家都来问，老板你说怎么办？我们听你的。老板说，我也不知道，要不然你们自己去试一试？领导或者决策者都不约而同的意识到，
面临瞬息万变的市场的时候，自己作出的决策不见得比一线团队更好。反而比较靠谱的方法，是让掌握信息最多，反应最快的一线团队，自己去试一试。
如果这个团队（一线团队）比较强，很有韧性，可能成功的概率会更高一些，实际上这就是
敏捷思维
。所以企业纷纷在进行敏捷转型，建立了敏捷型的环境、文化和氛围，希望能够打造出皮实的、好用的团队，来帮助企业活得更久。在敏捷转型里，企业比以往更加重视个人与团队的成长。作为我们个人和团队，应该抓住这种机会，实现更加快速的自我成长。
再说一下个人，过去有一句话叫做“一招鲜吃遍天”，学习和工作是分开的。比如我们的长辈学会了某项技能：打铁，可以始终停留在自己的舒适区，20年30年一直干，但这个年代早就不成立了。现在的知识更新程度可能3年5年就是一个批次。我们从毕业到退休，职业生涯也有三十几年，一不留神我们的知识技能就落后了，不学习新的技能，则可能会被淘汰。因此学习和工作再也无法分开，这不是在贩卖焦虑，这也是实际情况，大家也应该有感知。
我们想学习的时候，面对着这些海量的信息，学习感觉非常简单，你只要通过搜索引擎就能找到你所期望的内容，但是我们的精力是有限的，去评估学什么是靠谱的，应该去学什么，这件事情反而很难。先抛个问题，到底是知易行难，还是行易知难，大家可以自己思考一下，我个人目前是没有找到答案。那么我们怎么办呢？怎么去成长进步？以什么思路去应对呢？这就需要我们用敏捷的思路来作为我们个人成长的指导方针。
我相信我们每一个人心中都有一个理想的目标，我们想成为一个怎样的人？我们每个人也都有上进心，也具备这种自我进步的能力。那要如何去驱使自我呢？还需要一个清晰的思考系统去帮助大家，去帮助自己实现进步。
这幅图片大家都很熟悉，会联想到背景音乐五环之歌，大家都听过。
岳云鹏大家都认识，他的成长是一个非常完美的励志故事，我们用Scrum的观点去分析它，
Scrum理论是基于经验的过程控制理论。
这个理论的
三大支柱
是什么呢？
透明、检视和适应
，大家可以去看一下Scrum指南，在适应的时候也会发生调整。岳云鹏多年以来我们清晰而透明的看到他的成长，在全国钢丝的检视之下，他持续的进行调整和适应，最终走向了成功。
但是有谁知道这背后他经过了多少轮艰苦的sprint冲刺，他实现了多少的迭代和增量，他又有多少的快速反馈和持续改进？我觉得岳云鹏是一位让人肃然起敬的敏捷实践者。从这个角度来说，敏捷思想根本不是什么新东西，它是符合人的自然认知的。你可以没听说过这个词，但是你在追求进步的时候，你会不由自主的这么做。
大家是否了解过
Why-How-What的黄金圈法则。
这是 西蒙.斯涅克 提出的，有兴趣的同学可以自己去了解一下。根据黄金圈法则和岳云鹏的五环之歌，我创造了一个
敏捷实践的五环
，作为个人及技术团队进行敏捷实践的基本原则，它也是一个能够帮助我们实现自我进步的思考系统。
这里写明了目标，这个目标是什么呢？这个目标在第4环，更有价值的交付，要带领团队成长，要提升自身能力，这个目标只是第4环，和五环之歌一样，它向外还有一个比4环多一环的5环，这五环从内到外，是一个要想实现…必须…的关系。从外到内，是你只有…才能够…的一个关系。先看最核心的第五环，实际上也是马斯洛需求理论中高层次的一个需求，它是一种内在的激励力量，你想在这个时代享受到努力带来的收益，获得职场的进阶，达到自我实现，从而能获得这种自我实现的幸福感。
你必须成长为剑锋所指所向披靡的人，个人的能力实际是很小的，你需要带领你的团队，你的团队也必须是敢打敢拼、充满韧性，做什么都会很努力的团队。但是你要想成为这样的人，成为这种剑锋所指所向披靡的人，那么你必须带领团队去进步，去持续提升，去持续改进，你必须不能放过任何一个改进的机会。
这个过程你不但要思路清晰、灵活，处理各种问题，还需要驽马十驾长期的坚持和积累。如果你不想放过任何的改进机会，你想实现这种功在不舍。你只有把精益思想以及敏捷的价值观，和之前提到的三个支柱，把它深入骨髓，你不仅要深入骨髓，你还要拥有一个运用之妙存乎一心的这种高超的技巧，你需要用这些技巧来指导你的日常工作，并把这种思路和技巧传递给你的团队，变成团队的统一认知，而你一定要掌握这种技巧，能够达到运用之妙存乎一心，你必须不断的去学习和实践，不断的去和阻力做斗争，灵活的选择适合自己，适合团队的方法和套路。
我们要择其善者而从之，但是哪个是善的哪个是好的呢？你只有
不断的去学习，去思考、去积累，去实践。
当不断的思考积累和实践的时候，你会领悟到很多道理，它是一通百通的。这就是我理解的敏捷实践。
我们再说 Scrum，Scrum的创始人Ken Schwaber曾经说过， Scrum就像你的丈母娘，他会指出你所有的缺点，Scrum会暴露你之前隐藏的很多问题，这也是正常的现象，绝对不是因为实施了Scrum才产生的这些问题。当你把团队的问题都暴露出来，但是你没有办法去改正的时候，你觉得你会得到你丈母娘的认可吗？肯定是不会的。
在现实的敏捷实践中，我们有很多的伙伴，毕业不久就非常积极的学习和实践敏捷，这个非常好。但是当他碰到问题的时候，却不能非常好的去解决。碰了几次壁以后，他就会产生非常强烈的挫折感，这个时候就产生了敏捷不适合我们的想法，他对敏捷产生了质疑，但是这个是敏捷的问题吗？是Scrum的问题吗？不是的。是什么？是你发现问题，分析问题，解决问题的能力和分寸感还有待提高。这些经验、能力和分寸感，是在不断的积累，不断的碰壁，不断的痛苦的过程当中积累起来的。
所以说不要去也没有必要去质疑敏捷，去质疑Scrum。Scrum指南也告诉我们，它是轻量的，易于理解，但是难于精通的，难实际上也难在这。你需要选择适合的问题，有些问题是解决不了的，选择适合的问题去有套路、有技巧的解决，而不是毫无章法的去硬碰硬。
前两天Bob老师也发表了一篇文章，就是
重温 Scrum 的精髓
，核心第一点就是要解决问题，大家也可以好好的去学习一下，
敏捷实践的场景是千差万别的，脱离了场景的实践都是空谈，是毫无意义的，那是纸上谈兵。现实当中我一直也认为不存在什么最佳实践，因为没有完全一样的场景，也没有完全一样的实践，那么我们也不能光说不练。
接下来就是我们的第二部分，分享一下我在推行敏捷实践当中出现的一些问题，
这些问题包含了沟通、节奏、回顾、成长，
都是从2009年下半年开始，我和团队一起进行的一些实践。随着时间的深入，团队当然会有进步，但进步是伴随着解决问题的，你不能解决问题就不会有进步。这个问题可能会触及组织的流程制度，由于你和团队的进步，可能会对其他团队的配合上提出更高的要求。这些往往会被别人视为侵略的行为。而
敏捷实践往往是带有一种侵略性质的变革。
我们先说一下背景。某一个团队，为了一个新业务，为了尽快的验证业务和提高效率，就抽调了一些产品研发测试，组建了Scrum团队，开始进行实践。这个业务背景就不多说了。产品经理就是po，技术团队有一个leader，它是直接的技术负责人，他领导着一个技术梯队。
我们看到技术负责人下面有两个架构师，这个架构师是什么？就是资深的技术人员，他主要承担了系统的设计工作，有一定的职级，但是他不是领导，再往下就是成员的梯队，有骨干，有新人，也有兼职的 Scrum master，后来有几名测试人员也并入了这个团队。开始的时候根据Scrum的惯例，设定了两周的节奏：第一是因为Scrum默认是两周，第二是我们公司的发布窗口也是两周一次。
大家看一下这个节奏，第一天把这个任务拆分好，需求给大家认领。经过一周研发，第二周提测，然后最后两天上线。这个需求是谁拆分的呢？是架构师拆分的，在上一轮大家可以看到这个图里面蓝色的部分，在上一轮提测以后，架构师会先出来，和 po一起梳理需求，设计架构方案，然后全员评审，然后由架构师进行拆分，为下一个迭代第一天的计划会做准备。
这个节奏后期出现了很多问题，我们后面会提到。经过两三个月的运转，实际上还是取得了一些成绩的，基本磨合完毕，有了Scrum的过程，也梳理了和其他团队的一个边界。因为他们是基于平台的新业务，和平台的核心模块必然有需要磨合的交集，他们也定义了不错的看法，也有了一些关键过程的利用率，也展现出了让其他团队望尘莫及的交付速度。从上级和外部的观感上，其实还不错。
现在我们看一下
这个节奏它是有问题的，这种问题会导致团队内部实际上存在一些危机，
这个和外部的观感是不一样的。通过一些了解，我们发现一些现象，需求交付经常延期，业务领导认为研发团队不靠谱，研发团队的加班很严重，士气比较低落，人员也有一些动荡，出现了对敏捷的质疑，测试也走了一波， po夹在中间，一方面看到团队很辛苦，也不愿意给团队很多的压力，另一方面也不得不去找领导解释，技术负责人也面临着领导的压力，看到团队很辛苦，但是也不知道怎么改善，继续去访谈，得到了以下内容，比如说：
-
研发总是无法按承诺解决问题，每次都要我去向领导解释，我夹在中间很难受，这帮人到底行不行？
-
架构师说：需求这么粗糙，每次都逼着我们上，我又开发又设计我好累。
-
有一些骨干的研发会质疑架构师，架构师的方案总是有问题，但讨论调整就需要一两天，开发时间根本不够，我们只能是加班，因为你方案有变化，
-
测试反馈说：方案总是变，每次都压缩我们测试的时间，还要求质量，最后我们这边已经走了好几个人了。
-
技术团队负责人，他的吐槽最多，这一块他本来想交给这两名架构师的，但他们太忙，手头事情太多，根本就hold不住。测试新人太多，因为老人走了之后（被压迫走了）新人经验不足，完全依赖手工。随着我们系统的建设，系统测试和系统回归测试的工作量越来越大，根本就顶不住。还有一点是业务领导已经向大领导吐槽我们了，我又没有机会去解释，压力好大。如果延期我们就要向运维申请紧急发布，运维很有意见，感觉是四处冒火。
-
兼职的 Scrum：回顾会根本开不起来，大家都在吐槽需求有问题，但是产品又不认，现在交付确实是比以前快了，但是加班这么忙，感觉很难持续下去。这和敏捷的初衷不一致，这是敏捷吗？
这些问题大家是不是有些似曾相识？大家是不是好挣扎？
如果一直这样，Scrum还能持续多久？怎么办？我们必然要解决问题，如果不能逢山开路，遇水搭桥，这还是敏捷吗？这些问题里边大家可以想一想哪些问题是最要命的，大家简单的想一下。
现在我说我的看法，我认为po的质疑，大老板的不信任，技术负责人和业务领导之间缺乏沟通，是最大的问题。如果这个团队被业务方或者是领导定性为失败，定性为这个团队有问题，这个团队就死掉了，敏捷实践也结束了，就再也找不回来了。而且研发、产品和业务毕竟属于不同的部门。大家都很忙，怎么样能够建立起这种互信，因为互信对于敏捷团队来讲是生死存亡的问题。
学过PMP的同学应该知道有一个
干系人矩阵
，业务领导就是这里面最重要的干系人，从敏捷三大支柱的角度来看，这也是在重要干系人方面严重缺乏透明，在重要核心干系人之间的不透明，它的影响绝对是致命的。那么我们就
要建立起一个技术负责人与业务领导之间公开透明沟通的机会。
破局方法是什么呢？
破局方法就是建立了一个业务看板，我们也设立了每周一次的业务站会。
业务看板实际上是由三个独立看板组成，但业务实际上并不关心需求的拆分，他关心的是
独立的功能
，也就是
特性Feature。Feature也可以分拆成一些故事。
研发同学拿到这些故事后再去做研发，因此这个看板的颗粒度是什么？是Feature。左上角的图，左边是业务Feature落地状态的一个看板，Feature可以分为idea、还在构思的、等待分拆成故事、分拆好在做设计研发和上线。业务Feature，它有这些落地的状态，业务方到底是有什么想法？这个想法细化到什么程度，在系统建设上到了什么级别，这些都可以在看板上透明出来，当然我们做了一些基本定义。
第二个看板是左边左上那幅图，有一个红线的右边的一部分，是业务方未来1~2个月想实现哪些功能，想把哪些功能放在接下来的迭代里去实现，是业务方对于Feature的期望，看到期望我们就知道未来大概要上什么功能。
第三部分是需求明确和拆分情况的一个看板，
之前说需求太粗糙，它到底是po的问题，还是研发的问题，我们就要把它透明出来，让他们自己透明出来，
我们就给需求进行了三种定义，就是对于Feature级别的需求进行了三种定义
，这个思路来源于ACT敏捷教练的工具箱。
-
首先需求第一个是沙子，是只有想法，没有经过沟通，也没有办法进行落地。
-
第二个是板砖，板砖是经过了沟通，颗粒度比较相似，研发认为是可以接下来去研发。
-
第三个是钻石，是经过了设计和估算，边缘清晰，随时可以开始。
只有需求达到了板砖级别，那才能够进入研发设计的流程。有争议的话，就在看板上讨论。Po把需求把Feature贴在板砖这一列上，研发如果不同意就把它移回到沙子这一列。经过几次这种攻防，我们把它称为板砖攻防。下面的这幅图，双方就会达成一致，需求也会得到澄清。
这三个子看板其实是相互独立的，但是又相互印证的，很容易看到矛盾和问题。我们每周更新一次，就放在过道旁边，所有人都会从哪里经过，业务领导包括po包括研发团队，喝水、上厕所都会看到，大家不由自主就会看上几眼，如果有问题的话随时沟通。看板是po负责更新，我们约定是每周四的下午1:40~2:00开一个站会，我们平安是午休到1:30，下午开会的话一般是2点开始，这个时候大家都有空，1:40~2:00，就是业务领导、运营、po、技术负责人、架构师以及一些骨干都会来出席站会。
Po会说一说业务和需求的情况，运营和业务领导进行一些补充或者提出要求。技术负责人说一说研发的情况，不会聊太多细节，20分钟就可以沟通很多情况。这三个子看板结合在一个大的移动白板上就是1~2个月的规划，目前需求所处的状态和需求的颗粒度就透明出来了。
看板和周站会就得到了所有人的好评。仅仅开了三次以后，技术负责人就告诉我，他的感觉好多了。因为看板给技术负责人和业务领导创造了一个直接沟通和澄清的机会，他就再也不用去尬聊了。po也就不用再受夹板气了，如果有问题，技术负责人会直接澄清，尽管看板在某种程度上将po的工作成果透明在所有人包括他的领导面前，给了他很多压力，但是po自己也说也给了他很多动力。
我们看这个结果，上面的中间这幅图，你看 idea和构思还是很多的，这都是没有考虑好的需求。下面的也是需求期望计划的一个看板，未来堆满了想实现的需求太多了，结果经过了几个月，我们发现一个非常让人吃惊的现实，
我们发现完全没实现的需求，和我们经过了研发落地的需求基本上一样多，有一半的需求都被PK掉了，这个结果蛮令人吃惊的。
右上角这幅图一半一半，这个结果让我们所有人都感到吃惊。在团队实践中，我们认为透明是核心，找到最核心的问题，把他透明出来。我们促进了这种互信和理解一致，看板受到了所有人的好评。
但是解决了互信和重要干系人之间沟通的问题，加班和技术方案变更、你压缩测试时间的问题还没有解决，那问题出在哪呢？
Scrum要求迭代交付，设计、开发、测试都是在一个sprint之间去完成的。团队叫专注于迭代。对于技术人员来讲，如果不能做到专注，而是并行很多工作，工作效率和产能会衰减的很厉害。
大家看这个图里面谁最不专注？
很明显。架构师最不专注，第一天task认领，这task是架构师拆解的，而研发同学需要消化，如果没有提前把需求了解清楚，必然会有一些不同的看法。讨论一天，在进行一些设计和一些变化，可能第三天才开始编码，第二周的第一天就要提测，这个时候架构师实际上他要去抽身去接触新的需求，但是实际情况当中他根本抽不开身，研发在测试阶段要改问题，负荷很重。第二周对于研发来说，第二周的第三天，他还要去参加架构评审，下一个迭代的架构评审，根本就没有心思没有精力去听，往往是到了上线以后，到了第二周的最后一天以后，他才能腾出时间来去了解需求，这样的话就无法尽早的对技术方案提出意见，po就没有调整的时间，只能往后压缩测试的时间，这是一种恶性循环，影响到质量是必然的。
我们可以看到这个
根因是
什么呢？
并存的东西太多，就是在制品太多，两周的迭代根本没有办法做到专注。
Scrum价值观是什么呢？勇气、专注、承诺、尊重、开放，你做不到专注，你自然也实现不了符合Scrum 要求的这种迭代。
我们的结论是什么呢？
两周的迭代根本不适合当前的团队情况，我们要把它改成三周。但大家会怀疑这不是延缓了交付速度吗？我要问一句，业务方要的只是速度，他们期望的是稳定的节奏和预期，要的是质量，而不是一味求快，要的是一个稳定的节奏和预期。我们要专注于一个迭代，而不是要并行很多的task，不要很多在制品。因此我们要重新设计迭代的节奏。
第一周先评审，做设计和任务拆分，然后研发测试上线，到了第三周的最后一天，在提前进行需求沟通，就是refinement安排的工作量会略比之前两周的量要多一些。这样就干掉了所有跨迭代的并行的工作，就做到了专注的迭代交付，形成了真正意义上的TimeBox，就是时间盒。还有一个问题，公司的正常发布周期是两周，和三周的迭代就会产生一些冲突，敏捷实践是侵略性的变革，刚才我有提及，当你需要别人调整和改进的时候，你就需要去进攻别人，我们就去找运维沟通，说服他们配合我们。利用公司有紧急发布的一个流程，我们变通了制定了一个固定周期的发布计划，我们会向运维承诺，会严守这个周期，最终也得到了他们的同意。
新的节奏试运行了1~2个迭代以后，大家的效率提高了，抱怨也相对的减少了，我们不是单纯拉长了时间，而是实现了能够专注的TimeBox，敏捷原则的第8条，说的其实就是保持节奏，我一再强调节奏和TimeBox，这是非常重要的一点。TimeBox是敏捷团队能够实现改进和提高的重要基础。我们所有的进步所有的改进都是在TimeBox里面主动有计划的争取来的，你做到了专注就做不到符合Scrum要求的sprint。建立了时间盒我们就可以开始有精力去解决一些内部的问题了。
大家可以猜一下，接下来会是什么问题？是
Scrum三大支柱，透明、检视和适应。
怎么检视呢？最重要的手段当然是会不会，会不会有很多看法，大致的讨论和流程就是我们先要营造氛围，然后汇总信息，洞察问题，确定改进措施和责任人，然后结束回顾。
我们也组织了几次非常关键的回顾会，并且在回顾会上给大家就是巧妙的挖坑，让大家往里跳，首先大家是自由分组，然后按照引导的一些流程和套路，每个人限时静默书写，团队书写团队存在的5个问题，小组限时讨论，最终几个小组共同讨论出最严重的一些问题。然后集体投票，然后我们要优先解决哪一个，
因为在敏捷团队里面研发占了绝大多数，大家都认为需求问题的优先级别最高，往往大家需求问题都希望别人去改进。有一次关键的会不会一口气提出了4个期望改善的问题，要改善需求质量，改善需求沟通，改善需求的评审结果反馈，及时明确需求的范围。
问题就是这些，那么怎么不改进？你们继续讨论，当把问题通过投票列出来以后，方法也是你们自己去讨论，挖坑了。我不参与，我甚至主动离场，每隔10分钟我就问一下，你们有讨论好策略没有？如果没有就继续讨论，我继续离场。结果在这个问题列出来以后，他们讨论了两个小时，最终拿出了他们自己的整改方案，方案是什么呢？就是建立起了准入的标准，建立沟通的机制，建立固定的时间反馈机制，固定时间也明确需求范围。
继续挖坑了。你们有方案了，有策略了，行动项是什么？
大家一定要明确行动项，谁去牵头制定方案，谁去执行，谁来监督？什么时候完成？实现不了怎么惩罚。
当然可以是俯卧撑100个或者是平板支撑、青蛙跳这些都是可以的，有很多的这种惩罚措施。我也做了一个非常大的看板，高是1米2。长三米。贴在过道的墙上，非常醒目非常大。像中间这幅图一样打出来非常大的字，把改进目标行动项、责任人结果进来，都会展示出来，把它公示出来。每隔几天我都会更新情况更新进展，这个时间大概是2019年的9月份，过了一个多月，这些问题就得到了明显的改善，因为建立了需求准入的标准，建立了需求确认的规则和时间点，效果还是很明显的，这些都是他们自己搞定的。
我们看第二幅图，这个时间节点大概是2019年的11月份，需求问题已经基本解决，这个时候问题是什么？两个，一个是要严格执行遵守需求的准入标准，因为标准有了，可能大家在执行的时候还不够严格。另外一个就是要提高自测的质量，我们可以看到到这个阶段对于产品来说优先级别比较高的问题，已经是提高自测质量，到这儿已经是几个月了，一开始的士气低落，需求粗糙，并行的task太多，这种问题已经基本解决。
我们觉得缓过气来了。从挣扎就走向了可持续。什么叫可持续就是说我们实现了能够主动有计划的在TimeBox里面交付和进步，这个就是可持续。稳住了。我们做一个小小的总结。
回顾一下，我们是怎么做的？敏捷实践实际上就像看病，先救命，如果你是病的很重的话，再看病，在ICU里面，他不是要治你的病，而是要先用各种方式把你救过来，先避免继续失血，先缓过来，当然离开ICU以后就可以进入普通病房了，就可以看门诊了，但你活下来了你就可以治病，可以去头疼医头脚痛医脚，这个是接下来的问题。这个时候有同学问了，我们把病都治好了以后怎么办？我们可以继续spa，可以健身，可以提高免疫力，可以按摩松骨大保健，有同学可能会笑，我也不解释了。
问题分为组织的问题，团队的问题，个人的问题，组织的问题，比如说是一些基本的平台的环境，关联的系统，这些可能是我们解决不了的，解决不了我们要承认，我们就与这个问题共存，但是没有必要把这个问题拿出来做挡箭牌，成为不去解决其他问题的理由。我们要更多的去寻找哪些问题是我们能解决的。带病生存就是说伴随着问题生存是一个新常态，能解决问题，要靠自己去解决。如何去实现自驱呢？我们就想一个策略，我们认为只有实现多赢，才能够实现自驱。
我想了一个策略，也和技术负责人沟通了很久，我们希望加速团队小伙伴的成长，我们期望能够实现之前所说的这个项目的内容交付，个人成长，团队成长的多赢。团队里面架构师是以设计为主，也要编码。骨干以编码为主，也要承担部分设计，还有一些新人都是刚毕业不久，还不能放手让他们独立干活。
这个时候依然是以两名架构师为主来进行设计和工作分配。他们既要对接需求，又要设计方案，还要安排协调研发测试的任务，又要保证迭代和结果交付。在需求从需求产生到研发落地价值传递的过程当中，他们承担了关键的环节，非常辛苦，加班也很多，根本就忙不过来。另一方面，团队里面有一些相对年轻的骨干，毕业也有三五年以上了，在我这个活他们也几乎能干，只是经验和火候还没那么好，他们应该更好地成长和积累经验，他们应该得到更好的去锻炼，甚至说我们要解决团队的问题，必须要依靠这一部分人。
另一方面我们看看这个表，上面那个表是之前的节奏，第一周有明显的信息传递的过程，信息每多一份传递，就多一层衰减，纯粹研发的时间，实际上我们查一下只有4天，那么是不是可以再挖一挖潜力，更加提高效率。如果可以减少信息传递，使研发工作更加前置，是不是就能够提高效率？
我们再强调一下，我们期望能够实现项目内容的交付，个人成长，团队成长的多赢，
通过和技术负责人和架构师反复的沟通，就是你给他们讲课，讲团队动态成长，讲塔克曼理论，讲敏捷领导力建设，最终得到了他们的支持，就开始了我们的迭代牵头人的计划。这个计划就是在每一次迭代，从每个团队里面选出一名骨干，来作为迭代的leader，也就是迭代的技术总负责人，他来负责任务拆解，需求对接，进行设计，来牵头进行测试和上线运维的一些协同，也就是说承担了以往团队leader加上项目经理的活，由技术负责人和架构师给予帮助，来确保效果，必要的时候还是由基础的两个架构师来进行兜底。
经过一两个迭代的摸索，我们就形成了下面的新的流程。牵头人先去牵头拆分任务，把骨干们结队来进行设计，大家一起来设计，大家共同对这个方案负责。
第三天进行一个快速的计划会，这样的话就减少了信息的传递和削减，但提高了大家的一个主动性，增加了研发和编码的时间，客观上也给测试增加了实验窗口，也提高了质量。经过一段时间的运转，正常的发布就变成了水到渠成的事情。
大家忽然觉得自己比以前变得从容了，因为我们激发了牵头人的能力，使他们乐于去做这件事情，然后也减少了信息的衰减，我们对牵头人的小伙伴也进行了访谈，你作为牵头人，你觉得苦不苦？他说挺辛苦的，那你问他爽不爽，他说挺爽。他觉得提高很快，他的感慨也非常多。以前老骂领导傻叉，原来这个leader真的是不好当，感觉自己突然提高了一个段位。
Scrum讲究的是自组织团队，团队讲究互相信任，互相支持，形成共同的目标，对信息要共享，要能够自由表达。
这些说起来非常简单，但是做起来太难了。作为对公司，对领导，对自己，对收入，对现状都不满，然后个性又十足的，20多岁奔三的小伙，你凭什么让他们自组织？你能给他多高的薪水，你能给他什么？我们可能给不了你足够高的薪水，但是我们希望能够给你机会，给你一种正确的做事方式，给你敏捷的认知。我们一起来制定目标，一起来实现目标，我们能给你这种实现目标的满足感，真的有一天你在我这得到了成长，满足不了你了，你要走，你也会感谢环境，感谢我们这个团队，甚至说你会感谢你的领导，你会感谢我，我们就是要实现共赢。
几个迭代过去。这几名骨干也得到了一个非常大的一种脱胎换骨般的成长。把他们随便撒出去，他们就是一个不错的团队leader。另外从这个角度来说，我们也为组织培养了人才，往大了说，也是为社会贡献了力量。半年多的时间过去，团队到这是有半年了，团队确实是成长得非常多，这一页看似非常简单，但是实际上是非常关键的一步。敏捷就是要把大家的主观能动性给激发起来，要能够更好的交付，更好的提升团队，提升自己，到现在这个团队已经激活了，战斗力非常的强。
有经验的小朋友能看得出来这是敏捷吗？这是小瀑布。
我的回答是的。通过我们前一段时间的努力，能够
建立了这种稳定的专注的TimeBox
，就说明我们能活下来了，有的条件在他们的TimeBox里面折腾了，小瀑布那只不过是从ICU到门诊部到大保健过程当中，我们早晚要解决的问题，就看是不是到了水到渠成的那一步。那么我们一再强调节奏和TimeBox，我们所有的进步都是在TimeBox里面主动的争取来的，那么我们已经是有计划的得到了加速的成长。
接下来我们就要更加的关注自身，我们要开始向小瀑布要发起冲击了。我们看一下这幅图，顺着箭头分别是图1234，想当初是这样一种节奏，大家可以仔细看一下是不是？产品想着新的，研发做着当前的，测试测着研发之前提测的，大家都在并行，研发工作存在着大量的并行，至少要并行三个不同的任务。对于研发来说，一边要应付新的评审。一边写当前的代码。一边要改测试提出来的之前的bug，他无法专注，他的工作内容互相交叉影响，其实效率很低，这个是不是大范围的仍然在我们伙伴的这种工作环境里面存在。
在图一当中，我们从价值的角度再看一下，一个批次的需求，从开始设计算起，他要经过三个周期才能上线。然后顺着箭头看第二幅图。在一个迭代周期里面，减少了并行，可以专注于同一个任务，但是仍然是小瀑布。什么叫小瀑布？就一个批次的需求都研发完了，在统一进行提测，但是因为我们形成了稳定的TimeBox，从价值的角度，一个批次的需求从设计开始算起，要经过两个周期才能上线。实际上我们经常在敏捷里面用到一个工具，叫做燃尽图。因为小瀑布的存在，燃尽图根本画不起来，为什么呢？到了某一天批量提测，在这一天之前，你的燃尽图实际上无法对应得到，到了提测这一天可能突然下去了，这个燃尽图是失真的、毫无意义的。
再继续看第二幅图，很明显我们的团队目前处在图二的阶段就是小瀑布。
我们再看第三幅图，第三幅图是说研发和测试是同步的，发布一开发，发布一测试，它是同步的。这意味着什么？是一个批次的需求可以拆分的更细，完成一点就能测试一点，测好就能上线。一个批次的需求，从开始算起，也是两个周期，但是在第二个周期内，它可以是实现灵活上线，而不是要到第二个周期末才能上线，它可以实现灵活上线。做完就能测试，测好了就能上。
这实际上就需要在我们的持续集成方面要取得很大的进步，我们需要形成这种可用的自动化的测试体系，能够随时进行回归测试，我们还要具备这种自动发布能力，在DevOps领域方面要取得非常实质的一个效果。
首先自动化测试就是提前写测试代码，自动化的配置发布也是脚本和代码都需要持续的投入。当然现在距离图三还有很多路要走，但是到目前为止，我们形成了稳定的时间盒和质量有大幅的提高，团队已经被激发了，有了更多的主观的能动性，我们已经不再被动了。我们有精力，也有动力去做点自己喜欢的事情。研发和测试人员就能够腾出时间去写自动化测试的代码，可以去实践极限编程，可以去提升故事拆分的能力。因此我给大家取了个名字叫做奔三计划。
至于图4更加符合敏捷的思维，适合于那种能力超强的这种自主的团队，大家都具备这种跨职能的能力，一起摸索，一起考虑需求，一起研发，一起测试，这些活大家都能干。其实很多创业团队也都是这么干过来的。这是需要更高的能力，但是对于这个团队来讲，未来的很长一段时间之内，大家还是要做好自己的搬山之路。
接下来我们就向着图三的方向去努力。向小瀑布开始发起攻击，开始关注价值，这些都需要团队更加的积极主动，能自驱有计划，有策略，在稳定的时间盒里边，在满足组织要求的这种交互内容的前提之下，我们按照团队的能力也提升了自己的能力，这就是我们民营团队的一个小目标。
大家应该听过一个词，
守破离
。大家觉得这个时候这个状态到目前为止可以脱手了吗？不，还远远不够。刚才我说是奔三计划，突破了三以后，实现了很好的故事拆分，实现单件流的发布，实现了大家所说的这种全栈，才能勉强算是突破了守，我们还差得远。守破离的守，其实是最艰苦的进攻，要持续跟自己跟团队跟组织较劲，每一步都会充满挑战。我们简单回顾一下，在我做的团队级别的敏捷实践中，我们首先找出了生死攸关的问题，确保它不再出血能活下来，你能活下来才能考虑别的。我们推动了透明，特别是在核心的干系人之间，真实情况透明出来，问题就容易解决了。我们要形成TimeBox，并且在时间盒里要实现专注，我们所有的这种进步都是在TimeBox里面主动有计划的争取来的，解决问题要靠大家，大家提问题，大家一起来想对策和一起解决。
怎么发动大家呢？
叫激发团队，
我们给不了你更高的工资，我们就加快你们的进步和成长，而不是压榨和瞎折腾你们。
问题是不断涌现出来的，解决一个新的问题就会浮现出来。但这个就是进步的过程。我们要先活着离开ICU，先活下来，然后再头疼医头，脚痛医脚，再去各个科室去看门诊，看医生对症下药，身体没毛病了，可以继续健身，心急不得，需要时间。到这儿我这次分享就接近尾声了，最后由这幅图来结束本次分享。
这幅图也经常被别人拿出来做各种解读，我说一下我自己的看法。面对着用方的轮子拉石头的人，你要给他提供一个圆的轮子，你说你要用我的轮子吗？别人说不，感谢，我们很忙。你知道这个世界上有轮子，面对着不知道有轮子存在的人，你怎么样让他相信你？还有一个是对方真的不知道有圆的轮子的存在吗？真的不知道他们用的方块。他们现在正在使用的方块有问题吗？为什么宁愿用方块呢？你考虑过换轮子的风险吗？有可能你不碰，这个车子还能用，你一动这个车子就彻底不能用了。换一个角度问，你懂得了敏捷的方法论，就一定能够成功实践吗？不一定。你不能够站在上帝视角。你要放下一颗帮助别人的心，而且要和团队在一起，要成为团队的催化剂，你学会了敏捷实践，你拿着一把锤子，但别人不见得都是钉子。
我觉得我们自己可以有两个体会，我也经常用体会来提醒自己：
-
-
不要以为自己懂了圆的轮子，就想马上去换掉他的方的轮子。
我们的
实际的世界远远比教科书要复杂，
要对这个现状对现实情况充满了尊重和重视，这就是我今天的分享。有问题大家可以交流一下，右边有一个二维码是我个人的公众号，大家也可以去了解一下我的一些认知和经验。
内容来源：敏捷+社区线上直播009期，《在敏捷实践中加速成长》分享实录
【版权声明】本文为华为云社区用户原创内容，转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息， 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
评论（0）