微信号:grzlwx

介绍:光荣之路官方资讯

敏捷不能当饭吃

2015-07-21 21:41 光荣之路



喜欢敏捷的很多想法,喜欢它务实的态度。我说“敏捷不能当饭吃”,当然不是说敏捷无用,相反,我倒是挺推崇敏捷的。之前有两篇文字都涉及到一些对敏捷的看法。一篇是与神对话,另一篇是对敏捷的一些想法。只是看到很多人好像敏捷是他爷爷写的一样,龟孙子似地迷信和追捧敏捷,把工作一条一条跟书上描述的对照,一旦工作中实际操作跟书上有不一致,口诛笔伐,吐沫拳头无影腿就一齐上来了,那就太过了。敏捷跟太极拳一样,是一种思想精髓,它的一招一式体现在实际工作中灵活运用敏捷原则,敏捷并无特定套路。Scrum等流程是敏捷的一种成功案例,这个案例在特定环境下工作得非常好,但那只是特定环境而已。敏捷大师们自己也总提醒,很多项目采用敏捷开发,仍然一塌糊涂,是因为应用敏捷并不简单。

KentBeck是敏捷的发起者之一,很多敏捷的发起者后来都写了关于敏捷的书,但KentBeck的书是最有影响力的,它的Extreme programming explained – embrace change可以在这篇博客中找到。这本书主要阐述敏捷的一系列理念,对实践描述的并不具体。scrum之类讲敏捷流程的书,对实践操作的环节就会讲的很具体。先了解并接受敏捷的理念,再去看敏捷流程的话,比较容易理解流程背后的用意是什么,只有深刻理解了敏捷精神,才能比较好的实践敏捷。而现实情况很多时候不是这样,直接学习流程总是比较省事儿,于是scrum就被当成圣经直接拿来就用了,人家mc hotdog早就说过,“照单全收的盲从,就像在吃屎”。我相信通常情况下,scrum的实践在一个项目组,只有一小部分能用得上,当然,这已经是件很伟大的事情了。在一些常见的工作环境中,有些scrum的想法并不适用。

一个方面是,scrum强调“全功能团队”,每个人了解产品的每一个feature;团队人数在敏捷中是有限制的。但如果一个负责某个产品的团队就是有12,3个人,那么怎么办?再拆成两个敏捷团队以适应敏捷对人数的要求?垂直划分feature提供了细化团队的机会,但产品不总能清晰地一刀切成两半,尤其还要考虑各个程序员有不同的专长,甚至根本用的不是同一种编程语言,如果团队只有一个c程序员,一个js程序员,一个pl/sql程序员,其他做java,那么切分项目组的方式是跟c有关的一组,跟js有关的另一组?底层架构和公共模块都不容易竖切。如果产品比较大并且不易细分,大家都了解每个feature是很难做到的。如果产品使用的技术比较繁杂,pl/sql,js,java,c样样都用,全功能团队怎么实现?js的程序员跟c程序员也讲不到一块儿去啊。我可以理解scrum的想法,也认同它的道理,但是在实际工作中,如果确实人数对不上敏捷的要求,或者程序员的技术特长分散在不同层面,这很难照搬scrum的实践。人多开会费时间,效果又不好,鸡同鸭讲,各说各的。写c的人才不关心js有什么技术瓶颈呢。

还有,scrum想了个招儿,用打扑克的方式沟通需求和帮助定schedule。这是建立在全功能团队的基础上的,上面已经论述过了,如果产品比较大,程序员没法兼顾所有story,那成本太大了,打扑克也只能流于形式,尤其术业有专攻,唯一的c程序员的工作只有他自己估计才有意义。更实际的问题是,当你知道story具体需求的时候,还不足以估计出时间,程序员必须知道“怎么做”才能估出来比较靠谱的时间。很多时候需要做一些research的工作以及一点儿prototype才好估时间,在这样的情况下,你非逼我出张牌,我只能出“问号”。有时候,虽然我不需要做prototype,但我确实也不能在5分钟之内理清思路,知道用什么approach更合理,那么我怎么办,告诉大家容我想想,等我一会儿?技术问题本来也不应该规定在5分钟之内出个计划,非逼我出计划倒也没问题,但是随后我就得重做计划。还有一个问题,大家一起打牌,A知道这工作十有八九落在B头上,A可能出于好心多估时间,B可能为了面子少估时间,这些人为因素如何排除掉?

敏捷强调单元测试,这肯定是没错的。问题是,各个团队之间容易开始攀比覆盖率,其实程序员心里都明白,覆盖率的欺骗性很强,单元测试的有效性更重要。如果单元测试又没贡献于驱动开发,也没贡献于质量保证(简单的api,诸如getter/setter之类的api就是这样,不用测试驱动直接就知道怎么写了,写了手动测试一遍就知道写的没错,code以后也不可能改),那么就没必要写这种单元测试,写这种单元测试的唯一好处是,成本低,比较容易贡献覆盖率。麻烦在于,太多弱智这么说,咱们敏捷了,单元测试覆盖率应该向某某弱智team看齐,于是人在江湖,身不由己,开始对付覆盖率。好吧,scrum其实也没说具体百分比,这不是scrum的错。

我绝对不想抨击敏捷或者scrum,我觉得这都是很出色的想法。只是听了太多“这不是敏捷”这种话,是不是敏捷根本不重要,能优化流程,让工作更有效才重要。我喜欢敏捷的地方在于,敏捷强调以人为本,尊重程序员的各种诉求。正视design不能一蹴而就的现实。承认长期计划不靠谱。强调优先级,决定优先级的时候从性价比的角度考虑。scrum的很多实践也很实用,比如backlog应该包含的内容等等不一一罗列。敏捷不是一门玄奥难懂的技术,不需要花钱找培训机构受教育。敏捷的出发点就是务实,用务实的态度拥抱敏捷就足够好。套用二八原则,scrum的实践在实际中也许只需要吸收20%,却能取得80%的效果,剩下那20%要靠基于敏捷精神的创造力。

(作者:saybody 来源:http://saybody.iteye.com/blog/1127556)



 
            
 
            
 
            
 
           
 
           
 
           
 
           
 
           
 
           
 
           
 
           
 
           
 
           

一字一句当思来之不易,感谢作者,传播测试知识、技能与正能量!

光荣之路软件测试培训

官网:http://www.gloryroad.cn/

微信公众号:gloryroadtrain

性能测试QQ群:415987441
软件测试招聘QQ群: 203715128
自动化3群QQ: 371211499


 
光荣之路 更多文章 今天晚上的 linux 公开课- Awk 编程 7月28日(今天)晚上的 linux 公开课- shell编程 8月4日(今天)晚上的 linux 公开课- shell编程 9月1日(本周一)晚8点半,光荣之路Web自动化系列基础课—javascript第二讲 推荐本好书《与机器赛跑》
猜您喜欢 超清晰QQfamily头像免费下载中!- 腾讯ISUX 【API经济前世今生四部曲】江湖动荡篇:“互联网+” 时代下的产业变革之道 对盲目扁平化说No 运维朋友们,别再问需不需要学PYTHON了! JavaScript 原型中的哲学思想