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

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

1 研究背景

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

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

2 敏捷及Scrum簡介

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

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

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

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

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

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

第五，激發(fā)個體的斗志，以他們?yōu)楹诵拇罱椖?。提供所需的環(huán)境和支援，輔以信任，從而達成目標。

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

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

第八，敏捷過程倡導可持續(xù)開發(fā)。責任人、開發(fā)人員和用戶要能夠共同維持其步調(diào)穩(wěn)定延續(xù)。

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

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

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

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

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

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

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

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

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

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

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

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

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

（4）Sprint評審會議：每個Sprint，我們?nèi)匀槐Ａ羝俨寄Ｐ椭械闹匾h(huán)節(jié)，召開幾次評審會議：需求評審、設計評審、代碼評審、發(fā)布評審，需求評審一般在計劃會議之后召開，設計評審，則在設計完成后進行，代碼評審每周進行一次，發(fā)布評審則在每次迭代功能測試完成時進行。需求、設計、發(fā)布評審一般是會議形式，代碼評審則一般在工位電腦前進行，不必拘泥于何種形式，有問題也不必拘泥在什么時間提出，一般在發(fā)現(xiàn)問題時，我們鼓勵立即提出，不讓可能的缺陷或問題流入下一個環(huán)節(jié)，這也是精益思想的一種體現(xiàn)。一旦發(fā)現(xiàn)問題變成一種鼓勵，每個人都感覺到提出問題是安全的，團隊中的每個人都會放下戒心，更多的問題被提出，才能被盡早解決，而越早解決問題，越能減少修復問題的成本，也越能帶來產(chǎn)品質(zhì)量的提升，這是Scrum核心價值觀中的“勇氣”的體現(xiàn)。

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

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

4 結束語

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