敏捷開發方法在汽車儀表軟件研發中的應用

謝超

(大陸汽車電子南京軟件研發中心，江蘇南京 211100)

0 引言

敏捷軟件開發的概念在2001年由施瓦伯與麥克·比竇正式提出，它旨在改善軟件開發在需求快速變化中的應變能力，并已經在通信、互聯網網站、手機終端等IT行業的軟件開發中得到了極大的發展[1]。 在汽車電子儀表行業中，由于各家供應商的軟件開發受到汽車整車廠整體的研發規劃控制，同時其需求相對簡單穩定，更多的是采用了傳統的瀑布開發模型[2]控制軟件過程和質量，敏捷開發方法鮮少觸及。但是近些年來，伴隨著汽車電子化程度加速提高，以及各種電子控制芯片ECU的硬件性能顯著提高[3]，這都極大地豐富了汽車儀表產品的需求，同時對于供應商的軟件開發質量和交付速度都提出了全新的挑戰，敏捷開發方法在汽車儀表行業的應用成為了可能。作者以此為背景，深入闡述了敏捷開發方法在該領域中的應用。

1 敏捷開發Scrum過程

敏捷軟件開發思想強調軟件開發團隊與業務專家之間的緊密協作、人之間面對面的溝通、軟件版本的持續交付和緊湊而自我組織型的團隊。它與傳統的瀑布開發模型相比，能夠更好地適應軟件項目的快速需求變化以及更頻繁的交付場景。

實現敏捷軟件開發的核心是Scrum過程，它是在開發一個項目或產品中應用的一系列迭代增量產出的過程框架。Scrum中參與人員的主要角色包括：

(1)Scrum教練和團隊帶頭人(Scrum Master)。確保團隊合理的運作過程，并幫助團隊移除實施中的障礙。

(2)產品負責人(Product Owner)。確定產品的方向和目標，定義產品發布的內容、優先級及交付時間。

(3)開發團隊(Team)。一個跨職能的小團隊，人數一般少于10人，團隊擁有交付可用軟件需要的各種技能。

如圖1所示，Scrum過程總體來說由數個可以分割的沖刺階段(Sprint)組成， 每次沖刺階段一般2～4周左右，開發團隊可以從產品需求列表(Product Backlog)中決定在此沖刺階段要實現的需求。產品需求列表是按照優先級排列的要完成的需求列表，哪些需求項會被加入此次沖刺將由沖刺階段開始時的計劃會議決定。 在會議中，產品負責人(Product Owner)告訴開發團隊他需要完成產品需求列表中的哪些需求，開發團隊則會決定在此沖刺階段中他們能夠承諾完成多少需求項，并形成凍結的沖刺需求列表(Sprint Backlog)。在一次沖刺過程結束時，開發團隊要把開發的軟件展示給產品負責人以及其他相關關注者，并獲得問題反饋，以更新下一次沖刺需求列表的增量內容。以此類推，最終實現產品需求列表中定義的全部功能。在每次沖刺階段后，軟件系統的狀態必須已經集成完畢并且隨時可以釋放給客戶使用。

在管理Scrum過程中有很多實施方法，包括但不限于看板、燃盡圖、每日站會、回顧會議等，文中在下面的章節中會一一闡述其應用。

2 需求開發

Scrum過程的主要準備工作就是挖掘需求創建產品列表(Product Backlog)。在早期的儀表軟件開發中，由于需求相對簡單，一般整車廠在項目開始初期就能定義出完整的功能，單獨固定的需求文檔就已經可以滿足開發要求。但是作者在該軟件開發過程中，發現其復雜度顯著上升，其中不確定的需求量較大，如全尺寸屏幕動畫性能定義、報警顯示優先級和人機交互策略定義等。在項目開始時，產品負責人只能從整車廠得到初步的需求，并且會在后期對于需求的要求會不斷更新。

因此為了更進一步分析復雜的儀表需求，作者創建了產品需求列表(如圖2所示)，對于需求加以管理。其中包括了需求標識號、需求內容、項目名稱、計劃的軟件版本、優先級、狀態、類別、完成時間以及預估的工作量。對于需求內容，采用用例(Use Case)或者用戶故事(User Story)的方法以駕駛員的使用語言描述出來 。如所示的列表第23 343項目中，描述了屏幕內菜單選擇提示需要與右側滾動條同步的描述。這是一個很詳細且現實的用戶需求，作者以表格規定的方式體現在產品需求列表中。對于復雜的需求，可以進一步分解成更細的需求，并建立子需求項目列出。如在儀表中實現道路偏移信息顯示功能，要考慮總共應該顯示的信息元素或畫面，同時還要安排策略防止顯示信息沖突。因此需要細化該需求并列出子要求在列表中，如在所示的列表第51 738 項中描述了為車道偏移顯示界面創建一個靜態動畫，做為實現整個車道偏移信息顯示功能的其中一個子功能，這樣逐步分解確保功能實現的完整性。同時對于項目的內部開發活動(如代碼評審等)也可以一并列入。如所示的列表中第50 614項目，它直接描述了一個評審代碼模塊的任務，以跟蹤開發人員的執行狀態。

