云社区 博客 博客详情
云社区 博客 博客详情

知行合一的敏捷实践

Bob Jiang 发表于 2020-07-13 18:23:47 07-13 18:23
Bob Jiang 发表于 2020-07-13 18:23:47 2020/07/13
0
0

【摘要】 在敏捷实施过程中,有几个问题很关键,包括组织的问题、人的问题、执行力的问题,这篇主要聊聊人和执行力的问题。

《知-敏捷思维模式和价值观》


一、原动力-你在为谁工作


在敏捷实施过程中,有几个问题很关键,包括组织的问题、人的问题、执行力的问题。其中组织的问题不在我们个体控制范围之内, 今天主要聊聊人和执行力的问题。
image.png
人都是有惰性的,也正是因为人的惰性,才有各种各样的发明,比如汽车、飞机。敏捷也是一样,有人说敏捷是一批懒人在做的事情。确实,实行敏捷开发之前,大家都“不懒”,每天忙着写bug修bug、应对线上的各种各样的问题。
实行敏捷之后,人就变“懒”了。 可以实现一键发布、一键部署,简化了开发操作;引入自动化,不管是回归测试、压力测试都可以用自动化替代;通过交付更高的内建质量,促使软件开发效率和质量得到提升,不用再面对这么多线上的问题;实行自组织团队管理,团队内有完善的规则,大家按照规则办事,不用为了职责范围争吵,不需要任务分配,经理也懒得去管团队了。 
image.png
来一个灵魂拷问: 每天早上叫醒我们的是梦想还是闹钟? 我觉得这个问题是有意义的, 它可以让我们思考,我们的动力来自哪里。 可能是出于被动,比如生活的压力、公司制度的约束等;更好的是出于主动,发自内心地有一个目标想要去实现。《内驱力》中提到自主,专精,对目标的追求可以激发我们的内驱力”。
一件很奇怪的事,当一个人自己尝试经营一家小店,不管有没有挣到钱,不管有多辛苦,他都会很有热情地去做。为什么他会有这么大的热情呢?
image.png
我们发现 工作热情的大小很大程度上取决于认为“这件事是为谁做”。 当我们把工作当成自己的事业来经营时,就会有一种“为自己做事”的归属感,更容易驱动自己倾入更多热情和精力;当我们把工作当成差事来做,即认为是在“为公司工作、为老板工作”时,我们往往更倾向于按报酬来投入时间和付出。
大部分人属于后者。我们需要做一个转变,每一份工作都需要我们投入“开小店”一样的热情。事实上,对于大部分人来说,当你投入更多热情在公司的工作上时,获得的回报往往会比自己“开小店”来的多。
不妨停下来回顾一下,从你毕业到现在工作了多少年?从第一个月到现在薪水增加了多少?除去公司的8小时外,你额外投入了多少时间在工作上?有没有为了让工作做得更好而去学习什么或参加什么培训?工作能力有没有得到提升?
回答完这些问题后,你可能会发现其实你在工作上的投入并没有想象的那么多,但现在的薪水已经比刚毕业的时候增加了很多,如果能够花更多时间在提升工作能力上,我相信面对的机会、得到的报酬肯定会更不一样。
也许有人会说,公司已经996了,每天都要求重复繁杂的事情,疲于应对当前的工作,根本没有精力去思考和学习。这种模式下,公司和个人发展之间存在矛盾,对于公司而言,产生效益为优先,不管是不是重复劳动,只要能够快速交付产品就是有意义的;而这样的重复工作对于个人能力提升而言却意义不大。
image.png
敏捷为我们打开了一扇大门,提供了新的思路和机会。 在敏捷开发过程中,你不仅需要写逻辑代码,还要参与到方案的设计分析、搭建CI/CD、做需求管理、做项目计划、需求估算和排期等工作中。同样3年时间,个人在敏捷团队中的成长和收获都是在传统开发团队中无法比拟的。

二、敏捷思维模式和价值观

image.png
敏捷思维,更多的是说我们站在什么角度去思考问题。 典型的敏捷思维是成长性思维: 人的能力可以通过学习得到,我们要承认自身的不足,并通过努力去改变这些不足。
image.png

