车机系统开发怎么敏捷?

作者在近阶段加入了车机系统开发的项目,这个包含硬件、QNX系统、AOSP的庞大项目由多个团队共同合作,实现敏捷开发无疑是一件相当具有挑战的事情,在讨论怎么在这种项目中实现敏捷就先不得不提敏捷的概念:

一.什么是敏捷

在那几乎人人熟知的《敏捷开发原则》之下,其实每个人对敏捷开发实际的定义是不同的,我现在仍记得当时一位Thoughtworks资深的顾问给我们的培训中提到:“什么是敏捷?就是快,快速反馈。”

现在敏捷开发中大众比较认可的(也是最流行的)方法论就是SCRUM和XP两种,我们这里不提这两种流行的方法论中有哪些具体实践有所差异,其最核心的我认为只有一条:SCRUM在一个迭代内(通常为两周)不允许增加新的开发任务;XP则在永远做商业最高优先级的工作,允许临时变更。

听起来SCRUM不懂得变通,感觉做不到快速反馈,对吗?

其实并非如此,SCRUM不允许在一个迭代中加入新的需求,但是开发人员/测试人员在发现BUG或缺陷时会提出问题并由相关人员进行评估,根据优先级加入到后面的某一个迭代中去,这样开发人员可以保证持续聚焦在自己的开发任务中,提高效率。XP则推崇更加灵活的处理方案,当一个临时的高优先级任务出现时它有可能会直接安排进本个迭代中来顶替某个优先级相比较低的任务,它有效的提升了开发者的“反馈速度”和“工作性价比”,但是开发人员去理解迭代开始时需求分析会议中未提及的内容会增加上下文切换时间,降低效率,因此两种方案互有优劣。而在我看来,对于开发人员来说,敏捷应当是“专注,反馈,高效”。

SCRUM工作流程图
SCRUM工作流程图

二.如何进行良好的敏捷实践

作者曾经在一个敏捷实践做的比较好的项目中工作过相当一段时间,该敏捷团队采用SCRUM模式,配有一位Scrum Master(SM),一位Tech Lead(TL)和一位Project Owner(PO),开发者们在项目期间保持了相当不错的效率与软件质量(小小的自夸一下)。从这个我个人认为比较成功的实例来看,良好的敏捷实践应当符合以下几点:

  • 有效且良好的沟通:需要什么,有什么风险要及时说出来,憋到后面难免会憋个大的,打出GG

  • 理解业务流程的TL:TL作为第一个把关人,敏捷团队的负责人,对业务流程上下文了解越清晰返工和冲突自然越少

  • 及时并高效的反馈:无论是自测还是测试人员测试,问题发现得越早补救起来花费越少

  • 积极的开发团队:敏捷开发的基石,积极的态度、不拖他人后腿的理念才能高效工作

  • 频繁且足量的测试:只要是有意义的测试用例在一定范围内(当然要考虑人工成本)怎么也不嫌多

当然,还有其他一些比较好的实践,比如SM对团队的管理、TL对各成员开发进度的把控等等,但是上面的那几个方面我个人认为是最重要的几个,它们是开发团队敏捷高效的基础。

三.车机系统下敏捷实践的困境

作者参与的这个车机系统研发项目在硬件上运行着QNX与AOSP的代码,每天各个团队的人都很忙而且常有不少人加班工作,但是效率却并不高。作者个人认为还是项目的敏捷实践并不够好:

首先:它需要硬件作为测试载体(软件应用/服务开发的测试载体通常是docker容器),这就存在硬件资源受限的问题;

其次:基于AOSP的项目在数十个团队协作下代码已经达到几百G并涉及上百个代码仓库,相比于应用/微服务这种大多在几个G左右的大小且只涉及几个代码仓库来说编译与测试的成本变得相当高昂,尤其是这么多代码在测试与Merge Request时需要一起编译的情况下更甚(一杯茶一包烟,三行改动跑一天)

再次:在与硬件、QNX一起调试和“其他因素”影响下,常有紧急的需求需要立即处理,这种XP的实践模式会令开发人员频繁切换上下文

最后:一个庞大的项目+多团队的协作下,很多开发人员不得不每天处理相当多的琐事,这令其难以专注于开发任务,而作者认为,一个琐事缠身的开发人员必然无法做到专注,无法进行敏捷开发。

四.怎么尝试改进

  1. 增加硬件设备数量:这是最显而易见的,当然,因为成本问题这也最难以实现

  2. 让更多的开发人员专注于开发:不论是进行业务开发工作还是技术难题攻坚,都需要当事人保持专注,当然这里不是说让他们两耳不闻窗外事,必要的沟通当然必不可少,但是每天都要做茫茫多的业务对接、功能沟通和评审的开发者肯定做不出什么东西(他哪有空去做呢?)

  3. 敏捷在意不在形:插个题外话,作者有很多朋友都曾说过,他们的公司也在搞敏捷实践,增加了很多敏捷实践中提到的站会(Daily Meeting)、回顾会议(Retro)等等,但是他们并没有感觉到效率的提升(事实上反而下降了):这些敏捷实践给他们套上了沉重的枷锁,这与敏捷宣言的“个体和互动高于流程和工具”完全背离,流程化、形式化的东西并不能带来敏捷,反之,它拖慢了团队的效率,开发者们为了 “应付差事” 需要花额外的精力来走所谓的敏捷流程......这还怎么谈快速反馈呢!“个体和互动高于流程和工具”是敏捷宣言的第一句话,在作者看来也是四句话中最重要的一句,以人为本、加强沟通,要拥抱敏捷的前提永远得是不敌视敏捷。如果因为要进行敏捷实践而导致了更多的加班和精力损耗,那除了老板谁会乐意去推行呢?(笑)

这里作者只是根据自己的想法聊聊敏捷思想和敏捷实践,说的这些难免出现以偏概全的地方,欢迎各位敏捷实践大佬一起讨论,也可以集思广益思考一下这个场景下的敏捷实践怎样做会更好~

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值