传统项目的敏捷管理

前言

??都说这个时代唯一不变就是“不断在变”，开发一个产品的思路也从“你需要什么我给你做”越来越多地变成了“这个你应该需要我先做给你看看”，需求的变化变得越来越频繁，因此项目的管理方式也发生了变化，“现在”流行叫法是“敏捷”。这一词起源于2001年春天的一个程序员集会，但在此之前就已经有很多软件开发实践了。
??先放个著名的“敏捷宣言”镇楼：
??个人与互动 大于流程和工具
??可工作的软件 大于详尽的文档
??客户合作 大于合同谈判
??响应变化 大于遵循计划

方法解读

??敏捷属于轻量化的开发方法，这个“轻”指的是轻装上阵，并不是指量级。从宣言中可以看到它强调的是在开发过程中充分沟通，快速地将结果呈现到客户面前，并随时准备好响应反馈，持续迭代，所谓敏捷。
??个人觉得把敏捷方法推广开的应该就是互联网各种衍生应用（云大物移），因为大部分情况是纯软件开发，人员构成相对简单（产品经理、开发、测试、运维以最小作战单元实施），沟通相对方便，加上用户需求又不明确，需要不停地更新试错，敏捷用起来如鱼得水。当然随着需求越来越复杂，操作起来肯定又不够敏捷了，所以倒逼技术演进（包括硬件、操作系统等），产生诸如容器、微服务架构这些，既快也要好。
??大家尝到敏捷的甜头，更促进了敏捷这个思想方法向其他领域传递，形成趋势和共识，比如项目管理PMBOK是很强调做计划的（五大过程组中就有个规划过程组，专门有个过程叫“制定项目管理计划”，被称为计划的计划），按计划实施，发生变化要申请变更然后更新计划再更新一堆文档，甚是不敏捷，但几乎每个过程都介绍对敏捷项目的处理（我学的是第6版，预计下一版篇幅会更多）。能力成熟度模型集成CMMI起源于美军软件开发使用需求，主要针对的是庞大复杂且需求较为成熟的项目，但其实它站位比较高，只设目标而不给任何具体实践方法背书，所以在V1.3版本中，多个过程域（CM, PI, PMC, PP, PPQA, RD, REQM, RSKM, TS, and VER）中就加入了对实施敏捷项目的指导性描述，而到了最新的V2.0，则提供了更多的敏捷方面指导，尤其扩展到跨项目的实施，以帮助敏捷在组织中实现规模化。
??敏捷之所以受到认可是因为它是切实可行的，而“敏捷宣言”的开头第一句话“我们一直在实践中探寻更好的软件开发方法”，也印证了它生来就不是玩虚的。

传统项目应用

??虽然敏捷起源于软件开发，但其实有些思想或者说是目标和其他领域也是相通的（大家都是人，痛点也会一致），比如说敏捷中有个流行的实践方法叫“Kanban”就是来自于精益生产。
??传统项目因为一些因素缺乏实施敏捷方法的先天优势：
??1. 人员的思维及能力没有跟上；
??2. 项目类型不合适，比如开发一辆车，有些工序时间就比较长，并且做Demo需要真材实料，试错的成本也大；
??3. 公司内部环境，比如组织架构上缺乏职责定义，领导层不支持等；
??4. 客户接受度，并不是每个客户都愿意花时间提前给你做大量预验收的。
??但不合适归不合适，用户需求升级，市场竞争激烈的现实摆在眼前，所以越来越多的传统项目在实施过程中也开始拥抱敏捷的思想，有好东西干嘛不试着用用呢br>

个人实践

??本人目前所在公司业务在传统的汽车行业中也属于传统的了：电子控制器，并且还以发动机控制器为主。乍一看比什么“软件定义汽车”、“无人驾驶”、“车联网”等热点低了好几个level，而且发动机注定要被取代，但产品定位不同，有市场需求就有生存空间，比如拖拉机等农机在中短期就不会用上这些热点技术，不是没有应用意义而是成本不现实。因为需求比较明确，且通常变化也不大，公司主力产品更多地是遵循瀑布模型这样传统的开发方式，当然也会应用一些敏捷实践技术，比如CICD。
??而本文分享的实践是我负责一个项目时对敏捷方法所做的尝试，受条件和经验所限，所以并不完全是敏捷式开发，可以视为传统项目敏捷化的一种过渡态。

项目背景