敏捷的基本价值观如上图,这几个价值观太重要了。尊重和同理心、承诺和责任感,不只是敏捷的价值观,也是每个人都必备的。


image.png
一个人的心智模式、思维方式和价值观会对其行为起到决定性的作用,而行为会导致正向或负向的结果。 所以,倡导敏捷价值观实际上是对符合敏捷价值观行为的期待。

三、反敏捷原则行为

image.png
但是不是每个人都把敏捷价值观放在首要位置,比如上图中的行为在团队中司空见惯,这些都是不符合敏捷价值观导致的反面行为和负向结果。
我们不能直接通过一个问题去问团队成员是否都具备正向价值观,但是可以在实际工作过程中观察每个人的行为。 当有人出现这些反面行为时,需要及时干预,告诉他这不是我们期望的行为。干预团队行为也有一些模式可以参考和运用,帮助引导团队往更好更积极的方向发展。

四、部落文化5阶段


通过观察,我们发现表现 好的团队和表现不好的团队都会有一些共性:


  • 表现好的团队中至少会有一个或多个人工作态度非常积极,当他们看到不好的行为时会提出来,且善于观察工作中是否有可改进的机会。
  • 表现不好的团队中则会有一两个“愤世嫉俗”的人,平时团队中的人说什么做什么他会表现出毫不在意的样子,但是在团队之外,就会到处抱怨我们这个团队有多不好、领导有多糟糕等。


image.png
《部落的力量》一书的作者特别针对这个点从不同角度进行了分析。书中将团队比喻成部落,并将部落文化分成5个阶段,如图。在表现好的团队里,大部分人都处于第3/4阶段,特别是第4阶段,整个团队是一个正面的心态,包括用语等都是正面的。
作为管理者/leader/Scrum Master的我们,要做的事情是找到团队中处于第1/2阶段的人,引导和帮助他们转变心态。从个人角度来说,要选择正向的部落,并融入其中。

五、团队成员阶梯

image.png
几乎团队里的每个人都可以映射到这个团队成员阶梯中来。有些人平时对问题视而不见,对什么都无所谓的态度,认为来上班就为了拿工资,做一天和尚撞一天钟;稍微好一点的是会观察发现问题但是不说出来,可能他觉得说出来也改变不了什么,而且还会得罪人;再好一点的是看到问题并且说出来了,但是自己不去想办法解决;在往上是看到了问题,会自己思考得出解决方案,这是我们期望看到的,说到做到;再上一个阶梯是提前规划,比如团队要交付一个东西,从发布计划这个点出发,会想想自己当前的进度是什么、有没有潜在的风险、提前规划怎么应对等;最高阶梯的是合伙人,把团队当做自己的团队,不管是不是处于领导者的职位,都会从团队拥有者的角度去考虑问题。
处于上面阶梯和下面阶梯的人,其成长路线、发展/晋升机会都是不一样的,显而易见, 团队更希望看到处于上面阶梯的人,敏捷的模式也期望团队和团队成员都能往正向的发展。

六、蜂巢领导法则

image.png
蜂群中有部分蜜蜂直线飞行,引导整个蜂群飞行,其它蜜蜂只是跟随。 从蜂巢领导法则能得到一些团队发展的启示,包括:5%的核心领导力=90%的成功;群体中存在一些知情个体,可以使世界展现出不同于以往的状态。
我们要看一个敏捷团队里是否存在这部分具有核心领导力的人,这些人是否能使得团队往好的方向发展;如果我们本身处于团队之中,我们就要成为具有核心领导力的人,要知道团队往哪个方向走、怎么才能达到那个方向;我们要在团队中发现和培养具有核心领导力和正向价值观的人。

《行-如何落实敏捷实践》

一、为何实践敏捷如此不易


