敏捷不是过程,SCRUM只是框架,XP也是别人的实践

简介:
2010-04-27 23:21 by 敏捷的水, 2139 阅读, 22 评论, 收藏编辑

敏捷不是过程

经常听到有人说我们采用敏捷开发过程,我自己原来也这么说,但经过做几年的项目,我突然意识到敏捷不是过程。好像敏捷的那些之“父”也没有说过敏捷是一种过程。我们拿它来和瀑布模型,V模型来比较是没有意义的。看过敏捷宣言的人,都知道他只提到了四大主题思想和十二项原则

Individuals and interactions over processes and tools 
Working software over comprehensive documentation 
Customer collaboration over contract negotiation 
Responding to change over following a plan

我发现提出敏捷的那帮人,真是太聪明了,他们没有提出一个具体的过程,因为是过程都不是银弹,都只能解决一些特定领域的项目,或者是某一过程只是更擅长解决某一类型的项目。但是,思想这东西可不一样,就像我们每个人都知道有 “态度决定一切”这个帽子。尤其适合我们中国人,大部分都是如果我好好做,我一定会想办法做好,不好好做,我也让你找不出毛病。很多 “老油条”做工作,分的非常清,到领导那里是 “进可功,退可守,关键时候能转手”。这样的人,我的建议是不用,想想,你和你老婆把事情分的那么清,那能感情好吗?一个没有感情的团体能有多大的产出呢?所以,我一直说,项目管理有时就是帮大家建立感情,大家不但要有共同的目标,而且要有共同的指导思想。

所以,我说,敏捷提出了一个正确思想,让大家有共同的语言,有人说敏捷宣言,其实就是废话。实际上大凡能够得到很多人认可的事情,就是很明显的事,这样大家才容易理解。大家认为是“废话”,认为本来这样的嘛,还用你说,这是不一样的,首先说明大家承认这个“废话”是对的,只要是都认为是对,接下来继续讨论的意义就有了。

做了这么多年的项目,我对敏捷不是过程更坚定了,因为我之前做过的项目,用的是瀑布过程,同样成功了,那是为什么呢?因为瀑布有适合瀑布的场景。而且从我知道敏捷到实践敏捷这近三年的时间里,我越来越发现,如果我把敏捷的思想,至少是部分的思想用到之前的瀑布过程中,那一定是一件“很爽”的事情,我说的“很爽”可能你用了敏捷一段时间后也能体会到。比如:自动集成,单元测试,客户尽早参与等等。我实在不想谈具体的办法,因为那样来论证“敏捷不是过程”这个标题就庸俗了,因为你一定可以找到我说话的疼点。

很多人说,我没有推行“敏捷”,我项目用的是XX过程,我也成功了,我们也都很爽,我想说的是你可能就是把敏捷当过程了次这么说,实际上你已经接近或者使用的正是我所说的敏捷,只是你不好意思承认罢了, :), 算了,嗯啊,你要还是不承认的话,你就承认你找到了“银弹吧”。

SCRUM只是框架

SCRUM这个东西,要想知道那几个名词,太easy了,backlog, sprint, user story等等,这些东西你用一天时间就看完了,随便在网上搜搜就明白了,还不明白,看看《scrum-xp-from-the-trenches》或者查查《scrum checklist》,你很快就会明白了。然后,你要是认为scrum就是那几根毛,我靠,SCRUM一定笑了。

所以,我这个标题就是SCRUM只是框架,他只是从管理上来看项目的,也就是如果,你只告诉大家“累堆子安的砖头们(ladies and gentleman),告诉大家一个好消息,我发现了一个叫SCRUM的东西,今天我们来一,二,三,向前,向前…” 我想说的是,你可能调到水里连响声都没有。

SCRUM只是个框架,框架这个东西,做开发的人都知道,那他是以不变应万变的东西,他是不可能包括你的所有的“上层”应用的,如果这样,没几个人会喜欢这个框架的,指定几个规则,怎么“打拳”,那是需要随机应变的,说通俗点,就是这个是要根据context来调整的。

比如,sprint是多长,每周工作40小时,需要成以0.75还是0.5,那是要看具体团队的情况,每个user story需要多少时间,多少个点,这个水是很深的,不信, 看看《人月神话》。

