敏捷精髓——方法论框架

说起敏捷，你也许听过，因为确实现如今，敏捷太火了。然而说到敏捷方法论，你未必理解透彻。任何的方法论的产生一般都自带体系的，如若仅仅依附于表面，对于解决问题不但起不到效果，反而可能带来新的问题。

接下来尝试总结、归纳敏捷的精髓——方法论框架，用框架指导未来的行动，事倍功半！以下是本文提纲：

1、敏捷定义；

2、敏捷由来；

3、敏捷能解决什么问题；

4、敏捷框架；

5、敏捷应用理念；

通过本文你能主要获得：敏捷方法论的精髓（可以应用在其他领域）、掌握一个方法论如何形成！

1、敏捷定义

敏捷诞生与软件开发领域，但是其方法论已应用与各个领域。敏捷软件开发定义：敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。

2、敏捷由来

20世纪60年代，软件规模小，已作坊式开发为主；

20世纪70年代，硬件快速发展，软件规模和复杂度不同以往，引发软件危机；

20世纪80年代，引入瀑布模型，以过程为中心分阶段控制软件开发；

20世纪90年代，软件开发过程日益变重，开发效率降低，响应速度变慢；

21世纪，为了应对快速变化的需求，缩短交付周期，“敏捷开发”应运而生。感兴趣的朋友可以详见文章最后附件一内容！

3、敏捷能解决什么问题

敏捷是在控制与开放中寻找平衡，能够应对变化并快速响应！根据一项由DDJ在2008年由Scott Ambler发起的调查结果可知，采取敏捷开发后，82%的项目生产率有提高，78%的项目质量有提高，78%的项目客户满意度有提高，37%的项目成本有降低。

4、敏捷框架

方法论的框架及逻辑！

总体框架

敏捷宣言——价值观

（可以参见附件二原文）

敏捷宣言——原则

（可以参见附件二原文）

实践

敏捷开发随着演进，诞生了不同的实践方法，本文以Scrum方法论为例：

5、敏捷应用理念

列举一些可以在其他任何领域借鉴的理念！

迭代；

互动；比如直接面对面交流的价值！

可工作的成果；先行动并提供可工作、可展现的小成果，并不停的迭代；

相应变化；通过迭代、合作等能从容应对变化；

合作；双赢、甚至多赢；

另外强调诚实、勇气、信任、授权、开放、专注；

总结

敏捷是一种思维、一种理念，确实有它的可取之处，当然也不是万能的，它的价值体现取决于你的掌握及如何应用实践，交汇融合才是王道。

附件一、敏捷由来：

敏捷软件开发是一种迭代增量的软件开发方法（Iterative Incremental Development, IID）。敏捷的概念是2001年提出的，其源自IID，而IID其实历史悠久。说敏捷的历史，得从IID说起。

IID最早可以追溯到20世纪30年代贝尔实验室质量专家Walter Shewhart的工作，那个时候他提出了一系列用以质量改进的"Plan-Do-Study-Act"较小的周期。质量大师W. Edwards Deming从40年代开始大力推广PDSA，80年代他在《Out of the Crisis》一书中系统地总结了系统改善理论，阐述了如何通过系统地实现小而持续的变化来提高效率和质量。知道质量管理概念的人，“戴明环”肯定如雷贯耳吧（其中S改成了C，Check，PDCA）。到了70年代中后期，PDSA的应用扩展到了软件开发当中。

IID曾在NASA 50年代的X-15超音速喷气机项目中起到重要作用，虽然这并不是一个软件项目，但是却是一个里程碑式的事件。因为正是它促使60年代早期的NASA 水星项目开始在软件开发中应用IID。水星项目以非常短的迭代周期进行，开发团队会对所有变更进行技术评审。有意思的是，他们甚至采用了极限编程中的测试优先开发，在每个增量之前首先编写测试，基于桩(Stubs)进行自顶向下的开发。那个时候还没有极限编程的概念呢，Kent Beck应该连酱油都不会打。随后水星项目的成员启发了IBM联邦系统部门（IBM FSD，其实就是这帮人重新组成的）早期对IID的采用。而最早描述迭代开发的文献来正是自于IBM Watson研究院的报告。

1970年Winston Royce在“Managing the Development of Large Software Systems”一文中首次提出了瀑布模型，但是实际上这篇文章提出的模型与我们知道的经典瀑布模型其实并不一样，开发活动并非以严格的有序序列组织（需求分析->设计->开发->...)，它提出的其实是一个具有两次迭代的模型，其中第一次包含必要合理因素的试验性模型，第二次考虑关键的设计和运维问题。这虽然与现在迭代开发的概念相去甚远，但是大多数人只记住了严格的瀑布模型。

70年代期间，IID的采用者主要包括IBM FSD和TRW(Royce工作的地方)，成功的项目包括IBM FSD的国防部空间和航电系统、三叉戟潜艇操作控制系统，TRW的导弹弹道防御系统软件项目等。事实上螺旋模型的提出者Barry Boehm正是TRW的首席科学家。尤其值得一提的是70年代中期FSD开发的美国海军机载系统，该系统的开发以每个月为一次迭代，经历45次迭代成功交付。当前推荐的迭代周期长度一般为从一周到六周，这应该是迭代周期长度首次在这个范围内的项目。

