过去传统的工程开发，项目一般是将需要交付的范围和内容在前期完成限定。换句话说，在一个项目开始的时候详细明确了开发的需求，项目管理者和实施者需要在时间和各类资源上做调配，来获得一个完美的结果。
极氪作为一个年轻的品牌，诞生于一个不断变化的时代！变化对于每一个置身于这个时代的组织和个人来说，都是一个不可忽视的因素。你可能听过这个词，VUCA （ Volatility Uncertainty Complexity Ambiguity） 它表示的是事物存在的环境具有波动性，不确定性，复杂性和模糊性。因为外部变化太多太快，如果无法通过内部的快速响应去适应外部的变化，设计产品也好，执行的项目也好，最终很可能得到一个相对糟糕的结果。由此想到，当前整个产品开发过程的控制方法，是否能对一系列的开发的活动做比较好的把控？
NPDS（New Product Development System）NPDS是吉利汽车正向开发所采用的整车开发体系模型，覆盖整车项目管理，机械结构，功能特性，子系统，电子软件零部件等一系列研发活动。此类流程的渊源是基于上世纪70年代系统开发生命周期模型。它们经常被用于航空航天等大型工程项目和复杂系统开发的场景中。举几个这类模型比较明显的特点。由于流程中各个活动和目标有明确的阶段性，每当需要进入到下个阶段时，往往需要经过所谓的GATE（链接参考Project Management Institute的定义）。按照项目管理方法论，Gates Review的目标是要帮助定位识别会使项目失败的两大原因，即项目范围的变化和风险点。逻辑上看似乎没有问题。
然而，GATE的打开和关闭仍旧是由人来判断的，人的能力和知识储备水平是不一样的。往往会发生过了GATE，但是其中需要排查的风险并未发现出来。流程本身也不能保证工作内容的质量符合预期。最严重的痛点是，每个阶段需要很长的时间收集整理处理信息，整个项目的时间周期会拉的非常长，从而引入更多的不确定性。人们也常常把这种方法论称作瀑布式的开发方式，见下方图例为一软件开发相关的通用步骤。
图一.瀑布式的开发方式举例：需求->分析->设计-> 代码-> 测试-> 部署, 有的也会包含后续的维护部分
Agile - a short introduction
敏捷开发思维登场！简单介绍一下敏捷开发的历史：上世纪90年代，在美国硅谷的一些工程师在一起讨论为什么软件工程交付和质量变得越来越差，有什么样的方法可以改变这样的现状？在这样的背景下面，2001年，倡导轻量化和更多迭代开发方法的思想领袖们，聚集在了美国犹他州的雪鸟小镇。虽然大家所提出的方法各不相同，但是与会者一致认为这些方法所遵循的共同价值和信仰，最终提出了具有转折性意义的“敏捷软件开发宣言”。 如下图内容所示
图二.敏捷宣言建立的价值观 来源：agilemanifesto.org
翻译过来就是：个体的互动高于流程和工具，工作的软件高于详尽的文档，客户合作高于合同谈判，响应变化高于遵循计划，也就是说尽管右项有价值，我们更重视左项的价值。 由此为基础，由Scaled Agile, Inc 进一步发展出来的整套SAFe（Scaled Agile Framework）原则概述如下
#1 - Take an economic view
采取经济视角
#2 - Apply systems thinking
运用系统思考
#3 - Assume variability; preserve options
假设变异性;保留可选项目
#4 - Build incrementally with fast, integrated learning cycles
通过快速集成学习环进行增量式构建，
#5 - Base milestones on objective evaluation of working systems
基于对可工作系统的客观评估设立里程碑
#6 - Visualize and limit WIP, reduce batch sizes, and manage queue lengths
可视化和限制在制品，减少批次规模，管理队列长度
#7 - Apply cadence, synchronize with cross-domain planning
应用节奏，通过跨领域设计进行同步
#8 - Unlock the intrinsic motivation of knowledge workers
释放知识工作者的内在动力
#9 - Decentralize decision-making
去中心化的决策
#10 - Organize around value
围绕价值链组织活动（后续的版本新增）
介绍了那么多，敏捷的优势到底在哪里呢？通过以下两个图，粗略的对敏捷开发和传统的瀑布式开发做一个对比，图中红色曲线是传统的工作方式，蓝绿色代表的是敏捷的工作方式，横轴是时间线，纵轴相对关系的比较示意，没有绝对的数值。
左边图里面所描述的是，传统的开发中，在前期设立好的开发的范围，与客户商议的需要交付的功能清单，会因为资源或技术成熟度等因素的影响，使得实际交付变得困难。特别是临近项目交付时间点，与之前的承诺会有很大的出入。而敏捷开发是一个增量的变化，在前期保证可交付少量但是可以工作的功能。哪怕这些内容并不是非常完美，至少在整个框架内的这部分已提交内容可以被终端客户使用并接受检查的。后续的交付是在之前的基础上叠加，完善甚至超出客户的期望。
图三.传统和敏捷开发的优缺点举例
右边图中，更多的是从集成测试的角度和发现问题的数量来比较。在传统的开发过程当中，往往会忽略前期的，特别是在一个复杂的系统内跨部门之间的联合测试。传统项目直到后期才开展的大跨度的集成工作，有很大失败的风险。敏捷的方式引入持续集成和测试的概念，保证全链路新开发出来的相关部分都能尽早被对应的测试覆盖。每次控制的变化的数量，保证始终有软件在开发，集成测试，初期客户验证等不同阶段进行的活动。相比而言，传统的工作方式这些步骤会存在于不同的GATE后，无法得到小步快跑的效果。
Case study
著名的咨询公司麦肯锡研究了全球企业级的敏捷实践推广, 从中分析的由此转变得到影响。包含了总共有22个组织的6大部分，得到的结论敏捷的优势主要表现在三个方面
改善客户满意度增长10%-30%
员工满意度增加20%-30%
组织执行效力改善30%-50%
最终得到财务表现提升20%-30%的结果
图四.数据来源麦肯锡研究
做为大部分工程人员，可能无法经常得到第一线接触客户的声音和反馈。这容易引发一些问题，比如忽视开发的最终目的是让产品能够经过生产加工流通到终端客户并满足客户的某些需求。一味的从技术角度，无视客户的真实需求，堆砌各种功能，最后与初衷背道而驰。敏捷开发的宣言和原则的内容都很好的倾斜到对客户的期望满足上。
当今，各个科技型公司的最有价值的部分往往是组成这个公司的人才。对于知识劳动者，比如软件开发工程人员的管理和培养，需要区别于传统流水线上的工人。是否能够更好的激发他们的主动热情，往往是一个企业文化优劣的评判标准。鼓励主动思考总结，引领创新的工作氛围也是敏捷开发过程中强调的内容。
组织的上下协同，效率优先的做事方式是精益生产与敏捷开发中对工作流和价值流的追求的目标。对得到上述的调查结果没有惊奇！如果公司上下都切实践行了敏捷方法论，得到以上结果的甚至应该是理所当然的。
WHY？WHY？WHY？
如果敏捷开发优势这么明显...
为什么还要把两种开发方式结合起来呢？
不能直接全面替换掉原有的流程吗？
敏捷开发和NPDS能共存吗？
......
NPDS的灵感来源于沃尔沃汽车的VPDS，或者某种意义上也是延续了福特汽车的GPDS。包含的内容是集成了一套完整的汽车产品所需要经历的，从概念，工程，到生产制造和售后的产品生命周期管理方法；是许多或成功或失败的项目活动经验的总结而积累起来的管理方式；也是包含了无数各个领域的专业人士的意见的集合；更是一套符合法规合规的最佳实践。 NPDS和VPDS在这些年，也在自我演进，寻求突破。从缩短开发周期，增强部门协同，减少开发人员负担，提高灵活度等多个方面做了革新。敏捷的开发源于软件工程的范畴。而汽车作为一种相当复杂的产品，除了软件以外，存在大量其他需要考虑的部分。对于某些特殊场景，无法很好的适用。例如大部分公司会有一些开发流程外的辅助体系，比如财务对项目现金流的管理或对新工厂基建的投资，需要明确的项目节点来控制。一些重要的节点仍旧需要有一种能够把包含软件在内的工作与其他交付做一个同步配合的方式。例如配合造车计划节点和上市的时间表。同时组织架构决定了我们需要一个顶层的框架来保证公司的整体方向一致。
事实的情况日新月异技术的，像软件定义汽车的概念，汽车向消费品化和服务化的转变，又需要大家来面对这一系列变化。我们要做的是取长补短，将两者的优势发挥到最大，而规避各自的弱点。NPDS与Agile的关系，做个简单的类比就像是在军事领域，不同层级的指挥官。在不同的高度需要有两种不同策略来适应实际的需要。战场上瞬息万变，在一线作战的单位需要有灵活的决策方式，而在整个战局的把控和战略层面需要有通盘考虑，整体步调协同。
Expected result在推荐NPDS+Agile的管理方法时，期望得到的结果有以下这些方面，它们也是实施的目标：
- 面对本业务相关的客户和利益相关者，将他们引入到开发中来
- 识别价值流，特别关注增值的部分
- 管理部门内外存在的依赖关系和时间线，提高效率
- 关注迭代，自省与进步的循环
- 兼顾多个集成路径上自有路线和互相配合
- 实现自我管理的团队模式，形成新的团队文化
总结：我们的目标是仍旧需要NPDS！但要对NPDS进行改造，引入敏捷开发的思想，特别是电子和软件相关的开发。而成功的关键是需要你与我的共同参与和努力！
本文的最后引用库布勒罗斯改变曲线，给大家参考当一个组织在做某项变革的时候，组织的成员往往会遇到思想转变的一个过程。其中，内部的员工对新的概念和方法有很多负面的情绪，或者不愿意接受甚至抵触新的工作流程，这些都是正常的反映。如下图可以看到由灰色色块与其他颜色的边界组合而成的库布勒罗斯曲线是一个底部弯曲的形状。当外部发生剧里变化时，有些人会一直徘徊在曲线的左边部分挣扎；也有些人会不断的努力突破自己，学习适应新的知识体系，往曲线的右边部分冲刺。 如果是你，对于这个新的工作方式NPDS+Agile，会有怎么样的表现呢？
图五.库布勒罗斯改变曲线
细心的你是否发现本文的编排也是贯穿了敏捷的思维呢？非常感谢大家的时间！后续会有一系列的敏捷开发实践与大家分享，如果喜欢本次推送的内容，请持续关注我们的渠道！
Reference
参考及延伸
https://rezaid.co.uk/agile-waterfall-software-development/
https://www.scaledagileframework.com/
https://www.mckinsey.com/business-functions/people-and-organizational-performance/our-insights/enterprise-agility-buzz-or-business-impact
https://www.scrum.org/resources/what-is-scrum
https://www.atlassian.com/blog/jira-align/agile-mindset-waterfall-projects
https://www.ekrfoundation.org/5-stages-of-grief/change-curve/
本文 【本文来源：韩国服务器 https://www.68idc.cn欢迎留下您的宝贵建议】