总结一下,SCRUM只是一个框架,是站在管理层或者用户层的,不要强制从上向下推,每一个scrum里的内容,需要经过“实践--反思--实践--反思”这个过程的。

XP也是别人的实践

image

XP是很好的实践,但是我们要知道,这些实践来自于那些技术高手们,在项目里我们不是那些高手,我们甚至找不到那样一个高手,所以,我们千万别照搬所有的XP实践,降龙十八掌学完十八式,那是要有慧根的。

比如结对编程,你有很好的理解吗?如果没有,那就还是别大规模的使用,先找两个人试试吧。

比如TDD,单元测试都写不好,设计代码的根本没法写单元测试,就想推行TDD?是测试驱动开发还是测试驱动设计清楚吗?

当然,说了这些不是说是别人的实践,你就不能用了,我要说的是恰恰是别人的实践,我们要用,问题就是我们要变成自己的实践,行不行,先试试吧

image

下面是我的实践,当然对你可是“别人的实践”,仅供参考,切勿照搬

a.共享信息空间,中文还是没有英文好表达,Informative Workspace

b.坐在一起

c. 站立会议

d. 版本控制

e. 持续集成

f.  集体代码所有权

g. 简单设计

h. 重构

等等。

不同于SCRUM, XP是注重自底向上的,就是先关心的是程序员。这也是我最推崇的一种方式,程序员的问题解决了,推行SCRUM那就是易于反掌的事了。因为推不推行SCRUM已经是不重要的事的。因为你SCRUM需要的东西,我程序员都能做到,相反,程序员每天工作出现很多困扰,谈管理也只是一句“空中的话”了。

那么该如何做呢? 就是:我们拥护敏捷的思想,采用SCRUM的框架,再加上实践XP的一些好的实践,坚定不移的走我们自己的路,让别人去说吧。一小部分人先敏捷起来,带动后一部分人一起XP吧。

最后,申明一点,信敏捷,则敏捷则灵,不信,也别强求吧。但是,春哥,你一定要信,因为“信春哥,得永生”。当然,水哥,你也是要信,因为“上善若水”嘛。你们可以不同意我的观点,但请誓死捍卫我说话的权利。

王德水 北京 2010-04-27 23:10

 本文转自敏捷的水博客园博客,原文链接http://www.cnblogs.com/cnblogsfans/archive/2010/04/27/1722529.html如需转载请自行联系原作者


王德水

相关文章
|
6月前
|
敏捷开发 Devops jenkins
DevOps、瀑布模型与敏捷开发:关系解析与对软件交付工程师的影响
DevOps、瀑布模型与敏捷开发:关系解析与对软件交付工程师的影响
146 1
|
敏捷开发 数据可视化 测试技术
敏捷开发要点
敏捷开发是一种以人为核心,迭代、增量式的软件开发方法。它强调团队成员的自我管理、面对变化时的快速适应能力,以及持续的沟通和协作。
|
敏捷开发 监控 BI
敏捷项目管理和传统项目管理的区别(内附工具)
敏捷项目管理和传统项目管理在多个方面存在区别,包括但不限于以下几点: 规划方式 变更管理 文档量 等等
|
敏捷开发 测试技术 项目管理
​ 敏捷开发和传统开发的区别?以及Scrum敏捷管理工具推荐
Leangoo领歌一款永久免费的专业敏捷研发管理工具,它覆盖了敏捷项目研发全流程,包括小型团队敏捷开发,规模化敏捷SAFe,Scrum of Scrums大规模敏捷。能够支持多种场景,如:敏捷研发管理、敏捷项目管理、工作流管理、轻量级项目群管理、任务管理等。
|
敏捷开发 测试技术 持续交付
Scrum敏捷开发实施步骤和注意事项
Scrum敏捷开发实施步骤和注意事项
敏捷框架Scrum的核心要点(“3355”)
Scrum是敏捷实践中最知名的一套框架。对于初学 Scrum 的同学,领会精髓需要实践和时间,但借助对其中最成型的部分的了解,能最快速的一窥其概貌。虽不精确,但有助于建立宏观的体感。Scrum 的核心可以简单归纳为“3355”。
2294 0