劉瑞壯 中國鐵路上海局集團有限公司上海申鐵信息工程有限公司

2013年隨著成立國家鐵路局、鐵路總公司，近年來國家推動鐵路加快體制改革步伐。對于這一歷史時期鐵路信息系統(tǒng)項目而言，用戶的需求是多樣的、個性化的和不斷變化的。靜態(tài)的軟件項目管理方式，顯然已經無法適應鐵路管理格局的動態(tài)發(fā)展。

1 鐵路信息系統(tǒng)開發(fā)現狀及存在問題

上海局在全路信息化建設中始終處于前列，近年來在高鐵客服設備維保、車站設備智能化管理系統(tǒng)建設等方面取得重大突破，引起了鐵路總公司高度關注，成為各局爭相借鑒的典范，可以作為研究鐵路信息系統(tǒng)開發(fā)現狀調研對象，能夠反映全路信息系統(tǒng)開發(fā)中存在的普遍問題。為了深入了解目前鐵路信息系統(tǒng)項目開發(fā)現狀，本文中選取2013年至2017年鐵路總公司、上海局集團公司組織建設的，包括“鐵水聯(lián)運信息共享平臺”、“LKJ施工數據安全管理系統(tǒng)”、“上海鐵路局綜合實時監(jiān)測管理系統(tǒng)”等，20項典型鐵路信息系統(tǒng)項目，從軟件開發(fā)管理體系、流程和現狀方面做了深入調研，對技術人員進行訪談，記錄管理進程、項目狀態(tài)、存在問題。

經對20個項目進行統(tǒng)計，只有近60%的項目是基本按計劃完成的。經梳理分析，造成項目嚴重滯后的因素包括：用戶需求不穩(wěn)定，工作量估算不準，團隊成員管理不善，與用戶溝通不足。需求反復不定或者在項目中后期需求發(fā)生較大變化，是項目延期的主要因素，同時，不定的需求始終影響工作量估算，使已經拖延的工期難以推算完成時間，造成看似無盡的拖延。另外一方面，人員管理不善、缺乏溝通，在項目開發(fā)的關鍵階段，也阻撓了項目順利推進。

2 Scrum敏捷開發(fā)方法研究

Scrum是一個非常有效的敏捷框架，自誕生以來推廣很快，用橄欖球運動來比喻開發(fā)過程。在橄欖球運動中，每次沖刺（Sprint，是一種進攻方式）前，都需要先安排一個進攻計劃過程，一旦沖刺開始后，也就是開始實施進攻計劃后，則團隊需要在原沖刺計劃的基礎上，隨機應變，比如計劃是A要傳球給B最后由B得分，至于具體采用什么途徑，跑什么線路，就是要根據變化具體應對的了。最終目標還是要B得分，以達到預期的進攻目的（陳勇，2012）。

Scrum定義了4種主要的角色：

（1）產品負責人（Product Owner）：負責產品規(guī)劃，負責確定需求優(yōu)先級。在開發(fā)團隊和用戶之間溝通對接。

（2）利益相關者（Stakeholder）：是與產品有直接利益關系的人，可以理解為偏向用戶方面的干系人，負責制定產品需求，并且審查項目成果等。一般由用戶或最終用戶代表組成。

（3）Scrum 專家（Scrum Master）：指導團隊貫徹Scrum方法。在開發(fā)團隊和產品負責人之間溝通對接。

（4）團隊成員（Team Member）：實施項目開發(fā)工作的開發(fā)人員。

Scrum的核心做法：

Scrum收集最佳實踐，并且貫徹敏捷思想，為開發(fā)團隊提供了，一個實用的敏捷開發(fā)框架。比如采用測試驅動開發(fā)（Test Driven Development）、結對編程（Pair Programming）等都可以被整合到其中。

迭代計劃會 (Sprint Planning Meeting)。按照一個迭代2-4周的工作周期填工作，直到塞滿一個迭代，就可以進行開發(fā)了。

團隊估算。產品負責人主持，團隊要共同進行估算，集體智慧完成任務，這樣也使估算結果更為客觀。