上两周我给一个团队做了一次培训,培训完后,有个人过来跟我说:敏捷听起来好像会议很多,我们很忙,交付压力很大,能不能把站会、回顾会取消掉?我的回答很直接:不能取消。当然原因我也跟他仔细分析了为什么不能取消这些会议。
image.png
Scrum-but是经常会碰到的一个问题,团队常常会说时间不够用、角色能不能兼职等等。事实上哪怕是遵循scrum框架去做,也还有很多团队做不好,更不要说舍弃框架内的一些东西。 拿Scrum 会议举例,这些会议为我们提供了软件开发的过程框架,通过会议和配套的工具将计划、需求沟通、传递、验收等显示化地描述出来。 好比一个大厦的柱子,你说我把下面的柱子去掉一两根,这明显是不可行的。
Scrum存在一定程度的抽象,和具体实践也稍微有一些距离。就好像Java为开发者提供了一个很好的架构,定义了一些抽象的接口,我们在使用的时候不能直接拿这些抽象接口去适应全部的应用,而是要结合开发环境和场景进行编写实现。
image.png
上图提到的这些问题是做Srum的团队常常提的问题,Scrum中没有提到,严格来说我们碰到的很多问题并不属于Scrum的范畴,而是软件开发领域、团队管理的问题。
image.png
以武侠举例,想要做好敏捷和想要学好武功是一个道理,不可能通过一本九阴真经就立刻成为武林高手。我自己就是一个武术爱好者,练了很多年,还在练基本功。要想学好武术,要从一招一式开始,将这些招式练成本能反应,才可能在实战中见招拆招。

二、定义敏捷实践活动规则


对于敏捷团队来说,什么是基本功?就是 定义敏捷实践活动和检查规则。
image.png
相信很多团队已经在做“定义”这件事了,但有多少团队会根据我们的规则进行详细反馈,并根据反馈做实时调整? 光定义远远不够,还得有反馈、有改进。
平时我们总说会议难开,到底会议难开在哪里?是我们讨论的议题不详细?还是会议的过程不清楚?白板怎么设计?状态怎么更新?DOD/DOR标准怎么定义?story在分析、设计、开发、测试等不同阶段怎么流转?代码分支、生命周期如何管理?反馈机制是什么样的?遇到问题的时候,不同类型的问题分别找谁?是不是提前做好了约定?是不是承诺了会及时查看并解决问题?等等这些规则都要在开始的时候梳理和定义好。
因此 可以定一个清单,按照这个清单一个个去检查,并把检查过程和结果反馈出来。 比如会议开得好不好、为什么不好,大家一起来讨论改进。所以在开会的时候,有两件事要做,一是会议本身的内容和目的是不是达成;二是会议过程开得怎么样?有没有改进的空间。
具体到会议目的,比如需求会议的目的是要把需求传递给团队,那怎么验证是否成功传递呢?随机抽一个人脱稿重述一下需求,如果讲不出来就说明会议的目的没有达成,会议讨论过程可能存在问题。这就是一个检查机制。
我们会从敏捷教练的角度,提供一个软件开发过程中所有活动的参考规范。

三、提供敏捷实践参考模版

image.png
上图列了12个方向,在软件开发的过程中,敏捷团队要做的事情不仅是写代码和测代码这两块内容,还有其他10个环节。这12个环节,任何一环做得不好,都很难达成高绩效的敏捷团队,但实际上很少有团队能考虑得如此全面。 我们提供这样一个活动参考规范,并针对每个环节列出具体的清单,供团队360度参考,每个环节逐一检查反馈并作出相应改进。


3.1 需求规范


image.png
拿需求规范举例,上图列了一些点,要求PO按照这个方式去做,敏捷教练要看需求是不是满足这些点。 很多有问题的团队,其主要原因是需求端存在问题,需求端没有做好,交付就容易出问题,进而导致整个团队士气低下。


  • 愿景,希望需求做成这个样子,要有明确清晰的愿景,且有愿景是否达成的衡量标准,定义出一些基本指标,这些指标在上线之后可以收集到数据,反过来验证愿景是否达成。
  • 发布路线图,有未来6个月的发布路线图。
  • 发布计划,当前发布计划的时间和范围要清晰。当前发布什么,下个月发布什么,是否有计划,范围是否清晰,每个story是否清晰,验收标准是否明确等。
  • 组织,需求条目化树状组织,有保持更新的需求文档。
  • 拆分,遵循端到端的拆分方式拆分story,每个story的大小不超过velocity 25%。这一点很重要,如果story不能做到端到端拆分,后面跑迭代就非常难,QA在测试时也会遇到问题。story的大小建议不超过velocity 的25%,一个迭代至少得做4个story。
  • 书写,遵循三段式,有充分的AC。这个三段式不是教条主义,我们可以通过三段式验证需求的合理性,问题是不是真的问题、方案是不是解决问题的最好方案都可以从三段式的表达中显示出来。还要有一个充分的验收条件,验收条件最后决定产出的东西是什么。
  • 需求准备,按DOR标准检查story质量。需求的准备也要有要求,我们想要纳入迭代的story是否按DOR标准进行严格检查,比如story是否进行了拆分、是否具有业务价值,还有依赖的提前识别、数据格式的检查等,如果story不满足DOR标准的其中一个条件,在拉入迭代后就会出现各种问题。

