敏捷開發(fā)方法在鐵路信息系統(tǒng)項(xiàng)目中的應(yīng)用

劉瑞壯 中國(guó)鐵路上海局集團(tuán)有限公司上海申鐵信息工程有限公司

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

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

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

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

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

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

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

（1）產(chǎn)品負(fù)責(zé)人（Product Owner）：負(fù)責(zé)產(chǎn)品規(guī)劃，負(fù)責(zé)確定需求優(yōu)先級(jí)。在開發(fā)團(tuán)隊(duì)和用戶之間溝通對(duì)接。

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

（3）Scrum 專家（Scrum Master）：指導(dǎo)團(tuán)隊(duì)貫徹Scrum方法。在開發(fā)團(tuán)隊(duì)和產(chǎn)品負(fù)責(zé)人之間溝通對(duì)接。

（4）團(tuán)隊(duì)成員（Team Member）：實(shí)施項(xiàng)目開發(fā)工作的開發(fā)人員。

Scrum的核心做法：

Scrum收集最佳實(shí)踐，并且貫徹敏捷思想，為開發(fā)團(tuán)隊(duì)提供了，一個(gè)實(shí)用的敏捷開發(fā)框架。比如采用測(cè)試驅(qū)動(dòng)開發(fā)（Test Driven Development）、結(jié)對(duì)編程（Pair Programming）等都可以被整合到其中。

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

團(tuán)隊(duì)估算。產(chǎn)品負(fù)責(zé)人主持，團(tuán)隊(duì)要共同進(jìn)行估算，集體智慧完成任務(wù)，這樣也使估算結(jié)果更為客觀。

開放的辦公環(huán)境。便于溝通和互動(dòng)，大多數(shù)團(tuán)隊(duì)都會(huì)在辦公環(huán)境中設(shè)置白板，在語(yǔ)言難以表達(dá)的時(shí)候可以隨時(shí)進(jìn)行演示。

每日例會(huì)。“每日立會(huì)”（Daily Stand Up Meeting），每天要維護(hù)“燃盡圖”（Burn Down Chart），像燒蠟燭一樣，團(tuán)隊(duì)“燒”完一個(gè)任務(wù)就標(biāo)記完成，所有的任務(wù)都完成，項(xiàng)目的蠟燭也就燒完了。燃盡圖的功能是盯控項(xiàng)目進(jìn)度，預(yù)測(cè)進(jìn)度是否有偏差。

評(píng)審會(huì) (Review Meeting)、反思會(huì)(Retrospective Meeting)。沖刺沖完了，沖的結(jié)果怎么樣，要產(chǎn)品負(fù)責(zé)人說了算。迭代的最后一天，產(chǎn)品負(fù)責(zé)人要對(duì)沖刺的成果進(jìn)行評(píng)審，反饋是不是通過。

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

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

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

表1 各個(gè)用例權(quán)重的確定

F1代表最先進(jìn)行開發(fā)的功能組，也是整個(gè)項(xiàng)目中最核心的功能組，此功能組共進(jìn)行了6次迭代。Ni表示測(cè)試用例數(shù)，Si為測(cè)試成功數(shù)，Ri表示功能組的可靠性點(diǎn)估計(jì)。可以計(jì)算出 F1，F(xiàn)2，……，F(xiàn)6功能組經(jīng)過6次迭代后的可靠性變化情況。數(shù)據(jù)如表2所列（數(shù)據(jù)源于王曉華.敏捷開發(fā)環(huán)境下軟件可靠性分析及相關(guān)問題研究）：

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

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

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

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

3.2 任務(wù)分配和估算策略

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

（1）德爾菲法。德爾菲法的特點(diǎn)，就是可以得到很高的準(zhǔn)確率。

（2）類比估算。類比估算的特點(diǎn)，是容易達(dá)成共識(shí)。是依據(jù)團(tuán)隊(duì)經(jīng)驗(yàn)，設(shè)定簡(jiǎn)單任務(wù)，并對(duì)其他任務(wù)進(jìn)行類比并估算整個(gè)工作量的方法。

