《知-敏捷思维模式和价值观》
在敏捷实施过程中，有几个问题很关键，包括组织的问题、人的问题、执行力的问题。其中组织的问题不在我们个体控制范围之内，
今天主要聊聊人和执行力的问题。
人都是有惰性的，也正是因为人的惰性，才有各种各样的发明，比如汽车、飞机。敏捷也是一样，有人说敏捷是一批懒人在做的事情。确实，实行敏捷开发之前，大家都“不懒”，每天忙着写bug修bug、应对线上的各种各样的问题。
而
实行敏捷之后，人就变“懒”了。
可以实现一键发布、一键部署，简化了开发操作；引入自动化，不管是回归测试、压力测试都可以用自动化替代；通过交付更高的内建质量，促使软件开发效率和质量得到提升，不用再面对这么多线上的问题；实行自组织团队管理，团队内有完善的规则，大家按照规则办事，不用为了职责范围争吵，不需要任务分配，经理也懒得去管团队了。
来一个灵魂拷问：
每天早上叫醒我们的是梦想还是闹钟？
我觉得这个问题是有意义的，
它可以让我们思考，我们的动力来自哪里。
可能是出于被动，比如生活的压力、公司制度的约束等；更好的是出于主动，发自内心地有一个目标想要去实现。《内驱力》中提到自主，专精，对目标的追求可以激发我们的内驱力”。
一件很奇怪的事，当一个人自己尝试经营一家小店，不管有没有挣到钱，不管有多辛苦，他都会很有热情地去做。为什么他会有这么大的热情呢？
我们发现
工作热情的大小很大程度上取决于认为“这件事是为谁做”。
当我们把工作当成自己的事业来经营时，就会有一种“为自己做事”的归属感，更容易驱动自己倾入更多热情和精力；当我们把工作当成差事来做，即认为是在“为公司工作、为老板工作”时，我们往往更倾向于按报酬来投入时间和付出。
大部分人属于后者。我们需要做一个转变，每一份工作都需要我们投入“开小店”一样的热情。事实上，对于大部分人来说，当你投入更多热情在公司的工作上时，获得的回报往往会比自己“开小店”来的多。
不妨停下来回顾一下，从你毕业到现在工作了多少年？从第一个月到现在薪水增加了多少？除去公司的8小时外，你额外投入了多少时间在工作上？有没有为了让工作做得更好而去学习什么或参加什么培训？工作能力有没有得到提升？
回答完这些问题后，你可能会发现其实你在工作上的投入并没有想象的那么多，但现在的薪水已经比刚毕业的时候增加了很多，如果能够花更多时间在提升工作能力上，我相信面对的机会、得到的报酬肯定会更不一样。
也许有人会说，公司已经996了，每天都要求重复繁杂的事情，疲于应对当前的工作，根本没有精力去思考和学习。这种模式下，公司和个人发展之间存在矛盾，对于公司而言，产生效益为优先，不管是不是重复劳动，只要能够快速交付产品就是有意义的；而这样的重复工作对于个人能力提升而言却意义不大。
敏捷为我们打开了一扇大门，提供了新的思路和机会。
在敏捷开发过程中，你不仅需要写逻辑代码，还要参与到方案的设计分析、搭建CI/CD、做需求管理、做项目计划、需求估算和排期等工作中。同样3年时间，个人在敏捷团队中的成长和收获都是在传统开发团队中无法比拟的。
敏捷思维，更多的是说我们站在什么角度去思考问题。
典型的敏捷思维是成长性思维：
人的能力可以通过学习得到，我们要承认自身的不足，并通过努力去改变这些不足。
敏捷的基本价值观如上图，这几个价值观太重要了。尊重和同理心、承诺和责任感，不只是敏捷的价值观，也是每个人都必备的。
一个人的心智模式、思维方式和价值观会对其行为起到决定性的作用，而行为会导致正向或负向的结果。
所以，倡导敏捷价值观实际上是对符合敏捷价值观行为的期待。
但是不是每个人都把敏捷价值观放在首要位置，比如上图中的行为在团队中司空见惯，这些都是不符合敏捷价值观导致的反面行为和负向结果。
我们不能直接通过一个问题去问团队成员是否都具备正向价值观，但是可以在实际工作过程中观察每个人的行为。
当有人出现这些反面行为时，需要及时干预，告诉他这不是我们期望的行为。干预团队行为也有一些模式可以参考和运用，帮助引导团队往更好更积极的方向发展。
通过观察，我们发现表现
好的团队和表现不好的团队都会有一些共性：
-
表现好的团队中至少会有一个或多个人工作态度非常积极，当他们看到不好的行为时会提出来，且善于观察工作中是否有可改进的机会。
-
表现不好的团队中则会有一两个“愤世嫉俗”的人，平时团队中的人说什么做什么他会表现出毫不在意的样子，但是在团队之外，就会到处抱怨我们这个团队有多不好、领导有多糟糕等。
《部落的力量》一书的作者特别针对这个点从不同角度进行了分析。书中将团队比喻成部落，并将部落文化分成5个阶段，如图。在表现好的团队里，大部分人都处于第3/4阶段，特别是第4阶段，整个团队是一个正面的心态，包括用语等都是正面的。
作为管理者/leader/Scrum Master的我们，要做的事情是找到团队中处于第1/2阶段的人，引导和帮助他们转变心态。从个人角度来说，要选择正向的部落，并融入其中。
几乎团队里的每个人都可以映射到这个团队成员阶梯中来。有些人平时对问题视而不见，对什么都无所谓的态度，认为来上班就为了拿工资，做一天和尚撞一天钟；稍微好一点的是会观察发现问题但是不说出来，可能他觉得说出来也改变不了什么，而且还会得罪人；再好一点的是看到问题并且说出来了，但是自己不去想办法解决；在往上是看到了问题，会自己思考得出解决方案，这是我们期望看到的，说到做到；再上一个阶梯是提前规划，比如团队要交付一个东西，从发布计划这个点出发，会想想自己当前的进度是什么、有没有潜在的风险、提前规划怎么应对等；最高阶梯的是合伙人，把团队当做自己的团队，不管是不是处于领导者的职位，都会从团队拥有者的角度去考虑问题。
处于上面阶梯和下面阶梯的人，其成长路线、发展/晋升机会都是不一样的，显而易见，
团队更希望看到处于上面阶梯的人，敏捷的模式也期望团队和团队成员都能往正向的发展。
蜂群中有部分蜜蜂直线飞行，引导整个蜂群飞行，其它蜜蜂只是跟随。
从蜂巢领导法则能得到一些团队发展的启示，包括：5%的核心领导力=90%的成功；群体中存在一些知情个体，可以使世界展现出不同于以往的状态。
我们要看一个敏捷团队里是否存在这部分具有核心领导力的人，这些人是否能使得团队往好的方向发展；如果我们本身处于团队之中，我们就要成为具有核心领导力的人，要知道团队往哪个方向走、怎么才能达到那个方向；我们要在团队中发现和培养具有核心领导力和正向价值观的人。
上两周我给一个团队做了一次培训，培训完后，有个人过来跟我说：敏捷听起来好像会议很多，我们很忙，交付压力很大，能不能把站会、回顾会取消掉？我的回答很直接：不能取消。当然原因我也跟他仔细分析了为什么不能取消这些会议。
Scrum-but是经常会碰到的一个问题，团队常常会说时间不够用、角色能不能兼职等等。事实上哪怕是遵循scrum框架去做，也还有很多团队做不好，更不要说舍弃框架内的一些东西。
拿Scrum 会议举例，这些会议为我们提供了软件开发的过程框架，通过会议和配套的工具将计划、需求沟通、传递、验收等显示化地描述出来。
好比一个大厦的柱子，你说我把下面的柱子去掉一两根，这明显是不可行的。
Scrum存在一定程度的抽象，和具体实践也稍微有一些距离。就好像Java为开发者提供了一个很好的架构，定义了一些抽象的接口，我们在使用的时候不能直接拿这些抽象接口去适应全部的应用，而是要结合开发环境和场景进行编写实现。
上图提到的这些问题是做Srum的团队常常提的问题，Scrum中没有提到，严格来说我们碰到的很多问题并不属于Scrum的范畴，而是软件开发领域、团队管理的问题。
以武侠举例，想要做好敏捷和想要学好武功是一个道理，不可能通过一本九阴真经就立刻成为武林高手。我自己就是一个武术爱好者，练了很多年，还在练基本功。要想学好武术，要从一招一式开始，将这些招式练成本能反应，才可能在实战中见招拆招。
对于敏捷团队来说，什么是基本功？就是
定义敏捷实践活动和检查规则。
相信很多团队已经在做“定义”这件事了，但有多少团队会根据我们的规则进行详细反馈，并根据反馈做实时调整？
光定义远远不够，还得有反馈、有改进。
平时我们总说会议难开，到底会议难开在哪里？是我们讨论的议题不详细？还是会议的过程不清楚？白板怎么设计？状态怎么更新？DOD/DOR标准怎么定义？story在分析、设计、开发、测试等不同阶段怎么流转？代码分支、生命周期如何管理？反馈机制是什么样的？遇到问题的时候，不同类型的问题分别找谁？是不是提前做好了约定？是不是承诺了会及时查看并解决问题？等等这些规则都要在开始的时候梳理和定义好。
因此
可以定一个清单，按照这个清单一个个去检查，并把检查过程和结果反馈出来。
比如会议开得好不好、为什么不好，大家一起来讨论改进。所以在开会的时候，有两件事要做，一是会议本身的内容和目的是不是达成；二是会议过程开得怎么样？有没有改进的空间。
具体到会议目的，比如需求会议的目的是要把需求传递给团队，那怎么验证是否成功传递呢？随机抽一个人脱稿重述一下需求，如果讲不出来就说明会议的目的没有达成，会议讨论过程可能存在问题。这就是一个检查机制。
我们会从敏捷教练的角度，提供一个软件开发过程中所有活动的参考规范。
上图列了12个方向，在软件开发的过程中，敏捷团队要做的事情不仅是写代码和测代码这两块内容，还有其他10个环节。这12个环节，任何一环做得不好，都很难达成高绩效的敏捷团队，但实际上很少有团队能考虑得如此全面。
我们提供这样一个活动参考规范，并针对每个环节列出具体的清单，供团队360度参考，每个环节逐一检查反馈并作出相应改进。
3.1 需求规范
拿需求规范举例，上图列了一些点，要求PO按照这个方式去做，敏捷教练要看需求是不是满足这些点。
很多有问题的团队，其主要原因是需求端存在问题，需求端没有做好，交付就容易出问题，进而导致整个团队士气低下。
-
愿景，希望需求做成这个样子，要有明确清晰的愿景，且有愿景是否达成的衡量标准，定义出一些基本指标，这些指标在上线之后可以收集到数据，反过来验证愿景是否达成。
-
-
发布计划，当前发布计划的时间和范围要清晰。当前发布什么，下个月发布什么，是否有计划，范围是否清晰，每个story是否清晰，验收标准是否明确等。
-
-
拆分，遵循端到端的拆分方式拆分story，每个story的大小不超过velocity 25%。这一点很重要，如果story不能做到端到端拆分，后面跑迭代就非常难，QA在测试时也会遇到问题。story的大小建议不超过velocity 的25%，一个迭代至少得做4个story。
-
书写，遵循三段式，有充分的AC。这个三段式不是教条主义，我们可以通过三段式验证需求的合理性，问题是不是真的问题、方案是不是解决问题的最好方案都可以从三段式的表达中显示出来。还要有一个充分的验收条件，验收条件最后决定产出的东西是什么。
-
需求准备，按DOR标准检查story质量。需求的准备也要有要求，我们想要纳入迭代的story是否按DOR标准进行严格检查，比如story是否进行了拆分、是否具有业务价值，还有依赖的提前识别、数据格式的检查等，如果story不满足DOR标准的其中一个条件，在拉入迭代后就会出现各种问题。
3.2 会议规范
上图按照会议的过程列出了相应的会议规范。包括会议目的、会议开始的标准、是否需要前置准备、必备过程是什么样的、是否需要有过程指导、完成标准是什么等，一定要做好会议前中后检查。
每一个Scrum会议都有一个清单。我们在会议上会指定一个人负责对照清单对会议进行观察和记录，会议快结束时给大家一个反馈：
今天的会议开得怎么样、有哪些地方做得不够好，及时提出来，通过这样及时的反馈帮助会议进行迭代。
3.3 任务板规范
任务板（也可以说是看板，但这里我们会将其和看板开发方法进行区分）的
设计原则：任务板体现工作计划、迭代进展和风险。
-
-
开发过程和完成标准，关于完成的定义和标准要达成共识。
-
-
资源分配和开发日历、团队目标和行动项，在什么时间点实现什么开发目标，代码覆盖率要达到多少等，这些目标和行动项要透明出来，团队成员随时可以看到开发进度。
3.4 开发过程规范
开发过程规范如上图所示，此处不展开细讲，需要强调的是：团队要有一个共同遵循的标准。
3.5 测试过程规范
3.6 数据分析模版
数据分析，可能在很多公司和团队里更多提的是度量。谁会愿意被度量呢？这时这些“不良数据”的收集就会存在很大问题。
在我们公司，这些数据的收集分析都是团队自己来做的。比如
-
交付速率，考虑velocity Cycle Time、Burn down、 CFD、上线频率等。
-
交付质量，考虑需求质量、 Defect密度、单元测试覆盖率，code matrix等。
-
交付能力，考察CI/CD 、团队行动项完成率(Action Item) 、自动化测试等。
将这些数据收集起来，然后团队可以自己进行分析评估和迭代。
上面讲了这么多标准，团队会照做吗？通常在团队中，开发只关注开发的工作、测试只关注测试的进度，而除了开发和测试以外，上面我们列了12项活动，
怎么保证团队按照要求和标准去做呢？这是一个难点。我们遵循的是分散决策、全员参与的原则。
举个例子，人民公社时期，实行集体所有制，国家的地集体种，全民吃大锅饭，那时有一个词“磨洋工”，出一天工赚一天的工分。很像现在公司里有的员工的状态，上一天班赚一天工资，用时间去换取报酬，积极性没有调动起来。
改革开放之后，实行土地改革，包产到户，农民积极性被极大地调动起来，短短几年时间，家家有余粮，还出现了很多“万元户”，国家也变得更加富强。
回到团队中，我们怎么激发积极性让每个人都承担起责任？方法是：制定各项规则的owner。
假如团队是7个人，每个人负责几项规则，负责这项规则的意思是你要按照规则的要求去发声、反馈、并提出或组织团队获得改进方案。
敏捷开发之前，上这些工作都是项目经理要做的事情，现在每个人都参与到了项目管理的工作中，切身体会到管理的工作，无形之中会促进团队成员参与的积极性，提升他们这方面的能力。
同时我们也会让这些owner进行轮转，这样一来，每个人都能熟悉所有的规则，当你对这些规则都很熟悉了，如果你去一个新的公司、新的团队，都会很有帮助，因为它可以很快构建一个高绩效的团队。
5.1 构建数据驱动的反馈闭环
数据驱动前面介绍了，我们团队会主动收集数据，帮助自己回顾哪些做得好、哪些做得不好，因为
数据是客观的，团队做得好不好、是上升趋势还是下降趋势，都可以一目了然直观地显示。
从反馈闭环的角度来看，我们要及时检查；在站会上每日更新，站会上不仅要说昨天做完什么、今天要做完什么、有没有问题这三个问题，还要关注团队的各项活动质量并及时反馈；在回顾会总结改进，回顾会也要对这些活动有反馈，有问题提出来，及时进行总结和改进。
5.2 提高交付质量
举了例子，
假设目标是提交交付质量，怎么通过反馈闭环去实现这个目标呢？
首先要把迭代过程的相关质量数据收集起来，制定活动规则；之后开展活动，并在每个迭代进行数据分析；检查活动对质量的影响，是否符合设置的规则要求和验收标准；调整活动，根据数据分析的反馈结果进行改进和调整。
吉尔伯特，一位行为工程专家，上图展示的是他提出的行为工程模型。
团队绩效的影响因素分为两类：环境因素和个人因素，其中个人因素只占了很少的一部分，更多影响来自于环境因素。
比如上文提到的通过数据收集做反馈闭环、流程工具的使用和改进等，都会对团队交付带来很大的影响。
举个现实生活中的例子，春暖花开，大家都会出去玩，对于物业管理员来着头疼的事也来了，大家总是爱踩踏草坪。上面几张图分别展示了不同的应对策略：管理员站在那用大喇叭喊；在草地上立警示牌；设置小篱笆。很明显最有效的解决办法是第三个。这是典型的通过改变环境因素来影响结果。
人们常常会犯
基本归因错误，人们常常把他人的行为归因于人格或态度等内在特质上， 而忽略他们所处情境的重要性。
上述例子中以人去干预的解决办法可以称为“人控”，增加机器或设施的办法则可以称为
“技控”，即选择简单有效的方法和工具，改变固有的行为模式，以提高绩效。很多时候通过“技控”的方式可以让事情变得更简单。
上图中列举了一些软件项目中的技控例子。比如会议步骤清单，很多人反馈说站会很难，开不好，要么是大家讲得不全、要么是讲得太多。其实很简单，开会的时候用几张牌，每张牌写一个步骤，就可以做到会议时间有保障、内容有保障；代码检查清单，在代码走读时也是一样，按照清单一项一项去看，然后交付就可以了。
价值观的认同，团队成员要有一致的价值观。
工作过程有章可循，定义好活动规则和检查规则。
团队成员积极参与。制定各项规则的owner。
反馈闭环，以数据驱动反馈闭环。
技控，用机器和工具来解决问题。
内容来源：敏捷+社区线上直播003期，《知行合一的敏捷实践 》分享实录
分享者：道富银行敏捷教练杨贵
【版权声明】本文为华为云社区用户原创内容，转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息， 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
评论（0）