電腦怎麼執行指令碼
作者簡介：吳海慶，資深諮詢顧問、敏捷教練、DevOps專家、研發效能工具專家，復旦大學軟體工程碩士，近20年軟體行業從業經歷。曾就職於阿里系網際網路和TOP級車聯網等企業，擔任過DevOps高階經理、測試經理、專案經理和敏捷教練等職。結合管理和工程實踐輔導多家企業進行敏捷轉型。熟悉國內外主流工具鏈和雲平臺，幫助多個企業從0開始構建DevOps。
近年來，隨著國際形勢的不斷動盪，全球經濟充滿不確定性，頻繁變化的市場競爭格局，也加速了VUCA時代的到來，這對任何國家、企業或是個人來說，都是前所未有的大變局和大挑戰。
軟體行業在VUCA時代也變得複雜多樣。據Gartner表示，現代軟體大多數是被“組裝”出來的，不是被“開發”出來的。在軟體開發過程中，大量程式碼來源於開原始碼或開源元件，非常依賴第三方元件的使用，而且客戶的需求也複雜多變，這給軟體開發帶來了更多的不確定性。
一、為什麼需要指標
當前軟體行業開發模式主要有兩大流派，一個是瀑布模式，一個是敏捷模式。據Standish Group的調查結果顯示，當專案較小時，用瀑布模式和敏捷模式的成功率幾乎相等；當專案偏大時，敏捷模式的成功率是18%，瀑布模式的成功率是9%。即專案越大，使用敏捷模式的成功率也越大。其原因在於，小專案的週期比較短，相對複雜程度不高，無法體現敏捷模式的優勢。當然，需要強調的是，敏捷不是銀彈，它不能解決所有軟體開發專案的問題，專案採用哪種模式要結合實際情況，有的專案可能更適用瀑布模式，但是敏捷模式有很多好的方法，可以借鑑到瀑布模式中。
據2021年第15次敏捷現狀報告顯示，94%的企業都實施了敏捷，且時間超過一年；65%的企業在敏捷方面有3~5年或5年以上的實踐經驗；超過52%的受訪者採用敏捷實踐。該報告是對歐美國家100多個軟體公司進行的敏捷現狀調查，66%的人認為Scrum是他們最常用的方法，另有15%的人使用Scrum衍生方法。從報告結果可以看出，Scrum是目前最流行的一種敏捷方法。因此，基於敏捷模式的團隊，也應該是一個跨功能自組織的端到端產品Scrum團隊，共同為產品成果負責，更加關注價值流動效率和反饋週期。在這種價值流程體系之下，就需要一些指標來最佳化整個團隊的工作，才能最終實現業務目標，實現客戶價值。
從Scrum的理論支柱可知，它的基礎主要來自於經驗主義，即流程控制論和精益思想兩者的結合。經驗主義，即實踐出真知，它有三個支柱，分別是透明、檢視和調整。透明，代表所有東西要呈現事實，包括客戶、領導、執行長等，團隊成員彼此互相信任，好的或不好的資訊都要保證其透明度，每個人都為共同的組織目標而努力協作。檢視，就是在專案過程中不斷檢查目標計劃與實際情況是否有所偏差，此時就需要指標來輔助檢查。調整，就是在迭代中不斷去調整、適應及改進。
德魯克曾說，你如果無法度量它，就無法管理它。因此在實際工作中，我們會採用GQM（Goals-Questions-Metrics）方法度量分析工作，基於事實和資料，統一、客觀、科學、合理來評價專案的執行狀況是否滿足管理預期，包括專案的進度和進展、資源和成本、交付產品質量、過程工作效率等。敏捷指標主要有三個，分別是團隊管理指標、CI/CD指標和客戶價值指標。最終要實現的目標是：價值驅動，聚焦最高價值的目標，在儘可能短的時間內持續交付給客戶有價值的產品；適應變化，掌控和管理不確定性；自組織團隊，釋放團隊的內驅力，使團隊產生最大的價值能力。
二、團隊管理指標
團隊管理指標有很多，此處列舉部分個人認為較重要的指標進行說明，如燃盡圖、速率、累積流程圖、需求梳理週期、需求開發週期、需求交付週期等。
燃盡圖
燃盡圖，橫軸表示時間週期，縱軸是故事點，中間這條灰線是預計的走勢，紅色線條代表實際完成趨勢。如圖所示，剛開始迭代時有11個故事點，隨著迭代的不斷進行，故事點逐漸完成，直至為0；紅色線條上升，表示故事點增加，說明增加了需求；紅線在灰色線條上方，表示進度慢於預測進度，反之高於預測進度。
圖中右側部分是史詩級燃盡圖，是指一類比較大的需求，再拆分成不同的故事，所以它包含了所有的故事點，橫軸是迭代數，縱軸表示故事點。如圖所示，第一個迭代原始的預估是15個故事點，它進行到第7個迭代時，只剩下13個故事點，已經完成了2個故事點；到第8個迭代時，沒有完成任何故事點，但是新增了4個故事點；在第9個迭代中，增加了4個故事點，完成了3個故事點；最後的灰色部分，是預測下一個迭代大概是多少個故事點。史詩級燃盡圖不像前面所講的燃盡圖那麼流行，它主要是看長期的範圍蔓延，就是在實際過程中如果發現不斷在增加故事點，說明團隊沒有完全理解工作的需求，而是不斷使範圍蔓延，這樣一來，在時間上和範圍上肯定要做一個取捨。
速率圖
速率圖用
的
比較多，橫軸表示迭代數，縱軸表示故事點。每一個迭代又分成藍綠兩個柱狀圖形，藍色代表承諾完成的數量，綠色代表已經完成的數量。如圖所示，在第一個迭代中，承諾和完成的故事點一樣；在迭代二中，承諾和完成的故事點出現差距，實際完成的數量少於承諾完成的數量，造成這種情況的原因可能在於，工作中穿插了很多其他的工作事項，或團隊成員調走支援其他專案。因此，在團隊穩定的情況下，團隊成員經過一段時間的磨合，速率是相對平穩且高效的。如果出現承諾的故事點增加的情況，原因可能是自動化程度提高了，找到了新的開發方法、開發框架，都有可能會讓團隊挑戰更高的故事點數，而且完成率還會保持平穩。但是在完成承諾故事點數的時候，還需要考慮意外因素，比如線上有緊急Bug，因此要預留10~20%的時間來應對緊急情況。
累積流程圖
累積流程圖也是比較常用的，橫軸表示時間，縱軸表示問題數，藍色部分表示待辦列表，綠色部分表示正在進行中的問題數，淺藍色部分表示已經完成的數量。如圖所示，有3個指標比較重要，首先是平均週期時間，是指從進入開發到完成開發需要的時間；第二是在製品，是指進入開發到完成開發過程中，有多少個問題；第三是吞吐率，當執行比較平穩的時候，我們發現平均週期時間和製品數是相對平穩向上的，分佈較均勻。如果看到平均週期時間或製品數有明顯的寬和窄，就說明有明顯的瓶頸和負載，需要去找原因。
三、DevOps指標
持續整合和持續交付指標，其實是DevOps的一個指標。2001年，4個宣言、12個原則提出以後，出現了敏捷開發的理念，主要解決產品端到開發端之間的銜接。經過約10年時間，開發和產品端的效率越來越快，出現了雲計算、雲原生等技術幫助快速持續釋出，運用這些技術以後就出現了DevOps，解決開發到運維之間的差距，提高開發效率。現在來說，敏捷開發與DevOps是相輔相成的一類方法和工具的結合，而敏捷開發傾向於管理實踐，DevOps傾向於工程實踐，因此當管理實踐加快效率以後，工程實踐一定也要跟上。這裡有很多指標，比如程式碼庫配置、製品管理、構建頻率、構建成功率、構建平均修復時長、部署頻率、部署成功率、單元測試覆蓋率、缺陷率等，都和持續整合和持續交付有關。
DevOps總體框架，採用的是比較通用的工具搭建的框架，這些工具有很多其他種類和不同的組合。從專案啟動以後，透過Confluence記錄產品文件、技術方案、會議紀要、知識庫等，然後把專案匯入到Jira當中進行需求收集管理、缺陷管理、產品交付，然後透過一些測試用例管理、自動化測試管理，再形成一些資料和報告，將度量視覺化。當我們進入配置和製品管理，所有程式碼都有一個程式碼庫，有進行分支管理和版本管理。
構建成功率
，是指當開發完成一個小版本以後，他就會透過整合工具去構建，構建頻率越快越理想，就是當完成以後，能很快
的
構建，而且構建頻率比較快、構建成功率也比較高，因為成功率在一定程度上反映了程式碼的提交質量，如果程式碼合併進來以後老是失敗，說明程式碼的質量是不可信的，所以我們希望構建頻率快構建成功率高。
構建平均修復時長
，當在流水線上構建完以後，如果發生問題應該能儘快修復，否則當下一個人再提交上去可能使得構建再次失敗，這是整個流水線就是堵塞的。
部署頻率，是敏捷非常相關的指標，它體現了部署是否能快速響應市場的變化，將實際效果反饋給客戶或市場，驗證它的價值。比如以前在To C的網際網路企業，友商出了一個新功能，當我們知道這個需求以後，大家不管明天是是不是週末都必須要通宵，堅持完成這個任務，把這個新功能部署上去，這就對部署頻率有著非常高的要求，而且還要求部署成功率高，因為如果部署上去都失敗的話，實際上也沒有任何效果，可能還會給客戶造成不良的影響。
還有一個比較重要的指標是
單元測試覆蓋率
，因為現在自動化測試最主要和最有效的就是單元測試，所以現在有很多開發流行用測試驅動的開發模式進行開發，其實最有效的測試就是開發的測試，像黑盒測試或探索型測試，其實是對這些功能的補充性測試，但是大量的測試如果要在迭代中完成，一定是依賴於自動化的測試，依賴於單元測試。
四、客戶價值指標
客戶價值指標是敏捷中最重要的一個目標，透過及早或持續不斷
的
交付有價值的軟體，使客戶滿意。這些指標，關注的不一定是量化指標，而是定性的指標，更多關注他的一些行為和能力，包括聚焦價值、市場和競品分析、使用者畫像、策略和路線圖、mvp、反饋渠道、產品成功的衡量標準等，來衡量客戶價值的指標，這裡主要分享三個指標。
聚焦價值
聚焦價值是一個比較寬泛的指標，這裡分享一些比較有代表性的衡量標準。所有的故事、代辦列表在PDI中都是有商業價值，都是從低到高進行排序，可以看到整個需求是有一個金字塔型的，越往上面越詳細，優先順序越高。越下面需求越粗略，優先順序越低。
優先順序越高會拆分
的
越細，這個時候可能就在下一個迭代中去實現這個故事，所以一定要有拆解需求，然後排定優先順序的一個動作。當然，拆解的時候要遵循“DEEP原則”，就是更加詳細、可以估算、不斷湧現和優先順序排序。
使用者故事地圖
使用者故事地圖，就是讓所有人都瞭解產品需求端到端的開發目標和願景，還是一個開發路線，先開發什麼後開發什麼，最好的呈現方式可以用使用者故事地圖。簡單來講，最上面代表端到端價值鏈的整個過程，下面是某一個過程包含的故事。
比如該步驟是登入，那麼裡面的故事可以是正常使用者名稱密碼登入、非正常使用者名稱密碼登入、微信登入、手機登入等，這都是一個單獨的故事。有了故事以後，可以看到端到端整個開發的路線，下面有什麼故事也都大概分配好，就可以進行橫向的切割，按照版本或迭代去切割，這樣就可以讓所有團隊認同和對齊任務整體目標。也就是說，做產品規劃時，需要有一個使用者故事地圖來做全體的目標對齊。
MVP
MVP也是客戶價值指標中需要做的一個動作。比如造車，先造一個輪子，再造兩個輪子，然後再完成造車，這個過程不叫MVP。如圖中下部分所示，先造一個滑板，再造一個電動滑板車，再造一個腳踏車，最後過渡到汽車，這才叫MVP。上下兩種方式的區別，最主要是下面的每一個產品都是最小的可用產品，只不過是不斷的進化，透過使用者的反饋不斷的去最佳化改進，最終成為一個比較高大上的產品。
所以MVP就是產品的第一個可工作產品版本，它具有足夠的功能來滿足潛在的客戶，並收集和分析他們的反饋，用於下一個產品版本，它所需要的工作和資源都是最少的。很多國外的網際網路成功案例，其實也是用mvp的方法去驗證潛在市場和潛在客戶。比如維珍航空最開始的時候，只有一架飛機，一條航線，它只是驗證這種廉價的模式能不能成功。所以當我們做第一個產品的時候，或者說想做一個新產品時，可以採用MVP的方式來幫助實現客戶價值。
- End -