3.2 会议规范


image.png
上图按照会议的过程列出了相应的会议规范。包括会议目的、会议开始的标准、是否需要前置准备、必备过程是什么样的、是否需要有过程指导、完成标准是什么等,一定要做好会议前中后检查。
每一个Scrum会议都有一个清单。我们在会议上会指定一个人负责对照清单对会议进行观察和记录,会议快结束时给大家一个反馈: 今天的会议开得怎么样、有哪些地方做得不够好,及时提出来,通过这样及时的反馈帮助会议进行迭代。


3.3 任务板规范


image.png
任务板(也可以说是看板,但这里我们会将其和看板开发方法进行区分)的 设计原则:任务板体现工作计划、迭代进展和风险。
任务板的 设计的要素如图所示,包括:


  • 迭代进展、状态和进度。
  • 开发过程和完成标准,关于完成的定义和标准要达成共识。
  • 存在的和潜在的风险、阻碍要及时可视化地体现出来。
  • 资源分配和开发日历、团队目标和行动项,在什么时间点实现什么开发目标,代码覆盖率要达到多少等,这些目标和行动项要透明出来,团队成员随时可以看到开发进度。

3.4 开发过程规范


image.png
开发过程规范如上图所示,此处不展开细讲,需要强调的是:团队要有一个共同遵循的标准。


3.5 测试过程规范


image.png
测试过程规范如上图,不一一列举。


3.6 数据分析模版


image.png
数据分析,可能在很多公司和团队里更多提的是度量。谁会愿意被度量呢?这时这些“不良数据”的收集就会存在很大问题。 在我们公司,这些数据的收集分析都是团队自己来做的。比如


  • 交付速率,考虑velocity Cycle Time、Burn down、 CFD、上线频率等。
  • 交付质量,考虑需求质量、 Defect密度、单元测试覆盖率,code matrix等。
  • 交付能力,考察CI/CD 、团队行动项完成率(Action Item) 、自动化测试等。


将这些数据收集起来,然后团队可以自己进行分析评估和迭代。

《行-如何提高执行力》

上面讲了这么多标准,团队会照做吗?通常在团队中,开发只关注开发的工作、测试只关注测试的进度,而除了开发和测试以外,上面我们列了12项活动, 怎么保证团队按照要求和标准去做呢?这是一个难点。我们遵循的是分散决策、全员参与的原则。

四、制定各项规则的owner

image.png
举个例子,人民公社时期,实行集体所有制,国家的地集体种,全民吃大锅饭,那时有一个词“磨洋工”,出一天工赚一天的工分。很像现在公司里有的员工的状态,上一天班赚一天工资,用时间去换取报酬,积极性没有调动起来。
image.png
改革开放之后,实行土地改革,包产到户,农民积极性被极大地调动起来,短短几年时间,家家有余粮,还出现了很多“万元户”,国家也变得更加富强。
回到团队中,我们怎么激发积极性让每个人都承担起责任?方法是:制定各项规则的owner。 假如团队是7个人,每个人负责几项规则,负责这项规则的意思是你要按照规则的要求去发声、反馈、并提出或组织团队获得改进方案。
敏捷开发之前,上这些工作都是项目经理要做的事情,现在每个人都参与到了项目管理的工作中,切身体会到管理的工作,无形之中会促进团队成员参与的积极性,提升他们这方面的能力。
同时我们也会让这些owner进行轮转,这样一来,每个人都能熟悉所有的规则,当你对这些规则都很熟悉了,如果你去一个新的公司、新的团队,都会很有帮助,因为它可以很快构建一个高绩效的团队。

