敏捷軟件開發(fā)的三重迭代模型

在不斷變化的用戶需求和復(fù)雜的商業(yè)環(huán)境條件下，為了快速開發(fā)高質(zhì)量的軟件，諸多軟件企業(yè)采用敏捷軟件開發(fā)策略。在傳統(tǒng)敏捷軟件開發(fā)方法過程中，存在任務(wù)對人依賴、工作量非飽和等問題，導(dǎo)致開發(fā)效率低，項(xiàng)目進(jìn)展緩慢。本文提出基于敏捷軟件開發(fā)的三重迭代模型，針對任務(wù)對人依賴問題，在項(xiàng)目迭代過程中對任務(wù)的分配細(xì)化做出改進(jìn)；針對工作量非飽和問題，做了傳統(tǒng)迭代過程劃分并行的改進(jìn)。實(shí)踐證明此模型很好的解決了傳統(tǒng)敏捷軟件開發(fā)中存在的問題，提高了軟件的開發(fā)效率，降低了軟件開發(fā)的周期和成本。

【關(guān)鍵詞】敏捷方法 三重迭代 軟件工程 并行化開發(fā) 軟件模型

1 概述

如今隨著信息化時(shí)代的發(fā)展，軟件的需求量不斷增加，軟件開發(fā)方法也一直處在不斷發(fā)展的過程中。在眾多的方法中，敏捷軟件開發(fā)憑借其以人為核心，快速迭代，及時(shí)響應(yīng)客戶需求的特征，成為眾多高效團(tuán)隊(duì)的勝利之道。

敏捷軟件開發(fā)有多種，包括SRCRUM，特征驅(qū)動(dòng)軟件開發(fā)（FDD），自適應(yīng)軟件開發(fā)（ADP）以及極限編程（XP）等。這些方法都有以下主要特征：

1.1 迭代計(jì)劃

迭代是周期性較小的交付，從而實(shí)現(xiàn)用戶的一些需求，在每次迭代結(jié)束時(shí)，會(huì)給客戶演示迭代生成的系統(tǒng)，以得到他們的反饋。

1.2 用戶反饋

需求的具體細(xì)節(jié)很可能隨時(shí)間而改變，尤其在客戶看到集成到一起的系統(tǒng)。有用戶的反饋，再把反饋之后的需求集成到產(chǎn)品，這會(huì)避免很多無用功以及對需求的曲解。

1.3 持續(xù)集成和測試驅(qū)動(dòng)開發(fā)

開發(fā)人員每天會(huì)遷入他們的代碼并集成，頻繁的集成幫助項(xiàng)目在早期發(fā)現(xiàn)項(xiàng)目的風(fēng)險(xiǎn)和質(zhì)量問題，還可以在任何時(shí)間發(fā)布可以部署的軟件。 測試驅(qū)動(dòng)開發(fā)有助于編寫簡潔可用和高質(zhì)量的代碼，有利于重構(gòu)并加速開發(fā)過程。持續(xù)集成和測試驅(qū)動(dòng)開發(fā)是迭代的基礎(chǔ)。

在敏捷團(tuán)隊(duì)中，愿景和軟件一起演化，每次的迭代，團(tuán)隊(duì)需改進(jìn)系統(tǒng)設(shè)計(jì)，使設(shè)計(jì)盡可能適合于當(dāng)前系統(tǒng)。這種做法并不是要放棄架構(gòu)或者設(shè)計(jì)，而是增量地演化出系統(tǒng)最佳架構(gòu)和設(shè)計(jì)方式。正是敏捷軟件開發(fā)方法的這些優(yōu)勢，使得越來越多的企業(yè)來采用實(shí)踐。但隨著實(shí)踐的發(fā)展，出現(xiàn)的問題也越來越多。

2 問題