（3）故事點(diǎn)。團(tuán)隊(duì)選取一個(gè)最簡(jiǎn)單的任務(wù)，作為一個(gè)單位的故事點(diǎn)，記作1故事點(diǎn)或1點(diǎn)。將其他所有任務(wù)與1點(diǎn)的任務(wù)類比，根據(jù)結(jié)果分別估算為1點(diǎn)，2點(diǎn)，3點(diǎn)或者5點(diǎn)，對(duì)超過5點(diǎn)的故事就應(yīng)該拆分成更小的任務(wù)。

（4）三角測(cè)量。在團(tuán)隊(duì)估算中，結(jié)合功能點(diǎn)和類比分析的思想，采用"故事點(diǎn)"方法進(jìn)行敏捷估算，為提供準(zhǔn)確度，在每次估算后用三角測(cè)量的方法評(píng)估結(jié)果，4個(gè)點(diǎn)的任務(wù)應(yīng)介于3個(gè)點(diǎn)和2個(gè)點(diǎn)之間。故事點(diǎn)應(yīng)該是由整個(gè)團(tuán)隊(duì)進(jìn)行估算，盡量使團(tuán)隊(duì)中的所有成員都要參與故事的故事點(diǎn)估算，每個(gè)人都把自己的估算結(jié)果說出來，最后大家再定一個(gè)所有人都認(rèn)可的故事點(diǎn)。

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

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

編碼前考慮編寫測(cè)試。驗(yàn)收測(cè)試的編寫主要包括：測(cè)試數(shù)據(jù)、操作步驟、預(yù)期結(jié)果。當(dāng)編碼完成時(shí)，測(cè)試也就基本完成，假如已完成并且通過了所有驗(yàn)收測(cè)試，就可以進(jìn)行用戶評(píng)審。

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

（1）自行查驗(yàn)：由開發(fā)人員自行完成，目的是要提交一個(gè)或多個(gè)，可以進(jìn)行自動(dòng)化測(cè)試的用戶故事。

（2）用戶故事測(cè)試：由開發(fā)人員和"現(xiàn)場(chǎng)客戶"完成，目的是對(duì)一個(gè)或多個(gè)用戶故事的功能進(jìn)行測(cè)試，保證功能沒有問題。

（3）迭代驗(yàn)收測(cè)試：由開發(fā)人員和“現(xiàn)場(chǎng)客戶”完成，對(duì)當(dāng)次迭代的用戶故事，主要基于場(chǎng)景的測(cè)試。目的是要保證當(dāng)次迭代的工作任務(wù)確定被客戶“簽收”。

在估算后，由兩個(gè)對(duì)此任務(wù)更為熟悉，并且更有興趣的程序員進(jìn)行結(jié)對(duì)編程。結(jié)對(duì)編程的工作模式可能有多種，本文作者根據(jù)實(shí)踐經(jīng)驗(yàn)，提供一種結(jié)對(duì)方式：

由兩名程序員用同一臺(tái)電腦，輪流進(jìn)行編程，一個(gè)人在編程的同時(shí)，另一個(gè)人一邊看一邊指出問題，并且著手編寫測(cè)試，簡(jiǎn)要設(shè)計(jì)測(cè)試數(shù)據(jù)、操作步驟和預(yù)期結(jié)果。

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

3.4 評(píng)審策略

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

要注意的是：

（1）事先確定用戶故事標(biāo)準(zhǔn)。

（2）評(píng)審時(shí)以用戶故事為整體，進(jìn)行評(píng)價(jià)是否達(dá)到交付標(biāo)準(zhǔn)。

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

（4）在評(píng)審會(huì)前，單個(gè)用戶故事完成時(shí)，也可以進(jìn)行評(píng)審，以便降低交付時(shí)不能通過的風(fēng)險(xiǎn)。

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

4 總結(jié)與展望

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