敏捷开发方法在汽车仪表软件研发中的应用

敏捷开发方法在汽车仪表软件研发中的应用谢超【摘要】随着汽车电子化程度加速提高，汽车仪表软件的需求不断丰富，这种变化对汽车仪表软件开发质量和交付速度都提出了全新的挑战.要应对该挑战，软件开发流程必须加以改进，以快速响应不断变化的需求以此为背景，深入阐述了敏捷开发方法在实际项目中的具体应用，为同类从业研究人员提供借鉴.【期刊名称】《汽车零部件》【年(卷)，期】2014(000)003【总页数】4页(P52-55)【关键词】敏捷开发;Scrum;汽车仪表软件【作者】谢超【作者单位】大陆汽车电子南京软件研发中心，江苏南京211100【正文语种】中文0引言敏捷软件开发的概念在2001年由施瓦伯与麦克•比窦正式提出，它旨在改善软件开发在需求快速变化中的应变能力，并已经在通信、互联网网站、手机终端等IT行业的软件开发中得到了极大的发展［1］。在汽车电子仪表行业中，由于各家供应商的软件开发受到汽车整车厂整体的研发规划控制，同时其需求相对简单稳定，更多的是采用了传统的瀑布开发模型［2］控制软件过程和质量，敏捷开发方法鲜少触及。但是近些年来，伴随着汽车电子化程度加速提高，以及各种电子控制芯片ECU的硬件性能显著提高［3］，这都极大地丰富了汽车仪表产品的需求，同时对于供应商的软件开发质量和交付速度都提出了全新的挑战，敏捷开发方法在汽车仪表行业的应用成为了可能。作者以此为背景，深入阐述了敏捷开发方法在该领域中的应用。1敏捷开发Scrum过程敏捷软件开发思想强调软件开发团队与业务专家之间的紧密协作、人之间面对面的沟通、软件版本的持续交付和紧凑而自我组织型的团队。它与传统的瀑布开发模型相比，能够更好地适应软件项目的快速需求变化以及更频繁的交付场景。实现敏捷软件开发的核心是Scrum过程，它是在开发一个项目或产品中应用的一系列迭代增量产出的过程框架。Scrum中参与人员的主要角色包括：Scrum教练和团队带头人(ScrumMaster)。确保团队合理的运作过程，并帮助团队移除实施中的障碍。产品负责人(ProductOwner)。确定产品的方向和目标，定义产品发布的内容、优先级及交付时间。开发团队(Team)。一个跨职能的小团队，人数一般少于10人，团队拥有交付可用软件需要的各种技能。如图1所示，Scrum过程总体来说由数个可以分割的冲刺阶段(Sprint)组成，每次冲刺阶段一般2~4周左右，开发团队可以从产品需求列表(ProductBacklog)中决定在此冲刺阶段要实现的需求。产品需求列表是按照优先级排列的要完成的需求列表，哪些需求项会被加入此次冲刺将由冲刺阶段开始时的计划会议决定。在会议中，产品负责人(ProductOwner)告诉开发团队他需要完成产品需求列表中的哪些需求，开发团队则会决定在此冲刺阶段中他们能够承诺完成多少需求项，并形成冻结的冲刺需求列表(SprintBacklog)。在一次冲刺过程结束时，开发团队要把开发的软件展示给产品负责人以及其他相关关注者，并获得问题反馈，以更新下一次冲刺需求列表的增量内容。以此类推，最终实现产品需求列表中定义的全部功能。在每次冲刺阶段后，软件系统的状态必须已经集成完毕并且随时可以释放给客户使用。在管理Scrum过程中有很多实施方法，包括但不限于看板、燃尽图、每日站会、回顾会议等，文中在下面的章节中会一阐述其应用。图1敏捷开发Scrum过程2需求开发Scrum过程的主要准备工作就是挖掘需求创建产品列表(ProductBacklog)。在早期的仪表软件开发中，由于需求相对简单，一般整车厂在项目开始初期就能定义出完整的功能，单独固定的需求文档就已经可以满足开发要求。但是作者在该软件开发过程中，发现其复杂度显著上升，其中不确定的需求量较大，如全尺寸屏幕动画性能定义、报警显示优先级和人机交互策略定义等。在项目开始时，产品负责人只能从整车厂得到初步的需求，并且会在后期对于需求的要求会不断更新。因此为了更进一步分析复杂的仪表需求，作者创建了产品需求列表(如图2所示)，对于需求加以管理。其中包括了需求标识号、需求内容、项目名称、计划的软件版本、优先级、状态、类别、完成时间以及预估的工作量。对于需求内容，采用用例(UseCase域者用户故事(UserStory)的方法以驾驶员的使用语言描述出来。如所示的列表第23343项目中，描述了屏幕内菜单选择提示需要与右侧滚动条同步的描述。这是一个很详细且现实的用户需求，作者以表格规定的方式体现在产品需求列表中。对于复杂的需求，可以进一步分解成更细的需求，并建立子需求项目列出。如在仪表中实现道路偏移信息显示功能，要考虑总共应该显示的信息元素或画面，同时还要安排策略防止显示信息冲突。因此需要细化该需求并列出子要求在列表中，如在所示的列表第51738项中描述了为车道偏移显示界面创建一个静态动画，做为实现整个车道偏移信息显示功能的其中一个子功能，这样逐步分解确保功能实现的完整性。同时对于项目的内部开发活动（如代码评审等）也可以一并列入。如所示的列表中第50614项目，它直接描述了一个评审代码模块的任务，以跟踪开发人员的执行状态。图2产品需求列表示例这样该产品需求列表就包括了开发团队应完成的任务集，是团队在开发过程的唯一需求输入和人物列表。如果在开发后期整车厂提出需求需要更改功能时，可以根据现在已有的需求列表完成状态快速方便地评估出该变化对于项目产生的影响，较为准确地规划后期的功能实现计划，做到及时响应客户的需求。由于该表清楚地定义了每一个需求和任务的优先级和完成时间，因此它还是一个详细的软件开发计划，可以作为整体项目计划的细化文档，由此避免了因需求不断增多而造成的需求管理混乱和软件质量问题。该产品需求列表在Scrum过程中根据客户的实际需求和团队内部活动状况不断更新状态，直到研发结束。3冲刺阶段软件项目开发的节奏被细分为数个冲刺阶段，这些阶段兼顾了整车厂的测试计划和该项目其他部门（如硬件电子和机械设计等）的研发计划来确定。在每个冲刺正式开发前，产品负责人和开发团队都会召开冲刺规划（SprintPlanning）会议，该会议包含两部分：第一部分是需求简报，产品负责人从仪表需求列表中选取具有高优先级的用户需求并阐述澄清，让开发团队成员充分理解需求含义。会议内容只涉及具体需求，一般控制在2h左右；第二部分为开发团队成员间具体的技术实现讨论，最终由他们自己决定在此次冲刺阶段可以完成的功能需求，并在产品需求列表标识出来以便追踪。这种由开发团队自己做出的目标承诺与以往项目经理分配的目标承诺相比前者应更为可靠，因为在软件开发中只有开发人员最了解自身实际的情况，包括在当前阶段的可用工作时间、技术能力状态等。图3显示的是一个实际冲刺阶段中的人力资源状态。它定义了每个开发人员可以利用的工时和已经定义的冲刺时间段，这样就可以让团队开发人和产品负责人制定出一个合理且现实的产品功能实现计划，防止相关开发人员因工作负荷过重导致工作效率下降，进而影响软件质量。图3人力资源状态示例一旦开发团队做出了目标承诺，开发工作随即展开。团队带头人可以把所有这个冲刺阶段的需求任务罗列在看板上形成一个冲刺需求列表(SprintBacklog)，以便清晰明了地向团队展示项目状态，让其他利益相关者追踪软件开发进程。如图4所示，每一个需求开发任务都应该被归类在〃待完成”，“正在进行”，“待验证”〃已完成”4个状态中的任意一个。例如在开发自适应巡航信息显示功能时，把该功能作为一个总的功能表述，同时分解该功能并放入〃待完成”项目中，包括静态信息、动态信息、报警信息、人机交互冲突管理策略等；当开发人员开始实现人机交互冲突管理策略子功能时，该功能就应进入〃正在进行”状态；当该子功能编码完成后应进入〃待验证”阶段中，进行模块测试验证；如果测试通过则最终进入〃已完成”状态。在实现相对该功能时，各子功能有其互相依赖性，因此需要在所有相关子功能都进入到〃待验证”阶段中时才能测试该功能的正确性，通过后才能进入〃已完成”状态，在此时才能说该功能正真被开发完成。图4看板-冲刺任务列表示例Scrum过程强调开发人员之间充分沟通以快速了解项目的开发状态，但是这种沟通又不能太过于频繁，这样也会导致花过多的时间在交流上而不是软件开发上。在实践中，作者认为每天站会(StandingMeeting)的形式是一个比较好的方法。每个工作日的开始，团队人员会围绕在看板面前，依照自己负责的需求状态，主动交流3个问题，即：自从上次开会以来你做了些什么？今天你计划做什么？现在有无遇到任何困难？对于成员遇到的困难，团队带头人会做记录并对简单的问题做快速阐述，对于相对较困难的问题则会另行召开专题会议讨论。整个站会最多持续30min，目的明确，简单高效。它既能快速解决一些问题，又能让大家了解最新的状态，同时对于任何一个遗留问题都有具体的下一步行动计划。避免了在传统的开发模式下，开会总会陷入具体问题的讨论，或者开发团队只有在一段时间（1周或者1个月）之后才能了解项目状况的情况［4］。对于开发进度相对落后的程序员，其他成员的开发状态可以潜移默化地对该开发人员产生危机感，无形中可以激励开发人员的能动性，以达到提高其工作效率的目的。在每个冲刺阶段的开发过程中，团队成员都会根据自己的进度更新工作量的消耗状态，团队带头人会做总结记录并以燃尽图的形式实时客观地反映在看板中。如图5所示，该燃尽图显示了在开发仪表自动泊车系统信息显示功能的所花时间（横轴）和实现的功能数量（纵轴）的关系，其中虚线是一条预估的功能实现趋势，当实际的功能实现速度在此线之上，则说明有些功能开发花费了比原来预想更多的时间，需要进一步改进软件开发效率；如果实际的功能实现速度在此理想线之下，则说明了整个开发速度快于理想定义状态，需要检查软件质量并进一步优化预估的开发速度。图5看板-燃尽图示例该自动泊车系统信息的显示功能在初期开发阶段比较符合预定义的趋势，但是在后期由于人员低估了自动泊车系统与倒车雷达提示信息显示的需求冲突导致了所花时间高于预估，因此团队带头人根据此燃尽图的信息及时了解该问题的产生根源，迅速对于此问题做了专题研讨会，有效地解决了技术问题，并在最后赶上了预定的开发进度。因此燃尽图起到了项目风险预警提示功能，为开发团队尽早发现并解决问题提供了可靠的决策信息基础。在汽车仪表软件开发中，如果遇到任何新的需求输入，则产品负责人不会因此而干涉当前的冲刺阶段，而是会评估这些需求优先级，并更新产品需求列表，放入下一次的冲刺阶段中让开发团队讨论实现。这样的做法可以解决软件开发需求频繁波动造成的软件质量问题。从项目管理的宏观层面上来看，由于每个冲刺阶段时间并不长(一般2~4周)，整个项目开发实现了对客户需求的快速反应。4软件释放由于仪表软件需要在若干样件阶段集成相关其他硬件后才能验证功能(例如软硬件匹配等)，因此需要为每一个样件释放周期前计划一个专门的软件释放冲刺阶段(ReleaseSprint)去完成验证(如图6所示)，从而确保软件质量。开发团队会在该冲刺阶段中安排一次软件功能展示会(Demonstration),让产品负责人按照客户的需求测试该软件功能，判断是否满足客户要求并释放给客户。如果测试失败，则需要把这些失败的功能重新列在下一次冲刺的产品需求列表中去更正，并在释放文档中做出说明。图6冲刺阶段计划示例当软件团队完成了冲刺阶段之后，软件系统已经集成好，并已被测试过，该软件系统就具备了释放的状态。如果整车厂有临时需要，软件可以满足其要求释放，以便快速得到测试反馈结果，而不必等到最后样件释放阶段。在软件释放后，此次冲刺阶段并没有立即结束，开发团队和带头人需要在一起回顾此次开发中的经验教训(SprintRetrospective),讨论此次开发做得好的方面和需要改进的方面。这样可以使团队得到有效的激励，同时找到团队的弱点并得到及时改进，并让后续项目开发受益。在整个Scrum过程实践中，同样的项目回顾会议会召开多次(而不是在项目最后结束时才会做)，这是团队持续自我完善的重要方法。5敏捷开发实施所面临的挑战经过实施敏捷开发Scrum的实践，项目开发的效率、质量以及团队建设都得到了明显改进和提高。但是它在具体运作时还需注意以下几点：(1)团队建设方面，敏捷开发方法高度依赖团队中每一位成员的专业素质，它需要每位开发人员主动积极地参与才能成功，因此前期对开发人员的培养十分重要。(2)过程管理工具方面，由于敏捷开发方法还处在发展中，它的自动化支持工具较少［5］，需要实施方灵活运用现有的项目管理工具去实现(例如看板，变更管理工具)。⑶质量流程方面，敏捷开发方法并不与CMMI等质量管理体系标准冲突，它反而是实现该质量体系要求的重要手段之一。因此实施方需要充分理解敏捷方法的思想，并结合项目本身的状况对流程进行优化裁剪，最大化促进其作用。⑷该开发方法的实施需要得到供应商和整车厂双方组织级层面的理解和支持，必要时需要在项目早期启动时做专题讨论并达成一致。6结束语汽车工业在中国的发展日新月异，汽车电子系统的需求也越来越复杂。文中所论及的敏捷软件开发思想在汽车仪表软件中的实践应用，作为应对这一大趋势的可能方案之一非常重要。事实证明：这种开发模式取得了阶段性成功，开发的产品也已经批量生产。这对于汽车仪表软件的项目开发有着重要意义，值得同类从业研究人员借鉴。【相关文献】【1】BeckK,BeedleM,vanBen