敏捷开发就是一场多人运动

发布时间:2020-06-16

说到敏捷软件开发,很多人对各种名词如数家珍,从自组织团队到回顾会,从渗透式沟通到每天15分钟,从“个体与互动高于流程和工具”到“给客户演示已完成的功能”。但,有没有人想过,敏捷开发本身,其实是一种多人运动?

没错,多人运动。但不要误会,这种多人运费并非要大家去挑战极限,而是需要大家通力合作,这点请一定要记住。

1.jpg

过分计划的不可信

敏捷与瀑布最大的不同在于,瀑布中,研发人员不是人,而是没有感情的编码机器,所有研发人员的工作,都在WBS(工作分解结构)中已经明确定义,并且下一步还被拆成了动作(即一个人可以独立完成的工作),并且根据对动作的估算、排序后,得到一个项目进度网络图。对研发人员而言,他们只需要成为这个链条上的一个节点,做好这个节点应该做的事情就行。

这里可以看出来瀑布的做法是“用局部拼成全貌”,即认为只要局部做好了,根据原先的计划做下去,就能得到我们想要的全貌。而且这里还有一个很重要的观念,就是监控(monitoring and controlling),这是我们下面需要好好讨论的。

瀑布中的监控,一般是监控所谓的基线,即当极限发生改变的时候,我们就需要开始走变更管理流程。

那这里到底说明了什么?这里表明的是一种线性关系,即因为“基线变了”,导致我们需要“走需求变更流程”。如果再深入下去,你会发现各种线性关系无处不在,常见的有这么几种:

1、因为A延期了,导致B延期了,最终整体延期

2、因为需求增加了,所以时间成本需要增加

3、因为某人离职了,所以我们要从其他组招人

如果要继续找,我能找出更多出来。我相信这些也是大家往常都听到过类似的话语,并且不少人也会同意。

但这真的对么?

局部看其实都是对的,因为A延期了,而B依赖于,所以B延期也是正常的。其他的也是同理。但这并不能在更大语境中(比如整个项目中)得出相同的结论。

1、A延期了,那么我们是否有办法可以削峰填谷、资源调配或者其他方式,来帮助我们加速B的完成,从而确保B按照原定计划完成?

2、需求增加了,我们有没有办法砍掉一些不那么重要的需求,确保需求总量的不变(这里只考虑产品研发,不过多考虑项目研发,项目的做法不太一样,因为项目的变更是可以伴随更多的成本投入的)

3、某人离职了,这部分工作能否不做?能不能有更简化的方案?能不能用开源方案?能不能直接外采?

这说明了什么?为什么我们说的好像也很有道理?

这说明了将各个局部加在一起,不能认为等同于整体。之所以有“多个局部相加就是整体”的错觉,是因为瀑布模式,在一定程度上降低了人的作用,将研发人员工作安排的明明白白后,虽然减少了不确定性,但也让研发失去了主动推动的激情,那么当遇到问题的时候,自然而然就会根据“原先设定好的方案”往下走就行了。啊,你说走不通?哦,那不管我的事情,那是你的计划没有做好。我们就是写代码的,根据你安排好的做就行了。

通过绝对的计划,对项目永远只能做到管中窥豹。影响项目交付的点太多,想要通过计划完全控制,怕是不现实。这也是上面的情况出现的根本原因。

1、张三跟李四打配合,昨天他们吵架了,今天他们是否可以根据计划工作?

2、研发做好了,测试的用例写完了,我们是否就可以根据计划进行测试?

3、代码测试完成了,集成测试完成了,是否就就意味着马上就可以上线了?

如果你的回答都是“可以”,那么这就太理想了。吵架了还能好好配合,这种可能存在,但你将这种小概率事件放到项目中,本身对于风险管控是不足的;测试如果昨天晚上吃小龙虾拉肚子了,今天去医院输液了,你是不是准备将笔记本给测试送到输液室?你们公司外面在施工,不小心光纤挖断了,你们公司所在园区网络直接断了,你准备怎么上线?打开4G热点上传么?

