2.1 敏捷实践误区

团队接触Scrum一两个月后,往往自认为对Scrum的方法和流程已经足够了解,此时容易犯下几个小错误。但如果不能及时加以纠正,小错误将可能导致更大的错误,以致阻止Scrum或者其他敏捷方法的正常实施和组织的顺利转型。

1.越频繁变更越“敏捷”

进入这个误区的人不在少数,大多数人认为“快”就是敏捷,Scrum中的迭代周期如能缩短,团队将会更加灵敏。有些团队成员一边“享受敏捷的礼遇”,一边“开着小差”,觉得自己隔三差五给团队个交代就可以了。于是,想到哪里设计哪里,不和客户保持经常的接洽,更不会管理客户需求,只要是客户说的,无论成熟与不成熟都扔给开发团队。这导致了产品三天一小改、一星期一大改,这样的“Scrum”开发模式把团队完全弄懵了,还没明白过来是怎么回事,就被告知“进入下一个迭代了”,一边重复工作,一边又被灌输越“快”就是越“敏捷”。这种做法显然可笑,因为敏捷的增量型递增模型完全不存在,团队变成了“无头苍蝇”。

不得不指出,这种现象经常发生在互联网行业,这个行业的客户其实就是普通大众,对于一项网络功能,一半客户稀罕、另一半不稀罕是经常发生的事情。例如,针对网页中的Flash动画,如果询问用户,喜欢和痛恨Flash的差不多一半一半。如果不仔细观察和分析这类普通大众的需求,很有可能今天加一个、明天再去掉一个Flash,并且开始争辩哪种方式最好,既浪费时间又耗费团队的精力。

实际上,如果仔细分析,就会发现痛恨Flash的用户其实是不喜欢使用不当的Flash,那些大而复杂的Flash下载时间长,用户没有兴趣完整地观看。所以,设计过程中变化不可避免,但绝不要用“缩小迭代周期”、“短频快”的做法来遮掩设计的缺陷。

所谓“武功唯快不破”的只是小说,而不是敏捷开发。

2.“自我管理”等于“随心所欲”

我们鼓励自我管理是因为一线的员工比以往更聪明、更训练有素,我们发现员工的高效率来自充分明确自己的工作,并以最好和最省力的方式来实现。而且,员工在自己处理的问题时,往往表现出高度的集中和快速的提高。自我管理是授权给员工自己设定目标,将工作当做自己的事情来做。在一个高信任、低敬畏的组织里,员工不需要太多的监管,但是他们需要理解和支持,而不是“老板”时时在左右。

自我管理制度和“层级组织制度”针锋相对,在新的制度里我们不希望见到“老板”、“总裁”、“管理人员”的字样,这些高级头衔并不代表有能力“Lead(领导)”低级头衔。一个领导的影响力来自他展现出来的做事能力,以及作为团队建设者的卓越性,这类人往往为团队成功做出了较多的贡献。

但自我管理制度仍然有界限,无政府主义和滥用权力是不允许的。一个自我管理的团队是高效的管理系统,自由度不是无限的。美国的Whole Foods连锁超市,其最基础的组织单元不是门店,而是团队。Whole Foods的团队是零售业史上空前的自治团队。每个门店约由8个团队组成,他们对门店的各个环节进行管理,从食品加工到收银结算。按规定,每位新来的同事都会被分配到某一团队,经过4周的试用,团队成员投票决定这位新同事的命运——新同事需要获得2/3以上的赞成票以获得全职岗位。Whole Foods的决策者相信,关键的决策问题应当由那些受该决策结果影响最大的人做出,例如,雇用谁的问题就应该由未来和他共事的人决定。Whole Foods的团队绩效考核是透明的,绩效超过一定额度的团队得到更多的奖金;如果一个团队将一个懒散的成员纳入团队,他们下个月的奖金就可能减少!事实上,如果这些团队成员没能勇敢地站出来反对那些滥用权力的团队领导,或者没有否决雇佣低效率的新员工,就不算真正的自我管理。而这种高度的自治、自我管理方式向我们证实了一个道理:员工自我管理并决定自身的成败,而不由管理人员决定,自我管理绝没有变成“随心所欲”。

