作者：不详
原文地址：不详
_____________________________________

变化中敏捷开发软件
Flexible Agile Software Development

传统软件开发如同结婚

信息爆炸的年代，全球化经济、互联网，后现代思潮……正影响着我们的生活，你甚至不能不担心明天睡醒，又有你所不知道不了解的新东西出现。最近这一两年．•敏捷开发”突然成了一个热门词汇。相信许多第一次听到这个说法的人都会下意识地问：敏捷是什么?非敏捷又是怎么回事?
我们来举两个例子：结婚和寻找红颜知己。
你打算结婚。未来的新娘为什么突然想起来要结婚了？
你告诉她：我偶尔生病，想喝水却起不来床；我在外面应酬完毕，突然不知道该去哪里；我有很多故事，想讲给一个可以信赖的人听……
她点点头：嗯．你给我XX万吧，我会用半年时间来做准备，准备好了我们结婚，结了婚之后你的上述问题就可以迎刃而解了。
你很高兴，因为你不会看装修材料，也对逛街买东西毫无兴趣，现在有人愿意全包，真是再好不过。
半年后，你们结婚了。你看着妻子一手打理的新家，笑得嘴角流蜜。你开始憧憬美好的生活，可是你生病起不来床的那天，妻子碰巧回了娘家；你和客户喝完一顿大酒之后打电话回家，家里没人．妻子还在公司加班；有一天晚上你突然噩梦醒来，感到万念俱灰，你推醒妻子想和她说点啥，她嘟哝着”天亮再说吧人家困死了”，便又熟睡如泥……
传统的软件开发方式之所以被称为“瀑布式”，是因为它把软件开发分成几个独立的步骤：需求分析．概要设计，详细设计，编程，测试，维护．一步步做下来，最后就完成了。不会回头去做前面已经做过的事．如同瀑布，一泻千里。瀑布式开发过程大抵如此：软件公司给客户做一个项目启动，大概估计到一个项目要多少成本，然后分析需求，签合同，在多长的一个时间之后要完成项目，满足合同上写的所有这些需求，然后握手，说再见，软件公司回家开发，时间到了以后交货付钱。理想的状态下，这时候交付的软件，恰好是合同上所写的那些需求。但是即便在这样的理想状态下(很罕见)，
客户的需求仍然是在变化的．因为他的商业环境、他的供应商、他的客户在改变，他的业务必须改变。
而在这种”瀑布式”的方法中，盯没有办法跟着客户改变．，T只有——譬如说——半年做完一个项目．得到客户半年前想要的东西。而客户今天想要的东西，只好放进下一个项目去考虑，因为一旦需要改变，就超出了现在这个项目的合同范围。传统的做法即便允许变化，也用一个非常复杂的流程来管理。有个术语叫”变更管理”或者”变更控制”，在这种开发方法中，变更被看做一种需要”控制”的东西。在这种方法学的指导下，对于“项目成功”的定义是按时间、按成本地交付合同所规定的功能特性，透过这样的“成功项目”，并不保证能为客户提供最大的价值，因为客户的价值，很可能就存在于快鱼吃慢鱼。
这个过程，是不是和结婚很像?理想状态下，你遇见的那个她．正是梦寐以求的，她带给你的生活，正是你希望实现的全部理想。现实中有许多人的真实生活是：没结婚不好，结完婚却更糟。
现实中不乏开发人员和客户相互耍心眼的例子。他们拒绝分享关键性的信息：
“如果我把这些告诉工程师，他们会花几个月的时间来思考，而不是着手去做我所需要的事情。“
”如果我告诉客户完成这项工作只用了很短的时间．他会指望我做每件事情都这么快“
他们夸大事实、说半真半假的话，撒谎、掩饰，在相互误解的情况下工作。他们建起一套繁琐无用的行政和程序性体系，目的是保护自己，而不是获得成功。
于是．有的企业花大价钱请软件公司搞系统．系统上马后却发现“一切不是我想象。”软件公司觉得不专业．提出的要求都是无理取闹．你觉得软件公司不负责，却又无法用专业知识对他们进行反驳，于是一个巨大的烂摊子铺开了……
你对婚后的生活不满，这不满很可能就是婚变的开始。
你发现你要的生活并没有来到，希望妻子有所改变，她却觉得你很可笑，理由是“难道你从前不知道我是这样的吗?你明明知道我是什么样的人才和我结的婚，这才几天你就对我有意见了……”
她的表现又激发了你更多的不满，你的不满令她更加委屈……你们可能彼此并不能真正做到开诚布公毫无隐瞒，交流不但不能解决问题反而加剧了矛盾，周而复始，100集肥皂剧的素材都够了。
如同当今社会婚姻家庭的动荡，传统的软件开发方式常常会出现以下问题因为对软件开发成本和进度的估计常常不准确，开发成本超出预算，实际进度比预定计划一再拖延的现象并不罕见；用户对”已完成”系统不满意的现象也经常发生：软件产品的质量往往靠不住，Bug一大堆，补丁一个接一个；等等。于是，无论是产业界还是理论界，都开始对传统软件工程学思想产生怀疑，甚至背叛。