敏捷軟件開發(fā)的核心就是以最低的成本、最快速的為客戶提供價(jià)值?；谶@一優(yōu)勢，越來越多的軟件開發(fā)企業(yè)開始采用敏捷軟件開發(fā)方法，由于許多企業(yè)缺少在軟件開發(fā)方法研究上的經(jīng)驗(yàn)，在實(shí)施敏捷過程中往往會(huì)出現(xiàn)一些問題，從而未能達(dá)到預(yù)期的目標(biāo)。下面總結(jié)了一些經(jīng)典問題。

2.1 任務(wù)對人依賴問題

很多團(tuán)隊(duì)在進(jìn)行任務(wù)分派時(shí)，由于諸多不合理的任務(wù)分解，導(dǎo)致任務(wù)分解的粒度較大。開發(fā)過程中，對于大粒度的任務(wù)，安排的開發(fā)人員需要花費(fèi)較其他小粒度任務(wù)更多的時(shí)間，使得其他開發(fā)人員已完成手頭工作但無法插手到此大粒度任務(wù)中，因?yàn)檫@些大粒度的任務(wù)具有連續(xù)性，從而出現(xiàn)任務(wù)對人依賴的現(xiàn)象。例如，項(xiàng)目組一共7人，迭代周期為2周，一共8個(gè)story，在開發(fā)進(jìn)行一周后，4人已經(jīng)完成各自的story從而閑置，但又無法加入其他三人的story。因?yàn)槠渌说膕tory已經(jīng)開發(fā)了一半，而且這些story具有連續(xù)性，閑置的4人無法領(lǐng)到這些story下的任務(wù)。整個(gè)迭代不可能讓閑置下來的人員無事可做，等著另外三個(gè)人，所以不得不使本次迭代提前結(jié)束。

2.2 工作量非飽和問題

在常見的軟件開發(fā)迭代周期內(nèi)，不同職責(zé)的人員，任務(wù)的工作量可能明顯不同。例如，在某軟件開發(fā)的第m個(gè)周期內(nèi)，開發(fā)人員的工作量繁重，而需求分析人員和測試人員的工作量則相對輕松。從第m+1個(gè)周期開始，情況卻相反。這種分工不均導(dǎo)致不同職責(zé)人員的工作量在迭代周期內(nèi)不能達(dá)到相對飽和，很大程度上降低了項(xiàng)目的開發(fā)效率和進(jìn)度。

為了解決以上問題，本文提出了一種適合敏捷軟件開發(fā)的三重迭代模型。此模型對需求設(shè)計(jì)，產(chǎn)品編碼和測試進(jìn)行劃分，各自迭代。這三個(gè)大類迭代的劃分雖然與敏捷提倡的完整團(tuán)隊(duì)理念有一些差距，但是在各自迭代中，相互檢視，互為交付，在一定程度上不僅彌補(bǔ)了非完整團(tuán)隊(duì)的缺陷，降低了不同職責(zé)人員任務(wù)間的耦合度，而且極大的提高了團(tuán)隊(duì)的開發(fā)效率和項(xiàng)目的研發(fā)進(jìn)度。

3 三重迭代模型

為了解決上一節(jié)在軟件實(shí)施敏捷開發(fā)方法過程中遇到的問題，提出了一種三重迭代模型，將敏捷方法中的單個(gè)迭代過程分解成了三大類迭代過程。

通過對項(xiàng)目的規(guī)模大小、需要的開發(fā)資源、技術(shù)的難度等級評估建立研發(fā)團(tuán)隊(duì)。下面詳細(xì)的介紹從項(xiàng)目開始到交付的各迭代過程。

3.1 需求設(shè)計(jì)迭代過程

3.1.1 項(xiàng)目的初始階段

需求設(shè)計(jì)人員通過初始階段與客戶的交互，獲取對開發(fā)目標(biāo)的初步認(rèn)識。并與客戶及其開發(fā)和測試人員確定產(chǎn)品迭代周期以及最終產(chǎn)品交付的預(yù)期。

3.1.2 三重迭代階段

