大规模敏捷已经开始,再不成为这样的管理者就晚了 | 极客时间

阅读数:2 2020 年 1 月 8 日 18:51

大规模敏捷已经开始,再不成为这样的管理者就晚了 | 极客时间

写在前面

你好,我是宋宁,现在在 IBM 做敏捷教练和咨询顾问。今天想和您聊聊“如何用敏捷开发打造一支无往不胜的团队?”

从一线工程师到管理者,从项目经理、Scrum Master,到现在的敏捷教练、咨询师,我经历过研发管理从无序状态到瀑布模式、敏捷模式,对各个管理模式的优劣深有体会,也从各个角度体验过敏捷。

这几年我在 IBM 做敏捷教练和咨询顾问时,我经常会思考 3 个问题:

  • 程序员的核心能力是什么?
  • 什么决定团队整体效率和交付质量?
  • 为什么华为、腾讯这样的大厂,这两年都在做敏捷转型?

当时我发现大多数公司团队成员,这里面不乏一些大厂的程序员,平时会刷题、懂算法、做架构、写代码,但对于理解需求、拆分任务、编写测试、高质量的代码实现——这些基本功,反倒不重视。

为什么有人产出低、有人产出高?为什么有 10x 程序员?我觉得效率低的核心原因就四句话:观念落后、固守陈规、埋头蛮干、不找方法,这是典型的螺丝钉思维。

有竞争力的开发者是什么样子的?

我最早接触敏捷,是源于一位做开发的朋友。他就属于那种效率极高的,大家一个礼拜的任务他 2-3 天就能做完,代码质量高 bug 少。最主要的是,他除了写代码以外,有足够多的时间研究新技术,指导其他同事,在团队中口碑极好,后来还研究上了管理,听说这家伙后来做了首席架构师,还兼任团队 Leader。

他有个习惯,每次写代码之前都会仔细想一想需求,想好后先写测试用例代码,再动手写代码。一旦写代码就特别快,一气呵成。

那时我偷偷问他,“你写代码之前还要写测试,多麻烦啊,怎么还能写那么快那么好?”他眨巴着眼睛,一脸坏笑:“代码写得快靠得是思考快,而不是敲字敲得快,构思好了再写不就是记录自己想说的话吗?再者,我先写测试后写代码,磨刀不误砍柴功,好多问题在前面都解决了。”

我再看他写的代码,简洁优雅,顿时羡慕得不得了。他告诉我,“这就是测试驱动开发,敏捷的核心技术实践之一。”他改变了我对程序员的认知,也改变了我对这项工作的认知,原来厉害的程序员不只是撸代码啊。

我一直热衷于探索研发管理的效率、效益和精髓。带着疑惑,加之当时公司也确有敏捷方面的需求,我从此开始研究和实践敏捷开发。刚接触的时候我觉得理念很好,但有些理想化,那时我并没有从内心接纳敏捷。

随着过程推进,我逐步感受到了敏捷带来的好处,尤其在团队管理方面,敏捷为我省去了大量的时间

以下内容出自极客时间《说透敏捷》,👉点击试读

如何打造一支活力与战斗力并存的敏捷团队?

团队是整个敏捷实践活动的根基,只有团队能有条不紊又高效率的执行敏捷实践中的每一项工作,敏捷才能发挥出它最大的效用。如果团队氛围不好、执行力不高,那即便导入了敏捷实践活动,团队也很有可能做不好。

在做试点准备工作时,我们已根据最适合团队交流协作的方式,对团队的组织结构进行了重组,那么重组后的团队就可以成为一支无往不胜的团队了吗?当然不是,你还需要想办法来唤醒、激发团队,让整个团队更有活力和战斗力。

敏捷试点中最重要的一步便是:打造一支活力与战斗力并存、无往不胜的团队。学好了这关键一步,不管你和你的团队采纳的是哪种敏捷实践,你都能在推进时得心应手、运筹帷幄,你的团队管理能力也会因此更上一层楼。

一起制订社会契约

我先来讲一个做法,叫做“社会契约”(Social Contract)。

什么是社会契约?它本指一个社会里的全体成员,为了更好地生活,定义了一些基本准则,大家一起来遵守。用在团队中,指的就是团队里的行为公约,也就是为了让团队中每个成员都能加强协作、发挥价值,一起来约定的一些基本准则。在工作中,如果有任何成员的行为影响了团队协作,其他成员都可以拿出这个契约来约束他,这样就可以“对事儿不对人”,在处理不良行为的时候更有说服力。