??项目目标：基于某传统燃油车改装成混动车Demo，用于客户展示。
??回忆当初接到这个项目时竟然还比较乐观（无知者无畏），以为就是找供应商，交给他们做就完事了。后来发现整车结构可以找供应商帮你改装，电动零部件也能找供应商买和调，但是HCU要完全自己来（因为我们自己就是做控制器的）。
??当然找供应商改装也多有波折，这里就不详述了，主要围绕HCU开发这个子项目，因为项目发起人（CTO，内部客户）想要速战速决，加上没有现成的匹配资料，所以给的指导意见是怎么快怎么来，提供的大体思路是：硬件用快速控制原型设备RCP，这样也避免了开发基础软件，应用软件他之前有些开发经验可以提供参考，再从提供改装的供应商那边挖掘一些信息。
??整理下HCU开发的要求和条件：
??1. 范围，完成一辆混动车改装，HCU自己开发，其他零部件供应商提供，无具体需求，能开就行；
??2. 时间，初始期望2个月……
??3. 人员，不算我，负责HCU开发的有3开发+1集成+1仿真+2测试，普遍缺乏相关经验，仅有1名开发人员以前做过混动大巴项目，1名测试人员接触过混动控制器；
??4. 风险，很大，巨大，极大……（不一一列举）。

项目规划

??按上面的分析，HCU开发就没法用传统方法了，第一步需求就卡死了，反而有一些适合敏捷，对此项目发起人也无异议，所以就尝试按SCRUM走起来：

从各技术部门抽调的相对合适人选（之前在别的项目也合作过，能力及工作态度都是认可的），因为人员是敏捷开发得以实行的关键
每日上午召开项目站会，讨论最新进展，抛出问题，评估风险
遇到重要问题召开专门会议进行讨论，邀请CTO参加，比如通过头脑风暴来把一些需求达成共识，形成User Story。
2周1个Sprint，本次的回顾会与下次的规划会合并，邀请项目发起人CTO参加，回顾本次开发成果，确定下次目标，梳理Backlog，使用Jira作为管理工具
项目经验积累及资料共享使用Confluence
所有项目团队成员安排就近坐，便于当面沟通，包括自己（承担了部分应用软件开发工作）
开发新的集成脚本打通快速原型设备的基础软件与CI环境之间的壁垒
尽早测试原则，模型审查，模块单元测试，RCP端接口测试，整车改装未完成前用模型进行仿真模拟，不采用HiL验证直接上整车跑
至于时间节点，实在没谱，只能走一步看一步，后面再走项目变更了（大部分PM的心声吧）

项目实施

??HCU开发过程主要分为以下几大块：