這樣該產品需求列表就包括了開發團隊應完成的任務集，是團隊在開發過程的唯一需求輸入和人物列表。如果在開發后期整車廠提出需求需要更改功能時，可以根據現在已有的需求列表完成狀態快速方便地評估出該變化對于項目產生的影響，較為準確地規劃后期的功能實現計劃，做到及時響應客戶的需求。由于該表清楚地定義了每一個需求和任務的優先級和完成時間，因此它還是一個詳細的軟件開發計劃，可以作為整體項目計劃的細化文檔， 由此避免了因需求不斷增多而造成的需求管理混亂和軟件質量問題。該產品需求列表在Scrum過程中根據客戶的實際需求和團隊內部活動狀況不斷更新狀態，直到研發結束。

3 沖刺階段

軟件項目開發的節奏被細分為數個沖刺階段，這些階段兼顧了整車廠的測試計劃和該項目其他部門(如硬件電子和機械設計等)的研發計劃來確定。在每個沖刺正式開發前，產品負責人和開發團隊都會召開沖刺規劃(Sprint Planning)會議，該會議包含兩部分：第一部分是需求簡報，產品負責人從儀表需求列表中選取具有高優先級的用戶需求并闡述澄清，讓開發團隊成員充分理解需求含義。會議內容只涉及具體需求，一般控制在2 h左右；第二部分為開發團隊成員間具體的技術實現討論，最終由他們自己決定在此次沖刺階段可以完成的功能需求，并在產品需求列表標識出來以便追蹤。這種由開發團隊自己做出的目標承諾與以往項目經理分配的目標承諾相比前者應更為可靠 ，因為在軟件開發中只有開發人員最了解自身實際的情況，包括在當前階段的可用工作時間、技術能力狀態等。圖3顯示的是一個實際沖刺階段中的人力資源狀態。它定義了每個開發人員可以利用的工時和已經定義的沖刺時間段，這樣就可以讓團隊開發人和產品負責人制定出一個合理且現實的產品功能實現計劃，防止相關開發人員因工作負荷過重導致工作效率下降，進而影響軟件質量。

一旦開發團隊做出了目標承諾，開發工作隨即展開。團隊帶頭人可以把所有這個沖刺階段的需求任務羅列在看板上形成一個沖刺需求列表(Sprint Backlog)，以便清晰明了地向團隊展示項目狀態，讓其他利益相關者追蹤軟件開發進程。如圖4所示，每一個需求開發任務都應該被歸類在“待完成”，“正在進行”，“待驗證”，“已完成”4個狀態中的任意一個。例如在開發自適應巡航信息顯示功能時，把該功能作為一個總的功能表述，同時分解該功能并放入“待完成”項目中，包括靜態信息、動態信息、報警信息、人機交互沖突管理策略等；當開發人員開始實現人機交互沖突管理策略子功能時，該功能就應進入“正在進行”狀態；當該子功能編碼完成后應進入“待驗證”階段中，進行模塊測試驗證；如果測試通過則最終進入“已完成”狀態。在實現相對該功能時，各子功能有其互相依賴性，因此需要在所有相關子功能都進入到“待驗證”階段中時才能測試該功能的正確性，通過后才能進入“已完成”狀態，在此時才能說該功能正真被開發完成。

Scrum過程強調開發人員之間充分溝通以快速了解項目的開發狀態，但是這種溝通又不能太過于頻繁，這樣也會導致花過多的時間在交流上而不是軟件開發上。在實踐中，作者認為每天站會(Standing Meeting)的形式是一個比較好的方法。每個工作日的開始，團隊人員會圍繞在看板面前，依照自己負責的需求狀態，主動交流3個問題，即：自從上次開會以來你做了些什么？今天你計劃做什么？現在有無遇到任何困難？對于成員遇到的困難，團隊帶頭人會做記錄并對簡單的問題做快速闡述，對于相對較困難的問題則會另行召開專題會議討論。整個站會最多持續30 min，目的明確，簡單高效。它既能快速解決一些問題，又能讓大家了解最新的狀態，同時對于任何一個遺留問題都有具體的下一步行動計劃。避免了在傳統的開發模式下，開會總會陷入具體問題的討論，或者開發團隊只有在一段時間(1周或者1個月)之后才能了解項目狀況的情況[4]。對于開發進度相對落后的程序員，其他成員的開發狀態可以潛移默化地對該開發人員產生危機感，無形中可以激勵開發人員的能動性，以達到提高其工作效率的目的。

在每個沖刺階段的開發過程中，團隊成員都會根據自己的進度更新工作量的消耗狀態，團隊帶頭人會做總結記錄并以燃盡圖的形式實時客觀地反映在看板中。

如圖5所示，該燃盡圖顯示了在開發儀表自動泊車系統信息顯示功能的所花時間(橫軸)和實現的功能數量(縱軸)的關系，其中虛線是一條預估的功能實現趨勢，當實際的功能實現速度在此線之上，則說明有些功能開發花費了比原來預想更多的時間，需要進一步改進軟件開發效率；如果實際的功能實現速度在此理想線之下，則說明了整個開發速度快于理想定義狀態，需要檢查軟件質量并進一步優化預估的開發速度。

