我心中的敏捷(3)----两种世界观

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

引言：

“实践、总结，再实践，再总结”，我的很多研发观念，都是在这样的过程中不断形成和改进的，而我之所以能坚持这样不断作下去，是因为我想把一件事不断的作得更好，一直逼近我自己想要的极致。而事实上，因为每位开发者所在的领域、所掌握的工具、所面对的客户都可能有所不同，采用不同的开发方式本身就是非常自然而然的。其实，我的这个系列文章，有一部分是在说研发，而更重要的一部分是在说我们应该以什么样的思想、什么样的态度，以及什么样的方法来作事，而无论“这件事”是研发，还是销售，是产品，还是公司，我想，很多的东西，都同样适用。经过前面一虚一实的两篇文章后，下面引出的这篇文章仍然偏向于“虚 ”，仍然偏向于方法论，至于对大家有没有用，要看大家思考的深度和探索的力度。

正文：

"敏捷开发"中的"敏捷"二字, 其最本质的含义是: 对用户需求的快速响应. 而其产生, 发展乃至壮大的前提是: 随着信息化进程的不断推进, 有信息化需求的企业和用户, 也在不断提高自己提出IT需求的能力, 他们的需求不仅越提越专业, 而且, 也越提越快, 经常变化和更新. 作为一个系统实现者, 作为这个商业生态圈的服务提供者, 你无法否决用户提出的需求, 你所能作的, 很多的时候, 也最多是建议用户多给你点时间来完善, 让用户多交点钱. 而你, 该作的, 还是要作. 推而论之, 在这种情况下, 谁家能更快更好的响应用户不断变化的需求, 谁就能争取到用户.

从本质上说, 敏捷开发, 是一种非常务实的开发方式. 这种"务实"可以通过以下方面表现出来:

1. 它强调对于用户不断变化的需求一定要尽快的快速响应, 虽然用户需求的频繁更改是让开发者最为恼火的, 但是, 没办法, 作为一个商业行为, 无论你的用户提出什么修改需求, 你都要尽量满足, 只有这样你才能争取到用户, 才能让项目带来利润.

用户关注的是"他自己是否能用这个系统给自己带来好处", 用户始终不会关心"开发者因为这项修改将付出多大的代价". 虽然不近人情, 但作生意就是这样.

2. 敏捷开发的兴起, 是因为创建者们发现很多用户的很多需求在很多的情况下是无法事先全部预想好的, 是在开发过程中不断完善起来的. 传统的瀑布开发模型, 强调在开发之前先建立完整以及完备的开发计划和开发内容, 强调"先规划再开工", 是一种先全部计划好了, 然后再按步就搬进行操作的方式. 而敏捷开发, 更相信世界上根本不存在多么周详的计划能把所有的事情在事前全部计划好, 它相信, "需求变更本身就是需求存在的一种形式".

所以说, 传统的瀑布开发模型与敏捷开发模型相比较, 在形式上, 可能是一个先全面计划再执行, 而另一个是先计划一部分然后即刻开工, 在开工中不断完善; 但是在本质上, 这两种开发模型却代表了两种完全不同的开发世界观, 甚至就是开发者的世界观的反应:

前者假设世界太美好, 假设自己太强大, 假设团队太牛B, 一切都能搞得定, 所以, 他们设想着所有的东西只要列得出来, 就能按计划完成;

后者假设自己并不强大, 假设团队也不是万能的, 假设用户需求肯定是会变化的, 假设用户本身还需要不断学习和提高, 假设用户自己可能都搞不清自己想要什么样的系统, 假设要想作出用户想要的系统只有在作的过程中与用户不断交流与确认, 假设这种交流是不可能一次性完成而是一项长期的任务, 长期到甚至在软件交付了以后也仍然需要不断追踪用户需求的最新变更.

瀑布开发, 假设世界是无限美好的, 一切尽在掌控中; 而敏捷开发, 则假设世界本身是有缺点的, 而且, 有不少东西是我们只能影响但掌控不了的. 相比较而言, 敏捷开发的开发思想就要来得更为务实和坦率.

在瀑布模型中, 一旦发生需求变化, 给项目带来的风险是巨大的. 而如果不变, 那很可能作出来的东西就不是用户想要的东西, 那这个东西对于用户而言还有什么意义? 所以, 在瀑布开发模型中, 不管开发团队愿意不愿意接受需求变更, 这种变更的客观事实已经给项目本身带来太多的风险.

而敏捷开发呢? 是不是就没有瀑布模型的那些开发步骤: 需求提出-->需求冻结-->需求实现-->实现评估? 答案是否定的, 敏捷开发当然也会有这些过程, 但是, 敏捷开发对于瀑布模型最大的改进在于: 把瀑布模型中的大版本切成敏捷开发中的一个个小版本, 从而大大缩短软件发布小版本的时间周期, 始终坚持尽最快速度向用户提交一个最新功能的版本, 让用户在体验中不断与开发团队共同完善.

而不是象瀑布开发模型那样, 用户提出了需求后, 开发团队闷头作一两年, 发布一个很大的很全的但可能是不合用户本意的系统. 敏捷开发的发布周期通常是两周到两个月, 它不要求每次都要发布很多的内容, 但它要求最好要向你的最终用户频繁发布你的最新版本.

所以, 从这一点来看, 敏捷开发与传统开发, 最大的不同点正是在于"敏捷"二字, 而其对用户的具体表现就是: 用户可以拿到新版本的周期由一两年大大缩短到了两周到两个月。