我心中的敏捷(4)----多样的形式与不变的本质

本文作者:sodme
本文出处:http://blog.csdn.net/sodme
声明: 本文可以不经作者同意, 任意复制, 转载, 但任何对本文的引用都请保留文章开始前三行的作者, 出处以及声明信息. 谢谢.

引言：
前面几篇文章中，都在不断重复着＂敏捷＂二字的真正内含，是的，如果要说起这些所谓的内含，应该没有人会反对，但是，如果把这个问题再引申一步：如何理解各种各样的敏捷开发形式与敏捷方法论之间的关系？如何把书本上总结的各种各样的敏捷理论用于我们的开发实践？这些问题，可能就不再是那么容易回答的了．在本篇文章中，将会阐述我对这些问题的理解以及我的实践解决之道．

正文：

事实上，当大家把软件当作一件“工程”的事来作的时候，很多东西就开始变味了。按理说，软件开发是一件极具创造力的事，而写程序的我们自己也应该是每天生活在充满想象和幸福感的氛围里，而现实恰恰相反，我们总被这样那样的需求折磨得人不人、鬼不鬼，不断的修改设计方案，不断的调试代码，我们甚至变成了连打字员都不如的一类人：因为打字员只管快速击打就行了，而我们还需要不断地在既有的方案和新产生的需求里走钢丝，尤如穿针引线般地通过各种让我们自己和后来人都痛苦的所谓“技巧”来实现新的需求以及保持既有框架的稳定。

当需求变得越来越不可控，当软件开发变得越来越依赖个人经验之时，我们希望能有一根稻草将我们这些受苦受难的ＩＴ技术人解救出去。于是，软件生命周期，软件工程化管理，瀑布开发模型，敏捷开发模式等等等等，在实践与理论的交织过程中，我们发明了一个又一个新方法来不断适应真实的业务开发需求。从这个意义上来说，敏捷开发模式，可以称得上是软件开发领域的一件具里程碑意义的大事件，因为，它把开发本身还原成它本来所应该具有的那个样子，它承认了现实的复杂性，它也务实的提出了很多具有指导意义的具体开发方式。

在国内IT技术翻译界里，对“敏捷”一词的翻译，我想，是为数不多的几个好词之一，仅凭这一个词，就已精确表达了这一方法论下所有开发方式的起始和归宿，那就是：以“敏捷”的开发方式，带来“敏捷”的产品交付速度，最终带来“敏捷”的公司发展速度。

不管是XP，SCRUM，Crystal，ADD，FDD，还是DSDM或者RUP，形式可能多种多样，但其本质从未变过，那就是：让不可控的产品研发，变成可控的；让慢如蜗牛的开发，变成快速的；让杂乱无序的开发，变成秩序井然而让人心情愉悦的。

我们自己的开发框架，采用的是SCRUM为主体，但会根据需要临时在某个阶段或者某些同事之间采用XP的方式。“某个阶段”，是比如：我们想让某一块的关键代码，能被两个人以上的同事了解、熟悉并掌握，那么对这一块代码的开发，我们就会鼓励大家采用XP的方式来完成。而当这块任务完成后，就又恢复成既有的方式。

我们采用SCRUM方式时，并没有机械照搬它本身的多种职位设定以及人员设定，最主要的，我们是学习到了它的“神”：那就是，我们讲究充分授权，同时，强调关注结果，只对结果负责，且，结果要是明确的，可达成的，以及可周知的，逐渐的，要作到结果是可控的。而，作开发的人都会了解，对于一个经常变换需求且对发布周期要求苛刻的项目来说，“结果可控”是多么重要。可以这么说，如果“结果不可控”，那这种项目，只有死路一条，而这种团队，其最终结局必然是解散。

老实说，如果是一个新团队，一开始就采用我们现在这样的作法，那可能会遇到比较大的阻碍，因为，在我们的开发方式里，对个体的专业素质要求比较高，“独挡一面”几乎是团队成员的基本要求。也就是说，无论你原来作的是哪方面的内容，在既有的框架下，把你放在新的任务环境下，也要求你能马上适应，快速在新环境里出成果。

但是，不是每一个人，以及每一个团队，都能达到这种状态的。很多的团队，特别是初创团队，需要面临的，首先是团队成员专业素质不高的问题，而这一点，如果试图通过教育、辅导的方式来提高，其效果是比较缓慢的。所以，比较好的方式，是由老人来带，把一些作事的正确方法，一些良好的专业习惯，通过言传身教的方式传递给新人，最终把他们一个个都培养出来。我们的最终目标，是让团队里的每一个人，都能在某一方面独挡一面，当我们跟他们中的任何一位一起作战时，我们都可以放心的把自己的后背交给他。

我们自己的团队，也是这样一步步走过来的。刚开始，我们也是一群毫无经验的初生牛犊，我们比别人幸运的是，有比较好的公司背景和资源可以支持我们在这么长的时间里去失败、摸索与提高，而我们比别人优秀的是，在这个过程中，我们从没有退缩和逃避，也没有得过且过，而是在这将近四年的时间里，不断寻求着精益求精的方法，不断改进着我们每一天的工作，甚至，我们对自己在质量、安全和稳定方面的要求，已经到了刚来的新人不可理解的BT程度。是的，只要影响到安全、稳定和质量的再小的细节，我们也不会让步，更不会得过且过，放这些代码的丝毫一马。这，是我们的底限，不可逾越。

“效率，效率！质量，质量！”，每当我们在审视自己的实践与书本上的理论貌似“脱节”之处时，这两个词就会不断的出现在我们的脑海中，这也成为了我们作出正确选择的最主要的两个参考坐标。

有很多人，工作没激情，没效率，是因为他们的项目没有压力感，他们的工作没有生存的压力感，作好作坏不会对自己的前途造成太大影响，作多作少不会对自己这个月的工资带来多少波动，他们总说项目没前途，公司没前景，他们总想着，混点时间出来骗点所谓的“时间积累出来的经验”，然后跳槽换个大一点的公司，找一个工资更高一点的工作，如此往复。

而事实上，我想说的是，无论你换到哪一家你想换到的“大一点的、待遇好一点”的公司，你最终能从这个公司里获得的东西，永远只是因为你对公司贡献了多少价值，而我相信，你那些没有太多有价值经验而浪费掉的时间，对于这些新公司来说，也同样是没有价值的。

而如果，你想让自己将来更有价值，就应该马上从现在起，让自己每一天的工作开始有效率起来，不要总想着用在公司的时间作更多公司外的事，不要总想着在上班时间看更多与当前项目无关的技术书籍，你所最需要作的，就是把每一天你的老大，你的老板安排给你的事，作好，作到极致！人，总要先有付出，而后才会得到回报的。不要再抱怨待遇不好，不要再抱怨公司没前景，如果你想找个有前景的公司，那你自己就要首先成长为一个看起来有前途的家伙。

扯远了，本来是想说敏捷来着，竟然谈起了理想和人生，汗！好吧，其实，我是想说，我们现在在谈的，绝不仅仅只是一种写代码的方式，或者一种作软件的方式，更深一层次的，它会关联产生其它很多很多的效果，而这些效果，可能是现在的你连想都不曾想过的。千里之行，始于足下。如果想让自己变得更有价值，就让自己每一天的工作更有效率起来，而真正属于你自己的“敏捷”，其实是你自己在思考和分析了自己当作工作流程、工作环境的情况下，作出的真正符合你自己实际情况的解决方案，绝不是那些书本上所说的各式各样的理论。