該自動泊車系統信息的顯示功能在初期開發階段比較符合預定義的趨勢，但是在后期由于人員低估了自動泊車系統與倒車雷達提示信息顯示的需求沖突導致了所花時間高于預估，因此團隊帶頭人根據此燃盡圖的信息及時了解該問題的產生根源，迅速對于此問題做了專題研討會，有效地解決了技術問題，并在最后趕上了預定的開發進度。因此燃盡圖起到了項目風險預警提示功能，為開發團隊盡早發現并解決問題提供了可靠的決策信息基礎。

在汽車儀表軟件開發中，如果遇到任何新的需求輸入，則產品負責人不會因此而干涉當前的沖刺階段，而是會評估這些需求優先級，并更新產品需求列表，放入下一次的沖刺階段中讓開發團隊討論實現。這樣的做法可以解決軟件開發需求頻繁波動造成的軟件質量問題。從項目管理的宏觀層面上來看，由于每個沖刺階段時間并不長(一般2～4周)，整個項目開發實現了對客戶需求的快速反應。

4 軟件釋放

由于儀表軟件需要在若干樣件階段集成相關其他硬件后才能驗證功能(例如軟硬件匹配等)，因此需要為每一個樣件釋放周期前計劃一個專門的軟件釋放沖刺階段(Release Sprint)去完成驗證(如圖6所示)，從而確保軟件質量。開發團隊會在該沖刺階段中安排一次軟件功能展示會(Demonstration)，讓產品負責人按照客戶的需求測試該軟件功能，判斷是否滿足客戶要求并釋放給客戶。如果測試失敗，則需要把這些失敗的功能重新列在下一次沖刺的產品需求列表中去更正，并在釋放文檔中做出說明。

當軟件團隊完成了沖刺階段之后，軟件系統已經集成好，并已被測試過，該軟件系統就具備了釋放的狀態。如果整車廠有臨時需要，軟件可以滿足其要求釋放，以便快速得到測試反饋結果，而不必等到最后樣件釋放階段。

在軟件釋放后，此次沖刺階段并沒有立即結束，開發團隊和帶頭人需要在一起回顧此次開發中的經驗教訓(Sprint Retrospective)， 討論此次開發做得好的方面和需要改進的方面。這樣可以使團隊得到有效的激勵，同時找到團隊的弱點并得到及時改進，并讓后續項目開發受益。在整個Scrum過程實踐中，同樣的項目回顧會議會召開多次(而不是在項目最后結束時才會做)，這是團隊持續自我完善的重要方法。

5 敏捷開發實施所面臨的挑戰

經過實施敏捷開發Scrum的實踐，項目開發的效率、質量以及團隊建設都得到了明顯改進和提高。但是它在具體運作時還需注意以下幾點：

(1)團隊建設方面，敏捷開發方法高度依賴團隊中每一位成員的專業素質，它需要每位開發人員主動積極地參與才能成功，因此前期對開發人員的培養十分重要。

(2)過程管理工具方面，由于敏捷開發方法還處在發展中，它的自動化支持工具較少[5]，需要實施方靈活運用現有的項目管理工具去實現(例如看板，變更管理工具)。

(3)質量流程方面，敏捷開發方法并不與CMMI等質量管理體系標準沖突，它反而是實現該質量體系要求的重要手段之一。因此實施方需要充分理解敏捷方法的思想，并結合項目本身的狀況對流程進行優化裁剪，最大化促進其作用。

(4)該開發方法的實施需要得到供應商和整車廠雙方組織級層面的理解和支持，必要時需要在項目早期啟動時做專題討論并達成一致。

6 結束語

汽車工業在中國的發展日新月異，汽車電子系統的需求也越來越復雜。文中所論及的敏捷軟件開發思想在汽車儀表軟件中的實踐應用，作為應對這一大趨勢的可能方案之一非常重要。事實證明：這種開發模式取得了階段性成功，開發的產品也已經批量生產。這對于汽車儀表軟件的項目開發有著重要意義，值得同類從業研究人員借鑒。

【1】 Beck K,Beedle M,van Bennekum A,et al.The Agile Manifesto[OL].[2001].http://www.agileAlliance.org.

【2】 Bell Thomas E,Thayer T A.Software requirements:Are they really a problem[C]//Proceedings of the 2nd International Conference on Software Engineering.IEEE Computer Society Press,1976.

【3】 Heinecke H,Schnelle K P,Fennel H,et al.Automotive Open System Architecture—An Industry Wide Initiative to Manage the Comp lexity of Emerging Automotive E /E Architectures[R].SAE Paper,2004.

【4】 Brooks F P.No silver bullet — essence and accidents of software engineering[J].Computer,1987,20(4):10-19.

【5】 Azizyan G,Magarian M K,Kajko-Mattson M.Survey of Agile Tool Usage and Needs[C]//AGILE Conference,2011.