今天我给大家带来了一些关于敏捷方面的分享，也希望大家能有所收获。由于疫情我被困在了家中，所以在此我插播一个广告，非常感谢敏捷家及网易杭研组织这次课程，同时也感谢Bob老师以及在场的各位小伙伴。
今天我要分享的Topic是
敏捷的潘多拉魔盒
，当然了在讲课之前先做一个自我介绍，我叫李聃，我的聃和老子同名，我的姓也和老子同姓，所以我跟老子是同名同姓的。在我过去的16年的工作经验中，将近有10年是在做项目管理工作的。近5年其实我主要是公司的PMO负责人，管理公司的项目，并帮助组织做一些敏捷转型的相关工作，也辅导过很多的敏捷团队，也组织过或者作为演讲嘉宾参加过国内的一些敏捷或DevOps大会，并翻译过相关的一些书籍。关于专业认证方面，我有41个国际认证，包括项目管理、产品管理、精益敏捷、DeveOps、规模化敏捷和IT服务管理，同时我也是非常热门的火星着陆器和凤凰项目的沙盘授权讲师。
下面我们正式进入今天的课题，
今天要分享的内容主要是围绕着敏捷及敏捷的一些反模式的话题所展开的。它其中包括4个小节：
下面我们开始一起来揭开今天的潘多拉魔盒。说到乌卡这个词，它是由美国陆军在90年代初提出的一个概念，它是应对冷战后世界形势的一种解读。
乌卡是由易变性、不确定性、复杂性、模糊性这4个英文单词的首字母所组成的。
既然世界形势发生了变化，战略方针、战略行动、组织结构也应该随之而变，所以组织也应会应对这种战略、战术和组织结构做出相应的调整。个人应该做出什么样的转变呢？我觉得可能个人需要做到
有愿景、有知识、有勇气和不断适应。
那么乌卡时代我们要去转变或者是不去转变呢？开始讲我第一个故事，这个故事就是关于我本人的讲述，基本上是我的职业生涯的一些转变，可能有一些人给了我很多的标签，例如说像管理专家、讲师、敏捷实践者和孩子的父亲，但给我自己其实还有另外一个标签，就是一个幸运的人。其实我做过工程师，项目经理，也做过运营，也做过产品经理，为什么说我是一个幸运儿呢？这可能真的跟我的工作有关，因为我04年北邮毕业以后就顺利进入了国企，后来由国企又去了三大运营商，移动、电信、联通的第三方服务商，由甲方变成了乙方，后来又有机会去了互联网电商DHK以及互联网教育VIKID。有一次机缘巧合的情况下我又去了京东商城，还做了一名产品经理，接着又来到互联网金融行业，所以我的很多朋友都对我说，我所选择这个行业或我所在的这些行业，都可以用猪都能在天上飞来形容。所以可以说我是一个幸运儿，我能从通信再到电商，再到教育，再到金融，在行业不断的变化的情况下，接受变化带来的挑战，并适用这些改变，这就是我生命中的改变或者说改变中给我的一些机遇。
那么来到了2020年，我特别想知道或者说特别想问在场的大家一个问题就是大家对于2020年期望着什么，或者说在脑海里回想一下，我们都期望着什么？你可能会说公司不裁员不降薪，那我呢？我真的希望疫情早点过去。因为由于疫情的原因，感觉2020年刚刚开始，但是它已经进入到5月份了，一年的一半已经过去了，也许有很多人会说有没有一个赚100万的机会，怎么去破解未来，变成完成今天的想实现的这些愿望。面对疫情，生活发生了改变，不知道是否有小伙伴依然在家隔离办公，感受着这种全新的7×24小时的工作感觉。我在家办公确实是有这样的感觉的，或者复工的小伙伴会不会发现回到公司以后，周边的很多东西发生了改变？那么我觉得
改变、不确定、机遇和挑战，就是今年2020年的标签。
面对这种突发的疫情和不确定性，再看看我们周边的人、事物的变化是非常快的。我想起了2018年罗胖在跨年演讲的一段话，他是这么说的：前年在跨年演讲时，我还说要抓几只黑天鹅来看看，今年何止五只黑天鹅，那是黑压压的一片飞过的天空，一只接着一只，有人可能开玩笑说黑天鹅都快成了家禽了。那么今年2020年，也许灰犀牛也快成了家畜了，不确定性带来的变化可能慢慢的成为了我们时代的标签。我们正处在这种乌卡的时代，那么如何去面对呢？
面对变化和不确定性，我们可能要反过来去学习病毒的生存之道。这张图片就是新冠病毒在显微镜下的一张照片，他的生存之道是这样的：
保持始终变化的不变，对冲不确定性带来的变化，这也是和敏捷性创造性要达成的一些东西、事情是一致的。
说到了敏捷，来看一下敏捷的渊源，长期以来软件行业被一种工业的观点和信念的范式所支配，这实际上是旧的生产过程和理论的一种复制粘贴，这种知识、观点和实践的方式是基于一个因素——泰勒主义的思想，既不能相信工人有智慧，有自主或有创造性，他们能自主的去完成工作，他们只能完成那些预先设定好的或者那些可执行的一些任务。他们的工作是由高级管理人员去精心准备设计规划，然后由一级主管人员去监督了他们的工作，工人只是执行了这些精心准备好的任务，是通过接受那些好的，或者说不接受那些坏的来保证质量的。奖金就是刺激这种期望的一种行为，不受欢迎的行为就会用一些惩罚的方式，这就是古老的胡萝卜加大棒的策略。
人们花了很长时间，在这种时间的观察，工业范式在软件开发中的问题和一些异常状态，新的想法和见解就慢慢的形成了。新的世界观的种子，是早在20世纪90年代就播种下来了。这个代表就是戴明发明了PDCA，包括丰田的TPS、丰田生产系统，精益理念，后来又有水晶Crystal 、DSDM、Scrum、极限编程、结对开发等等这些实践，直到了2001年这种新的世界观才真正的用敏捷名词来命名，这是软件开发历史上的一个转折点，一个新的范式的诞生在软件行业，与此同时它也不断的扩大到社会的各个领域中，这种具有启发和创造性的范式，是一种在尊重或者说恢复工作的创造性和人的智慧性为基础的一种范式。
常常我会听到很多人谈论到对敏捷的一种渴望，通常这种渴望是希望敏捷是一种神奇的解决方案，一个能解决一切问题的灵丹妙药。但是这样的敏捷其实并不存在。敏捷其实不是一个固定的流程方法和实践，敏捷是软件开发方法的共同原则的集合。敏捷是指敏捷软件开发宣言表达的思维方式、信念和偏好。那么真正的敏捷是什么？我更喜欢用三个关键词来描述敏捷，它是一个
以人为本，一种迭代增量的过程，用价值来衡量成功的唯一标准。
既然改变、不确定，敏捷性成为当今时代的标签，敏捷的方式也将成为很多公司的选择。敏捷自从2001年敏捷宣言发布之时，截止到今天已经蔓延到社会的各个互联网企业或IT企业中，成为了他们的一个必备的技能。就连很多的大的业务部门也开始慢慢的学习敏捷，在做业务敏捷的一些实践和方法。那么我们一起来看一下潘多拉打开的敏捷的魔盒里面到底有什么东西？
说到潘多拉，他是希腊神话中火神赫斯托斯和宙斯用粘土捏成的给地上带来的第一个女人，这个潘多拉用什么赋予他无限的诱惑人的魅力？神创造它的目的是作为对普罗米修斯造人和盗火的一种惩罚，希望潘多拉用他的好奇心去打开宙斯给普罗米修斯的魔盒，然后释放出世界上所有的幸福、灾祸、友情、忧伤、爱情。潘多拉在打开魔盒的时候，尊重了宙斯的一个旨意，在希望没有释放出来的时候，他扣上了魔盒，把希望永远锁在了魔盒之内，这就是潘多拉的故事。
敏捷的潘多拉魔盒里面到底有什么呢？想想除了敏捷宣言的4个价值观以及背后的12个原则，还包括2001年签署宣言的17位敏捷先驱者所遵循的不同的路径和方法，每种路径和方法都是敏捷的一种新的范式的不同的实践模式。如Scrum、极限编程XP、DSDM、水晶Crystal、特性化驱动开发FDD等等这些实践，最后的希望到底是什么？我们要通过不同的最佳实践去解决公司内部，包括业务产品设计、开发测试、架构DBA甚至运维部门之间的一系列问题，通过敏捷的实践方式持续改善，找到适合公司的模式，这才是敏捷最后的一个希望。
说到敏捷呢，可能有点像八卦，老子在道德经里的第42章里说到这样的一句话，道生一，一生二，二生三，三生万物，万物负阴而抱阳，冲气以为和，这就是和敏捷其实是有点像的。敏捷基于4个价值观，价值观背后有12条原则，基于这些原则所包含的方法、框架、策略、实践，同时方法也不断地在演化发展。如这两年比较热门的DevOps，或者说规模化敏捷SAFe或Scrum@Scale、Less等等。敏捷4条价值观都是以什么样一个格式去定义呢？都是以这样的
什么高于什么，
它真的就有点像八卦里的阴阳两面，需要在实际的工作中并不断寻找平衡，达到持续改善开展的状态。
所以敏捷我觉得是一个永无止境的状态。敏捷既然是一个永无止境的状态，那么在这些实践和方法中有没有一些规律呢？我记得去年参加了敏捷宣言的发起者海瑞的一个课程，课程中有两点受益匪浅，一个就是这张敏捷的大伞，还有一个就是他的雪人模型，海瑞通过大伞下的多个维度来分析一些实践的应用场景。
-
-
其次我们要改善的方向的维度，例如质量、效率和价值。通过大伞我们可以看到各种不同的方法实践和策略的运行场景，一个个人层面的质量问题，可以通过极限编程XP来解决，或者说团队效率方面，可以通过Scrum或精益看板去解决它。
-
同时值得关注的两个点，也可以看到是在价值方面，可能往往去忽略掉水晶Crystal或DSDM方法。这说到大型组织的一种质量策略，它这里写的是TNBI其实就是需要我们持续去寻找更好的一种解决方法来提升大型组织中的质量。也许大型组织中质量的提升是需要运用精益理念中，让团队和个人做到一种自工程完结，或者说是内建质量的一个过程。通过团队和个人的质量的提升，来最终达到大型组织的一个质量的提升。
如果大家选择了这条敏捷的道路，也许我们可以一起像谦谦君子那样默默地磨练内心，持续学习。要在这样一个图书馆的迷宫中去不断的磨练自身，去学习掌握新的知识和技能。这是因为其实我们生活在乌卡的时代，我们的工作是在一个复杂的领域中工作的，需要在不可预测的情况下随时接受一种全新的挑战，或者说要随时能翩翩起舞。根据我的经验，工作中可能有很多的突然间就要求你去做，或者说去促进某种并没有做好完全准备的一种行动或者一种计划。
作为一个合格的敏捷教练，没有借口去说对不起，我没有做好准备。在敏捷的环境中，需要不断的提升自己的技能，以便能够立即跳舞。这就是敏捷魔盒给我们带来的冰与火的磨练。
关于提高技能方面，也许一个正式的培训课程可以给你很多的帮助，还可以通过大量的阅读书籍提高技能。随着大家的工作的强度和工作的时间越来越忙，996或者说007这样的状态，读书的时间会越来越少，但是作为一个敏捷人来说，去通过读书这种方式来提升自己的能力是必要的一个条件。我一直在努力着坚持，在每个月尽量去读4本书，来不断提升我的能力。只有这样，我才能觉得才能更好地影响到我的公司的组织和公司的高管层。
再来看第三个方面，同时敏捷的魔盒里，还需要在这种冰与火之中，用以一种初学者的心态去遵循敏捷的价值观和原则，在这么多的实践中去不断的通过这些实践的完整的过程，去刻意练习实践的步骤，然后持续尝试实践，并尊重敏捷的实践。
在实际工作中，也可能看到了问题通常是很多的，但是其实这些问题都可以在工作过程中通过一些实践的方式来解决掉。我们都知道
办法总比问题多
，要遵循敏捷的原则和价值观，去运用最好的实践找到其中最优解。但是最大的问题往往在于在敏捷的实践或实施过程中，敏捷的有些传言会接踵而来，这些传言让我们错误的理解敏捷或迷失了方向。例如就是：
-
速度和价值是同一回事，真的是快了吗？我们就得到这种价值了吗？在我做团队培训的时候，往往会说Less is More，少即是多，不要去玩命的去制造那些用户不想要的功能，只有那些能真正打开用户钱包的功能才是要交付的。
-
敏捷方法要比瀑布方法好，但是敏捷不是什么灵丹妙药，不是只要敏捷了就变得无敌了。其实敏捷有时候并不如意，有时候瀑布的模式也可能是一个最好的选择。
-
敏捷表明稳定性降低，灵活性增加。虽然灵活性对于敏捷来说很重要，但不等于要交出次品，往往在实施敏捷的过程中，例如在DOD的定义当中，去忽略到一些技术卓越性的条目，导致了产品是一种次品上市，或者说带伤上市，或者说是带有技术债的功能就上市了。我会在后面的话题关于DOD的这块给大家用一个例子去讲解。
-
敏捷等于Scrum，大家如果是敏捷圈的人就明白，敏捷其实还包含了很多的实践，Scrum只是敏捷实践中的一个。
-
敏捷就像大爆炸一样，立刻就可以替代一切。但是其实像开始说工业范式一样，我们是一直在复制粘贴它，敏捷也一样，不可能去照搬，只能去寻找最佳的方式。同时敏捷的道路其实是一个变革的道路，它是一个非常漫长的，就像在面对疫情的过程，我们心理上其实都是经历过三个阶段的改变的——否认、接受、适应，这个过程是一个很艰苦的战斗过程，所以敏捷的变革道路也是这样的。想想我们在疫情刚开始的时候，每个人都被困在家中，我的孩子非常小，刚一岁半的时候，他每天都想着出去玩，然后我不可能老是带他下楼，因为担心他的身体健康，所以他被憋在家中很难受，但是人其实都可以慢慢去接受和适应的，我看到随着时间的推移，很多的人在朋友圈晒厨艺，晒生活，晒在家办公的状态，这时候大家就慢慢的接受了在家办公的状态和疫情带来的影响。最后其实是不是也有的小伙伴已经适应了或者习惯了在家办公的一个环境。我跟Bob聊天的时候，Bob老师就说他已经习惯了这个状态了，其实对他的影响并不大，他觉得还挺开心的。其实这就是敏捷变革的过程给我们的一些改变，
要从否认、接受到适应。
-
敏捷意味着没有计划，没有文档。说到文档这个事，我来说第二个故事，记得当时我们公司刚开始转型敏捷的时候，我和一个开发同学的一段聊天，我当时就问他你在最近在忙什么？因为我看他特别忙，他说“别提了,自从有了敏捷，我现在快成了产品加设计加开发的全栈了。现在我在做后天要评审的交互设计的程序设计”。这时候我就想交互设计都没出来，你怎么去做程序设计，我就继续问他：“你知道交互设计是什么样吗？”他的回答是什么？“领导说了敏捷就是要快，省去文档，所以你可以先做一些设计，等交互出来了，这些设计应该跟你的程序设计，因为你们俩一碰应该差不多”。当时我的脑海里就觉得各种的不知所谓，其实PPT中写的东西基本上都可以用敏捷的神话来表述。
我们说完了敏捷的神话，再来看一下在团队中经常使用的敏捷的实践，其实最经常用的就是
Scrum+看板+极限编程的方式。
首先我们就来看一下Scrum，Scrum大家听一听，肯定都想起了3355，很多人会认为它有很多的会议，因为有5个会，其实Scrum是一个简单的框架，它是上个世纪90年代以来，就已经被应用到管理复杂的产品的工作上了。
Scrum并不是一种流程或技术或确定的方法，倒不如说它是一种框架。在框架中你可以使用各种的不同的流程或技术或方法，Scrum的帮助是让你的产品管理和工作技术相应的效果更加清晰的能在组织中呈现出来，以便可以持续的改善团队、组织、产品和工作环境。Scrum是Scrum团队及其相关的角色、事件、工件和规则组成，框架中其实每一个部分都有特定的目的，对Scrum的整体成功其实都是至关重要的。所以我们不能忽略掉Scrum框架中所有的或者说每一个组成部分，在实际工作中其实往往会忽略到一个点——
Sprint Goal
，就是冲刺的目标，我在后面会专门对于冲刺目标会做一些讲解。
然后再来看一下Scrum Guide中是如何描述去定义Scrum的。其中有一句话我觉得特别值得我们关注，这句话就是说
Scrum是轻量的，易于理解，但难以精通。
既然Scrum是一个难以精通的，在实际工作中会不会有这种是ScrumBut的情况？
-
我们使用了Scrum，但不在Sprint设置时间。
-
我们使用Scrum，我们在Sprint计划中去设置Sprint的时间，如果没有一个时间盒或者说时间是随时设置的，不是一个稳定的状态，团队很难找到这种节奏，同时这样的话会影响效率，往往会落入原来那种瀑布式的模式。记得我的公司开始实施Scrum的时候，我的团队当时由于需求非常多，想快速交付，所以运用了Scrum，但是Scrum来了以后，在最开始的时候，产品经理只能去把这些大的一个需求去拆成几个阶段性的一个步骤去交付，分阶段交付，其实就有点像在瀑布模式下的一种里程碑，他并没有形成这种Sprint的一个持续交付的状态。这时候团队状态其实还是在原有的工作模式下，大家都是在加班赶工去交付这些输出或者功能。但是Scrum其实不是一个范围或者功能驱动的一个框架，它是一个目标驱动的框架。我在后面关于Sprint Goal的时候，我会讲述一下Sprint目标应该是更关注于结果的，而不是一个关注于产出的一种状态。如果关注产出，员工就会不停的去忙碌着，大家也不知道目标是什么。当时我的团队因为前端开发的工作量很大，前端5个同学，基本上每天都是凌晨2点才下班，第二天早上10点到公司工作。到时候我们发现了在第一个阶段交付的时候，交付质量当然是相当差的，因为其实大家在那种强度下的工作已经成为了一个机器，但是软件工作其实是一个创造性的一个工作，不可能是通过简单的敲代码就能完成的。
-
我们在使用Scrum，但是我们不让产品待办事项逐渐的演进。
-
我们使用Scrum，但不在Sprint中去做回顾会议。如果产品不去做演进、团队不做回顾会议，也许是因为这些做起来真的可能比较费劲，但是我们失去了什么？失去了对产品和团队工作的持续改善和提升的机会。为什么说是可能说是产品演进比较费劲，或者是回顾会议比较费劲呢？因为在我实际指导的很多团队中，产品经理尤其是初期产品经理转过来的时候，他们还是习惯于完整的把需求收集过来，做一个完整的规划，成为一个产品的概要，这时候他们的需求清单其实已经在那了，他们没有时间或者说并不愿意去调整他们的Backlog的优先级或者说一些条目。这个时候其实他们的工作模式还是在旧的瀑布模式下，而且他们也不知道怎么去改变，因为可能每个Sprint目标就是一个为了产出多少个功能的一个Sprint，在Review和回顾的时候，并不能得到很多的客户的Feedback，所以也没法去调整去演进产品代办事项。
在说到回顾会议，我认为是Scrum几个会中比较困难的一个会议，这个会议需要作为敏捷教练或者Scrum Master要有很好的引导技术和教练技术。这个时候其实这种技术需要大量的时间的积累，往往这种回顾会议就在组织中开成了流于形式的一种会议，或者更有甚者会开成了“复盘会”，找纠错，怎么找问题这种会，所以往往Sprint回顾会议有可能在很多团队中就不开了，省去了。所以这种情况下就不是Scrum，所以我所说的ScrumBut并不等于Scrum，在实际工作中一定要坚守Scrum框架中的3355或者其他的一些方法和组成部分。这样才能使在实施敏捷转型的过程中，才能更好的给组织带来价值。在我的公司的部分团队中，很难从原来的瀑布模式转到Scrum的方式的一个原因，就是这种ScrumBut的现象。
极限编程是由KentBeck开发的方式，它简称XP，它是一种敏捷方法，它是为了适应并满足快速变化需求的软件开发团队的工作，一种刻意的严谨的软件开发模式，它是通过更多的短的开发周期去降低需求变化带来的成本，这种变化是一种自然的不可避免，是一种可取的方式。其实它的原因在于极限编程方法和组成部分，不是由它来创造出来的，而是这些工作方式已经在软件开发过程中已经运用了很久了，只不过是这些方式方法被很多复杂的流程中运用，KentBeck只是把它们提取出来并收集在一起。XP还引入了一些原则，比如说
简单设计，拥抱变化
，实践方面还包括了
结对编程，持续集成TDD
等等。
接下来再来看一下XP的日常惯例，也就是如果选择一个XP的方式，每天都要做如下的一些工作。
例如说结对编程，在分配 story的时候，分配任务的时候，可能是运用XP方式有自主的一种选择，设计要遵循简单的设计，测试和开发的时候，可能是要测试先行用TDD的方式，还要不断的重构，持续集成，还要停止工作，这个停止工作就像我刚才的一个故事中，不能像我的前端开发，一天从早上10点工作到凌晨2点，他的停止工作的意思每天都是只能工作8个小时，每周只有40个小时。这里其实请注意的是大家如果选择XP，就要每天都要执行这些活动。
常常看板被作为带有粘性的报时贴和泳道的板子被大家所误解，但实际上看板的定义是这样的，
看板是一种策略，是通过可视化在制品限制的拉动的一种系统来优化价值流的。
在这张图中就是一个标准的看板示例，我们在图上都看到了什么，包括报时贴、泳道、WIP、 DOD、圆圆的头像以及工作流程。那么看板的规则到底是什么样？
这里简单描述了一下WIP限制是看板里一个核心概念，它的目的就是要让我们尽早的发现瓶颈，能快速的交付价值，同时降低一些风险。我举个WIP的简单的例子，它就像在高速公路上开车，我在高速公路上开车发现路上只有我一个人，那么高速公路的利用率肯定不是很好的。如果说高速公路非常拥挤，那也不行。像在北京上下班高峰时候的三环四环，都像大的停车场的那样，肯定流通率也不会很高。
怎么找到WIP的一个值呢？需要大家在看板实践中不断去关注团队WIP数量，不断调整它，来达到一种高速流动的一个状态，这就是价值流动的一个速度的体现。这个就是非常重要的指针或者一个指标。往往在实际工作中WIP被忽略，就是工作中的常见的反模式，如果不去设置WIP，想想会发生什么？
这张幻灯片呈现了这个效果，开始的时候我们工作可能会正常的进行了一个状态。随着工作的进行，其实是很难发现过程中的瓶颈。只能看到大家都在不停的忙碌，但是最终的产出是什么样子？其实没有人能知道或者说也看不到任何的产出，只能看到大家不停的忙碌，因为没有WIP限制，也感受不到团队成员之间的一种协作。例如说开发工作量很大，测试同学或者是分析人员，产品人能不能帮助开发做一些工作，这时候都是不会产生一些协作的一种方式。
第二个反模式往往就是在Scrum中和看板结合的一个反模式。Scrum已经把团队划分成了一个很小的5~9人的一个团队，但是团队中如果看到了看板中每个泳道，竖道底下都有一个DOD，泳道+DOD的一个状态，无形中把团队成员的不同工种之间设置了成了一个舱桶，产生了一个无形的墙，就像我现在的团队当时我记得开发团队就对产品设计人员说，你们设计没达到DOD的标准，我们根本就无法进行开发，所以我们要等你完成了以后在完成。关于Scrum中的DOD的定义应该是什么样，我在后面的内容会给大家详细的去讲解，在这里我就并不多说了。
所以这时候不是说看板中的DOD是有问题的，但是我们要不断的发现会不会存在这种现象，比如说产生了部门墙的这种现象，来帮助团队去解决这种现象，这才是我们遵循的一个更核心的原则。如果只是用这样的看板，没有WIP的看板，可能真的只能看到现在的状态——就是一个缺少开发的状态，实际的根本原因是什么？可能是技能不够，或者是人员协作不好，或者说由于开发的质量和工具质量导致了测试以后返工的东西比较多，哪些才是真正的问题，其实并不能发现的到，所以并没有起到一个看板的作用， 最后只能是保持着一种忙碌的状态，并发现不了任何问题。
再来看一下开发实践，在敏捷的道路上，大多数人都会想将原有的大型的项目去拆解成小型的项目。记得我原来的一家公司在实施敏捷的初期就是这样的想法，当把大型的项目拆成了小型的项目的时候，这时候业务和产品就开始头大了。因为原来的大型的一个完整的PRD怎么去拆？同时拆小了以后真的能快了吗？拆散以后是否能交付更多的价值？因为需求被拆解了，变小了，是不是只能做一些修修补补，然后更大的需求怎么去满足？这个时候其实设计开发团队也有一些问题，因为他们拆成了5~9人的小的Scrum团队，一个小的特性化或组件化的团队，根本就无法在两周之内完成整个的功能开发。
但这时候该怎么办？同时研发架构、DBA运维的问题也来了，因为原来的应用和数据库都是非常吻合的，怎么去把它解耦？同时发布的频次变快了，回归测试的质量下降，运维发布的时候会出现一些异常，但是回滚的时候又出了岔子怎么办？这些现象其实就是把项目拆小了以后的管理成本的一种指数级的增加。这些管理成本就像这张图中的交易成本是一样，当我们的批次变小的时候，交易成本是一个很大的过程。
所以要在批次见效情况下，怎么去降低总成本？可能大多数情况下只能去通过降低交易成本，例如工作的交接、各种审批、回归测试、集成测试和部署等等的这些时间和成本来去降低交易成本，来最终达到了总体成本的一个下降，而同时还能快速的交付价值。这时候就需要引入了很多的自动化的技术或开发实践，甚至Devops工具链，因为持有成本这条线其实是在公司里以后长期很难去改变它的。
说了这么多，最后来看一下如何抓住敏捷魔盒中的希望。来看一下实施敏捷Scrum看板和极限编程的几个重要内容，也是常常忽略的点，由于时间的关系，我可能只能快速的讲解一下关于
Sprint冲刺目标和DOD
这两点。关于看板和Scrum的一些融合的方法，以后有机会再跟大家分享。现在首先就来讲Sprint Goa——冲刺目标。
接下来我再给大家讲另外一个故事，是我辅导过的一个刚刚组建的敏捷团队，当时PO是刚刚从产品部门提拔过来的，有一天 PO就跑来我的工位来找我，他的心情表情是非常担心的一个状态。我就很好奇难道团队遇到了什么问题？他跟我说团队表示由于没有任何的改进的产品待办事项，因此无法进行开发。于是我就向PO去确认了他有对Sprint目标是否是很清晰，并和他们一起来到了会议室。在会议室里我看到的团队的Sprint计划会议非常焦虑，我先让PO讲述了他认为的Sprint的目标是什么，他说发现我们的访问者在网页上停留5秒钟后后下降率达到20%，这个指标非常令人担忧。我们想通过Sprint来降低下降率达到10%，如果我们真正能达成这个目标，将会非常高兴。
于是Sprint计划会议就围绕这个目标展开了，大概持续了一个小时多，然后团队在计划会议中围绕Sprint目标所展开，虽然团队在Sprint当中只能完成一两个代办事项，想想只完成一两个代办的事项，团队的速率会急剧下降，但是我们都认为冲刺目标是比待办事项更重要的，如果Sprint结束后，不能实现任何的目标，那么集中精力去固定范围，或者匹配之前的速度，其实是没有意义的，或者说又回到了工业化时代的旧的思维方式，旧的范式。
当时其实有一个令我特别意外的收获，有一个高级开发工程师提出了一个新的想法，他说让我们这样做，我喜欢这种不同的对待Sprint的一个方式，也许我们下次可以通过更加关注Sprint目标去缩Sprint计划会议的时间。就是这样的一个过程，我们往往应该更关注于Sprint的目标，这样实施Sprint计划会议往往会给我们一个缩短时间的状态。在实施Scrum期间，其实许多的Scrum团队或者其他很多的组织都忽略 Sprint目标这一点，但是这一点在Scrum中Sprint目标是非常重要的。因此我们来讨论一下如何建立一个以结果驱动的Sprint目标，而Sprint的目的是提供完成的增量，同时去完成冲刺目标。
Spring的目标是Scrum的核心方面，在实际Scrum Guide中提到冲刺目标的频次要比冲刺的待办事项要多10倍。也许许多Scrum的团队还是去按照项目的模式去专注于交付多少的Sprint代办事项或交付多少功能或者用户故事。但是尽可能的在每个Sprint去达成目标，才是更有价值的，这样才能给产品带来更多的价值，才会影响到业务和生意。没有Sprint目标冲刺，在冲刺结束的时候就无法实现一种大家一起工作的共同状态，就不会有一个为了一个目标共同协同工作的一个团队，一个人在做事情的时候，其实也是需要一个目标的。
就像我今天要完成和大家的分享的时候，我的各个器官都要整体配合在一起，才能完成这个目标，我的手、眼、嘴、肢体各个部才能更好的配合起来，有了目标，团队才能向一个整体去运作，像一个人一样去运作它。没有Sprint目标的一个团队，人们只会于忙碌在自己的事情上，自己的工作上，每日站会往往会成为了一种状态更新的一个会，而不是去寻找任何机会和方法，用团队共同的一个目标去前进的方式。
同时没有Sprint目标，Sprint 评审会的时候，也只是去展示迭代所做完成的这些Sprint待办事项的一些功能的展示，而失去了作为检查目标是否达成的一个机会，或如果没有达成，怎么找到达成目标的解决方案的一个反馈的点，如果没有目标，我们就丧失了这种机会。有些团队是有Sprint目标，但是他们的Sprint目标，并不是令人鼓舞人心的，因为他们的Sprint目标是更关注于输出的，这使团队成为了一个功能工厂，或者说特性工厂。令人鼓舞人心的Sprint目标，我觉得应该是一种以结果导向的Sprint目标，这样团队看起来才能更像一个创新者是或者说一个业务问题的解决者，更能发挥开发者的智慧和他们的创造性。
输出驱动的指标，例如功能数量、完成率、吞吐量、项目及时性和速度，以结果导向的一种目标，例如用户粘性、已支付的数量，客户留存率、推荐率和利润，往往高的输出并不一定能带来高的结果，冲刺目标应该是令人鼓舞人心的，所以冲刺目标应该是一个结果导向的。
因此不应该落入以输出驱动的去定制Sprint目标，把思维方式始终保持在工厂的一种思维，或者说旧的模式。常常见到输出的目标是这样一个东西，完成产品待办事项100号、101号、102号，同时修复1000号的bug，这样的Sprint目标要在工作中尽量去避免使用，因为他不会激励团队去蓬勃的发展和促进协作。
这里有个小贴士，在实际工作中不要这样做，这样做会使团队成为一个功能工厂，每个人员就是工厂中的资源，像一个螺丝钉，像一个齿轮，在机器中的齿轮不停的在转动。实际上输出型的目标，并不能视为真正的一个冲刺目标，但是许多的团队仍然选择了这种冲刺目标，我们应该改变，或者帮助他们摆脱旧的模式，工厂的心态，也许造成工厂的心态的一个原因，是因为衡量结果其实往往是很难的，所以改为衡量输出。
想想之前这几个结果的目标，转化率、留存率，复购率，UV、PV、停留时长，如果在系统中没有去做一些埋点，或者说没有做一些收集的功能的话，是无法得到的，或者说如果得到了不准确的话，也很难去衡量。同时一个小的Scrum团队的两周的版本，其实是很难去测量的，正是因为这些困难，所以往往去衡量输出指标。我见过了很多团队，都会想每个Sprint的迭代速度会不断的提升，通过迭代做20个故事，下个迭代做24个，然后逐一依次类推。这样其实就是把团队变成了一个功能工厂，让工人们不断的劳动，就去增加产量，真正鼓舞人心的Sprint目标应该是什么样的呢？我用这几个例子给大家展示:
-
我们的Sprint目标应该是访问整个网站的流量增加10%。
-
-
-
我们的用户在浏览我们网页5秒钟后的下降率降低到15%。
其实能够在每个Sprint中去专注结果的Sprint目标确实是很难的，但是它其实是真的很有意义的。为什么说它很难，就像刚才我说的，度量它就很难。
如果没有一个很好的衡量手段，无法测量它，就不能知道这个Sprint是否完成了，所以前提条件是要能度量它。如果选择一个结果输出的 Spring的目标，此刻团队的心态是什么样一个状态呢？应该是结果高于输出的。请记住Scrum是一个目标驱动的框架，而不是一个范围驱动框架。这就像我刚才讲的Sprint计划会议故事一样，应该更关注于结果，而不是输出。为了提出一个结果导向的目标，可以让项目团队或更主要的是产品负责人和开发团队提出三个问题：
-
第一个问题就是
当前产品业务状况如何，上次Sprint评审会得到的客户反馈是什么？
想一下，如果评审会的时候仅只是展示或演示功能，而没有一个Sprint的目标，或者先前的Sprint完成的时候，只是根据的Spring代办事项定的目标的话，很难去获得客户的反馈。
-
第二个问题我们需要问，
我们希望在 Sprint中影响的最重要的结果驱动指标是什么？
有了这个结果指标，才能更好的运行Sprint计划会议。
-
第三个问题，
我们希望完成 Sprint ，通过产品改变的客户行为是什么
？就我而言，我更喜欢在Sprint计划会议的一开始，首先去设定Sprint的目标，这时候产品负责人和开发团队就有了一个目标，然后他们就可以一起合作，从产品待办事项里头故事中选择符合目标的故事，放入到Sprint待办事项，这将使此Sprint成为一个结果驱动的Sprint，而不是一个输出或代办事项驱动的一个Sprint。同时在一个Sprint中，也不应该设置多个Sprint目标，应该只有一个。如果设置了多个Sprint目标的话，往往团队会陷入没有重点的混乱状态，会再次恢复到功能工厂的心态。
这张图是一个Sprint计划会议的输入过程和输出。
输出里面的sprint目标在待办事项的上面，这就是说明输出是要是一个结果驱动的目标，Scrum团队的心态应该是成果高于产出的。聊完了Sprint的目标重要的点，也许Sprint目标就是团队中所忽略或错误理解Scrum的一个重要方面。
另一个非常重要的点，也是在Scrum的团队中常常被忽略，
Definition of Done——DoD完成的定义，
忽略完成的定义是很多团队在实施敏捷或者实施Scrum的时候失败的一个重要原因。因为没有足够重视完成的定义，就不能去更加关注这种技术的卓越性，这种状态就会导致敏捷的一种失败，导致上市的很多的功能和产品都是有技术债的产品。如果将Scrum用一个简单的一句话来描述它，就是说要持续完成增量，在每个Sprint中达到目标。
为什么用这么一句话说完成增量？完成，是非常重要的点。由于Definition of Done——DOD的重要性，一起来看一下完成的定义。
许多人认为完成的定义和验收标准AC是相同的，验收标准其实是在产品待办事项PBI的一个属性而完成的定义是增量的一个属性，确保每个产品待办事项的验收标准都完成，它只能是DOD里头检查清单的一部分或者说其中一个标准，根据Scrum Guide，当增量满足完成的定义时，表现出增量就是可以部署到生产环境，但是只确保满足验收标准，往往是不能满足增量达到了生产就绪的状态的。为了保证生产就绪，所以完成的定义中还有包括一些其他的内容，例如所有级别的测试，如单元测试、集成测试、功能测试、渗透测试、安全测试等等。
看到这些测试以外，还会有什么？许多人会看到这样的一个神话，在组织中实施Scrum的时候，不需要再写文档，我前头已经说过了那个故事，在此过程中，任何对团队或者对企业有价值的文档，其实都是我们所需要的，也都应该放到DOD里的，或者说也都应该成为DOD的一部分。因此对于企业和Scrum团队有用的文档，例如用户指南、故障排除手册、发行说明、系统架构设计，然后测试场景用例等等都应该放到DOD里头。
我还发现一个大的问题或者一个大的神话，因为很多团队并不关注治理和审计，我现在在一个金融行业，因为金融行业其实每天都受着银保监会的监管，也都有很多的内部审计和外部审计，还有一些治理的标准，这些其实都是影响产品和功能的。例如我前一阵一个项目中要求记录用户在使用产品的行为轨迹，打上标签，这个时候其实治理和审计的要求就应该放到DOD里头，所以DOD中也应该包括治理审计。
同时我刚才说过的由于完成的定义中不包含技术卓越性的实践，或者不包括任何DevOps的事件，产品就会带伤上线，或者说是有技术债的，所以DOD里头也应该包含这些实践，例如单元测试率达到90%，通过MOB编程的方式进行代码审查，MOB就有点像我们结对编程，但是MOB和结对编程的不一样的点，结对编程是一个人开发，一个人在旁边做导航并审查代码， MOB可能是有多个人在做导航的职位，可能是有2~3个人去帮助一个人审查他的代码，同时还有应该包含一些自动化测试脚本，还有持续集成，自动化部署、自动化配置脚本等等。
这些其实都是DOD的一部分。有了DOD的实践，在Spint评审会的时候，只有符合DOD的用户故事或代办事项，才能把它放到了潜在的产品增量上。如果不符合DOD的标准的故事，就会放到了产品待办事项列表中由PO去管理，这时候如果PO愿意，可以把这些已经完成的产品增量发布到生产系统中。就像产品所有者是拥有产品待办事项一样，开发团队是拥有完成的定义的，因为开发团队是对产品的质量负责的，开发团队通常也会在Spint回顾会议阶段不断的去改进完成的定义，以确保产品的质量的不断提升。
说了这么多，关于AC和DOD的常见的一些混淆，这里我引用Evelyn老师的一个例子，希望能给大家带来一些更好的理解DOD和AC。大家肯定都吃过麦当劳，我用麦当劳的套餐的例子简单描述一下AC和DOD，大汉堡、麦香鸡、薯条等等，这些其实都是PBI的描述。最原始的PBI可能是客户，客人要两个大汉堡，一个麦香鸡套餐，AC里面就会写着大汉堡里面有两片肉，两片奶酪，三片生菜等等。麦香鸡套餐是包括一个薯条和一个麦香鸡，麦香鸡米包含了一块鸡胸肉和沙拉和生菜等等。
DOD是什么？DOD其实就是薯条需要在多少温度下的油里炸多久，肉需要在烤盘上用多少温度，正面烤多久，反面烤多久等等这些。那么大汉堡都是由两片肉和两片奶酪所构成的，这些大部分的PBI的AC，其实是重复的东西，那也就是说在点菜的菜单上面都是有很多重复的AC，所以在菜单上有可能直接写着大汉堡、麦香鸡、麦香鱼这样的AC。如果说AC一定是DOD里的一部分，再想一想，如果Bob老师进来点餐，他就是要在大汉堡上加多加两片奶酪， PBI上会写着什么呢？PBI上的AC里头会写着什么呢？就会写着大汉堡+两片奶酪的AC，我进来点餐我就要正常的快餐，就写着一个大汉堡麦香鸡套餐，然后点完餐以后取餐，我发现我的麦香鸡多了两片奶酪，这个问题是什么？就AC的问题，AC写的不对，那么如果发现肉烤糊了，或者说薯条炸的特别焦特别咸，这些问题是什么呢？这些都是质量的问题，是DOD。
所以还是回到我之前说的那句话，就是产品所有者拥有产品待办事项列表和AC，开发团队拥有完成的定义，因为开发团队是对产品的高质量所负责的。
我们说完了DOD和Spint Goal，最后如何去面对乌卡时代，打开了潘多拉魔盒，可能需要我们要
有愿景、有知识、有勇气和适应。
-
愿景是要在这种不可预测的状态下，需要更好的去使用愿景，使命去催生力量，去塑造环境。能预见未来才能创造未来，赶不上变化就不能塑造变化。
-
就像庄子说的一句话，井蛙不可语于海 夏虫不可语于冰。为了跟上这个时代，要突破原来思维框架的这些束缚，不断提升自己的知识模式和心智模式。
-
勇气就像框架中的价值观的勇气一样，我们需要勇气，变化意味着一种选择，选择的时候是需要很多的勇气的，不要让摸着石头过河的思路成为了我们不加思考，不做担当，不去选择的借口。所以勇气和选择在这个时代是非常重要的。
-
最后就是适应，物竞天择，适者生存。从个体的角度而言，需要我们从被动的适应到主动的塑造，乌卡时代我们要做一个士者，士者就是要整合所有的资源、知识、框架和体系，为组织去创造带来更多的价值，让我们与时俱进，让我们在这个时代中酣畅淋漓的发挥作用，让我们在敏捷的道路上更顺风顺水。
为了帮助更多期待转型者，或者说已经在转型道路上的这些实践中走出了误区，突破这些障碍，今天我从敏捷的源头来讲到敏捷实施的过程和方法，让真正能从潘多拉魔盒中，在不断遵循敏捷的原则指引下，通过不断的学习，从不断的方法到思维方式的敏捷转变的过程中，一起去体验一次旧模式到新模式的转变之旅。这就是敏捷道路上的冰火人生，要持续学习，不断刻意的练习，能在瞬息万变的环境中不断随时接受这种挑战，达到敏捷的守破离的过程，去破解未来，去寻找潘多拉魔盒最终的希望。最后是我的希望。战役必胜，中国必胜，谢谢大家。今晚我的分享就是这些。
内容来源：敏捷+社区线上直播008期，《敏捷的潘多拉魔盒》分享实录
分享者：李聃
【版权声明】本文为华为云社区用户原创内容，转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息， 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
评论（0）