敏捷转型的困境与解决之道(立青 阿里巴巴)

敏捷转型的困境与解决之道(立青 阿里巴巴)

为什么采用Scrum敏捷?问题驱动。我们的按时交付率低。我们基本上除了开发,测试、UI都是根据项目需要临时调用的。这些人做事情都是为了完成任务,完成KPI的。他来了不关心你的产品好坏,因为他们是跟项目走的,所以他们可能身兼多职。

环境适宜:我们觉得当时业务的压力没有达到不能做转型,我知道有些团队的压力大到无法做其他任何的转型,有些公司接受不了的。第二个是研发负责人很认可敏捷。我的环境还是比较适宜做敏捷的。

SPI影响力:我们的影响力,我们的能力,都是适宜做敏捷的。

2012年找了几个团队做试点,2012.5大面积实施,200多人80%双周交付周期,按时交付率翻倍,协作满意度提高,2013.3我们也在尝试持续集成,精益创业,看板,Impact mapping等很新的东西。未来,我们不知道,但是肯定继续往这条路往下走。

一些思路,主要是围绕人,主要让人有能力适应这个变化,四个维度。

管理者:起到差不多是决定性的作用。我们如何搞定他,1.利益需要绑定。需要找到管理者和这个事情相关的利益点,你绑定后他就care这个事情了。我们当时研发中心的老大刚来这个组织,当时业务团队对研发团队不认可,他需要解决这个问题。研发总监、测试总监需要老大对他们认可,我们就把他们30%的KPI绑定了。我觉得KPI是一把双刃剑,因人而异,有些人要用这个来约束的,有些人过于使用会约束他的。所以不是所有人都用KPI绑定。2.消除顾虑。你动了的他的奶酪,或者对这件事无信心。首先我们是晓之以理动之以情,者还不够,有时候我们还拉着老大和HR,我们叫HR是政委,它的职能是很大的。如果这个人还不和你一玩,我们就冷处理,不带他玩,等到大部分都玩起来,他回来找你的。我们会给他些数据,让他知道这个是切实有效的。让他们眼见为实,或者口口相传。还有就是,外来的和尚好念经,所以我们回去请外部的培训顾问,别家公司怎么采用敏捷,有什么效果老消除他们的顾虑。3.引导期望。有些人对SM的理解是他是以后管理的接班人,然后领导就隔段时间换个SM,去验证他们是否有这样的领导潜质,这对敏捷是致命的啊!他们根本不懂敏捷!我们会把他们的期望引导到合适的位置上。4.深度参与。我们成立了一个虚拟的转型社区,这是组织层面,在每个产品线里,一旦遇到问题,我们都会去找负责人去制定方案,让他们有责任感。

PO:1.利害关系。我们遇到一个问题,很多产品经理在杭州,有的在北京。很多产品会,总结会,他们就不愿意拆。有些人我们是说服,能搞定。但是总有大部分人,搞不定。后来还是拿了KPI这把刀,我们Scrum考核机制挂了他们30%的KPI。2.培训+手把手。树立典型,他们自己写一些敏捷管理的文章,我们就大肆宣扬。不能光做培训,培训完了他们能否落实,所以还是得手把手地跟进。3.建立氛围4.交流与共创。可能有的时候,他们自己之间相互交流就能产生火花。

SM:1.找对人!我们可能没有权利去选PO,但是我们有权利去选择SM。这个人的EQ一定要很高。这个很多东西不是硬技巧,而应该是软实力,他的情商应该高。我们再找人的时候也出现问题。2.利益保障。我们的SM原来都是开发、测试,没有专职的SM,他们是额外的工作做的工作的。那么能否保证他们的利益呢。所以我们考虑他们的晋升渠道。第二点有些人很在乎他在公司的影响力。发在内部社区发的文章,我们会置顶。还有就是抓骨干和典型,他有意愿做敏捷教练,我们会重点培养。可能每个人的诉求都不一样,但是我们会尽量去满足他们的各类需求。3.培训+手把手。4.建立氛围。5.交流与写作。你学完一个东西,写下来,和别人交流,甚至讲给别人听,才是你学习最快的方法。我们把大部分的SM的文章汇总,形成一本小书。

