软件开发流程的演变之敏捷Agile开发模式

由于当下的时代市场多变，战略目标经常飘忽不定，所以为了实现战略目标的项目就逃不脱不被频繁变更的命运。从而，从21世纪初，一种比较新颖的开发模式即Agile（敏捷）开发方法逐步走到了历史舞台的中央。尤其是在2001年很多不同流派的创始人或业界大咖级人物共同组建敏捷联盟这样的协会之后，敏捷联盟所一致推崇的敏捷宣言、敏捷原则和敏捷价值观更加深入人心，大有成为业界目前主流开发理论和方法实践之势。

那么，什么场景会适合传统的瀑布式开发或传统以PMP为代表的项目管理方法，什么场景会更加适用于敏捷开发方法呢？这个问题是很多初次接触敏捷开发的朋友经常提及到的。我们可以通过一个经典图例即史黛西图来说明瀑布式开发和敏捷开发所各自适用的范围。史黛西图的横坐标是技术解决方案，纵坐标是需求或项目目标。通过史黛西图我们可以得出如下经典结论：

1、需求和技术解决方案已定的情况，适用于瀑布式开发模式和传统PMP的项目管理方法；

2、需求和技术解决方案两者有一个不确定，适用于Agile（敏捷）开发模式；

3、需求和技术解决方案两者都不确定，是属于混乱和无序的状态，应用Agile（敏捷）开发模式中的试错和探针等方法可以把这种混乱和无序逐步变成有序，即把项目的状态从史黛西图的右上角拉回到左下角，从混乱变得有序。

目前 Agile（敏捷）开发的门派很多，但是他们都共同遵循敏捷宣言、敏捷原则和敏捷价值观。其实敏捷价值观就体现在敏捷宣言和敏捷原则之中。敏捷联盟推动了敏捷宣言和敏捷原则的落地。很多人比较熟知是敏捷宣言，一共四条，敏捷宣言的解读如下：

敏捷宣言第一条：个体和互动高于流程和工具

敏捷强调项目利益相关方应该在一起，彼此在一起的方式往往是通过每天的站会、阶段冲刺(迭代）结束时的评审会和迭代回顾会等形式来提供及时的个体互动和信息反馈，在提供反馈的过程中不断减少之前无效的流程和具体环节由于等待（Waiting）而浪费时间和资源的可能性。简单的讲，敏捷是通过个体互动的形式，减少由于流程冗长和低效的一些问题。通过充分沟通来及时发现问题和解决问题，做到持续的过程改进，个体互动都充分体现敏捷思想所提倡的团队需要充分沟通和相互协作的指导原则。

敏捷宣言第二条：可工作软件高于详尽的文档

敏捷强调持续交付和尽早的用户体验，文档够用就好。所谓够用就好就是如果有亦或没有文档，所交付的产品质量都是一样的，那就不需要撰写那份文档。杜绝瀑布式开发周期过长和拖到项目收尾阶段再交付产品所带来的不必要的风险。敏捷希望最好的需求、架构和设计应出自团队与客户的不断互动。团队成员应该是跨职能的，即每个人可以兼具需求分析、架构设计、开发和测试等能力。这样在文档不尽详细的情况下，可以通过团队彼此的充分沟通，自我的不断学习和技能的长足突破来交付可工作的软件。

敏捷宣言第三条：客户合作高于合同谈判

敏捷强调客户或产品负责人对产品开发工作的全程参与，通过紧密的客户合作及时发现最有价值的产品特性，并优先开发，在需求交付方面与客户达到协同和共赢的局面。有价值的需求也是客户为了实现商业价值的本质保证，所以要与客户合作持续交付最有价值的内容，而不是对立的来通过合同条款来约束所谓的甲乙双方。

敏捷宣言第四条：响应变化高于遵循计划

敏捷强调动态适应业务战略或市场需求的变化，允许在合理的成本控制下的项目或阶段中后期的变更。敏捷原则承认利用变更可以为客户创造更多的竞争优势，即尽早实现客户的市场或商业价值。针对这一条来讲，应用敏捷方法的项目管控比PMP或PRINCE2更加大胆，更好的应对未来市场商业需求多变的特点。敏捷强调迭代或冲刺计划，并视纳入计划中的用户故事或冲刺订单（Sprint Backlog）在整个迭代开发期间不要轻易变化。在迭代开发过程中如果由于市场调整的需要，客户或产品负责人想临时添加额外的用户故事，通常的做法是选择把在本次迭代中优先级比较低的等量用户故事从本次迭代中移除，做到迭代工作量的同等置换。因为团队在某次迭代的速率是一定的，速率就是团队整体的开发效率，每次迭代能够开发多少工作量是由团队自主决定的，不能由于市场的变化而使团队承担更多的开发任务，需要做到有节奏的开发，这也体现了自组织团队的特点。

敏捷遵循的原则共十二条及关键要点如下：

1. 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。

关键要点：交付价值

2. 欣然面对需求变化，即使在开发后期也一样。善于掌控变化，帮助客户获得竞争优势。

关键要点：拥抱变化

3. 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。

关键要点：持续交付

4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。

关键要点：合作

5. 激发个体的斗志，以他们为核心搭建项目。提供他们所需的环境和支持，相信他们能够达成目标。

关键要点：人本思想

6. 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。

关键要点：面对面沟通

7. 可工作的软件是进度的首要度量标准。

关键要点：可工作软件

8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

关键要点：节奏

9. 对技术精益求精，对设计不断完善，将提高敏捷能力。

关键要点：精益

10.以简洁为本，极力减少不必要工作量。

关键要点：简洁

11.最好的架构、需求和设计出自于自组织的团队。

关键要点：自组织

12.团队定期地反思如何能提高成效，并依此调整团队的行为。

关键要点：自省

总之，敏捷开发方法是传统瀑布式开发方法的合理补充，是应对未来市场或需求多变场景的良好实践。敏捷开发方法仍然可以借鉴瀑布式开发关于需求管理和架构设计的一些实践，比如界面原型的设计与评审，针对关键的问题的架构决策等内容。我们可以想见，在未来相当一段时间内，各种开发方法还会持续保持其特有的生命力。不同企业可以根据自身的业务特点和研发体系的成熟度和适应性，针对不同项目来适时选择不同的开发方法。

国外正品店铺介绍

感恩这个时代！您只要手机在手，就拥有一间世界级正品商铺，从而拥有您向往的高品质生活。请扫描如下二维码，进国际店铺：

请添加如下二维码向店主咨询：

关于通用的项目管理和服务管理工具和模板可以查阅如下微店电子书城,感兴趣的朋友可以长按或扫描微店电子书城二维码。

微店电子书城介绍

本微店电子书城致力于分享实用的IT电子书和拿来即用的经典案例模板文件，分享的领域涉及项目管理、服务管理和企业（软件）架构等三个方面。

电子书籍来自小编以前的著作，案例模板文件来自小编以前的工作总结和日常积累。本店“致力于为您收集有用资料，提升大家的工作效率为己任”。多谢大家的持续支持和关注！

温馨提示

PMP管理交流平台简介

谨以此公众号为中国企业和个人用户持续分享PMP（项目管理）/ITIL（服务管理）/TOGAF(企业/软件架构设计)落地的最佳实践！一花一世界，一叶一菩提。希望更多的志士仁人加入我们，这是大家的平台，一起努力分享专业！