【软件工程】week5-个人作业-敏捷开发方法初窥

敏捷开发方法初窥

引言：本周的软件工程个人博客作业是阅读关于敏捷开发方法的文章（http://martinfowler.com/agile.html），并撰写自己的读后感。文章内容非常丰富，对敏捷开发方法的解释和探讨也较为深入，在这篇博文中我将就我所学习到的知识进行分享，并对自己特别感兴趣的方面做下探讨。

---

I 介绍

　　在我们（指我以及大多数周围的同学）所不知道的时候，软件开发过程发生了很大的变化。而其中最大的变化也许是“敏捷（agile）”这个词出现。对于我们（再次强调：指我以及大多数周围的同学）来说，这都谈不上变化，因为我们之前就不了解原来的软件开发过程是什么样的。但是很遗憾的是，在这篇文章里，我却要对我曾经所不知道的，现在刚刚接触的所谓“敏捷开发方法”大胆地发表想法（年轻人总是这样）。这里我将首先引入“敏捷开发方法”的简单介绍，以防止谈论了半天不知道在说什么。

　　总体上来说，敏捷开发方法就是一种新兴的软件开发方法，旨在矫正官僚繁琐过程，以软件的适应性和开发者的人性为方法的出发点和归宿。

　　这里所谓的官僚繁琐过程，就是说整个过程太过繁琐，在软件层面外的事情上占用了太多的时间，延缓了软件开发进程。它相比较来说更面向文档，偏向于建造房子一般：首先设计好全部的结构，画好图纸，剩下的，建筑工人干去吧！这种方法放到软件开发上就是，刚开始全部写好设计，剩下的，码代码去吧。但是这个问题就在于，房子是设计好就可以直接盖的，而且以如此长久的历史经验来说，这一点问题没有。但是软件的需求却不是维持不变的。软件开发受到客户需求的约束，而客户并不可能在最开始就完全提供所有需求并保证说再也不改了。那这就存在一个可预见性的问题。建造房子是可预见的，但是软件开发是不可预见的。就比如客户不能在不知道价格的情况下决定选择买下哪种商品，而软件恰恰难以在完成之前定价。这样就存在了矛盾：传统工程性的软件开发方法不接受改变，而现实的软件开发需要适应改变。所有软件开发者以及相关的人士都被这个问题拖累，幸运的是，长期被压制的敏捷开发思想终于在20世纪90年代。

　　敏捷型开发方法的两大理念：

• 面向人：没有任何过程能代替开发组的技能，过程起的作用是对开发组的工作提供支持。
• 适应性：它的目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。

---

II 敏捷宣言

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：
 
　　个体和互动 高于 流程和工具
　　工作的软件 高于 详尽的文档
　　客户合作 高于 合同谈判
　　响应变化 高于 遵循计划
 
　　也就是说，尽管右项有其价值，我们更重视左项的价值。

　　2001年一些新方法的代表人物聚集一堂，最终发表了一份《敏捷宣言》如上。该宣言很好地将整个敏捷开发的含义和理念。这也是我把它单列出来的原因。从这份简短的宣言中我们能看出其两大特征：面向人和适应性。

　　“个体和互动”高于“流程和工具”：敏捷开发倡导开发者的个体性和集体性被重视，看重人的存在和作用。尽管流程和工具很重要，但是它们只是工具和手段，它们的价值有局限性。然后个体创造和集体融合，将产生难以预计的价值！　　

　　“工作的软件”高于“详尽的文档”：与建造业不同，软件开发的需求总在改变，文档只能提供最初的构架，却在变化发生时显得无力脆弱。再详尽的文档，在需求变化的时候，相应的部分将成为一张废纸！而写这些文档的时间如果用来创新和开发将更有价值。敏捷开发倡导“面向源码”，源码便是一份最好的“文档”。

　　"客户合作"高于“合同谈判”：敏捷开发在意客户的需求。将客户当做软件开发的重要一环。不是和客户谈完合同，然后开发团队管自己完成任务，而是他们的关系更是一种合作关系。合作完成一个伟大的软件！

　　“响应变化”高于“遵循计划”：计划不如变化，软件开发更是如此。如果死死跟着计划走，软件将不如预期实用和适应当前使用环境。对于变化的响应，是敏捷开发一种重要的观点。

　　敏捷开发不完全否认右项的价值，但是从对比上来说，你会发现左项的价值发挥得更人性，更长远。

---

III 极限编程

　  五条基本价值观：交流，反馈，简洁，勇气和尊重

　　从文章对于极限编程的探讨和介绍中我认为，极限编程就是把有效的方法发挥到极致。就比如结对编程。曾经有人发现两人合作编程非常有效，解决了很多问题，更是诞生了很多公司（比如微软，hp），那这种方法就被发挥到极致：一个人只管码代码，一个人只管想怎么码并告诉另一人。又有人发现测试非常重要，对每个写好的模块进行测试，将有助于后面的集成。那我们再把它发挥到极致：把测试贯穿在全过程中！程序员写一段测一段。对！我们就是要疯狂！

---

VI SCRUM

　　SCRUM是一种高度迭代性的方法，着重点是在软件开发的管理方面。它把一个项目分成若干个为期 三十天的迭代阶段，每一阶段称之为一“冲”。每天有一个短会， 称之为一个scrum，这样管理者能对项目有近距离的观察与控制。

　　当一个团队--尤其还不是小团队（在软件开发领域，7个人就该是大团队了吧）--在进行一个项目的时候，最高效的方法就是高度迭代。尤其在攻关阶段，每天都开个短会，交代进程，解决问题。一方面整个团队的氛围非常积极向上，团队成员非常投入，不容易懈怠。一方面大家有问题可以及时解决，每一步都走得踏实！我所在的软件工程课的项目组就是7个人。大家各有所长，但是毕竟课业繁重，也许从一开始就使用SCRUM并不合适，但是我认为在最后阶段还是应该采取这种高效的方法强力推进我们的项目！

---

V 改变会议方式

　敏捷开发方法还对开会方式提出了创新。不单单向以前那样坐在会议室里开会，可能站着，走着，或者干嘛着。我这一看，真不就是团队建设吗？带一个团队，不止要在业务层面上积极推进，更重要的是协调团队氛围，营造开放积极的环境。改变一下开会方式，大家或许更加投入。找个风景秀丽的地方，公园长凳上，未名湖旁，情人坡，多好的地方哈！

　

---

VI 总结

　敏捷开发方法到底还是新兴的方法，而且我认为它的这些价值观和特性将使它成为未来的主流。现在的年轻人越来越豪放不羁，不喜欢官僚制度，厌恶一成不变。敏捷方法不仅是一个高效的开发方法，还能提高程序猿的幸福感呢！

　编辑：胡言乱语