关于敏捷开发方法(Agile Software Development)的阅读笔记

曾经终败给现在 2021-12-09 15:09 347阅读 0赞

对“敏捷开发”（Agile Software Development）这个词，我是在这学期邹欣老师《现代程序设计》课上第一次听到的，刚听到时并不知道其具体指什么，只是从字面上直觉其意思应该是快速开发之类的。这次从 [Agile Guide][] 、 [The New Methodology][] 以及其他一些中文资料上较为详细地了解了敏捷开发方法及其与传统开发方法相比的优势所在，收获颇丰。下面谈谈在这次阅读中所学习到的东西。

一、**什么是敏捷开发方法**

通常而言，敏捷开发方法是一种以人为核心的、循环的、迭代的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态（来自百度百科）。我想，其关键之处在于迭代。

二、**敏捷开发方法的核心思想：适应变化（Adaptive）和以人为中心(people-oriented)**

软件开发方法的发展经历了从没有、到繁重的工程方法、再到敏捷开发方法的过程。早起软件开发方法没有完整的规划，是一个短期的、即时的、边写边改的、组合的过程，当系统很小时这种方法可能很有用但是当系统较大时就无能为力了；为了改变这种状况，引进了”方法论“（methodology）的概念，借鉴工程领域的实践提出了规划驱动的方法（plan-driven methodologies）或工程方法（engineering methods）。为了让软件开发更具可预测性（predictable）和更有效率(efficient)，强调在软件开发前制定详细的规划来约束开发过程，但成效也并不显著；后来诞生了敏捷开发方法，这种方法企求在无过程和繁重的过程（no process and too much process），也就是上述两种方法中找到一个平衡点，以不多的步骤过程获得合理的刚刚好的结果。其核心有两方面：

**※　强调适应性（adaptive）而非预测性（predictive）：**不是先制定详尽的需求计划然后按着计划按部就班地做，而是先做出个雏形，然后根据需求的细化或变化进行迭代开发，对需求做出充分的响应。从某种程度上说，这种开发方法不仅不忌讳需求的变化甚至在开发的过程中需求变化得越细越明确，其产品结果越好。

适应性不仅指在开发过程中修改软件来适应需求的变化，更包括自适应的过程，即通过每个阶段的回顾和总结来（What did we do well? What have we learned? What can we do better? What puzzles us?）来发现自身的问题，继而选择一个更合适的方式或过程来进行开发工作，从而不断完善开发过程。

**※　强调以人面向人而不是面向过程（people-oriented rather than process-oriented）：**工程方法强调事先制定详尽的过程（process）以便让参与进来的人都能按照计划按部就班地做好工作，而敏捷开发方法断言制定过程不能作为一个开发团队技能的组成部分，其角色是支持团队的开发工作。在开发过程中，应以人为中心，让他们与应用领域的业务专家充分接触来汲取业务方面的专业知识，合理安排成员的工作，合理评价、衡量每个人的工作成果，从而成为一个高效的、有责任的开发团队。

**三、敏捷开发的价值观**

在极限编程四个价值观的基础上扩展到五个：Communication（沟通）, Feedback（反馈）, Simplicity（简易）, Courage（勇气）, Respect（谦逊）

**四、具体的敏捷开发方法**

xp(extreme programing)极限编程、Scrum、Crystal、Context Driven Testing、Lean Development精益开发、(Rational) Unified Process等

**五、****对敏捷开发方法与传统工程方法的对比的一些看法**

读完这篇文章 （[The New Methodology][]） ，我觉得这两种开发方法最大的不同在于着眼点的天壤之别，即 **adaptive** process 与 **predictive** process 的区别。

对于敏捷开发来说，强调适应性

“It is adaptivity in the context of a project adapting its software frequently to meet the changing requirements of its customers.”

而对工程方法来说，着重通过完整的需求制定具有预测性的计划

“Everything else in software development depends on the requirements. If you cannot get stable requirements you cannot get a predictable plan.”

1、开发过程的差异。