电气架构、网络拓扑梳理
应用软件模型搭建（含快速控制原型设备驱动库应用）
软件集成环境构建
测试（模型功能及软硬件接口）
油耗仿真及优化
整车集成及调试
整车油耗试验及验收
??要意识到这本质上是一个传统项目：软件无法独立于硬件运行，而硬件也无法独立于环境产生有意义的效果，环境又依赖于整车改装进度和可行驶场地。
??这种情况下要严格遵循敏捷，在每个迭代都能给客户交付些可工作的软件是不现实的，但是依然是可以交付出一些可见的东西的，比如在前6个Sprint定的目标分别为：
??Sprint 1 – “完成电气架构梳理，完成油耗试验分析报告，整车仿真模型搭建”
??Sprint 2 – “完成应用软件初版定义，分析快速控制原型设备驱动库”
??Sprint 3 – “完成全局变量、输入输出模块，完成CAN通讯矩阵，完成可用的集成脚本”
??Sprint 4 – “完成状态管理、系统约束模块，完成集成后的IO接口测试”
??Sprint 5 – “完成状态管理、驾驶意图判断模块”
??Sprint 6 – “完成扭矩管理模块，完成集成后的CAN接口测试”
??可以看到在第一个Sprint貌似都没有出现软件的开发工作，主要原因在于团队基础太薄弱，首先要打基础，了解混动架构是怎样的，HCU是如何工作等一系列问题，但即使如此还是有不少输出物交付给内部客户（CTO）去检查的，比如电气架构图梳理出来一部分需求也出来了，油耗试验分析报告则是用于了解原车燃油动力总成的油耗水平，整车仿真模型是有现成的example参考所以可以直接生成一版。结果是良好的，CTO反馈了意见，并结合他的经验给我们提供了更多的需求输入，其中就包括大体的软件框架。
??第二个Sprint再接再励，形成软件框架的初版设计，并完成各个模块的功能定义，子模块的划分，Simulink建模环境也搭起来，商定了建模规范，如变量的命名规则、模型需要填写的接口信息。同时在供应商的协助下，也对快速原型设备驱动库应用有了一定了解，实现了一个小的Demo（实现一路AI控制一路DO），这个小Demo为后续搭建我们自己的集成环境打下了很好的基础。当然过程中CTO也参与了我们应用软件模块定义的讨论，帮助完善，看到我们有实在可见的进展，因此也对团队工作给与了认可。
??第三个Sprint才正式开始进行软件的实现，并且最开始只是实现外围的一些公共功能，一方面是因为这部分确定性高，后续改动小，另一方面这部分完成后可以去调试集成脚本，甚至进行接口测试，而此时内部逻辑功能模块可以用空模块代替。这个Sprint为模型开发起了一个很好的头，环境和规则确定了就好比柴火锅灶都准备好了，接下来可以烧菜了。呈现给内部客户的是软件框架的模型实现，当然对方提出了他的期望，即输入输出模块和功能逻辑模块完全解耦，便于做功能仿真验证，很好。但由于快速控制原型设备驱动库的使用较为复杂，规则限制较多，所以集成开发脚本在本次Sprint未能达到一个可用状态。已开发好的模块通过交叉审查、PC仿真的方法进行Debug，软件单元的迭代已经开始了。
??第四个Sprint完成一版可用的集成开发脚本，终于生成出第一版可测试的软件，并且在电气环境下通过了信号输入输出测试，是个很大的进展。对快速控制原型设备驱动库应用的主要问题解决了，接下来就可以集中开发功能模块已经进行通讯配置，但由于混动系统相比燃油系统运行模式复杂得多，HCU还需要协调多个控制器，所以状态管理模块未能在这个Sprint完成。
??第五个Sprint状态管理模块完成并且评审通过，驾驶意图模块也有了个雏形，整个产品的完整度又更近了一步。
??第六个Sprint进一步补齐了原定软件架构中的模块，并在实验室电气环境下测试了CAN通道信号的收发测试。但此时部分模块内容是暂定或者缺失的，只能说是结构上大体完整了。
??至此在春节前共推进了6个Sprint，虽然软件框架实体基本完整了，集成也打通了，接口还测试了一轮，但离项目目标还很远，不过受益于敏捷的开发方式，整个团队都很清楚当前状态，并且对内部客户来说，每个Sprint都有可见的交付成果出来，过程中的沟通也相对多很多，还是比较满意的。再加上供应商那边也未能如期交付改装后的整车，所以从整个项目的关键路径看，HCU的开发工作并没有成为瓶颈。
??接下来受疫情影响，部分人员无法上班，减小了每个Sprint包含的User Story，项目进度自然也因此延后，最终整个项目共花了13个Sprint完成交付。其中迭代到第8个Sprint时进入整车调试阶段。迭代到第11个Sprint时目标功能开发完整，进入调优。

经验总结