落地社会契约的过程,其实就是团队内部相互认可、磨合和协作的过程。那具体怎么来做呢?我认为可以将团队所有成员都聚到一起,大家一起来制定,只有这样,才能够充分征求每一个人的意见,让大家一致认可,并有充分理由一起执行。

首先,给大家分发一些贴纸,并给所有人 5 分钟的静默时间,让每一位团队成员思考这一个问题:你认为加强协作、达成团队目标,需要哪些行为准则?每一个人都要把自己认为重要的准则写在贴纸上,且一张贴纸只写一条准则。

写完之后,每个人把自己手中写好准则的贴纸贴到白板上,然后将白板划分为不同区域,把内容相似的贴纸归在同一个区域。

接着,会议的组织者逐条给大家读贴纸上每个人写的准则,询问大家是否同意,如果有人不同意,就停下来就此讨论一番,如果讨论的结果还是有人不同意,就放弃它;如果大家都同意,就将该准则保留下来。

这样进行一遍,把大家都同意的行为准则留下来,就形成了团队的“社会契约”。

你要注意的是,“社会契约”做完以后要张贴到所有团队成员都可以看到的地方,以便整个团队时时可以看到它,感受它带来的激励和约束。如果把它束之高阁,那就失去了它应有的效用,你的团队的协作也可能因此出现问题,进而导致敏捷推进的失败。

回顾会议,引导团队的自主性

在试点推进前制定“社会契约”,可以让你的团队形成一个约束和激励机制;那么在试点推进过程中,通过开展回顾会议,你的团队会形成一个引导机制,来引导团队的自主性。

在评估诊断阶段的调研访谈中,你已大体了解到团队的痛点,也根据痛点选择了相应的敏捷方法。那问题来了,敏捷方法里既有管理实践又有技术实践,推进顺序是怎样的呢?

一般而言,作为敏捷教练,我们自己会有一个自认为“正确”的推进顺序。但敏捷实践方法是团队来用的,行为和习惯转变也是团队要做的,而且我们也要打造自组织团队,所以相比你自己单纯地做口头宣讲,按自己的想法推进敏捷,引导团队自行选择和决定推进顺序会比较好,这更容易让团队认可和接受。所以重要的不是“你想”而是“团队想”,回顾会议正好可以完美地做到这一点。

怎么开展回顾会议?其实也很简单。

首先,要选一个大家都方便的时间,把会议时间固定下来。前几次的回顾会议可以由敏捷教练来引导,等大家对会议流程都熟悉了,就可以由团队的组长来组织。

会议开始后,先说明会议目的,接着让大家讨论三个条目:

  • 团队工作中做得好的地方是什么?
  • 做得不好的地方又是什么?
  • 除此之外,有没有什么其它疑问?

和制定契约的会议一样,先用五分钟时间让大家静默思考,然后把每一个点子都只写在一张贴纸上。将白板划分不同的区域,把相似内容的贴纸分区域贴到白板上。

接着一一讨论这些问题。做得好的地方我们在接下来的迭代中就可以保持下去,做得不好的地方大家可以一起头脑风暴到底怎么去改善,并做一些行动计划。对于有疑问的地方大家也可以互相提问,有些是敏捷教练需要阐释的,有些则是团队成员需要解释的。

这里你要注意,回顾会议是有时间盒的,一般不会超过 1 个半小时。在前几次回顾会议中,团队会提很多关于敏捷实践的问题,但我们的时间有限,所以如果问题几句话就能解释明白,通常我会当场解释清楚,否则我会安排专门的时间来和团队解释他们的疑惑,而不会把会议拖得过长,占用过多时间。

你可以看到,这个会议其实也有查漏补缺的功能,可以让你察觉团队成员在哪些方面有疑惑,或者哪些敏捷知识储备不足,后面你可以安排其它时间来帮助团队专门补齐。

以我带过的一个手机银行团队为例。在第一次回顾会议时,团队针对做得不好的地方提出“项目透明度差,只了解自己的工作而不了解其他团队成员的工作”,我就这个问题引导团队思考其背后的原因,之后团队一致认为主要原因是“没有地方和机会了解别人的工作”。我就势引导团队说:“大家觉得可以做些什么事情来改善这个问题呢?”最后大家讨论认为,不如约一个时间,每天定时定点地开个短会来共享一下彼此的工作内容和状态,这不就是“站立会议”吗?我们又一起给这件事情定了一个时间段:下个迭代。我领取了这个改进任务,在下一个迭代中为团队导入“站立会议”。