（1）需求設(shè)計(jì)人員拿到開發(fā)人員發(fā)布的項(xiàng)目最新測試版本，演示給客戶。若客戶認(rèn)可當(dāng)前版本，則把此次迭代的任務(wù)模塊和需求文檔直接拋給測試人員進(jìn)行測試。若客戶反饋問題，保留原先的需求文檔，并記錄需要修改或添加的功能，加入到下一個(gè)迭代周期的任務(wù)清單中。而任務(wù)清單的各任務(wù)，需通過分析其緊急性和重要性，做出優(yōu)先級判定，優(yōu)先級由高到低分為A、B、C、D，迭代過程中嚴(yán)格按照優(yōu)先級順序進(jìn)行。

（2）在此過程中，如果客戶的需求發(fā)生改變，那么及時(shí)做出響應(yīng)；若開發(fā)人員在上次迭代有任務(wù)剩余，則需重新評估確定任務(wù)優(yōu)先級，并加入這次的迭代任務(wù)中。至此，此次迭代結(jié)束，把生成的需求文檔拋給開發(fā)人員。

3.2 編碼設(shè)計(jì)迭代過程

3.2.1 項(xiàng)目的初始階段

開發(fā)人員根據(jù)對當(dāng)前項(xiàng)目的了解和評估，構(gòu)建最初的設(shè)計(jì)。

3.2.2 三重迭代階段

（1）對于需求設(shè)計(jì)人員那里拋過來的需求文檔，選擇適合本次迭代工作量的任務(wù)需求，對需求進(jìn)行評估，然后將任務(wù)選擇分派。任務(wù)的選擇一直持續(xù)到所有的任務(wù)都被分配出去，或者所有的開發(fā)人員都已經(jīng)用完了他們的預(yù)算時(shí)間為止。如果當(dāng)開發(fā)人員已經(jīng)用完了預(yù)算時(shí)間，還有任務(wù)未被分配出去，那么此時(shí)開發(fā)人員需相互協(xié)商，基于各自的專長交換相應(yīng)任務(wù)。在迭代進(jìn)行到一半的時(shí)候，團(tuán)隊(duì)會(huì)召開一次會(huì)議。在這個(gè)時(shí)間點(diǎn)上，本次的迭代所安排的半數(shù)任務(wù)應(yīng)該被完成。如果沒有完成，那么團(tuán)隊(duì)需設(shè)法重新分配沒有完成的任務(wù)和職責(zé)，以保證在迭代結(jié)束時(shí)能夠完成所有任務(wù)。若不能實(shí)現(xiàn)這樣的分派，則需要與需求設(shè)計(jì)人員和客戶溝通去掉一些優(yōu)先級較低的任務(wù)。至此，此次迭代結(jié)束，開發(fā)人員發(fā)布一個(gè)測試版本并通知需求設(shè)計(jì)人員，需求設(shè)計(jì)人員拿到此版本系統(tǒng)并演示給客戶，獲取客戶反饋。

（2）在下次迭代開始之前，集中處理測試人員反饋過來的bug清單，處理完成之后把bug清單以及發(fā)布的最新版本產(chǎn)品給測試人員。最后開發(fā)人員進(jìn)入下一個(gè)迭代階段。

3.3 測試迭代過程

3.3.1 項(xiàng)目初始階段

在項(xiàng)目初期階段，測試人員參與并確定產(chǎn)品的可測性，了解用戶需求，確定需要引入何種測試工具或平臺(tái)。設(shè)計(jì)測試用例時(shí)就會(huì)對用戶的場景和預(yù)期的行為做一個(gè)描述，能夠彌補(bǔ)產(chǎn)品人員考慮不到的情況，這樣便可以更加完善需求，提升產(chǎn)品的體驗(yàn)和質(zhì)量。

3.3.2 三重迭代階段

（1）對于需求設(shè)計(jì)人員那邊客戶認(rèn)可的測試版本和需求文檔，做針對性的模塊測試。找出當(dāng)前版本無法通過的測試用例，并將這些失敗的測試用例以及相對應(yīng)的需求理解整理成一份bug清單。