3.年轻的团队最有“创造力”

这是肯定的,但是,没有经过“培养”的新人,在没能判断其是否可以独立工作之前,不要急于让他上岗。对新人的培养、新团队的建设是绝不能忽略的。事实证明,入职过程很少能在极短的时间内完成,一般需要2~3个月,而IBM会用6个月完成新员工入职的一系列培训,包括法律法规教育、公司文化熏陶等。

当然,并不是刚入职的员工不能成为Scrum团队的一员,有很多刚入职的员工是明日之星,只是不能将工作放心地交予没有基础的员工。年轻的团队需要教练、需要引导、需要有经验的人带着走入这个有声有色的圈子,还需要理解流程、通晓团队中的各项职能、理解如何定义工作的“完成”,然后才有能力上岗。一支团队从组建到完全释放每个人的能力需要经过团队初建期、过渡期、风暴期和成熟期四个阶段。在IBM的几乎所有工作项目中,都有比较近似的团队初建过程,也就是团队成员在一起共同分享和探讨下面这些问题,确保所有人都做好了准备。

·互相介绍背景。

·给予团队一个名字。

·确定团队定期召开会议的时间和地点。

·分享团队的一般工作流程,介绍团队工作中的主要递交物。

·教会新人如何判断工作已经“完成”。

·建立团队的独立规则,例如请假需要跟负责人提前沟通等。

·如果需要,确定团队定期培训的时间和培训内容等。

任何团队都必须融入组织中。IBM的组织结构是矩阵式的,一般员工都有三个“领导”。第一个是行政经理,负责批复假期、做入职手续、离职手续。如果员工需要资源,一定要先找到行政经理,因为他离员工往往最近,没有人能够像他一样更好地支持员工,我们可以叫他“经理”。第二个是职能经理,负责员工的工作绩效考核,和员工一起制定工作季度规划、年度规划。员工要经常和职能经理保持畅通的交流,这样功劳、苦劳才会记载在功劳簿上,我们可以叫他“老板”。最后是员工所参与的项目中具备相同职能的一个“老人”,我们姑且叫他“Lead”或者“Technical Lead”,这个人身先士卒,极有威望。对于入职的新人,我一般都建议他们去学习Lead的工作方法:你看他怎么干,你就怎么干,一定没错的。

我们需要Lead参与团队的培养,Lead需要分出一部分时间来做团队的“领导”、“教练”、“老师”,学会时间管理和授权,让自己专注于更有价值的工作,而将执行和具体的操作交给团队的新人,同时做好以下几件事情:

·在老板和利益关系人面前代表团队做出承诺(例如工作时间、交付期、工作范畴),任何时候都不需要告诉老板和利益关系人你还需要和团队商量后再确定,第一时间代表团队做决定,要果决。

·监控团队的工作进度,最好是通过系统监控,不要在团队认真工作时打扰团队。

·如果出现问题,必须立刻参与进来,判断和解决主要部分,并将一部分工作交由新人来做。

·对团队新人需要经常表扬,必要的时候批评,棍子和糖都需要。

·分配工作,让每个人都充实起来,多给予员工支持。和新人的沟通一定要到位,不要简单粗暴,一定要让他们认为工作是可以承受的,才能够放心授权。

·经常帮团队申请资源,比如聚会、活动等,但是一定要让团队有机会展示自己。我的经验是,团队曝光率越高、占用资源越多对团队越好。

