Scrum在民航IT研發應用實踐

◆李圣霞 劉盼 夏侯康 羅軍 程宇

（廣東機場白云信息科技有限公司 廣東 510470）

1 研究背景

隨著社會的進步和管理水平的日益提高，軟件開發與各個行業和領域都密不可分，民航單位作為運輸行業的一大重點，日常運營管理越來越精細化，對信息化的程度要求越來越高。第一，用戶迫切需要信息化的管理軟件，來幫助自己梳理和記錄日常業務流程，提高自身管理水平；第二，用戶對軟件不熟悉，對系統的需求是模糊的、不明確的，只有在軟件研發的過程中，才能逐漸明確下一步的需求計劃；第三，因為民航業務的特殊性，對安全和質量的要求很高，軟件系統的質量問題，對日常業務影響較大，且一般影響范圍較廣。

在這種情況下，傳統的瀑布模型已經無法適應不斷變動的需求，因為需求變更在瀑布開發模型中，尤其是開發后期帶來的成本是高昂的，不確定的需求也會導致開發過程中工期、成本、質量的多重風險，并最終導致項目的失敗。

2 敏捷及Scrum簡介

敏捷是一種通過創造變化和響應變化在不確定和混亂的環境中取得成功的能力。敏捷軟件開發是基于敏捷宣言定義的價值觀和原則的一系列方法和實踐的總稱。

敏捷開發遵循十二條基本原則，如下：

第一，我們最重要的目標，是通過及早和持續不斷地交付有價值的軟件使客戶滿意。

第二，欣然面對需求變化，即使在開發后期也一樣。為了客戶的競爭優勢，敏捷過程掌控變化。

第三，經常地交付可工作的軟件，相隔幾個星期或一兩個月，傾向于采取較短的周期。

第四，業務人員和開發人員必須相互合作，項目中的每一天都不例外。

第五，激發個體的斗志，以他們為核心搭建項目。提供所需的環境和支援，輔以信任，從而達成目標。

第六，不論團隊內外，傳遞信息效果最好效率也最高的方式是面對面的交談。

第七，可工作的軟件是進度的首要度量標準。

第八，敏捷過程倡導可持續開發。責任人、開發人員和用戶要能夠共同維持其步調穩定延續。

第九，堅持不懈地追求技術卓越和良好設計，敏捷能力由此增強。

第十，以簡潔為本，它是極力減少不必要工作量的藝術。

第十一，最好的架構、需求和設計出自自組織團隊。

第十二，團隊定期地反思如何能提高成效，并依此調整自身的行為表現。

Scrum是敏捷開發的一種最基本框架，也是最流行的一種框架，尤其是對于初次進行敏捷開發的企業尤其適用。Scrum原始含義是指英式橄欖球次要犯規時在犯規地點對陣爭球。傳統的“接力式”的開發模式已經不能滿足快速靈活的市場需求，而整體或“橄欖球式”的方法——團隊作為一個整體前進，在團隊的內部傳球并保持前進，這也許可以更好地滿足當前激烈的市場競爭。

Scrum框架包括3個角色（Product Owner、Scrum Master、開發團隊）、3個工件（Product Backlog、Sprint Backlog、產品增量）、5個事件（Sprint、Sprint計劃會議、“每日站會”、Sprint評審會議、Sprint回顧會議）、5個價值（承諾、專注、開放、尊重、勇氣）。

3 Scrum應用實踐中的問題和解決方案

在民航系統管理軟件的開發過程中，采用傳統瀑布模型，因為客戶需求的不確定性、各單位部門之間溝通協調的復雜性、對接其他系統數據的困難性等各種因素，往往前期需求調研階段特別長，因為工期緊張容易造成延期問題，并帶來質量的隱患，容易導致客戶滿意度的降低。

采用敏捷開發方法中的Scrum，可以有效地解決以上問題，把客戶需要的大的功能劃分為一個一個小的迭代，采用增量發布的方式，每次只需要確認當前迭代的功能，使客戶需求漸進明細，目前已成為我們研發的主要模式。

Scrum主要有5個事件：Sprint、Sprint計劃會議、“每日站會”、Sprint評審會議、Sprint回顧會議。下面分別一一講述：

（1）Sprint：每個Sprint就是一個迭代，按照敏捷開發原則是迭代周期越短越好，因為這樣可以使客戶更早看到系統并進行試用，也能更早反饋意見。但鑒于民航管理系統的復雜性，太小的功能點完成對客戶來說是沒有意義的，機場是7*24小時在運轉的，客戶因為其自身業務工作的繁忙，也很難進行深入的試用，因此，迭代周期太短，無法取得預期的效果，而迭代周期太長，則無法按照敏捷開發模式推進，經綜合評估，我們確立了1個月的迭代周期長度，9人的開發團隊，基本可以完成80人天左右的開發工作量，預留測試和修復bug時間。經過近三個迭代的實踐，目前這是比較合適的一個工作安排。