传统的工程方法（或如文章中所说，成为规划驱动方法）强调先详细了解客户的需求，然后分析需求并制定周密的开发计划，可称之为 “规划编程”。但是想了那么多、那么全面、那么复杂值得吗？要知道，计划是赶不上变化的。相反，采用敏捷开发的方法，关键是先搭出个总体的框架，不要太在意与细节；然后在实践的过程中不断补充、添加细节，在实践的过程中不断完善，一有新的两点就可以加进来，这样不仅能完成任务，而且灵活性很大，给开发过程中产生的很多奇思妙想以实现到项目中的机会，大大提高了项目的质量，从某种程度上也大大减少甚至避免了规划编程的一个很大的缺点——deadline的压力。积少成多，日积月累、集微致盛的哲理在这里得到现和运用。

2、需求变化所带来的影响的差异。

通常，在开始的时候，客户并不真正知道自己想要什么，他们只是有个相当模糊的想法说自己想要个什么样的、能干什么事的软件，传统开发方法在开始前需要想法设法地去探寻客户到底要什么，在这方面它们投入很多，但是结果往往是他们的产品并不是很贴近用户所需，更甚，这时用户不可避免地有新的需求补充，这对开发者来说是致命的打击，不管是在精神上还是在精力上、开发过程上。敏捷开发则不同，它先把一次两次迭代开发的产品拿给用户初步体验，用户在使用这个产品的过程中越发清晰地体会到了哪些功能是有价值的哪些是可以舍弃的，越发明白他们自己到底想要什么样的东西。与此同时，开发者也越来越清楚地知道用户要什么，在下次迭代中应该侧重于哪些方面的开发，这样就达到了 ”双赢“ ！这可以说是对用户需求会不断变化这一令人头疼的现实的充分利用，在这里，！"A late change in requirements is a competitive advantage"，用户需求的变化成为了一个优点，与传统开发方法害怕用户需求变化形成了鲜明的对比！！！

3、产品偏离用户需求的程度的差异

传统工程方法design在整个开发时间中所占的比重很大，一旦制定完规划后便付诸实践，这个实践所占的比重一般比 design 少。只要做好design，其开发速度便可以变得很快，因为每一步都规划好了，只要按部就班就可。但也正因为其按初期的需求分析进行开发，在开发过程中缺少与用户需求方面的继续沟通，导致了一个致命缺点——这时，初期需求分析的失之毫厘很可能导致最后产品与用户的需求差之千里，导致”徒劳一场“；而迭代开发则是 ”In an adaptive process“—— 在最后定稿前的每个迭代过程都充分与客户交流，一有偏差就改正，这样就更早地发现了不符合需求的地方并及时解决，把产品与需求的差异扼杀在摇篮中，可以说开发的过程就是不断解决现实与需求之差异的过程，就是不断修正的过程，最后自然而然地非常接近用户真正想要的东西，从这方面来看，敏捷开发甩传统的开发过程几条街！

4、产品的衡量标准的差异

传统开发方法由于是按需求分析来做的，因此衡量一个产品是否成功在于是否很好地符合根据需求做出的计划，是否准时和物符所值（on-time and on-cost）;

而敏捷开发则看中经济效益——对客户来说产品的价值是否比其投入更多，即是否物超所值。如问文章中所说：” A good predictive project will go according to plan, a good agile project will build something different and better than the original plan foresaw.“

就个人的理解，我想或许我们可以说，迭代过程中体现出来的适应性（adaptive）是敏捷开发方法的精髓，也是它如此备受推崇的核心优势之所在！

附：[敏捷宣言的十二条原则][Link 1]     [敏捷宣言遵循的价值观][Link 2]

转载于:https://www.cnblogs.com/z-sm/p/3371077.html

[Agile Guide]: http://martinfowler.com/agile.html
[The New Methodology]: http://martinfowler.com/articles/newMethodology.html
[Link 1]: http://agilemanifesto.org/iso/zhchs/principles.html
[Link 2]: http://agilemanifesto.org/iso/zhchs/