智能汽车+敏捷开发=?
00
序言
在智能电动汽车的时代,无论汽车产品经理在前期如何定义一款汽车,开发完毕后都可能无法完全满足客户的需求,因为消费者对于汽车的期待在今天变得既模糊,又变化频繁。
假设今天某一家汽车企业开发出一个其它车企不具有的汽车功能或特征并且刚好切中用户的痛点,那么这对其它车企来说是一种典型的降维打击。不具有迭代升级能力的传统汽车开发模式,将导致主机厂不能很快的对市场需求作出反应,这就是为什么现在主机厂都热衷于引入“敏捷”的开发“流程”。
01
传统瀑布式(waterfall)开发流程
瀑布式开发是最典型的预见性的方法,如同瀑布一样从上到下,符合人们正常的思维逻辑。其严格基于需求约定并遵循预先计划好的进度有序进行开发。注重详尽的产品规划和严格的开发流程,对开发过程中的文档和工具有明确的要求。每一个前序步骤的成果作为评价整体项目进度的指标和下一步工作开展的前提。
瀑布式开发存在几个不可避免的问题
1. 产品规划(即Requirements)必须早于其它工作之前完成,但产品经理在规划初期很难完全理解项目
2. 严格项目节点划分使得的自由度降低,导致对后期需求的变化难以调整,代价高昂
3. 若需求不明或项目进行过程中需求变化频繁,瀑布开发基本不可行
02
什么是敏捷(Agile)开发
2001年17位叛逆的美国程序员在犹他州共同发布了敏捷软件开发宣言和相应的十二条原则,其中最重要的敏捷的价值观(values)如下,左侧就是“敏捷开发”模式的核心,而右侧就是“传统开发”模式的核心。“高于”其表明敏捷思维下,尽管右项有其价值,但敏捷开发更重视左项。敏捷开发就是遵循的敏捷的价值观,因此提到敏捷不应该想到各类方法论或者工具。
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
敏捷价值观不限于行业,如果开会的时候每个人都必须站起来(即每日站会),那么卖鞋子的商贩会告诉你,鞋子越舒服团队越敏捷。敏捷项目开发过程中团队成员都运用敏捷价值观和敏捷原则来做出决策,这就是敏捷开发。
03
典型敏捷开发过程Scrum
Scrum的核心可以概括为“化繁为简”,Scrum将整个项目被分为不同的小部分,首先围绕最小可行且优先级最高的产品特性进行产品规划/开发/测试和评审,得到一个可向用户发布的版本,一般这个过程一般持续1-4周左右,称之为一个冲刺(Sprint)。通过每个Sprint的和客户进行充分的沟通,及时根据用户需求变化进行调整。
产品往往有诸多功能和特性,不断重复这个Sprint过程直到产品功能齐全,称为迭代。可能在第二次,第三次或者第N次Sprint发布的时候,就能构成包含所有功能的汽车产品。
Scrum解决的痛点是团队无法在项目初期就了解全部内容,更不能保证这些内容不会发生任何变化。根据功能需求的优先级完成主路径,再通过不断地迭代去完善,这样当需求产生变化时推翻的工作量较少,并能够很快的完成新的需求变更。
04
典型敏捷开发过程Kanban
Kanban方法最初起源于丰田,以价值流动为核心,不断发现团队中的瓶颈工序并改进。Kanban的特点是工作流程形象化,把工作细分成任务,写在卡纸上并贴在墙上的不同状态栏。通过下游直接拉动上游的工作任务能极大的避免资源闲置和浪费。同时Kanban会明确限制在制品的数量(work in progress),即明确设定在每个状态栏下同一时间最多有多少工作任务,保证团队成员不会任务过重。
Kanban没有Sprint的概念,但在每个功能模块开发测试完成后(即进入Done栏)就可以进行及时发布。
05
汽车行业敏捷开发的不足
敏捷开发的名字非常好,容易让人联想到快速高效,但这并不意味着敏捷开发在汽车行业就一定是高效的,常见的情况如下:
1. 汽车行业某些固定的产品和功能,需求往往是长期不变的。其开发目标都由国标、行标以及企业内部标准提前规定,对于这样的固定需求项目,敏捷应对需求变化的优势不复存在。
2. 如果团队没有真正遵循敏捷价值观,却要求项目成员运用某种指定“敏捷”工具,按照一套既定的方法进行交付和迭代,这种开发方式和敏捷价值观恰好相违背,敏捷反而成了额外的工作负担。而瀑布式开发在早期已经规定好每个阶段的交付物,容易确保项目稳定的推进。
3. 敏捷开发强调团队成员的沟通,但是如果一个团队过于庞大或者人员变动频繁,敏捷开发难以开展或者只能在局部开展;相反的瀑布流开发中强调文件存档和工作流程则更为适用于此种情况。
敏捷开发一定是在软件定义汽车时代下智能网联电动汽车项目开发的重要路径,但实际运用中应该考虑产品特性和团队实际,在尊重敏捷价值观和原则的前提下探索汽车项目敏捷开发的合适路径。
-如果您喜欢这篇文章,或者觉得这篇文章对您有帮助,请点击下面的名片加关注,关注和转发是对笔者最大的支持!