六西格玛、精益制造、IPD、敏捷开发等先进方法帮助过很多企业提升产品研发速度、企业管理水平。然而时过境迁，到了互联网+时代，当传统企业想要研发互联网+产品的时候，发现以上先进方法似乎都不再奏效，甚至会阻碍新产品的研发。是这些方法真的失效了，还是我们用错了地方？让我们一起回顾一下这些方法，再作评判。
我将从产生时间、来源企业、产生原因、核心目标、方法论、局限性等六个方面对四种方法来进行剖析。
敏捷开发(Agile Development)
产生时间：2001
来源企业：敏捷宣言（2001年2月由17位当时称之为“轻量级方法学家”所编写签署的）
产生原因：
统开发方法是基于客户能够在需求阶段就给出完整、准确的需求的假设，所以期望于在项目初期获得详细的需求，然后严格控制需求变更，最终完成符合需求的软件。
但我们发现实际上往往需求是“涌现”出来的，也就是说是随着开发的不断进展而不断发现出来的，而无法在项目初期就明确的定义它，也就是说传统开发方法的基本假设是错误的，这一新的假设导致了敏捷方法的一系列实践。
另外，传统的软件开发方法认为需求是可以确定，所以采用的是基于工程的开发方法，也就是说期望通过事先的详细策划定义开发的整个过程，而敏捷认为需求是无法在早期完全确定的，所以采用的是基于经验的开发方法，也就是说事先不详细定义整个开发过程，而通过多次迭代来逼近最终目标
核心目标：
以人为本、价值驱动、减少浪费、拥抱变化、
方法论：
基于敏捷宣言的核心思想，敏捷开发产生了多种不同的方法流派，其中应用较广有两种。
Scrum
Scrum包括一系列实践和预定义角色，是一种灵活的软件管理过程。它提供了一种经验方法，可以帮助你驾驭迭代，实现递增的软件开发过程。这一过程是迅速、有适应性、自组织的，它发现了软件工程的社会意义，使得团队成员能够独立地集中在创造性的协作环境下工作。
极限编程（XP）
极限编程是由Kent Beck提出的一套针对业务需求和软件开发实践的规则，它的作用在于将二者力量集中在共同的目标上，高效并稳妥地推进开发。其力图在不断变化的客户需求的前提下，以持续的步调，提供高响应性的软件开发过程及高质量的软件产品。
虽然Scrum偏向管理实践，XP偏向技术实践，但万变不离其中，他们都遵循着以下几个核心方法。
1）迭代式开发。即整个开发过程被分为几个迭代周期，每个迭代周期是一个定长或不定长的时间块每个迭代周期持续的时间一般较短，通常为一到六周。
2）增量交付。产品是在每个迭代周期结束时被逐步交付使用，而不是在整个开发过程结束的时候一次性交付使用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。
3）开发团队和客户反馈推动产品开发。敏捷开发方法主张客户能够全程参与到整个开发过程中。这使需求变化和客户反馈能被动态管理并及时集成到产品中。同时，团队对于客户的需求也能及时提供反馈意见。
4）持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。一些项目是在每个迭代周期结束的时候集成， 有些项目则每天都在这么做。
5）开发团队自我管理。拥有一个积极的、自我管理的、具备自由交流风格的开发团队，是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制，而非把过程和机制强加给人。
局限性：
1.对人要求很高，难于掌握
敏捷开发与IPD一样都是在解决产品研发的问题。只不过敏捷开发是从软件领域开始的，所以在软件研发上应用较多，而后引入到部分可编程硬件领域。它与之前的三种方法最大的不同是，它从以“流程”为核心转变成以“人”为核心。这是研发方法从工业领域转向到高科技领域的一个重要标准。前者是以机器为核心的，把人当做资源看待，努力将人的工作标准化可替代，因此需要靠精心设计的流程保证其高速运转。后者是以智力为核心的，把人当做不可替代的核心创造者看待，让工具为人服务，提升其创造力。因此大幅度弱化了流程，承认了人的不确定性，即承认人会犯错，客户会犯错，开发者会犯错。从靠流程、制度、评审来规避犯错转变成为接受错误，尽早发现尽早修正。同时承认高智商高经验人的产出是低者的上百倍，因此要为其营造高产的环境，即宽松的环境。这些都是与传统方法相反的思维方式。
在它带来好处的同时，也带来了问题。敏捷开发方法因为缺乏严格的操作方法，过度灵活，难于掌握。这就对采用敏捷开发的企业员工提出了更高的要求。他们需要深刻理解其背后的逻辑才能够让方法发挥正向效用，否则会导致更低的效率，甚至混乱的状态。这也是历时十多年，敏捷被谈多做少的原因。
不仅如此，敏捷开发本身对每个人的技能要求也极高，例如对开发人员，要求能够具备对架构持续重构，保持简单，这都是需要很高的技术修养才能做到的。同时要求团队要能够做到“自组织”，即“团队是一个整体，没有角色之分、职位之分、也没有高下之分。团队成员的任务不是项目经理强加于身，而是根据自己的愿望和能力对任务进行合理评估，并主动进行领取。被动与主动所产生的驱动力显然不可同日而语。”这是非常理想的状态，几乎没有企业能够做到一点。然而这却是很多敏捷方法的基础，这便造成敏捷开发落地的很多难题。
2.以项目交付为主命题
敏捷开发产生是源于企业软件交付的诸多难题，比如变更、缓慢、高成本等。这类交付大多以项目形式组织、以产品为结果。
项目有两个核心特征“为客户服务”、“一次性”。
项目的发起是从客户需求出发的，这隐含了客户必定是存在的，而且是明确的，通常客户是一个人或一个公司的需求提出人。通常是一对一服务的。他们的需求一般也是明确的，至少方向是明确的。
但这并不是用于产品研发。产品通常是自主研发的，它是有企业对市场的分析，洞察出一个普遍性需求，进而研发出产品，然后寻找购买者进行销售。通常是一对多服务的。因为面对大量用户，他们会存在各种各样的个性化需求，因此便不能想做项目一样有明确的需求，这就需要主创者对产品方向进行判断和把控。
所以敏捷开发中“客户合作”、“客户现场”等都是对客户重要性的确认，一旦客户不存在，例如自主产品研发早期还没有用户的时候，需求的挖掘、产品的验收就都成了问题。
项目一般是为一个确定目标所完成的一次性活动，所以项目是以客户验收为结束标志的。然而产品因为存在大量用户，它是持续交付的过程，再加上产品的更新换代，还需要对老用户进行升级。
敏捷开发中强调“客户验收”的重要性，要求与客户频繁验收，从而尽早发现问题，尽早调整，减少返工浪费，同时收敛项目范围。但这并不是用于产品，因为产品的功能是越做越多的，不断发散，同时还无法快速与用户验收，甚至无法验收，因为用户太多，不知道以谁为准，或者用户拒绝对未成形产品验收。这都让敏捷开发更多的局限在项目交付范畴之内。
方法并无好坏之分，也无过时之说。方法只存在适不适用。通过系统性回顾各种方法的背景、理念和方法，可以很清楚看到各种方法的适用性。它们都在他们所擅长的领域发挥着巨大的作用。
同时，我们也发现方法不是孤立存在的，它们之前有着很多共性。
四种方法都在努力服务客户，以客户为中心。
六西格玛和精益都在追求完美。
敏捷和精益都在努力减少浪费。
六西格玛和敏捷都强调质量内建。
IPD和敏捷都以人为核心。
正确的事情总是殊途同归。方法也不例外。在相同的处境下遇到相同的问题，最有的办法总是非常相似。与之相反的是，错误的方法却千差万别。
但当处境和问题发生变化的时候，一部分方法就会失效。比如互联网+产品带来的变化：
以用户为中心，而非客户。
从不确定性出发，而非确定性。
主导产品，而非交付项目。
追求体验，而非质量。
追求容错，而非完美。
追求创新，而非执行。
所有这些都在呼唤新的方法产生——“极速产品研发”。
■作者简介：艾永亮（个人微信公众号：ALS111222333），互联网+领先思想者与实干者，《腾讯之道》作者，《极速产品研发》方法创立者；TII互联网+咨询董事长，步步高、美的、深交所、华为、顺丰等企业互联网+转型导师，前腾讯首席敏捷管理教练。
网友评论