说到这你发现了没有,通过回顾会议来引导团队思考,所有的敏捷改进就不是我作为“敏捷教练”安排给团队来改进的,而是团队自己思考出来的行动。身为敏捷教练,我只需要将专业的敏捷知识和做法示范给团队即可,团队会更愿意践行自己主动思考出来的行动,这样,整个团队的行为和习惯就会转变得非常顺畅。

所以说,只要掌握了正确的方法,敏捷的推进并没有想象中的那么难。每个团队其实都有向好转变的原动力,我们只需要将它激发出来,并且告诉他们正确的行为规范,加以引导就好了。

成绩墙与错题集,记录团队敏捷的成长

有了契约的约束和回顾会议的引导,是不是就意味着在试点过程中,会一直一帆风顺呢?不会,你一定还会遇到些小波澜。因为团队也不会一直都正确地思考,也有犯错的时候,比如:

  • 团队为了赶进度,省略了部分测试,匆忙上线;
  • 迭代中间有业务人员向某个团队成员提出了新的需求,要求加到迭代中,团队成员不顾自己的研发产能,擅自将该需求加到了迭代中,最后却搞不定等等。

遇到类似这些情况,该怎么办呢?这里我不想教你具体的解决方案,而是想教你如何引导团队解决问题的思维。

如果这个所谓的错误并不会带来毁灭性的灾难,比如导致用户大规模投诉,或给公司带来巨大的经济损失,那么我会选择放手让团队去按自己的想法先做一做,即使碰个壁也未尝不可。事后我们再坐下来认真分析到底怎么做才是对的,引导团队想出新的解决方案。有了这样一个试错的过程,团队通常会将经验教训记得很清楚。

另外,配合着团队敏捷试点,我会让团队通过“成绩墙”和“错题集”在敏捷推进过程中记录自己的心情曲线,记录自己的喜怒哀乐,记录取得的成绩和错误,所以这其实也记录着团队的成长。

团队有任何大大小小的进步和成绩,我都会让团队顺手记录下来,贴在一面小小的“成绩墙”上。同样,我们也将自己遇到的问题和坎坷,以及解决方案也顺手记录下来,贴在另一面小小的墙上,构成一个“错题集”。这样团队成员时不时经过它,都会很生动地想起在我们敏捷实践的过程中都发生过什么。在敏捷试点结束的时候,我们也会把试点总结里成功的经验和失败的教训写到这里。

这样做有很多好处,首先团队会一直感觉到敏捷氛围的存在,有精气神儿;其次,以后有团队请我们去宣讲时,我们很快就能找到素材,也能绘声绘色地传达给大家;再次,团队记录的心情曲线、“成绩墙”和“错题集”,这些都是试点结束后在做总结时,记录团队敏捷成长历程的鲜活的素材,是团队敏捷实践的轨迹。

另外我自己在深入进行敏捷实践的同时,接触了很多国内的研发团队,这些团队的规模不等。他们的共同特点是很努力,但也存在很多问题。比如:

  • 初创团队,没有任何成熟的管理实践,想到哪里做到哪里,研发管理相当混乱;
  • 有的团队已经经历了前期的混乱,想着要正规一些,就倾全公司之力引入 CMMI,导入瀑布流程,导致整个公司流程过重,交付速度受限制,三个月甚至半年才上一个版本,业务部门相当不满意,项目团队成员也怨声载道;
  • 有的团队听说现在流行的方式是敏捷,于是拿书来看,自己琢磨,炮制了一套敏捷流程,结果根本不适合自己团队的业务模式。

作为敏捷咨询师,我给上百家公司做过分享和敏捷教练,目睹了各种各样公司在推进敏捷开发过程的疑难杂症,我一直想把自己的经验总结出来,帮助敏捷团队和个人真正解决实践中的痛点,于是我和极客时间团队决定打磨一个把敏捷讲透的课程。

现在市面上有很多关于敏捷的书,会讲一些基础知识和理论,但是敏捷毕竟有很强的实践性,只了解理论是不够的。以我个人的经历来讲,想要真正理解并接纳敏捷,你需要真实的案例来辅助你对它的理解。

鉴于此,我和极客时间团队一起打磨了你现在看到的《说透敏捷》专栏,我将结合实际案例来揭示这些年来自己对敏捷的研究和实践,手把手帮你定制敏捷实践计划。

👉点击「链接」,立即全方位了解敏捷开发。

评论

发布