有人会说——你这个太极端了。是,我承认太极端,但是你是否敢说这个绝对不会出现?大概率是你不敢。而实际情况将会比这种想象的复杂的多,这也是更加不可控的原因。我就没有必要再加上诸如商业环境变化、人员变化、心情变化、丢数据、跟老婆吵架这种极有可能发生的、非小概率事件了。

因此,我们基本得出了“过分计划”的不可靠性。毕竟,项目环境中,很难可能是一个线性的,这就让过分详细的计划(包含了监控)的可信度大打折扣。抛开计划的成本,就是变更的成本都能让你哭。

个人与互动 高于 流程和工具

既然过分计划不可信,那么我们该怎么办?

《敏捷软件开发宣言》早就给出了答案,那就是:

个体与互动 高于 流程和工具

                                            敏捷软件开发宣言

而且从其手稿来看,这条在宣言中的位置都没有改动过,而其他三条是改动过的。这就给我们释放出了一个信号——这条很重要,非常重要。

2.jpg

为什么个人与互动可以解决问题?

与瀑布相对,敏捷一直提倡“价值交付”,即我们需要交付给客户的是价值,而不是过程。所以一开始,我们就可以聚焦最终的重点,让团队进行了聚焦。

而后,敏捷并没有规定所谓的标准流程(SOP,Standard of Process),而是用了“自组织团队(Self-Organized Team)”将过程完全托付给了研发团队,通过一线的员工,在边界内(敏捷的边界是价值)适当使用自己的权力,而不对其作出过份的约束。

这种做法的好处是很好的规避了一些所谓管理者(姑且认为Project Manager是管理者,虽然根本不是)无法解决,或者说无法通过一己之力解决的问题。比如上面我们举得三个例子中,项目经理到底是要做多少的计划,才能预见到有人会食物中毒,并且还得找出对应的应对方案!

那么我们该怎么做?如上所述,将这个职责,连同对应的权力,全部交给团队,即自组织团队中,团队决定怎么做(How)。这就让团队有动力遇到问题的时候,主动去处理而不会遭受太多的约束。这不仅可以让团队更有动力,也让团队在一定范围内可以发挥更大的创造力来解决问题,甚至有些方案都是我们想不到的。

拿我最喜欢做的“意面棉花糖”游戏,如果你限制了团队只能用现有资源,我见过最高的记录是1.2m,但一旦我将约束去掉,让团队可以找他们能找到的任意资源的时候,这个成绩最高直接跳到了3m之上。这恐怕可以说明一些问题。

而如果我们再深入到具体的技术细节、沟通细节,PM 就更加鞭长莫及了。甚至已经是不可能再给出任何具体的建议了。而团队由于身处其中,所以他们才是最有动力解决问题的人。一旦这种权力授予后,团队的沟通交流、互动将会大大增加,且各种方案层出不穷,甚至我还见过团队成员从其他团队找来外援帮助我们的情况。这些都让我对“个体与互动”对团队的解绑以及赋能过程,赞叹不已。

除此之外,再回到项目中各种不确定因素以及这些因素之间的相互影响来看,团队互动一旦产生,这些因素带来的不确定性其实也就不值一提了。在人与团队这种究极复杂体面前,所有其他复杂因素,都是小儿科。我们做的,不过是使用了更复杂的系统(人和团队)来对抗复杂(项目环境),从而获得在项目管理中的成功。

结论时间

敏捷中最强大的武器,毫无疑问就是“个体与互动”,这个做法让研发团队可以更好发挥其潜力,进而利用这些潜力来对抗项目中的不可控因素,从而让我们对项目的结果更有信心。

并且敏捷也将软件开发工作返璞归真,让真正的建造者(研发人员)参与进来,并且鼓励创造者之间多多交流,通过自组织团队实现成员间的多人运动(嗯,沟通也是一种运动),从而发挥团队潜能并交付更多的价值。

迈开你的腿,张开你的嘴,把这项多人运动坚持到底。


Copyright O 2020 All Rights Reseverd Designed by Sthspace.net PICPE150170198-1