Scrum之成败——从自身案例说起
 

2011-06-14 作者:Justina Chen 来源:网络

 

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

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

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

Gopher的评论:

你缺乏对程序员足够的培训,为什么要切分任务、评估工作量,对比以前,我们需要解决什么问题?为什么人家会反感,估计是开会前缺乏足够的准备,PO自己都解释不清楚需求,慢慢的会议发展为头脑风暴。并且会议主持人对这种明显超出讨论范围的乱象并没有及时制止。

所以,结论是:1、你自己都没搞清楚为什么搞敏捷。

2、因为你没有搞清楚,所以你缺乏实施敏捷的路线图。

3、因为没有路线图,所以在人员选择上,你找了一群没有“敏捷人格”的人来做敏捷。

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

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

Gopher的评论:

根据团队的velocity,我们通常会对需求的粒度进行要求(这点也是我们敏捷QA的度量目标)。在确定需求粒度之后,任务切分肯定是全体团队成员一起进行的。如果有Issue,就记录并落实Issue责任人,同时解决Issue也形成任务并需要评估时间。当然,长官意志必不可少。

摆明了这人承担不起这项工作(解决Issue都有问题)你也让他选?找死!

摆明了这人面临的任务有多个待解决的Issue(导致团队工作延后)你也敢让他做,找死!

能力参差不齐不是关键,关键的是,scrum master缺乏控场技巧和领导力。这样的水平,当PM都成问题。

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

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

Gopher的评论:

首先,CMMI的基线并非通常意义上的敏捷的“广泛认可”或“增量输出”。所以CMMI在配置管理和质量管理的基线标准不会定义得如此变态。

再次,“清晰”是相对的,在我们的公司里面,一个成熟的敏捷团队,不用将任务粒度划分得过细。而一个才成立的团队,任务粒度几乎就是流程图级别的。当然,无论资深还是新手团队,Scrum Master必须是资深的。

最后,你的团队无法“清晰”的定义任务,要么是PO没有做到位,要么是成员不了解需求。对于团队中的资深的“个性”程序员,那么,尊重他们个性好了。也就是我说的,长官意志。

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

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

Gopher的评论:

在我的实践经验中,这种人最好培养。你们不会是因为成本考虑找的实习生吧。如果团队都是高手,我想这种团队,无论CMMI还是敏捷都不重要了。

5. Scrum缺乏领导者

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

Gopher的评论:

会议主持人能力相当重要,并不是每个人都可以做Scrum Master的。争论,是我最喜欢看到的情况。有分歧才有争论,有争论才有更详细的任务目标。关键是,你真的尝试过去引导争论并使之切题?

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



由外而内看敏捷软件开发
架敏捷开发中史诗故事与用户
看板任务管理
面向全球化的有效敏捷交付
小型团队快速开发方法
DevOps,不是一个传说!
更多...   


统一过程及应用
敏捷过程实践
基于XP/RUP的迭代开发
软件开发过程指南
SCRUM过程实践
敏捷测试-简单而可行


某博彩企业 产品经理与产品管理
北京 研发团队与工作管理
广东金赋信息 敏捷开发过程与项目管理
某支付平台 软件配置管理与发布管理
富士 软件外包项目管理与进度管理
塞孚耐 基于Scrum的敏捷开发
更多...   
 
 
 
 
 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号