软件工程个人作业——Agile Software Development读后感

昨天利用了半天的时间看了下老师给的网页下的8篇文章和一段宣言，将感悟整理为下面的一篇博客。

首先先介绍一下这个网页。记得我们上学期上过一门课叫做面向对象建模方法，在这门课上刘超老师极力推荐的一本教材——UML精粹的作者就是此网站的作者Martin Fowler。这个网页的主要目的就是告诉我们敏捷开发这种新方法的方法论，开发过程以及最重要的一点——如何使用好这种开发方法来创造最大的效益。下面我就来根据这三点来展开我的看法和思考。

一.敏捷开发方法的定义

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。敏捷型方法有以下两个重要的特点：

1.敏捷型方法是“适应性”而非“预见性”。工程型方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划， 然后依计划进行开发。这类方法在一般情况下工作良好，但（需求、环境等）有变化时就不太灵了。因此它们本质上是拒绝变化的。而敏捷型方法则欢迎变化。其实，它们的目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。

2.敏捷型方法是“面向人”的而非“面向过程”的。工程型方法的目标是定义一个过程，不管是谁用都工作。而敏捷型方法则认为没有任何过程能代替开发组的技能，过程起的作用是对开发组的工作提供支持。

主要的敏捷性方法有：

XP（Extreme Programming －－ 极限编程〕，SCRUM，Crystal系列，相关环境驱动测试，精悍开发，（Rational）Unified Process。

二.敏捷开发过程简介

这里主要举两个例子，standup meetings和continuous integration。

第一个例子，standup meetings正如作者所说，并不是一种简单的形式，相反，他是一种有效的daily scrum的形式。这种形式不仅可以缩短以往的开会时间，而且还可以让新老员工之间互相交流工作中遇到的问题，指出对方的错误。

以下是standup meetings的目的，可以被总结为GIFTS（Good Start, Improvement, Focus, Team, Status）

G:有激情，充满能量的开始每一天

I:解决每个人暴露出的问题，分享好的经验和技术，让每个人获得提升

F:让每个人关注工作的最终目的，而不是工作的过程，防止无谓的劳动

T:好的团队是要经常在一起讨论问题，解决问题，互相帮助攻克难关的

S:时刻关心最新的进展，状态，以不致于错过有用的信息

第二个例子，持续集成（continuous integration）。持续集成是一种软件开发实践。在持续集成中，团队成员频繁集成他们的工作成果，一般每人每天至少集成一次，也可以多次。每次集成会经过自动构建（包括自动测试）的检验，以尽快发现集成错误。

持续集成最显著也最广泛的益处是降低风险。持续集成不能防止 bug 的产生，但它能明显让寻找和修改 bug 的工作变简单。长时间的集成不再存在，盲区被彻底消除了。在任何时间你都知道你自己的进展，什么能运转，什么不能运转，你系统里有什么明显的 bug，这些都一目了然。从这个方面看，它更像自测试代码。如果你引入 bug 后能很快发现，改正也会简单得多。因为你只改了系统中很小的一部分，你无需看很多代码就能找到问题所在。因为这一小部分你刚刚改过，你的记忆还很新鲜，也会让找 bug 的工作简单不少。

三.如何较好的利用敏捷开发方法

对于敏捷开发方法的理解层次我们可以分为四层：

the first stage：（one star）

the second stage：（two stars）

the third stage:       (three stars)

the fourth stage:     (four stars)

最后以敏捷开发宣言做为结束（这么优美的英文就我就不用蹩脚的中文翻译了）