1976年Tom Gilb出版了著作《软件度量》（“Software Metrics”），他在书中阐述了IID的实践。这应该时最早讨论和推广IID的一本著作，这本书也将"演化（evolution）" 和"演化性（evolutionary）"这两个词引入了软件过程的术语中。70年代其实瀑布模型依然是主流，是美国国防部的开发标准，生命周期这个词默认就是瀑布生命周期，不过这个时候已经开始出现迭代增量模型替代瀑布模型的声音。那个年代的开发人员是纠结的，要遵循瀑布标准的同时采用IID，甚至要对不得不放弃瀑布而采用IID表示歉意。软件工程是个极其年轻的学科，回头看看短暂的发展轨迹也很有意思。

IID在80年代的发展总结起来很简单：反思瀑布模型。很多学者和实践者通过文章和著作批判经典的瀑布模型，大力推广IID，Gilb正是其中的代表人物。80年代人工智能和专家系统的研究非常活跃，在这个领域最常用的方法就是演化的原型，典型的IID实践。85年Boehm提出的螺旋模型，首次将“风险驱动的迭代”这一概念显式提出，认为每一次迭代都需要独立的风险评估。《人月神话》作者布鲁克斯老爷子那时也说过去几十年对他个人实践的巨大影响，无出“增量开发”之右者。他更在1995年的国际软件工程大会（ICSE，软件工程研究者的顶级会议）发表主题演讲：“The waterfall model is wrong!”。

事实上，美国国防部也逐渐意识到了瀑布模型的局限性。在1987年，布鲁克斯老爷子主持的军方科学委员会会议上，美国国防部终于修改了以瀑布模型为基础的标准，允许IID的采用。这是一个名为DoD-Std-2167的标准，不过IID只是被建议而已，文档驱动和单向阶段划分的瀑布模型其实依然岿然不动。后来在1999年他们做过一次失败总结回顾，结论是，在耗资370亿美金的项目样本中，百分之75的项目失败了或者从未使用过，只有百分之2的项目在没有重大修改的情况下在正常使用。DoD-Std-2167的制定者们也表示了歉意，表示应该当年强烈推荐IID。这样的马后炮没什么Ruan用，话说回来，一个标准的改动不仅仅是技术因素的推动，各种利益关系都会产生影响，改革和变化必然是在曲折中前进的，但大势从来不可逆转。

90年代IID的论文和书籍更是开始井喷。七八十年代的IID依然注重前期的规格说明，而90年代起则推崇在演化中分析。美国国防部也于1994年要求项目必须采用迭代开发，通过快速部署初始功能的方式应用演化开发。

而在商业领域，Jeff Sutherland and Ken Schwaber 开始应用采用Scrum方法。这种源自于80年代日本的生产制造企业的方法日后大放异彩，以后独篇再书。1994年1月十六个开速应用开发（RAD）实践者在英国一起讨论支持RAD开发的标准迭代过程，最终形成动态系统开发方法（Dynamic Systems Development Method, DSDM）。这个IID方法在欧洲得到了广泛的推广。

RUP(Rational Unified Process)也是在差不多的时候提出，现在演化成为了Open UP，也是一种典型的IID方法。1995年微软提出了每日构建和冒烟测试的概念来支持周期短至一天的为迭代。1996年Kent Beck提出了极限编程（XP），1997年从一个新加坡物流系统的开发中，Jeff De Luca将整个迭代过程总结成为了特征却动的开发（Feature Driven Development，FDD）。

时间来到2001年2月，17个来DSDM、XP、Scrum和FDD方面的牛逼的中年愤青程序员，在盐湖城的雪鸟滑雪胜地，他们都觉得现在的软件开发方法非常Shit，都像推动更加现代和简单的IID方法和原则，于是他们吃着火锅唱着歌，一起发布了敏捷宣言，你可以认为这是一组口号，但由此催生了敏捷软件开发的热潮，各种敏捷方法也大显神通，更为大家所熟知。

附件二、敏捷宣言、价值观原文：

1、宣言

Manifesto for Agile Software Development

We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.

2、原则

Principles behind the Agile Manifesto

We follow these principles:

Our highest priority is to satisfy the customer

through early and continuous delivery

of valuable software.

Welcome changing requirements, even late in

development. Agile processes harness change for

the customer's competitive advantage.

Deliver working software frequently, from a

couple of weeks to a couple of months, with a

preference to the shorter timescale.

Business people and developers must work

together daily throughout the project.

Build projects around motivated individuals.

Give them the environment and support they need,

and trust them to get the job done.

The most efficient and effective method of

conveying information to and within a development

team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.

The sponsors, developers, and users should be able

to maintain a constant pace indefinitely.

Continuous attention to technical excellence

and good design enhances agility.

Simplicity--the art of maximizing the amount

of work not done--is essential.

The best architectures, requirements, and designs

emerge from self-organizing teams.

At regular intervals, the team reflects on how

to become more effective, then tunes and adjusts

its behavior accordingly.

共鸣

深度思考、践行、反思、循环

小贴士

欢迎大家

在留言区留言，一起交流进步