開放的辦公環(huán)境。便于溝通和互動，大多數團隊都會在辦公環(huán)境中設置白板，在語言難以表達的時候可以隨時進行演示。

每日例會。“每日立會”（Daily Stand Up Meeting），每天要維護“燃盡圖”（Burn Down Chart），像燒蠟燭一樣，團隊“燒”完一個任務就標記完成，所有的任務都完成，項目的蠟燭也就燒完了。燃盡圖的功能是盯控項目進度，預測進度是否有偏差。

評審會 (Review Meeting)、反思會(Retrospective Meeting)。沖刺沖完了，沖的結果怎么樣，要產品負責人說了算。迭代的最后一天，產品負責人要對沖刺的成果進行評審，反饋是不是通過。

3 敏捷開發(fā)在鐵路信息系統(tǒng)開發(fā)中應用策略

3.1 迭代規(guī)劃管理策略

在迭代規(guī)劃中，確定開發(fā)優(yōu)先級是首要任務。在確定的過程中，采取什么方式能夠保證快速、合理、便于操作，是一個值得研究的問題。查閱文獻過程中發(fā)現，大部分文獻的工作核心，在于確定一系列需求的重要程度，以此作為優(yōu)先級排序的依據。文獻（胡文生等，2013）闡述了，核心功能優(yōu)先開發(fā)，可以在之后的迭代過程中發(fā)現缺陷并修正，借此明顯提高系統(tǒng)可靠性。如表1（數據源于王曉華.敏捷開發(fā)環(huán)境下軟件可靠性分析及相關問題研究）：

表1 各個用例權重的確定

F1代表最先進行開發(fā)的功能組，也是整個項目中最核心的功能組，此功能組共進行了6次迭代。Ni表示測試用例數，Si為測試成功數，Ri表示功能組的可靠性點估計?？梢杂嬎愠?F1，F2，……，F6功能組經過6次迭代后的可靠性變化情況。數據如表2所列（數據源于王曉華.敏捷開發(fā)環(huán)境下軟件可靠性分析及相關問題研究）：

表2 各功能組在每次迭代周期的可靠性

從列表數據可以看出，在經歷了6個迭代周期的F1功能組，可靠性有很顯著的提升，以此，使整個系統(tǒng)更可靠。因此如何判斷功能組為核心功能組尤為重要。

將各類功能組分為高風險且高價值的功能組、低風險且高價值的功能組、低風險且低價值的功能組，高風險且低價值的功能組。確定迭代順序的原則就是，把有限的資源，投入到高風險且高價值的功能組上，以此優(yōu)先實現核心功能，同時減弱風險。

要優(yōu)先開發(fā)高風險且高價值的功能組，目的是在歷次迭代中不斷發(fā)現問題，并且進行糾正完善，以提高整個系統(tǒng)的可靠性。然后依次開發(fā)低風險高價值、低風險且低價值的功能組。盡量將高風險且低價值的功能組排除在項目外，因為項目資源是有限的，冒著項目失敗的風險去開發(fā)可有可無的功能，是沒有必要的。

3.2 任務分配和估算策略

團隊共同對任務進行討論。團隊成員集體行動，討論從產品負責人那里聽來的故事（用戶需求），把將每個用戶故事進行轉換，變成具體的開發(fā)任務。估算后由程序員對任務進行認領，其中可以由兩個人對此任務更為熟悉，并且更有興趣的進行結對，完成特定工作。這樣一來，程序員會對其所認領的任務更為自信、具備更強的責任感，更盡力的在限期內完成任務。估算采用以下方法：

（1）德爾菲法。德爾菲法的特點，就是可以得到很高的準確率。

（2）類比估算。類比估算的特點，是容易達成共識。是依據團隊經驗，設定簡單任務，并對其他任務進行類比并估算整個工作量的方法。

（3）故事點。團隊選取一個最簡單的任務，作為一個單位的故事點，記作1故事點或1點。將其他所有任務與1點的任務類比，根據結果分別估算為1點，2點，3點或者5點，對超過5點的故事就應該拆分成更小的任務。