由于自己还负责其他事宜，所以无法全程和团队人员在一起开发，受传统管理思想影响，我还是习惯把控全局，要求所有发现的问题都要有记录，这带来了开发人员很大的抵触，因为团队面对面沟通问题解决问题，可能很快就完成了，却还要把已经解决的问题再文档化一遍，非常耗时且无意义（本项目首要目标是时间，非关键问题可以妥协）。所以到开发中后期，我基本已结束了这个没有必要的坚持，让结果去自证吧。但有借鉴意义的教训还是会让他们记录到Confluence。
团队欠缺开发经验，虽然尽量搜集了可参考资料，部分功能需求还是只能靠想，先从逻辑上保证正确性。好在组建团队时挑选的都是思维敏捷、善于探索的成员，且有一定的自组织潜力，所以虽然在头脑风暴时大家讨论激烈，但都是就事论事，也没有影响后续的合作。从这点理解实施敏捷中“个体”的重要性。当然我自己也是如此，从理解和信任的角度去看待成员给我提的意见甚至批评。一句话，格局放大些。
讲讲整车调试的问题，因为第一次，搞了不少教训。比如电池电量小，开始没注意监测，SOC掉到允许充电阈值以下，导致叫厂家售后；忽视了附件控制重要性，DCDC一直工作会把动力电池的电补给原车蓄电池导致电量下降快；对快速原型控制设备上下电条件没有看全，导致高压系统和HCU无法下电……好在之前计划了稳妥的调试策略：“原地驻车上电换挡->原地驻车起停充电->纯油行驶刹车->纯电行驶->混动行驶”，没出安全事故。同时相应地调整Backlog中的优先级顺序，比如附件控制模块的开发本来优先级很低，测试到问题后立即加入到当前Sprint中来。
即使功能开发完成，上转毂台架试验时仍然有很多不足，主要是动力性方面：离合器结合冲击大，有时候还会把发动机憋熄火；换挡过慢车速无法跟随循环工况，且平滑性不好；最高车速过低，比原纯燃油动力时还低……遇到的问题如果是软件导致，就采取快速迭代就地解决，安排两波人，前方1波在整车旁验证，后方1波在办公室修改软件，集成通过就发送给前方，基本上也能做到1天迭代2-3个版本，最终验收时的版本号转换成数字是127，这在传统开发中是很难想象的。
和供应商之间没有做到敏捷中的足够“互动”，比如在实验室环境虽然完成了CAN通讯测试，但都是基于我们自己对各xCU通讯协议的理解，或者虽然供应商有解释但我们理解的和实际仍有差别，所以拿到车上后出现各种控制不正常甚至不工作，返工花了不少时间。
当然项目实施过程中不免受到外部环境因素影响，比如在项目后期因公司政策变化导致不少人员离职，我的团队也陆续有各职能人员离开，累计过半，尤其是测试人员差点换了两波，而且又是在测试、验收的关键期。这个时候体现敏捷优异性的一点就是大家对项目整体都比较了解，一些工作之前也是有相互cover过，所以在有人离开后其他人能快速接手，加上大家交接也都非常负责，项目验收没有受到太大影响。
回顾下敏捷的四条宣言，大多数还是做到了，并且管理工具、流程这些相对次要的也是起到作用的，项目在遇到不少困难情况下没砸自己手上一定程度上还算成功。不过有个项目的优势在于没有盈利目标，再加上属于“吃螃蟹”，可以放开干。
想象下，如果做的这个项目有成熟的产品和技术积累，测试设备和时间充裕，人员充足且高效。哪些地方可以改善，更敏捷化呢人觉得最大的变化在于从开发到测试实现更全面的迭代，按熟悉的V流程来看，现实项目走的是“系统测试开发”这个大循环迭代，如果理想化后就能把在PC上运行的，甚至HiL环境运行的都加入到持续集成测试中，增加了更多更底层的“单元测试开发”、“集成测试开发”这些小循环迭代，花在用户环境上的成本就能变小。另外如果有较高精度的MiL、HiL仿真环境就能做TDD，BDD开发。当然对业务的熟悉还可以加强沟通有效性以及降低风险。
实施敏捷后带来的负面影响，想了下，本项目没有，因为也就这条路能走。对于传统项目的话，主要就是人员、技术的需求门槛变高，以及要领导支持和客户有一定容忍度，最好愿意参与开发细化需求，按个人经验想想还是有些难度的，如果硬要实施不作变通那可能导致失败。比如提前得到领导保证并不断给他提供信心，设定合理的Sprint周期，把控好释放给客户版本的成熟度等。

尾声

??传统项目做敏捷就是要保持开放的心态充分沟通，以人为本，突破环境限制去呈现产品可视化的部分，才能向客户或者项目发起人确认，得到反馈不断迭代。考虑到FOTA是以后汽车电控发展的大趋势，软件开发必然会要求越来越敏捷，所以还在做传统项目的我们必须要用发展的眼光看待敏捷，尽早武装自己的思想，适应变化。

??最后以“敏捷十二原则”压轴：

我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
业务人员和开发人员必须相互合作，项目中的每一天都不例外。
激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
可工作的软件是进度的首要度量标准。
敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
以简洁为本，它是极力减少不必要工作量的艺术。
最好的架构、需求和设计出自自组织团队。
团队定期地反思如何能提高成效，并依此调整自身的举止表现。

本文部分观点学习于:
1. 敏捷与CMMI的同与不同
2. 《敏捷转型-打造VUCA时代的高效能组织》　王明兰著
3. 《敏捷项目管理-快速交付创新产品（第2版）》　吉姆·海史密斯著

来源：sankever

声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！