Scrum之成败——从自身案例说起,仅供参考

从07年中初次接触Scrum的概念到其中几年项目中逐渐实践CI、TDD,到亲自掌握项目实践Scrum近一年,最终我们放弃了Scrum这个框架和所谓的“自组织”。原因为何?

 

1.成员放弃了Scrum所“赋予”的“权利”

比如领用任务、评估工作量、自组织协作、决策等。在第一次Scrum计划会议上排出任务让大家领用时,成员的态度可以用“反感”来形容。在经历四个Sprint后成员依然坚持认为,应为PM完成这些工作,故放弃。

 

2.团队成员能力参差不齐

我很主观地认为,现在国内的开发团队都会是一部分高级工程师搭配一部分初、中级工程师,这种搭配本身就决定了领用任务时的混乱,尤其是团队中一部分成员极度渴望去做那些自己没有经验的任务。结果造成一部分人一直搞不清楚自己在团队中的定位,一直处于“费力不讨好”的挫折中。高级工程师对另一些成员的效率、成果也颇有微词,对团队分工非常不满。

 

3.没有清晰的设计阶段是造成上面第2个问题的另一个因素

众所周知,敏捷倡导演进式架构,其本质是,在目标不确定性极大的情况下,通过一次又一次短周期的反馈修正来不断接近目标,固在敏捷中,每项任务、剩余工时、成本燃尽,控制得如此之细,CMMI根本扛不起这样恐怖的基线变化次数。取消清晰的设计阶段,以及采用大量并行的测试,可谓敏捷的一种取舍,赢取更短的发布周期。也正因为如此,在任务分解时,无法清晰地定义设计任务,而将其混杂在功能化的任务中,事实说明,这里有大量的重复工作并且交付良莠不齐。

 

4.高估了工程师的成熟度

敏捷对工程师的心智有过高的要求。为什么说是过高?其实,在公司里担任高层管理人员的,恐怕都不具备成熟的心智,何况处于一线年轻又尚轻的程序员?现在的程序员,从学校或从培训班子里出来,人际圈子小,知识面狭窄,遇事仅能从自身考虑,常常因生活中一些事情影响情绪和工作,遇到难题就放弃,全力投入到项目开发中来的,并不多见。所以,在项目和开发过程中,监控、管理,催促、激励甚至批评,是必须的!

 

5.Scrum缺乏领导者

Scrum把团队想象得太完美了,如果有完美的团队,开发方法根本就不重要。工作、项目在进行的过程中,必须会遇到困难、遇到卡壳、团队发生冲突和争吵,这时候,必须有一个人挺身而出,作出决定,解决问题,为大家指明方向,平息争端,警告不利分子,这个人只能是领导人物,能力、权力和职位比团队成员高的人。扁平式组织,想象得太完美了,团队里各种性格的人都有,不服你不爽你的也总有人在,吵个没完没了,各做一套,家常便饭。

 

最后我想说说Scrum适合的团队,这样的团队需要有一些技术成熟度比较高(五至八年经验)、并且比较稳定地做技术的成员,使用Scrum可以使团队日益默契,并改善技术团队沟通交流不善、积累反思不多的常见问题,基本上,Scrum的正面意义在于,以前的项目管理、开发管理都只注意到了需求、技术、测试等机械性问题,而Scrum把团队管理、团队建设的思路引进到了技术团队。而在这个范畴里,Scrum还比较轻量级,它的回顾会议在工业产品开发中随处可见,可作入门指南,大家会问,进阶怎么走?我想未来软件开发团队的路子会和工业产品相似,渐渐地把决策过程、分析思路引进到团队中,这样子的团队才真正是一个“工程师团队”。

posted @ 2011-05-17 10:16  Justina Chen  阅读(5524)  评论(49编辑  收藏  举报