（4）三角測量。在團隊估算中，結合功能點和類比分析的思想，采用"故事點"方法進行敏捷估算，為提供準確度，在每次估算后用三角測量的方法評估結果，4個點的任務應介于3個點和2個點之間。故事點應該是由整個團隊進行估算，盡量使團隊中的所有成員都要參與故事的故事點估算，每個人都把自己的估算結果說出來，最后大家再定一個所有人都認可的故事點。

項目開發(fā)過程中，將團隊效率看作是速度，總的工作量看作是路程，所用時間可以很簡單的用t=s/v公式求得。故事點就是一個團隊工作效率（速度）的基本單位。將最簡單的一個故事看作1點，其他故事與之比較，比它規(guī)模更大的或者更復雜就賦予更高的速度。受人主觀認知水平不同的影響，每個人的對理想日的估算方法和結果往往會有很大差異。為了規(guī)避這種個人能力差異，我們采用“故事點”估算方法。

3.3 開發(fā)和測試策略

編碼前考慮編寫測試。驗收測試的編寫主要包括：測試數據、操作步驟、預期結果。當編碼完成時，測試也就基本完成，假如已完成并且通過了所有驗收測試，就可以進行用戶評審。

將測試分為3個階段進行，開發(fā)人員在迭代中的自行查驗，用戶故事測試，最后是迭代末期的驗收測試。

（1）自行查驗：由開發(fā)人員自行完成，目的是要提交一個或多個，可以進行自動化測試的用戶故事。

（2）用戶故事測試：由開發(fā)人員和"現場客戶"完成，目的是對一個或多個用戶故事的功能進行測試，保證功能沒有問題。

（3）迭代驗收測試：由開發(fā)人員和“現場客戶”完成，對當次迭代的用戶故事，主要基于場景的測試。目的是要保證當次迭代的工作任務確定被客戶“簽收”。

在估算后，由兩個對此任務更為熟悉，并且更有興趣的程序員進行結對編程。結對編程的工作模式可能有多種，本文作者根據實踐經驗，提供一種結對方式：

由兩名程序員用同一臺電腦，輪流進行編程，一個人在編程的同時，另一個人一邊看一邊指出問題，并且著手編寫測試，簡要設計測試數據、操作步驟和預期結果。

如果其中一名程序員編程效率明顯比較高，也可以不做輪換。但考慮到工作強度不宜由一人承擔，并且旁觀者雖清，但長時間旁觀容易分心，對本職工作失去興趣，還是要求結對的兩人輪流進行編碼。

3.4 評審策略

Scrum方法采用時間盒策略。事先定好了評審會召開的時間，到了時間是一定要進行評審的。不可以等開發(fā)工作完成，測試完成以后才評審，因此迭代一般不會被拖延。

要注意的是：

（1）事先確定用戶故事標準。

（2）評審時以用戶故事為整體，進行評價是否達到交付標準。

（3）如果部分功能沒有通過驗收測試或者沒有通過評審，也不需要拖延時間糾結于某個問題，可以與用戶協(xié)商先確認將完成的工作通過評審，沒完成的或者需要改進的，可以產品待開發(fā)項，作為以后迭代的任務去完成。

（4）在評審會前，單個用戶故事完成時，也可以進行評審，以便降低交付時不能通過的風險。

這樣很大程度上，可以避免陷入項目超期甚至嚴重超期的窘境，盡管有可能會增加迭代，但在規(guī)定期限內，一定會完成一個可發(fā)布上線的產品，遺留問題可以在試用期內進行解決完善。

4 總結與展望

本文調研鐵路信息系統(tǒng)項目現狀，發(fā)現存在問題，通過重點研究Scrum方法在信息系統(tǒng)開發(fā)過程中的應用，結合鐵路生產系統(tǒng)項目目前遇到的關鍵問題，研究并提出更貼合實際、更具操作性的迭代規(guī)劃、估算、開發(fā)、評審等策略。今后進一步的工作，需要不斷提高估算的精確度。定量的估算方法可能相對結果會比較精確，但過程復雜，受條件變化影響大，準確性差。相反，定性估算精度不如前者好，但快捷、易操作。為了在準確估算的前提下，不斷提高估算精度，有必要基于歷史數據以及項目經驗的積累，對定性估算和定量估算的數學方法進一步分析研究。