起
隨著“軟件定義汽車”的浪潮,整車軟件功能和復(fù)雜度在不斷提升,主機廠為了把握主動權(quán),開始逐漸參與甚至主導(dǎo)整個軟件開發(fā)過程,使當(dāng)前整車軟件開發(fā)呈現(xiàn)出多方交互、參與和協(xié)作的特點。
此外合作模式也更加靈活和多樣,例如有的供應(yīng)商只供硬件,而底層和應(yīng)用層則由主機廠完成;有的則是供應(yīng)商主導(dǎo)主機廠只參與其中很小一個功能包的開發(fā),比如四驅(qū)功能。在Autosar還未大規(guī)模普及之前,合作雙方都有各自一套約定俗成的方式來進行接口交互和溝通,這個交互過程可能一次涉及很多類型文件,例如.C .H或者.O等等,后面則可通過Arxml來進行接口交互等。
承
總體來說當(dāng)一個開發(fā)活動中,參與元素越來越多,由于個體主觀疊加之客觀條件的差異(如組織流程差異、合作方式選擇、接口交互方式等)就會使整個合作開發(fā)任務(wù)變得復(fù)雜和具有挑戰(zhàn)性。
轉(zhuǎn)
影響軟件合作開發(fā)的因素有很多,我只選擇幾點來談?wù)剛€人看法,也歡迎跟大家交流。
3.1 主動性和約束
攻城獅向來討厭流程和約束,創(chuàng)造性活動與約束是相悖的,合作開發(fā)過程中除了開發(fā)工作還充斥著流程、文檔等活動。這些流程和文檔類工作我認為分為兩大類:
1、有必要且有助于保證產(chǎn)品質(zhì)量和項目進度
2、無必要徒增工作量的。
當(dāng)約束變多,攻城獅逐漸開始應(yīng)付并消極待之,那么也會讓有價值的約束失去作用。既然兩者都沒錯,如何調(diào)和?只能精簡約束且約束制定者必須具有項目實踐經(jīng)驗,一個脫離項目實踐的人制定流程就好比“紙上談兵”。只有真正了解痛點才能有措施針對性鏟除并讓攻城獅發(fā)揮主動性再把主要時間放在功能設(shè)計和開發(fā)上,例如不要再動不動整個功能就要拿著所謂的Aspice說事,首先是不是有必要?如資質(zhì)審查需要,如果沒必要還要強加顯然不合理,因為除了它還有很多有效措施保證開發(fā)質(zhì)量,這就好比石器時代結(jié)束后,大家推崇青銅。但是現(xiàn)在有些時候還是石頭好用。地球上石頭也沒有消失,只是多了青銅這個選擇,流程花樣再多只是一種選擇,合適自己的才是最好的。
3.2 一夫當(dāng)關(guān):需求管理
一個功能的實現(xiàn)從簡來說主要有三部分:輸入、內(nèi)部邏輯和輸出,輸入和輸出可以統(tǒng)一概括為接口,內(nèi)部邏輯則是依據(jù)輸入經(jīng)過某些運算得到輸出達到控制目標。從這個角度講在合作開發(fā)過程中,分配的功能模塊要想順暢完成,那么我們談好接口明確功能即可,但實際操作起來我們發(fā)現(xiàn)并不容易,要么需求接口到了開發(fā)都還沒完全確認清楚而是開發(fā)過程中不斷更改甚至持續(xù)到整個項目末期;要么就是合作雙方未理解,造成傳遞錯誤等等。
需求交互、分解和傳遞作為開發(fā)活動的起點,對整個項目起著我認為是80%的作用,首先需要一位相匹配的系統(tǒng)或架構(gòu)攻城獅。他們是一棟大樓骨架的設(shè)計者,大樓建設(shè)順不順利且建后穩(wěn)不穩(wěn)固全靠它。例如對于未確定和持續(xù)變化的接口要有效跟蹤和管理,對于明確的功能要做好分解、傳遞和測試驗收,這就考驗系統(tǒng)和架構(gòu)師的功底了。
3.3 組織和人
當(dāng)某業(yè)務(wù)興起,很多公司都會為了新業(yè)務(wù)調(diào)整組織架構(gòu),例如德爾福在智駕單獨成立安波福;上汽在新能源單獨成立智己等等。有在現(xiàn)有基礎(chǔ)上整合的,也有直接干脆新拉一個團隊的?!独顺敝畮p》中也寫了很多鮮明的例子,有固守體制而失敗的也有改變但偏離而失敗的(如雅虎)還有改變非常成功的(如重回蘋果掌權(quán)的喬布斯進行的改革),這是一個探索道路的過程。當(dāng)改變后若組織間存在著太多的條條框框限制或價值差異那么協(xié)作起來談何順暢,例如組織臃腫,大家會發(fā)現(xiàn)部門間協(xié)作扯皮的事越來越多嚴重影響效率。當(dāng)然一個組織經(jīng)過這么多年的發(fā)展已自成體制,改變原有價值認同也不容易,我們有句古話:不破不立,不破除舊東西何以更好重生?此時我們需要一個真正的引領(lǐng)者。
人是一個公司最寶貴的財富,組織是一個有約束邊界的平臺,在公司戰(zhàn)略方向?qū)Φ那疤嵯?,人在此基礎(chǔ)上創(chuàng)造出價值。那么檢驗組織首先就是輸入:員工的真實反饋,就好比診斷通訊需要經(jīng)常問答反饋,得到系統(tǒng)運行的實時狀態(tài)再制定措施修復(fù)完善,當(dāng)真實反饋普遍不好時就需要警惕和思考,因為這會使一個團隊活力逐漸消退,影響最終的價值輸出。在一段《遺失的訪談》紀錄片中,喬布斯關(guān)于團隊合作曾說過這么個例子:一位老人讓他撿一些普通的石頭,然后放進一個磨石機里,開動后讓他明天再去看,他第二天后打開罐子看到了打磨的異常圓潤美麗的石頭。這些普通石頭通過相互摩擦最后變成了光滑美麗的石頭。而這正是團隊合作過程中通過大家之間相互碰撞:辯論、對抗、爭吵、協(xié)作和完善修正等來磨礪ideas最終圓滿完成項目。
4、不可能三角
持續(xù)快節(jié)奏交付與質(zhì)量的相悖,這也是一個老問題了。
軟件合作開發(fā)模式下,軟件要求的交付節(jié)奏越來越快,但有些功能涉及的開發(fā)量巨大很難滿足交付質(zhì)量這也是事實,現(xiàn)在的敏捷和持續(xù)集成測試有一定作用,但無法完全解決上述痛點,對于有標準的可以做到一次做好終身受益,例如某功能主機廠在每個控制器上要求一致且萬年不變,那么做好測試case后不管換什么產(chǎn)品,功能開發(fā)完后都進行持續(xù)檢驗就可以了,前期的費勁主要在于這些測試庫的建立。而當(dāng)某個功能在同一主機廠都在持續(xù)更改更別談在不同主機廠是咋樣時,這種問題對于使用持續(xù)集成和測試也顯得力不從心。這其中可能存在著這么幾個問題:首先開發(fā)人員理解需求且知道測試什么和測試目標,但負責(zé)搭建持續(xù)測試的人不理解要測試什么,而當(dāng)把這個任務(wù)交給開發(fā)人時又對開發(fā)的人提出了額外的工作內(nèi)容和技能要求:編寫測試case甚至再轉(zhuǎn)化為測試腳本,這項工作是持續(xù)的;其二,整車配置非常多樣,項目軟件對應(yīng)的測試模型難以覆蓋各種配置等等。
持續(xù)集成測試好的一面就是規(guī)避人的錯誤,保證有測試case的功能驗收的一致性。那么推動合作方對功能做好標準化并一以貫之是合作雙方利好的事,但這個推進過程會很遙遠甚至根本不現(xiàn)實,國內(nèi)主機廠的功能向來說變就變。
5、高效合作新模式探索
探索新的方式,這個在一個固有模式的行業(yè)要想翻出新的水花會比較困難,馬斯克自傳中也曾說過一句話:顛覆者從來都不是在原有行業(yè)誕生的。新能源和智駕興起時,當(dāng)時傳統(tǒng)汽車開發(fā)人員是眾矢之的,他們保守、他們拉胯,招聘都不受待見,但隨著傳統(tǒng)汽車人員在新勢力和智駕公司的遷移,我們發(fā)現(xiàn)這些曾經(jīng)要改變現(xiàn)有模式的新勢力反而又回歸到原有的模式,因為這些遷移的人把原有行業(yè)的開發(fā)方式帶過去并影響了他們,這我更愿意稱之為同化進程-跟《人類簡史》中有些片段描述非常相似。不論是傳統(tǒng)主機廠的人,還是互聯(lián)網(wǎng)的人當(dāng)面臨的客觀環(huán)境超過專業(yè)知識能解決的范圍后都會從傳統(tǒng)文化中尋找解決方法。馬斯克是一個狂人,但這種狂人畢竟少。
合
軟件合作開發(fā)是后面的主旋律,合作方式、參與內(nèi)容都很靈活和多樣。但探討一種高效的合作手段需要時間不斷打磨。