（2）對于開發(fā)人員發(fā)布的新版本進(jìn)行模塊測試，若還有bug問題，則連同上一步驟測得的模塊bug一起整理成一份新的bug清單，把更新后的bug清單反饋給開發(fā)人員。至此，此次迭代結(jié)束，進(jìn)入下一個(gè)迭代階段。

在三重迭代階段結(jié)束之后，軟件進(jìn)入交付階段。此階段，主要以測試人員為主導(dǎo)，需求設(shè)計(jì)人員和開發(fā)人員配合測試人員對當(dāng)前版本的軟件進(jìn)行測試。確保功能覆蓋用戶的所有需求，并及時(shí)響應(yīng)bug的反饋并修復(fù)bug。當(dāng)產(chǎn)品滿足客戶需求及設(shè)計(jì)要求，產(chǎn)品的缺陷率下降到可以接受的比例時(shí)，發(fā)布最終的軟件產(chǎn)品，軟件開發(fā)過程結(jié)束。

4 模型的特點(diǎn)和優(yōu)勢

相比于現(xiàn)有的其他模型，三重迭代模型具有明顯的特點(diǎn)以及由此帶來的優(yōu)勢：

（1）需求、開發(fā)和測試人員不需要嚴(yán)格同步，根據(jù)自身的特點(diǎn)，選擇適合自身的迭代周期，從而避免了需要等待其他人員完成當(dāng)前迭代而浪費(fèi)時(shí)間的現(xiàn)象。提高了人員的利用率，加快了項(xiàng)目進(jìn)度。

（2）需求與測試人員在軟件開發(fā)過程中快速迭代，使需求不斷的細(xì)化，而且讓客戶直接參與到需求的迭代過程中，有利于需求捕捉的準(zhǔn)確性和真實(shí)性，讓軟件往更加符合客戶需要的目標(biāo)推進(jìn)。

（3）通過一次次的迭代和發(fā)布，項(xiàng)目進(jìn)入了一種可預(yù)測、舒適的開發(fā)階段。每個(gè)人都知道將要做什么，以及何時(shí)去做?？蛻裟軌蚪?jīng)常地、實(shí)實(shí)在在的看到項(xiàng)目的進(jìn)度。

（4）開發(fā)人員看到的是基于自己估算并且由自己度量的開發(fā)速度控制的合理的計(jì)劃。開發(fā)人員選擇自己感覺舒適的任務(wù)，并保持高的工作質(zhì)量。管理人員從每次的迭代中獲取數(shù)據(jù)，根據(jù)這些數(shù)據(jù)來控制和管理項(xiàng)目。

5 三重迭代模型的實(shí)踐及總結(jié)

5.1 模型的項(xiàng)目實(shí)踐

SRM（供應(yīng)商關(guān)系管理系統(tǒng)）是為企業(yè)構(gòu)建全面的供應(yīng)商管理平臺(tái)為主要功能的應(yīng)用軟件。此系統(tǒng)采用三重迭代的敏捷軟件開發(fā)模型進(jìn)行開發(fā)，并基于“客戶現(xiàn)場”的模式，使客戶直接參與到軟件開發(fā)過程中。三重迭代階段，需求、開發(fā)和測試人員各自迭代，不斷的提交客戶變動(dòng)的需求和bug清單，很好解決了任務(wù)對人的依賴問題；在各自人員不斷地迭代過程中，每個(gè)人都有適合自己工作量的任務(wù)，解決了工作量非飽和的問題，提高了人員的開發(fā)質(zhì)量，降低了軟件的開發(fā)周期和成本。在開發(fā)過程中對于復(fù)雜的采購流程、送貨和要貨計(jì)劃的管理、層層的供應(yīng)商關(guān)系管理等，三重迭代模型的運(yùn)用不僅對客戶的需求有很好的實(shí)現(xiàn)，而且極大的提高了軟件的開發(fā)效率。

5.2 結(jié)束語

