你真的搞懂了什么叫敏捷式 ( Agile ) 开发吗?

敏捷式开发(Agile Development)是近来时常耳闻的一个名词，我们或多或少对于这个名词有些微的概念，但是却又很难具体的描述出一个全面性的观点来。

敏捷式的精神

原则上敏捷式开发主要的精神在于较短的开发循环（建立在反复式开发方式上）以及渐进式开发与交付。换句话来说，项目的成果，包含计划、各类的需求细节、设计等都会随着项目的进行而渐渐完整，而非在一开始将所有的计划与需求拟定完成。

在Craig Larman的Applying UML and Patterns第三版（该书的第二版着重在UP开发流程的说明，在第三版中才加进了敏捷式开发的精神）中花了不少篇幅在阐述敏捷式开发的一些定义。敏捷式开发并非一种制式的开发方法，而是一种软件开发的精神（spirit），任何开发方法都可以加入敏捷式开发的一些原则进而改善软件开发的成效。

在敏捷式开发中有个很重要的观点是笔者很感兴趣的，它认为塑模（Modeling）的目的在于增加开发者了解软件的程度，进而使得软件更接近于使用者的需求，而非使用塑模之后产生的文件。

The purpose of modeling (Sketching UML,…) is primarily to understand,not to document.[Apply UML and Patterns,3/e]

换句话说，它希望开发者使用塑模的时机，是当使用这个技术有助于开发者更了解被开发的软件时才使用，例如某些具关键性的议题或者高风险性的项目，而非不管三七二十一的将软件所有范围的设计都加以塑模留下文件。

草稿与蓝图

有趣的是，如果我们延伸这个观点，塑模在敏捷式开发的精神下是一种类似草图或者草稿的作用。也就是说，用以在团队开发时讨论以及研究议题的一种工具，在过程中利用塑模的技术来让问题得到解决，一开始的动机并非谓了留下设计图让程序设计师去实作。

同样的观点在Martin Fowler的UML Distilled Third Edition中也有所著墨，Martin认为，UML作为一项工具，可以有三种被使用的方式，一种是草图，一种是所谓的蓝图，最后一种则是程序语言。

Martin本身则是将作为一种草图的工具来使用，当然也有人将其作为蓝图来使用。而将UML作为蓝图来使用到一种极至时将出现UML本身就可视为一种程序语言，例如所谓的模型驱动（MDA）开发。当然这并不在本文的讨论范围内。

Agile

2001年时支持敏捷式开发的社群组成了Agile Alliance(http://www.agilealliance.com/)，并且发表了Agile宣言与原则。

The Agile Manifesto (敏捷宣言)

独立的工作成员与人员互动 胜于 流程与工具的管理

工作产生的软件 胜于 广泛而全面的文件

客户的合作 胜于 契约的谈判

响应变动 胜于 遵循计划

The Agile Principles (敏捷原则)

最为优先的事情是透过早期与持续交付有价值的软件来使客户满意。

欢迎需求的变动，即使是在开发的晚期。敏捷式流程驾驭变动来作为客户的竞争优势。

频繁的交付工作产生的软件，自数周至数月，周期越短越好。

领域专家与开发成员必须一同作业，并贯穿整个项目开发时期。

使用积极的工作成员来建构项目，给予他们环境以及支持所需的一切，然后信任他们能够完成工作。

在开发团队中最快也最有效的传递信息方法就是面对面的沟通。

工作产生的软件是衡量进度最主要的依据。

敏捷式流程倡导水平一致的软件开发

项目发起者，开发人员以及使用者都必须持续的维持项目进度。

持续重视技术的优势以及设计质量

最好的架构、需求以及设计会出现在能够自我管理的团队里

在规律的反复之间，团队会反省与思考如何更有效率，然后相对的来调整与修正团队的开发方式。

透过以上的条文相信读者都能比较了解敏捷式开发的一些精神。当然，既然称作一种原则，就代表团队引用敏捷式开发时，并非照本宣科的一股脑引用，而是应该审视团队与公司的文化及产业特性，来评估能够参考的部份。

延伸思考

其实延伸敏捷式开发的议题，笔者联想到一个一直在台湾软件信息界争论不休的问题，就是CMMI究竟对台湾软件有没有帮助。其实敏捷式开发的精神与CMMI这类流程与制度导向的观点在某些层面是有冲突的，如果制度化一切是个良方，那么敏捷式开发出现就显得没有道理。

但是反过来思考，制度化的开发也使得印度内的软件公司不断壮大，他们很显然的不会是使用敏捷式开发来运作。

若是有时间，或许大家可以来思考这样的议题，希望对于台湾的软件界能够有所帮助吧。