浅谈敏捷开发

首先要提的是参考书目，这个也是《系统与分析》课上推荐的书目，是由Henrik Kniberg编写的《硝烟中的Scrum和XP》，里面主要介绍了敏捷开发中的Scrum和XP的经验，另外的参考是在《软件工程》和《系统与分析》这两门课中的笔记，这里主要是想分享敏捷开发的经验，算是一个快餐过程。

首先是敏捷开发（AgileModeling，有些地方可能简称为AM）要注意的是，敏捷开发并不是一个完整的方法论，而是对已有声明周期模型的补充，在应用的生命周期模型时可以借鉴AM的过程指导思想。

敏捷开发可以分为一下几个分类：极限编程（XP），迭代增量过程（SCRUM），水晶方法系列（Crystal Methods），以及特性驱动开发（FDD）。

敏捷开发的概念比较难理解，上面的那个定义也是一家之言，我通过学习，总结来说可以这么理解，快速地开发一个软件。因为有软件生命周期模型的存在，这里存在很多完整的方法论，但是例如原型（prototype）和文档是极其影响效率的事，所以就有了敏捷开发。因此，敏捷开发不是一个说明性过程，只是一种想法，一种开发软件的办法，可以这么说，学习敏捷开发不需要系统性的学习，例如买一个书，这只是一个想法，因为条件苛刻。

然后就是敏捷开发的优缺点。首先是优点快，这个前面就说了，较短的开发周期意味着成本被大幅度降低。缺点十分明显，就是风险。缺点是敏捷开发的重点，它的风险承担能力特别差，如果需求改变，或者致命性的软件缺陷都有可能导致比传统开发更高的成本，传统的开发在风险方面比敏捷开发低得多，并且更加有序。接着就是利益分配，敏捷开发没有固定的工作分配，基本是靠软件工程师的信念驱使的，即是说，假如其中有人不满的话，很容易让团队分崩离析。但是这个风险不是不可控的，有关于敏捷开发队伍的条件。

用通俗易懂的话来说，你玩一个游戏，50个平均等级为20的玩家很艰难才可以过一个关卡，那5个99级的玩家可以很轻松通过。就是这个道理，敏捷开发的首要条件就是远超平均水平的软件工程师，这个“远超”特别重要，敏捷开发并不是新手可以驾驭的，我的老师给出的一个例子就是，28岁的本科生或研究生，就是至少工作了一段时间的软件工程师，并且有系统性训练和在大公司工作过多年的经验，才能驾驭这个方法。然后就是相同的理念，这个十分重要，大多数敏捷开发是自觉加班，自觉工作，所以可能会有分配不均的情况，所以利益驱使的团队是无法完成敏捷开发的，相同的行年也同样重要。

所以也可以这么理解，敏捷开发就是老手的一个快速开发软件的办法。