謝超

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

0 引言

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

1 敏捷開發(fā)Scrum過程

敏捷軟件開發(fā)思想強調(diào)軟件開發(fā)團(tuán)隊與業(yè)務(wù)專家之間的緊密協(xié)作、人之間面對面的溝通、軟件版本的持續(xù)交付和緊湊而自我組織型的團(tuán)隊。它與傳統(tǒng)的瀑布開發(fā)模型相比，能夠更好地適應(yīng)軟件項目的快速需求變化以及更頻繁的交付場景。

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

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

(2)產(chǎn)品負(fù)責(zé)人(Product Owner)。確定產(chǎn)品的方向和目標(biāo)，定義產(chǎn)品發(fā)布的內(nèi)容、優(yōu)先級及交付時間。

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

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

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

2 需求開發(fā)

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

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

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

3 沖刺階段

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

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

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

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

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

該自動泊車系統(tǒng)信息的顯示功能在初期開發(fā)階段比較符合預(yù)定義的趨勢，但是在后期由于人員低估了自動泊車系統(tǒng)與倒車?yán)走_(dá)提示信息顯示的需求沖突導(dǎo)致了所花時間高于預(yù)估，因此團(tuán)隊帶頭人根據(jù)此燃盡圖的信息及時了解該問題的產(chǎn)生根源，迅速對于此問題做了專題研討會，有效地解決了技術(shù)問題，并在最后趕上了預(yù)定的開發(fā)進(jìn)度。因此燃盡圖起到了項目風(fēng)險預(yù)警提示功能，為開發(fā)團(tuán)隊盡早發(fā)現(xiàn)并解決問題提供了可靠的決策信息基礎(chǔ)。

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

4 軟件釋放

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

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

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

5 敏捷開發(fā)實施所面臨的挑戰(zhàn)

經(jīng)過實施敏捷開發(fā)Scrum的實踐，項目開發(fā)的效率、質(zhì)量以及團(tuán)隊建設(shè)都得到了明顯改進(jìn)和提高。但是它在具體運作時還需注意以下幾點：

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

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

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

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

6 結(jié)束語

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

【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.