本文從敏捷軟件開發(fā)方法入手，提出了一種基于敏捷軟件開發(fā)的三重迭代模型，很好的解決了諸多企業(yè)在敏捷開發(fā)之路上遇到的問題。顯然，現(xiàn)階段敏捷軟件開發(fā)的三重迭代模型還略顯粗糙，還有很多后續(xù)的工作有待完成和優(yōu)化，例如結(jié)合Rational RequisitePro、Urtracker等管理工具對軟件需求和測試進(jìn)行集中管理等。要達(dá)到最佳實(shí)踐水平還需要進(jìn)一步探索及經(jīng)驗(yàn)積累，這將在今后的研究和實(shí)踐中進(jìn)行改進(jìn)。

參考文獻(xiàn)

[1]馬丁，馬丁鄧輝，孫鳴.敏捷軟件開發(fā)： 原則、模式與實(shí)踐：C#版[M].人民郵電出版社，2013.

[2]賈子河.輕松Scrum之旅：敏捷開發(fā)故事[M].電子工業(yè)出版社，2009.

[3]Chowdhury A F，Huda M N.Comparison between Adaptive Software Development and Feature Driven Development[C]// International Conference on Computer Science and Network Technology. IEEE，2011：363-367.

[4]Che K， Li L L，Niu X T，et al.Research of software development methodology based on self-adaptive multi-agent systems[C]// IEEE International Symposium on It in Medicine & Education.IEEE，2009：235-240.

[5]Apostolis D R.Extreme Programming Practices[M].Dic Press，2011.

[6]Debray S K，Lin N W，Hermnegildo M.Task Granularity Analysis in Logic Programs[J].Sigplan Notices， 2004，25（06）：174-188.

[7]Martakis A，Daneva M.Handling requirements dependencies in agile projects：A focus group with agile software development practitioners[J].Zookeys，2013， 264（264）：1-11.

[8]李必信.面向?qū)ο筌浖詈系亩攘亢万?yàn)證[J].東南大學(xué)學(xué)報(bào)（自然科學(xué)版），2006，36（03）：446-451.

[9]薛蓓燕.大小迭代軟件開發(fā)模型及迭代規(guī)模制定研究[D].上海交通大學(xué)，2008.

[10]玄躋峰.面向軟件Bug倉庫的數(shù)據(jù)分析及其應(yīng)用[D].大連理工大學(xué)，2013.

[11]IEEE.Specification directed module testing[J].IEEE Transactions on Software Engineering，1986，SE-12（01）：124-133.

[12]Sullivan M，Chillarge R，Sullivan M， et al.Software defects and their impact on system 118 availability[C]// Symposium on Fault-Tolerant Computing.1991.

[13]張燕麗.供應(yīng)商關(guān)系管理（SRM）系統(tǒng)基本功能[J].計(jì)算機(jī)系統(tǒng)應(yīng)用，2004，13（12）：70-72.

[14]Koskela J，Abrahamsson P.On-Site Customer in an XP Project： Empirical Results from a Case Study[J]. Lecture Notes in Computer Science，2004，3281：1-11.

[15]Ahmad N，Laplante P A.Software Project Management Tools：Making a Practical Decision Using AHP[C]// IEEE/NASA Software Engineering Workshop.IEEE，2006：76-84.

[16]IBM Rational RequisitePro.Rational RequisitePro[J].Ibm Corporation.

[17]鐘林輝，謝冰，邵維忠.青鳥軟件配置管理系統(tǒng)JBCM及相關(guān)工具[J].計(jì)算機(jī)工程，2000，26（11）：82-84.

作者簡介

馬佳?。?990-），男，江蘇省南通市人，碩士研究生，研究領(lǐng)域?yàn)檐浖_發(fā)方法與應(yīng)用。

羅翊坤（1992-），男，碩士研究生，研究領(lǐng)域?yàn)檐浖_發(fā)方法與應(yīng)用。

作者單位

江南大學(xué)物聯(lián)網(wǎng)工程學(xué)院 江蘇省無錫市 214122