【AICon】硅谷视野+中国实践,汇聚全球顶尖技术的 AI 科技盛会 >>> 了解详情
写点什么

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

  • 2020-01-08
  • 本文字数:4463 字

    阅读完需:约 15 分钟

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

写在前面

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


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

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

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


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


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


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


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


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


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

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

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


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


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

一起制订社会契约

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


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


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


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


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


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


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


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

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

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


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


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


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


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


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


  • 团队工作中做得好的地方是什么?

  • 做得不好的地方又是什么?

  • 除此之外,有没有什么其它疑问?


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


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


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


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


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


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


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

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

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


  • 团队为了赶进度,省略了部分测试,匆忙上线;

  • 迭代中间有业务人员向某个团队成员提出了新的需求,要求加到迭代中,团队成员不顾自己的研发产能,擅自将该需求加到了迭代中,最后却搞不定等等。


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


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


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


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


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


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


  • 初创团队,没有任何成熟的管理实践,想到哪里做到哪里,研发管理相当混乱;

  • 有的团队已经经历了前期的混乱,想着要正规一些,就倾全公司之力引入 CMMI,导入瀑布流程,导致整个公司流程过重,交付速度受限制,三个月甚至半年才上一个版本,业务部门相当不满意,项目团队成员也怨声载道;

  • 有的团队听说现在流行的方式是敏捷,于是拿书来看,自己琢磨,炮制了一套敏捷流程,结果根本不适合自己团队的业务模式。


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


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


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


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


2020-01-08 18:573493

评论 1 条评论

发布
用户头像
广告文
2020-01-08 18:59
回复
没有更多了
发现更多内容

【架构师训练营第 1 期 11 周】 作业

Bear

极客大学架构师训练营

【架构师训练营第 1 期 11 周】 学习总结

Bear

极客大学架构师训练营

性能优化 - 学习总结笔记

Xuenqlve

Week 11 學習總結

Judyyy

架构师训练营第十一周作业

文智

极客大学架构师训练营

架构师训练营第 1 期 -- 第十一周学习总结

发酵的死神

极客大学架构师训练营

第二周课后练习

Binary

极客大学架构师训练营

Week 11 作業

Judyyy

架构师训练营第 7 周课后练习

菜青虫

极客大学架构师训练营

Spock单元测试框架实战指南二-mock第三方依赖

Java老k

Java 单元测试 JUnit spock

「架构师训练营第 1 期」第十一周作业

张国荣

第七周大作业

小兵

架构师训练营第 2 周学习总结

Binary

极客大学架构师训练营

架构师训练营第十一周学习总结

文智

极客大学架构师训练营 架构师一期

架构1期 第十一周作业

haha

极客大学架构师训练营

Architecture Phase1 Week11:HomeWork

phylony-lu

极客大学架构师训练营

架构师训练营week11总结

FG佳

架构师训练营 1 期 - 第 十一周总结(vaik)

行之

极客大学架构师训练营

第 7 周作业

Steven

极客大学架构师训练营

第十一周作业

wanlinwang

极客大学架构师训练营

架构第十一周总结

Geek_Gu

极客大学架构师训练营

Week7-性能优化-总结

Sean Chen

架构师训练营第 1 期 week11 总结

张建亮

极客大学架构师训练营

架构第十一周作业

Geek_Gu

极客大学架构师训练营

架构师训练营 - week11 - 作业

lucian

极客大学架构师训练营

架构师训练营week11作业

FG佳

极客大学架构师训练营

第七周作业

hunk

极客大学架构师训练营

第七周-总结

jizhi7

极客大学架构师训练营

第七周作业总结

hunk

极客大学架构师训练营

先从哪里开刀-组织形式还是制度安排

luojiahu

组织思考

架构师训练营 1 期 - 第 十一周作业(vaik)

行之

极客大学架构师训练营

大规模敏捷已经开始,再不成为这样的管理者就晚了 | 极客时间_语言 & 开发_宋宁_InfoQ精选文章