软件开发新模式：敏捷开发
做软件开发的同鞋可能都或多或少的听说过敏捷开发，但是实际采用这种开发模式的项目场景可能就比较少了，今天针对敏捷开发能实际解决的问题做一个基本的介绍，让有兴趣的小伙伴能对敏捷开发的内涵有个基本的认识。
软件开发存在些什么问题？
硬体世界的突破与发展速度逐渐趋缓，软体世界的需求扶摇直上，面对环境的瞬息万变，再加上对各类软件质与量上的快速需求，以往有时间慢慢处理的问题，越来越难以即时处置，例如：
.客户连需求都讲不清楚，分析师只好也不清不楚的混过
.客户的需求一变再变，设计也只好一改再改
.开发时程的估计有两种方法：掷茭 ＆ 闭着眼睛喊
.项目准时关闭？你求神保佑吧…
.加班是必需的，伤肝是正常的，谁叫你入错行
.我们PM的全名是Post Man，把客户的邮件转寄工程师，再把工程师的邮件回寄客户
.那个谁谁谁呢？唉！人又被其他项目拉走了…
.交付给客户的每个版本，开发周期越来越长，却依然觉得时间紧迫
.无法依据原始规划，如期产出最终成品
.版本交付时，仍存在明显缺陷，双方都不满意
.开发时间很长，过程中需求不断变化，致使初始规划显得很不正确
.规划赶不上变化，新的需求很难加入原始规划中
.为能如期达交，往往开发人员会牺牲质量
.极重的开发压力，让所有人员心情沉重，士气受创
为何要导入敏捷开发？
原有的设计流程通常是预测性(Predictive)或称顺序式(Sequential)的设计流程，它启动时的假设情境是—已建立完整的愿景，愿景中所有的需求均已定义清楚，同时已策划出实现愿景的详细计划(战术)，换言之，原有的设计流程是基于下列假设条件而进行规划的：
需求不会变更，而且已被完全理解，所以设计初期就应明确所有需求。
项目开始前，即可确认预计要采用的「技术」，该技术是足够的且能发挥正常功效以完成整个设计。
“人”可以像机器一样可预测并且能够可靠工作。
只有计划能以“精准并且保持需求不变”的情境为前提，开发前期用于计划的投入才有价值。
可惜的是，某些设计项目，在期初通常只有大方向，客户往往也难以清楚表示“需求”，随着开发的进程，客户越懂越多，以前没想到的需求往往就会随时浮现。同时，新的技术层出不穷，可能真正要开发时，该项软体技术已经过时。再加上开发人员的认知、技术、传达、构思方式不仅人人不同，甚者，不同时间也会出现差异。这些林林总总的噪音加进来，让过往著重初始规划，与规划完成后才进行分工设计的模式，不仅在开发前期投资很高，也感觉初始规划显得很不正确。
敏捷开发适用于实体产品的开发吗？
在项目开发过程中，有几个主要的情况，是难以采用敏捷开发的，包含：
在价格竞争的环境下，若试运行或塑模（Modeling）成本过高，我们是难以取得此项成本。
敏捷开发主要的精神在于较短的开发循环（建立在反复式开发方式上）以及渐进式开发与交付。若试运转的时间过长或取得运作结果的时效过慢，发现问题时可能机会已然失去。
顾客对产品缺陷的容忍度极低。如果今天你买了一辆汽车，每半年叫你回原厂做一次调整，你愿意吗？但观察近年上市的软件，都是初版发行后，会不断的调适(debug)与升级，这也不知道是我们使用者真的拥有较大的容忍度，还是已被厂商*而认为这是正常的。
所以敏捷开发较适用软件开发，又称为敏捷软体开发。对于其他开发，虽然无法一体适用，但敏捷开发中所推荐的一些观念与工具，仍可引用在其他类型的开发项目上，增进开发的绩效。
敏捷开发的发展
2001年，十七名软件开发人员聚会(因在美国犹他州的雪鸟度假村，俗称雪鸟会议)讨论1957~1997年间的一些让开发不那么沈重的方法与框架，并由Jeff Sutherland，Ken Schwaber和Alistair Cockburn起草，一同发布了「敏捷软件开发宣言」。
2005年，由Alistair Cockburn和Jim Highsmith领导的小组编写了一份项目管理原则的附录，即「相互依存声明」，以便根据敏捷软件开发方法来指导软件项目管理。
2009年，Robert C Martin编写了软件开发原则的扩展，即软件工艺宣言（Software Craftsmanship Manifesto），根据职业行为和掌握程度来指导敏捷软件开发。
2011年，敏捷联盟建立了敏捷实践指南、敏捷实践、术语和元素工作定义的演化开放式汇编，以及来自敏捷从业者社群的经验指南。
2016年，将敏捷实践指南进行调适并更名为「敏捷词汇」
敏捷开发的基本精神
将产品开发工作细分微小化，因此大大的减少了前期规划和设计的数量。
运用迭代(冲刺)这种短时间(1周～1月)的运作的模式来进行1至数个Story的开发与验证。每个迭代都具有跨功能的团队，包含了规划、分析、设计、程序编码、单元测试和验收测试。在迭代结束时，将工作产品向利益相关者展示。透过上述方式让整体风险分散与降低，并使产品能够快速获得反馈与适应变化。
迭代的方式，可能不会一次增加足够的功能来保证可立即发布使用，但是目标是在每次迭代结束时，有一个可用的发行版（最小化程序缺点）。
完整产品的发布或新功能可能需要多次迭代。
敏捷开发的框架
如同我们所熟知改善活动有许多不一样的手法，如QC Story、8D、VA/VE、Lean、DMAIC、DMADV‧‧‧等多种不同类型的框架，敏捷软件开发的框架也因派别与视角的差异而有持续的发展，例如:自适应软件开发（Adaptive software development，ASD）、敏捷建模(Agile modeling）、终极程序设计(eXtreme Programming :XP)、迅速应用程序开发、统一处理程序与动态系统开发法（DSDM）、Scrum法、看板(Kanban)法、水晶清透法(Crystal)、功能驱动开发(Feature Driven Development: FDD) ‧‧‧，其中Scrum法是目前看到最广泛被使用的敏捷开发框架。
敏捷开发的几个重要作法
每个框架的发展都有其自成系统的工具与之搭配，真的是族繁不及备载，此处仅列出几个在Scrum中较具特色的管理方法(此处不涉及软体设计的专业技术)：
迭代和增量式软件开发：此为相对于传统「瀑布式开发」的对立作法，瀑布式开发认为初期应有明确的需求与目的，故先做好完整的规划，将总体目标分拆给不同的群体，各自群体努力工作，完成子系统，然后汇总进行测试。我借用一本书(敏捷开发的逆袭) 的作者Teddy Chen 的比喻来描述两种不同的模式：切一块蛋糕给人享用，应是纵切的，每块蛋糕都有鲜奶油层、蛋糕层、水果层、布丁层‧‧‧(敏捷开发推荐运用基本版本+多次的迭代版本的发布方式，让顾客拿到的每个版本都是可以实际使用的)。而不应该横切，单吃奶油或单吃布丁层，没人会觉得吃到的是成品蛋糕。不幸的是，在很多时候，我们的开发设计，往往采用横切法：需求定义>设计规划>概念设计>各自分工从事细部设计>模型建置>汇整测试>设计修正>原型测试>放行。
非常短的返馈回路和适应周期:敏捷的 Stand up(站立会议)或日常scrum作法，运用简短的会议，让团队成员相互报告他们前一天(或阶段)对于团队的迭代(或阶段)目标与成果、今天(或阶段)打算做的目标以及他们可以看到的任何障碍或阻碍，进行资源调配与设计对应方案。频繁的讨论与分享，一有问题大家就会知道，也有可能获得回馈，人员也不致觉得太孤单。
测试引导开发与结对编程(Pair-Programming)：对由业务需求进行分析，分解为不同的Story。然后两个人同时对某一Story进行运作，经过讨论取得共识后，先由一人建构测试代码，这样写出来的测试代码就真实反映了业务功能需求。接着由另一个人控制键盘，编写功能的实现代码。先写测试代码，能够让开发人员明确目标，就是让测试通过。Pair做事有很多好处，两个人在一起探讨很容易产生思想的火花，也不容易走上偏路。
持续集成(Continuous Integration)与客户参与(Customer Engagement):敏捷开发中提倡持续集成，短时间(一天之内十几次甚至几十次)的集成，由于集成很频繁，每一次集成的改变也很少，开发过程中有什么问题或者产品经过一轮迭代后，能够以最快速度得到客户的反馈，即使集成失败也容易定位错误。
小版本发布(Frequent Releases):在敏捷开发中，希望而是尽量多的产品发布频率，一般以周、月为单位。这样，客户每隔一段时间就会拿到发布的产品进行试用，而我们可以从客户那得到更多的反馈来改进产品。
较少的文档(Minimal Documentation):简单可读的代码才是好的代码，我们的理想为，所写的东西别人一看就能够看懂。故而很少需要对代码进行补充注释。
公开与合作(Collaborative Focus)，在敏捷开发中，每个人都有权力获得系统任何一部分的代码，基于互信与合作原则对系统进行优化。这样每个人都能熟悉系统的代码，即使团队的人员变动，风险也低。
自动化测试(Automated Testing):由于需要频繁的迭代与验证回馈，测试的时间与成本势必增加， QA人员则需要有自动化测试的开发能耐。
最后，奉上案例：learun.cn
原文：windy