团队成员:1消除顾虑。动了他的舒适圈了,有的同学都不愿意搬,尤其设计师,我不愿意开什么会,我需要独立的空间。我们要改变他,而不是适应它。我们组织不会给他提供这种舒适圈的。开始的方式是我们拉着管理层和HR政委去找他们。有的人走不出来,我们就冷处理,残酷点就是“干”掉,实在是我们帮他了,如果他还没有改进,就必须处理掉。这也许很残酷,但是为了大部分人,必须这么做。最近我们管理层有个这样的声音,所有没有被执行的ACTION都是耍流氓。很多时候我们说好的事,但是后来有人违反了没有人去关了,那么大家就灰心了,不想和你玩了。2分阶段培训。我们让他们知道组织一直在做这件事情,我们在每个团队启动的时候,对会去培训的。但是也就半天的时间,内容很多可能两天都说不完,所以我们一直用分阶段的培训,让他们在实践中落实和学习。没有在开始的时候就让大家高度认识一致,都是在经过几个月的磨合后才有一定的默契。

组织氛围。成功案例宣传,树典型人物,我们会让优秀的SM交流经验。抓住关键时刻,有些关键的时刻,比如年会的时候,老大是不是提到了Scrum团队了,有没有奖励Scrum啦?奖励了多少的奖金啊!?这是很多人都在听着看着的。管理者导向,站立会的时候,管理者有没有提高这个事情呀,有没有在一些细节上引导大家实施啊?

实践演示。

Agile社区。有几十篇文章,平均每篇文章阅读在200左右,大概是每天1000字。比较成功的是上次我们带领大家去参观海底捞的站立式会议的一片感悟文章,阅读量600多。我们做了半年的报告。年终报告。平均的延期率降到了15%。我们还设计了打分表。我们最后给大家送了4到点心。

旺旺:立青

邮箱:

 

问:使用看板基于什么目的和背景。

答:开始我们对看板不了解,我们在想他是否适用我们。我们在使用Scrum的时候,他不是能很好的判断对这个团队的阻碍,不如看板。所以我们想说,现在一个小team去尝试使用看板,也在摸索。我们在业务那边也会做精益创业。阿里有很多业务部,不可能有一个方法打通所有的。所以我们希望每个团队都去找一个合适自己的方法。

 

化繁为简,一矢中的:度量组织级敏捷成熟度(黄方 CISCO)

我是贫苦出身,我原来是也是写JAVA代码的。我在外企工作2年,在国企工作5年,有两次痛苦的经历,一次是CMMI3一次是CMMI5。我是04年的PMP,08年开始转敏捷,我们的全球化是很厉害的,最多的团队跨越了7时区。我所处的组织在中国超过3个城市有1500个工程师。

我们转型快两年了,很多人都在问一个问题,我们到底敏捷没有啊?或者我们敏捷到什么程度了?所以我找了很多人去问,去美国,在中国。这里给出一个词单。有句话很重要,就是Deliver real products every Sprint.这个在我们访谈里每次都会出现。但是80%的Scrum团队都做的不好。

如果你形式做的很好,但你短期内一个UserStory都交付不了,你依然是假敏捷。虽然你一次Scrum会议都没开,但是你短时间内可以不断交付产品,那你就是真敏捷。我去美国出差,很多小公司都是被思科收购了,因为怕他们成长起来成为竞争对手,我去调研他们。没有任何敏捷认证,没有任何敏捷培训,但是他们是真敏捷,他们每天自动往你手机上推送两个版本的发布。

作为一个敏捷开发工程师,应该可以每个几天发布一个版本(DevOps)开发,运营。

我们的度量:UserStoryCycleTime

我们很习惯CMMI成熟度模型有没有。

问:复杂度的问题

答:敏捷是一个非常好的工具,是发现问题,而不是解决问题。敏捷是一个逆向思维的方法论,当你尝试用Scrum解决问题,就很困难。

问:你这个度量里边有必要加入运营么,因为很多ScrumTeam主要按开发任务来分的。

答:如果Scrum开发团队可以开发完成,但是运营团队没有时间,堆积起来所以这个也不是敏捷的方法。所以我们必须要加入后边第三段的运营。

posted @ 2013-09-06 11:46  tonybom  阅读(612)  评论(1编辑  收藏  举报