敏捷如同寻找红颜知己

马丁•福勒认为，软件开发不能被认为是一个既定的过程，因为在一个团队中开发一个软件时会有太多的变化出现，任何一个既定的过程设置都将达到一个合适的预想结果是不可能的。由于需求在变化，技术在更新，还有人员流动等问题的存在，所以许多软件设计工作应该在软件开发到一定程度的时候才能进行，两者不应该在顺序上严格分开。他说：“从哲学的角度讲，到底软件开发活动是艺术还是工程呢?我很难清晰地界定，也许都是或者都不是。也许我们应该把软件开发活动当做一个独立的东西来对待。”
这陈述显得不够直白，我们可以继续”化神奇为腐朽”地对技术进行庸俗化：敏捷开发如同寻找红颜知己。
敏捷开发小组先听人讲故事，然后和这个人成为朋友．和他一起应对发生的问题．直到有一天这个人说：OK．你走吧，我自己可以搞定。
可是，一旦当他感到某种不适，又可以毫无压力地对敏捷开发小组说我又遇到麻烦了．你回来吧。
敏捷方法对于“成功”的定义是，“贯穿项目的整个周期．随时为客户提供最大的价值。”
为了保证“随时提供最大价值”．首要的任务是持续、快速地交付能够工作的软件；让客户能够尽快开始使用．只有用起来．他才能从中获得价值．并且提出反馈意见，所以，敏捷方法的第一要务就是”迭代”(小型发布)，通常每一周或者两周发布一次，发布的东西不是完整的软件．只有其中部分的功能，但它是可用的，可以工作的。客户可以在任意一天说“你们明天就不用来了“．他第二天得到的必定是一个可以用的软件．虽然不完整，但一定是迄今为止价值最大化的。
迭代发布实际上力度较大，因为涉及到要与客户的业务部门协作。很多企业都有自己的盯部门，他们本来就是要不间断地为业务单位提供IT支持的。所以，企业的IT建设其实并不是一个项目一个项目划分开的，这原本应该是一件连续、渐进的事情。敏捷开发团队和客户的[T团队在一起工作，把知识和方法传授给他们，所以到一定时间以后．他们就可以继续以后的事情了。
在这个世界上．除了母亲能对你无怨无悔，最后一个能在你最需要的时候出现的，恐怕只有红颜知己了。她关心你，但又保持着局外人所具备的清醒，所以容易替你看到问题的症结所在。她不是你生命的全部，没她你并不会死，但有她，你可以活得更精彩。苏麻喇姑对康熙大帝那种感情．是多少人企盼的?
作为敏捷开发中最具代表性的是极限编程，我们来看一下极限编程的12个有效实践：
1．完整团队
XP项目的所有参与者(开发人员、客户、测试人员等)一起工作在一个开放的场所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。
2．计划游戏
计划是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。
3．客户测试
作为选择每个所期望的特性的一部分，客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。
4．简单设计
团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。
5．结对编程
所有的产品软件都是由两个程序员、并排坐到一起在同一台机器上构建的。
6．测试驱动开发
编写单元测试是一个验证行为，更是一个设计行为。同样，它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环，尤其是功能验证方面的反馈循环。程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。
7．改进设计
随时利用重构方法改进已经腐化的代码，保持代码尽可能地干净、具有表达力。
8．持续集成
团队总是使系统完整地被集成。一个人拆入(Check in)后，其它所有人责任代码集成。
9．集体代码所有权
任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责，每个人都可以参与任何其他方面的开发。
10．编码标准
系统中所有的代码看起来就好像是单独一人编写的。
11．隐喻
将整个系统联系在一起的全局视图；它是系统的未来影像，是它使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符，那么你就知道该模块是错误的。
12．可持续的速度
团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作，他们保存精力，他们把项目看做是马拉松长跑，而不是全速短跑。
极限编程是一组简单、具体的实践，这些实践结合在形成了一个敏捷开发过程。极限编程是一种优良的、通用的软件开发方法，项目团队可以拿来直接采用，也可以增加一些实践，或者对其中的一些实践进行修改后再采用。

极限编程的核心思想在于：从长远看．早期发现错误以及降低复杂度可以节约成本。极限编程强调我们将任务／系统细分为可以在较短周期解决的一个个子任务／模块，并且强调测试、代码质量和及早发现问块，并且强调测试。代码质量和及早发现问题。通常，通过一个个短小的迭代周期，我们就可以获得一个个阶段性的进展，并且可以及时形成一个版本供用户参考，以便及时对用户可能的需求变更做出响应。

选妻子还是选红颜知己

信息技术的迅速发展迫切需要我们越来越简单透明．不仅仅是软件，整个工业界，乃至整个现代人的生活方式，都更加倾向于“快速反馈•及时调整”，而不是“周密规划—逐步实行”，叫嚣了一些时日的企业扁平化管理，也是信息技术带来的直接后果。现在的老板可以直接联系到任何一个员工(当然，前提是他愿意)。所以他更有机会得到来自整个企业各个角落的反馈信息．并及时调整。
大篇幅规划未来蓝图的求职报告会让主考官打呵欠，同样，老板遥远的许诺也买不到员工的足够信任，”明天”就是从今天过去之后的第二天而不再是一个模糊的指代，大家越来越在乎更接近此刻的“下一站”。

如果拿战争来举例子，60年前的战争．要求将军具有卓越的战略眼光，预测对手的行动．提前部署自己的军队。胜利的战役都是因为指挥者“料敌先机”， “运筹帷幄”；从第二次海湾战争可以看得最清楚．现在的美军指挥官不需要任何才华．他可以随时知道敌军的每支部队、每个士兵在干什么，他可以随时要求导弹攻击任何目标。所以，现在的指挥官需要的不是预测能力，而是获得反馈、快速反应的能力。那么，是不是要得出结论：”敏捷”将取代”瀑布”?
肯定有人希望是这个结果，我们回过头来谈谈婚姻家庭这些通俗话题。
从现下的情形来看．作为妻子身份存在的女性比作为红颜知己身份存在的女性要多得多，男人可以没有红颜知己，但如果全世界的男人都不结婚．我们无法预计这个世界会怎么样。从现下的情况来看，传统软件开发模式还在占据整个软件开发的大片疆域。当然，这个比喻不太贴切，我们把敏捷开发团队描述得有些过于牺牲自我了．必须正视的一点就是：红颜知己也要生活。所以不管是传统的开发方式还是新型的开发方式，最后客户都要掏钱。最重要的是瀑布和敏捷．从某种程度上来讲是对等的．针对的是不同的对象。一如妻子和红颜知己对于一个男人来说有着不同的意义，在一些需求比较固定的项目上，一气呵咸显然最为便捷，所以更适合选择传统开发模式：比如神舟六号，它不但需求固定，还没有成本压力，软件开发团队可以把大量的力气花在后期的保质方面。
家庭是保证社会安定团结的主要因素，但也有人预言．按照这个情势发展下去．也许有一天，婚姻制度会被取消，所有的妻子都会变成红颜知己。不过这毕竟只是个”也许”，未来会怎样，让未来自己回答。
就现下来说，反抗并不代表着一定要推翻．有红颜知己的男人并不需要背叛家庭，马丁•福勒等人制定《敏捷宣言》的时候，做了如下说明：我们并不是说右边的东西没有价值．但它们已经受到了足够多的重视；在这种情况下，左边的东西更有价值，更值得重视。
显然，再更新的开发理念出现之前．瀑布与敏捷并存且继续统领整个行业。

【赞赏 / Reward】