五、注重反馈闭环


5.1 构建数据驱动的反馈闭环


image.png
数据驱动前面介绍了,我们团队会主动收集数据,帮助自己回顾哪些做得好、哪些做得不好,因为 数据是客观的,团队做得好不好、是上升趋势还是下降趋势,都可以一目了然直观地显示。
从反馈闭环的角度来看,我们要及时检查;在站会上每日更新,站会上不仅要说昨天做完什么、今天要做完什么、有没有问题这三个问题,还要关注团队的各项活动质量并及时反馈;在回顾会总结改进,回顾会也要对这些活动有反馈,有问题提出来,及时进行总结和改进。


5.2 提高交付质量


image.png
举了例子, 假设目标是提交交付质量,怎么通过反馈闭环去实现这个目标呢? 首先要把迭代过程的相关质量数据收集起来,制定活动规则;之后开展活动,并在每个迭代进行数据分析;检查活动对质量的影响,是否符合设置的规则要求和验收标准;调整活动,根据数据分析的反馈结果进行改进和调整。

六、 行为工程模型-吉尔伯特

image.png
吉尔伯特,一位行为工程专家,上图展示的是他提出的行为工程模型。 团队绩效的影响因素分为两类:环境因素和个人因素,其中个人因素只占了很少的一部分,更多影响来自于环境因素。 比如上文提到的通过数据收集做反馈闭环、流程工具的使用和改进等,都会对团队交付带来很大的影响。


举个现实生活中的例子,春暖花开,大家都会出去玩,对于物业管理员来着头疼的事也来了,大家总是爱踩踏草坪。上面几张图分别展示了不同的应对策略:管理员站在那用大喇叭喊;在草地上立警示牌;设置小篱笆。很明显最有效的解决办法是第三个。这是典型的通过改变环境因素来影响结果。
人们常常会犯 基本归因错误,人们常常把他人的行为归因于人格或态度等内在特质上, 而忽略他们所处情境的重要性。

七、技控

image.png
上述例子中以人去干预的解决办法可以称为“人控”,增加机器或设施的办法则可以称为 “技控”,即选择简单有效的方法和工具,改变固有的行为模式,以提高绩效。很多时候通过“技控”的方式可以让事情变得更简单。
image.png
上图中列举了一些软件项目中的技控例子。比如会议步骤清单,很多人反馈说站会很难,开不好,要么是大家讲得不全、要么是讲得太多。其实很简单,开会的时候用几张牌,每张牌写一个步骤,就可以做到会议时间有保障、内容有保障;代码检查清单,在代码走读时也是一样,按照清单一项一项去看,然后交付就可以了。

总结


总结来说, 知行合一的敏捷实践要求做到:


  • 价值观的认同,团队成员要有一致的价值观。

  • 工作过程有章可循,定义好活动规则和检查规则。

  • 团队成员积极参与。制定各项规则的owner。

  • 反馈闭环,以数据驱动反馈闭环。

  • 技控,用机器和工具来解决问题。


内容来源:敏捷+社区线上直播003期,《知行合一的敏捷实践 》分享实录

分享者:道富银行敏捷教练杨贵 

登录后可下载附件,请登录或者注册

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区),文章链接,文章作者等基本信息,否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:huaweicloud.bbs@huawei.com进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。
评论文章 //点赞 收藏 0
点赞
分享文章到微博
分享文章到朋友圈

评论 (0)


0/1000
评论

登录后可评论,请 登录注册

评论

您没有权限执行当前操作

温馨提示

您确认删除评论吗?

确定
取消
温馨提示

您确认删除评论吗?

删除操作无法恢复,请谨慎操作。

确定
取消
温馨提示

您确认删除博客吗?

确定
取消

确认删除

您确认删除博客吗?

确认删除

您确认删除评论吗?

温馨提示

登录超时或用户已下线,请重新登录!!!

确定
取消