第一次做“敏捷教练”

一位软件产品公司朋友找我,想在公司内部推动敏捷,让我帮忙做研发团队敏捷教练。这是四、五个月前的事情,不久前,团队终于在Scrum模式下完成了一款产品升级,尽管跌跌撞撞,但还是坚持下来了。我在过程中只参加了两次回顾会。
 
第二款产品比第一款困难得多,无论技术难度还是业务复杂度都不在一个量级上,团队里有一半成员经验丰富,另一半几乎是新手。经过商量,他们决定让经验丰富的成员带新手,将项目分成几个大的模块,每个人带一个新手领一个模块。PO和架构师都认为这样既能保证开发进度,也能保证质量,只是将八个人变成四个人的敏捷团队。是这样吗?
 
敏捷模式在达到交付目标过程中,与传统开发模式在策略上有一个很大的差异,传统模式是直接围绕既定的交付目标工作,而敏捷模式是通过最大化成员效率,实现最优的交付目标。传统模式下,项目经理为完成一次交付,会要求成员加班;敏捷模式下,Scrum Master为不断提高成员效率,禁止成员加班。靠加班,只能保证工作量,效率并不提升。
 
敏捷的交付策略是最大化个体效率,从而导致最好的团队效率,最终带来最好的交付结果,交付结果并不是固定不变、项目开始前就定义好的,PO/客户与团队的密切沟通和协作,是保证最优交付结果的前提条件。另一个方面,敏捷模式关注人,以个人发展为出发点,实现业务/交付目标。人的发展在前,团队的发展、业务目标在后。传统模式下,团队建设和发展会是个难题,因为团队建设为交付服务,成员发展并不是首要任务,成员甚至要为业务/交付目标做出牺牲。
 
回到刚才的问题上,我问其中一位经验丰富的成员,自己一个人做,和带一个人一起做,哪个更快?他想了想,说自己做更快。
 
我们已经知道敏捷团队关注个人效率,但只有独立完成工作才有个人效率。如果没有人带,新手怎么参与项目,怎么成长?目前他们甚至不能理解架构,靠自己怎样完成从设计到实施的过程?
 
眼前的方案,是团队里经验丰富的成员要先写完/设计好底层结构,再由新手完成剩余部分。如果要新手自己设计底层,就需要对架构有深刻的理解,并反复尝试不同的设计方案,直到最终完成,这可能会花10倍、20倍的时间/工作量。我们细想想,给10倍、20倍时间,让新手独立完成一个功能,和在别人帮助下,迅速完成这个功能,哪一个更有利于新手成长?
 
容许新手花费10倍、20倍的时间独立完成工作,是企业对员工真正的投资。急于让新手有所产出,出发点是保证交付目标,而不是人的发展。
 
从PO/客户的角度,他的目标是用最少的预算拿出最优的产品,培养新手不是他最关心的问题。企业应该有独立的预算和部门用于梯队建设和新人培养。
 
同样的,以盈利为目的来开展业务对一个企业看似天经地义,这与开发团队直接以交付为目标是一样,没有分清事情先后顺序。企业获得利润在最后,个人利益和发展应该在前。一个不断为个人发展创造机会,为客户创造价值的企业会变得更有生机和活力,把盈利放在后面,水到渠成。如果一个公司负责人整天忙于获得更多利润,他就会陷入自己编织的利润黑洞里,不能自拔。让公司每一位成员获得更好的发展,拥有更大的价值,在我看是更优的企业盈利战略,也是负责人应该花时间思考的问题。
Categories: 
up
0 users have voted.

Comments (2)

敏捷过程应该以人为主,相对于过程规范来讲,这点更难做到~
通过这个游戏可以提升你的英语词汇量。 每天只需要玩几分钟就能够提高你的英文发音。你把每一个类别学好了之后一定可以在短时间之内把英文学会。 Visit for Click here: - http://www.xuexiyingyu.cn

Add new comment