（2）Sprint計劃會議：計劃會議主要用來確定本次迭代要完成的功能，產品經理在前一個迭代開發過程中，就開始與客戶溝通確認下一迭代的功能，因此，在計劃會議上，產品經理確認好本次迭代的功能點，做詳細地介紹，每個迭代的計劃會議時間盒為8小時，產品經理按功能點對客戶業務需求和需求實現方式進行詳細地講解，開發團隊一起進行討論，對需求錯誤點和遺漏點直接指出，每個功能點講解完成后，立即進行開發任務分配，由開發工程師，利用敏捷估算撲克，對詳細功能點進行估算。傳統模式下，開發工程師在需求評審時基本不提意見，開發過程中經常按照自己的理解去開發，到測試環節后才發現實現與需求不符；而敏捷開發模式當場估算的方式，無形中讓開發工程師盡可能地去了解需求，及時提出可能遇到的問題，給出相對準確的估算，這也是Scrum核心價值觀中的“承諾”。

（3）“每日站會”：“每日站會”是Scrum的經典應用，體現核心價值觀中的“開放”?！懊咳照緯蔽覀儾捎米詈唵蔚氖止た窗?便利貼，把開發、測試任務細化到個人，每人有一行來標識自己的任務和進度，每日約定9點10分為站會的時間，到時間點大家自動在看板前聚集成半圓，不用每日通知，也不用安排專人召集，按順序發言，回答三個問題：1）昨天我做了哪些工作；2）今日我打算做什么工作；3）遇到的困難和障礙。全部完成后，大家散開回去開始今天的工作，敏捷教練記錄下所有的困難和障礙，和對應成員討論并解決。一方面，“每日站會”提供了一個溝通交流的平臺，讓大家有機會了解團隊整體的工作進展，一個系統內部總是互相關聯的，對整體的把握有助于對部分的設計完善；另一方面，“每日站會”從心理學角度分析，雖然敏捷團隊更注重整體的進度，但每日匯報進度時，個體總是會想要展示自己更好的一面，從其他人贊賞的眼光中，獲得一種滿足感，因此，敏捷開發團隊無形中會有更高的工作熱情，以在每日的站會中有更好的表現，這便是核心價值觀中的“尊重”。

（4）Sprint評審會議：每個Sprint，我們仍然保留瀑布模型中的重要環節，召開幾次評審會議：需求評審、設計評審、代碼評審、發布評審，需求評審一般在計劃會議之后召開，設計評審，則在設計完成后進行，代碼評審每周進行一次，發布評審則在每次迭代功能測試完成時進行。需求、設計、發布評審一般是會議形式，代碼評審則一般在工位電腦前進行，不必拘泥于何種形式，有問題也不必拘泥在什么時間提出，一般在發現問題時，我們鼓勵立即提出，不讓可能的缺陷或問題流入下一個環節，這也是精益思想的一種體現。一旦發現問題變成一種鼓勵，每個人都感覺到提出問題是安全的，團隊中的每個人都會放下戒心，更多的問題被提出，才能被盡早解決，而越早解決問題，越能減少修復問題的成本，也越能帶來產品質量的提升，這是Scrum核心價值觀中的“勇氣”的體現。

（5）Sprint回顧會議：每次迭代結束后，在發布評審會議后，我們會立即召開回顧會議。回顧會議在各種參考書籍中有很多推薦形式，但核心思想就是要讓團隊全員都參與進來。敏捷團隊中犯錯誤是被允許的，一般不會在回顧會議上對犯錯誤的人或事進行批斗，但必須要做的事情是，我們哪些地方做得不好，我們可以做什么來避免錯誤的再次發生。這些要采取的行動，就變為下一迭代的改進任務，和其他任務一起粘貼在白板上。做這些事情的，不是上級領導，不是敏捷教練，而是開發團隊中的每個人，一般來說，讓大家說的效果沒有寫下來的效果更好，我們經常制定5分鐘的時間盒，讓大家去思考，并把問題或者改進措施寫下來，完成后再一起進行討論，也嘗試過大家坐在一個會議室里面輪流發言，首先發言的過程中很容易被打斷，再就是可能前面的人說過的問題，后面的人覺得差不多就不會再提了。

最后，再談談Scrum核心價值觀中的“專注”，專注是指讓團隊成員盡可能地不受外界干擾，把全部精力都投入到目前的工作中。現實的工作中，絕對的不受干擾是不存在的，比如一個開發工程師，正在進行A項目的開發工作，此時，正好有一個之前參與的B項目，客戶有一些疑問，幾分鐘時間可以解答的問題，難道一定要推開嗎，從公司的角度來看，一定不會希望產生這樣的情況，從敏捷團隊角度，這樣的打擾太多，也會造成一定的困擾。因此，敏捷教練在其中要起一定的作用，把握好度，既不能犧牲客戶的滿意度，也不能影響當前的工作。

4 結束語

綜上，Scrum在提升效率、提高質量方面為我們的研發工作做出了積極的貢獻，在使用過程中，我們嚴格遵守它的核心價值觀，遵循敏捷的十二條基本原則，但并沒有拘泥于固有的形式，和原有的瀑布模型也進行了一定的整合，在一些項目應用上取得成效之后，后續也將應用到其他民航IT研發項目中。