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

敏捷不是过程

经常听到有人说我们采用敏捷开发过程，我自己原来也这么说，但经过做几年的项目，我突然意识到敏捷不是过程。好像敏捷的那些之“父”也没有说过敏捷是一种过程。我们拿它来和瀑布模型，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也是别人的实践

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

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

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

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

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

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

b.坐在一起

c. 站立会议

d. 版本控制

e. 持续集成

f.  集体代码所有权

g. 简单设计

h. 重构

等等。

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

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

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

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