敏捷不是过程
经常听到有人说我们采用敏捷开发过程,我自己原来也这么说,但经过做几年的项目,我突然意识到敏捷不是过程。好像敏捷的那些之“父”也没有说过敏捷是一种过程。我们拿它来和瀑布模型,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 image](https://i-blog.csdnimg.cn/blog_migrate/d40915ea698b6a4cdd0c65dfa6e55eb1.png)
XP是很好的实践,但是我们要知道,这些实践来自于那些技术高手们,在项目里我们不是那些高手,我们甚至找不到那样一个高手,所以,我们千万别照搬所有的XP实践,降龙十八掌学完十八式,那是要有慧根的。
比如结对编程,你有很好的理解吗?如果没有,那就还是别大规模的使用,先找两个人试试吧。
比如TDD,单元测试都写不好,设计代码的根本没法写单元测试,就想推行TDD?是测试驱动开发还是测试驱动设计清楚吗?
当然,说了这些不是说是别人的实践,你就不能用了,我要说的是恰恰是别人的实践,我们要用,问题就是我们要变成自己的实践,行不行,先试试吧
![image image](https://i-blog.csdnimg.cn/blog_migrate/0065fe50195386ed443ca36752910e8f.png)
下面是我的实践,当然对你可是“别人的实践”,仅供参考,切勿照搬
a.共享信息空间,中文还是没有英文好表达,Informative Workspace
b.坐在一起
c. 站立会议
d. 版本控制
e. 持续集成
f. 集体代码所有权
g. 简单设计
h. 重构
等等。
不同于SCRUM, XP是注重自底向上的,就是先关心的是程序员。这也是我最推崇的一种方式,程序员的问题解决了,推行SCRUM那就是易于反掌的事了。因为推不推行SCRUM已经是不重要的事的。因为你SCRUM需要的东西,我程序员都能做到,相反,程序员每天工作出现很多困扰,谈管理也只是一句“空中的话”了。
那么该如何做呢? 就是:我们拥护敏捷的思想,采用SCRUM的框架,再加上实践XP的一些好的实践,坚定不移的走我们自己的路,让别人去说吧。一小部分人先敏捷起来,带动后一部分人一起XP吧。