不过,对新人不能太“民主”,尚不能任由新人自己从Scrum的产品清单中选择工作项目。还有,和利益关系人的沟通也要一步步放开。这绝不是“反”敏捷,而恰恰是非常务实的经验之谈。让年轻人先将那些“天花乱坠的想法”收敛起来,虚心学习他人的智慧,懂得尊重前辈,不跳跃、不敷衍团队建设这个自然过程,才可以形成良好的团队氛围并奠定扎实的基础。对于年轻人来说,先学会“规则”,看到“边界”,虚心学习,这一切都将对他们的个人发展产生积极影响,他们会看到成长后将有更多的自由选择空间,包括喜欢的工作和喜欢的工作方式,也会期待将来的一天成为“Lead”,可以有“弟子们”的帮忙,做更有成就感的工作。同样,对于资格已老的团队员工来说,通过悉心帮助成长起来的新人让他们有更多的时间去做更有价值的事情,包括许多以前很难做到的事情,并带来成就感。而且,“师生关系”潜移默化地消除了“长江后浪推前浪”的不安,老员工心态会更平和,也能看到更远的人生。

总之,团队建设初期,或者新人刚加入团队的一段时间,建议经过培训和教育再参加Scrum工作模式。团队Lead扮演了重要的明星Scrum成员的角色,在团队中既要做导师、教练,又要在Scrum团队中承担工作。所以,一个比较好的组织方式是,Lead直接参与Scrum团队的各项工作,而新人在入职的一段时间里跟随Lead参与Scrum的所有活动,但是不发表意见,只做聆听者、学徒和主要的执行者,Lead会给出新人的一切工作安排并负责与其他Scrum成员和利益关系人沟通。

4.不了解项目的产品负责人

产品负责人(Product Owner)的主要职责是定义产品的功能,他的任务包括倾听用户需求、负责产品功能的规划等。后端的工作也需要产品负责人,如解决各种问题、处理组织关系、有效地和研发团队沟通产品的功能需求和设计等。产品负责人的问题是忽视燃尽图和整体产品研发进度的跟踪。“无论如何,那不是我的主要工作,团队负责人和项目经理、开发经理应该更关心燃尽图”,一个资深的产品经理甲曾经对我如是说。又有产品经理乙曾对我说:“产品负责人负责思考需要开发什么,而开发团队、开发经理负责如何开发,所以,燃尽图不是我的工作。”

不关心进展和状态的产品负责人很少有兴趣了解迭代的过程,也不了解团队当前遇到的问题、关心的话题、需要的帮助。所以,在迭代后期,会出现由产品负责人引发的不必要的需求变更。

不经常、甚至不愿意和团队保持通畅的沟通,因为那些对他们来说是浪费时间和效率的做法,与团队进行针对需求和设计的讨论对他来说也是对自己尊严和地位的挑战,因而,很难让团队能够“转身就可以和产品负责人讨论一个必要的细节”。相反,产品负责人更愿意一次性交付给团队全部需求和设计,同时给出详细的要求,甚至对自己的杰作有着另一种苛刻,细致到了“完美”的程度,而这样的需求和设计对于团队而言形同“一纸文书”。产品负责人愿意将和团队面对面的沟通回归到电子邮件或其他书面沟通方式,而这种做法深深地伤害了团队对自身工作的认可和参与新模式下研发工作的热情,团队会怀疑自己是不是真的找到了“为自己工作”的热情,面对产品经理,他们会觉得“低人一等”、“受人支配”。产品负责人“独立”工作的态度和方式也将阻碍“有深度的思想”传达到位,同时将增加团队内部的沟通成本并损失一定程度的工作效率。

显然,这样的产品负责人仍然会给自己找不少“麻烦”,倒不如保持平常心,把自己和团队放到一个水平面上,更多地关心和尊重团队。比如,认同团队在设计细节上有着更为精准的定位,在产品质量和验收上是更为直接的受益者和关系人。而且要关心团队进度,如果团队正处在峰值工作,应该避免给团队更多压力;如果团队正处在高效率、健康的工作状态中,可以将新的产品清单增加到迭代中。这些都需要产品负责人看懂各种状态的燃尽图,那么我们来了解一下燃尽图如何体现项目的状态和进展。

