一篇短文再谈“敏捷”

仅以此文用来抒发一些对于行业现象的批判。

 

敏捷是如今十分流行的软件研发模式，而且正在成为业界主流。下图来自于2018年软件测试行业报告，能够看到在受访测试人员中，工做于敏捷或类敏捷项目中的比例已经高达89%。

将测试融入敏捷模式中，根据敏捷项目的模式进行调整，实现“敏捷测试”，是成熟的测试团队必须具有的能力。

 

在谈论敏捷测试以前，首先要搞清究竟什么是敏捷。

敏捷，汉语名词解释指反应（多指动做或言行）迅速快捷，关键在于快字。也正是因为这一特色，很是适用于小步快跑的现今项目节奏，也使得敏捷得以大行其道。作项目，必谈敏捷，不敏捷项目经理出门都很差意思跟人打招呼。

然而，许多（危言耸听的说，甚至是大多数）项目对于敏捷的理解和应用都是产生了误差的。对于某些项目组织者而言，敏捷就像是一棵救命稻草，使得他们能够名正言顺的抛弃掉他们认为的那些繁文缛节，自觉得是的将团队力量投入到他们认为最有价值的领域中去。这样的敏捷，蔑视流程，蔑视管理，蔑视全部的准备和规划，到头来项目只能是乱成一团。

敏捷是行之有效的理念和模式，但必须被正确的看待和使用。

 

当咱们谈论敏捷，咱们到底在谈论什么

有一些理论体系中，会将敏捷和一些常见的软件生命模型并列而谈，认为敏捷与瀑布模型、迭代模型同样是一种“模型”。但笔者认为，与其认为敏捷是一种模型，不如说是一种颠覆性理念。敏捷这一律念所对比的，并非软件生命模型，而是更基础的，软件研发的组织办法：“软件工程”。

软件产业的发展，经历许多个阶段，从早期的软件开发=编程，到上世纪70年代，逐渐诞生了工程体系。到如今，软件工程已是行业的一种标准理念了。

咱们不妨回过头来问一句，为何软件的研发要采用“工程”式的组织？

咱们不去纠结其名词解释，工程这个词一般的用法在什么场景下面呢？他被用的最多的一个领域可能就是：基础建设“工程”，好比盖房子，装修--典型的工程式管理。

咱们能够对比一下软件研发和基建项目的类同性：经过一行一行代码的积累，与一砖一瓦的将一栋建筑搭建起来，是否是很是近似呢？！

因而就以下图所示，咱们将软件研发过程与基建工程作了一个类比：

这种类比是很是ok的，确实咱们能够按照基建工程的组织形式，将软件研发一样进行工程式管理。到如今为止，“软件工程”已是咱们行业内的标准定义和模式了。

在工程思惟导向下，许多“精益生产”领域的理论体系也在被不断的融入软件研发行业内，好比PMP项目管理，好比CMMi成熟度模型，等等。

 

——————————————————————————分割一下——————————————————————————————————————————

 

可是，随着社会节奏的加快，业内的人士逐渐发现了工程式管理的弊端。好比，繁文缛节的项目组织、计划、设计阶段所花费的投入，甚至远高于实际的产品生产。

这个时候咱们再回过头去审视咱们关于软件工程和基建工程的对比，他们真的是一毛同样的吗？

盖一栋房子，咱们须要严密的工程规划，设计，须要严格按照计划进行建筑材料的采购，须要严格按照结构设计的要求进行施工。规划和设计中出现的一点不合理，均可能会动摇后续的工做的根基；施工过程当中的一点点不严谨，均可能造就成一项豆腐渣工程。

那么软件研发是否是也一样如此？是否是一个产品功能特性，采用A方法完成和B方法完成会产生根本性问题？是否是少写几行代码，就必定会致使产品的崩溃？是否是没有设计图纸，工程师就彻底没法开展施工（编码）工做？

你会发现这些问题的答案所有都是否认的，软件研发与基础建设工程绝非彻底类同，衡量软件研发的成功与否，甚至只有一条标准：用户的满意。

换一个角度来讲，传统工程意义上的软件研发，将软件视做一种待售产品，他与其余的商品生产过程并没有二样。那么精益生产的理念，流水线式的生产车间管理也被引入软件研发过程。软件真的与工厂里流水线上生产的产品同样吗？绝对不同，软件的需求具备高度定制的特性，不一样的企业不一样的人不一样的群体，须要不一样的软件，绝非日用产品那般千篇一概。随着理念的更新和升级，如今的业界更多认为，与其说软件是一种产品，软件更是一种服务。用作服务的思想去作软件研发，也是敏捷的出发点之一。

因此从这个角度而言，软件究竟经过怎么样的过程被研发出来，并不重要，重要的是研发出来的软件要符合用户需求。闭门造车，循规蹈矩，工厂车间式的软件研发，已经不能适应当今的许多项目需求。

 

咱们能够看看，敏捷四宣言都在谈论什么：

1. 人员交流重于过程与工具（Individuals and interactions over processes and tools）
2. 软件产品重于长篇大论（Working software over comprehensive documentation）
3. 客户协做重于合同谈判（Customer collaboration over contract negotiation）
4. 随机应变重于循规蹈矩（Responding to change over following a plan）

对于这些敏捷宣扬的理念，若是不理解敏捷的上述背景，就会产生应用的误差。

好比说第二点：软件产品重于长篇大论，强调说复杂的文档不是软件研发的核心，产品自己才是咱们的最终目标。指的实际上是咱们不该该过度追求复杂的文档，指的是文档形式的转变，而不是不要文档！敏捷项目有着本身适用的文档组织形式，好比敏捷需求更倾向于使用用户故事形式，而非传统意义上的PRD。

再好比说第四点：随机应变重于循规蹈矩，强调说不该该死板的遵循计划，而是应该拥抱变化。他谈论的问题核心在于变化的处理和应对，而不是毫无计划，杂乱无章！

好比传统意义上的软件研发，可能耗费一两年一个软件才最终问世，而在这一两年的时间内，这个软件究竟是否符合市场定位和用户需求，这一判断是含糊的，由于这个过程当中最终用户始终也没有看到软件的成品。而敏捷则强调对于用户需求的强响应，经过引入冲刺周期的形式，将庞大的软件开发过程拆分红为期2-4周的阶段，快速的产出基础产品。快速的将基础产品推向市场和用户，让用户来评判产品的适用度，若是市场满意度低，一个字：改。

拥抱变化，这才是敏捷。

 

最后总结一下：

敏捷的核心在于灵敏迅捷，在于快速。快速的终极目标不是为了快速而快速，不是为了偷工减料而快速，不是由于你管理能力低下，不少事情你组织很差，因此干脆抛弃这些你没能力作好的事情来达到快速目的。不是由于敏捷因此能够不要需求，由于敏捷因此该作的事情不作，不要以敏捷为借口来达到偷懒的目的，这是无知和无耻的表现！

快速是为了更好的需求响应，为了更好的提供服务，这才是敏捷。