(1)发布燃尽图

在图2-1中,实线部分描述出实际发生的每个迭代所增加的工作量(用故事点计算工作量),实线的曲率表示开发的速度,即单位迭代所完成的工作量,曲率上扬表示增量开发继续在先前的工作基础上增加了新功能,曲率下行则表示以前开发的故事已经被放弃(虽然不愿意看到,但是几乎不可能杜绝)。虚线部分代表发布计划,表示对这个发布燃尽速度的大概规划,这条曲线只作为参考。图中第二个迭代完成的工作量落后于计划,这意味着以后的工作强度要比计划的大,或者计划部分的工作量有可能需要从发布计划中剔除掉。

00095.jpeg

图2-1 发布燃尽图

(2)迭代燃尽图

迭代燃尽图(见图2-2)即在一个迭代内标示工作量完成的进度,图中的虚线部分是每天实际发生的工作量,实线部分是计划燃尽曲线,这个图是用“减法”思考的,随着时间的推移(天/小时)曲线从最高点滑向“0”。

00098.jpeg

图2-2 迭代燃尽图

如果你是产品经理,燃尽图所表示出来的信息你能够都读懂吗?看看图2-3的分析,你就会明白了。

00101.jpeg

图2-3 如何读出燃尽图背后的故事

这张图是我在管理团队项目时的实际燃尽图,折线部分是实际发生的燃尽曲线,我们从上至下看看几个被圈出部分所代表的含义:

1)因为没有更新工作项进度,或者没有统计每天的燃尽工作量,或者工作量阻滞了,这个区域燃尽曲线是水平的。

2)当时间进展到周六、周日,大家通过加班赶上了原来被阻滞的进度,情况还算不坏,但看得出来大家很用功、很辛苦。

3)第3个和第4个圈出的区域显示曲线的下行突然被打断,而实际情况是并没有工作被阻滞,也没有忽略统计,结果只有一个,就是团队低估了工作项(Over Commit),在开始迭代的第二周,团队增加了对该工作项的评估工作量。

4)第5个圈出的区域有陡峭的曲线,这显然不合乎我们对团队工作能力和开发速度的认知,后来发现,这主要是由于团队对已完成的几个工作项有过高的估计工作量(Under Commit)导致。

5)第6个圈出的区域也有较陡峭的曲线,原因是在迭代的后期,大家担心时间不够,怕拖了团队的后腿所以真的非常用心,也非常高效,而且周六也确实在加班。

可见,产品负责人学习读懂燃尽图,对于团队的工作速度、能力认知非常有帮助,能够明白团队的辛苦,了解当下团队的工作强度,帮助产品负责人做出判断,何时“见缝插针”,何时“减轻工作负担”。

5.好大喜功

中国式敏捷很像盲目的城镇化。有些人简单地理解城镇化就是钢筋混凝土的高楼大厦和复杂的交通设施,殊不知城镇化是一项历史过程,伴随着物质和精神文明的进步,产业功能的转变,和住房、教育、工作、就医、资源配置等一系列变化。敏捷也不是简单地叠加众所周知的最佳敏捷实践,如测试驱动开发、迭代、持续化集成,更不可解释为更好、更快地开发产品。敏捷首先将项目开发中的资源优先配置在高价值的需求上,通过增量型的产出和验证使得产品以最快的速度进入市场并成功盈利,进而带来了一系列的沟通、技术、过程、组织的变革。这是一个历史过程,盲目模仿可能会得到最快的结果,但一定不是有生命力的结果。忽视敏捷转型过程,仍然过份强调效率、时间、成本,鱼和熊掌皆想得,甚至从原来一个月一次的发布变成像网页开发一样一天多次发布才甘心,这些都是中国式敏捷好大喜功的表现。过速的敏捷转型、盲目的跟从、不依附客观条件而妄想的敏捷世界让我们又要深思,为什么敏捷,敏捷是否有效,或者敏捷转型如何做到稳健且波澜不惊?