敏捷軟件開發的三重迭代模型

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

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

1 概述

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

敏捷軟件開發有多種，包括SRCRUM，特征驅動軟件開發（FDD），自適應軟件開發（ADP）以及極限編程（XP）等。這些方法都有以下主要特征：

1.1 迭代計劃

迭代是周期性較小的交付，從而實現用戶的一些需求，在每次迭代結束時，會給客戶演示迭代生成的系統，以得到他們的反饋。

1.2 用戶反饋

需求的具體細節很可能隨時間而改變，尤其在客戶看到集成到一起的系統。有用戶的反饋，再把反饋之后的需求集成到產品，這會避免很多無用功以及對需求的曲解。

1.3 持續集成和測試驅動開發

開發人員每天會遷入他們的代碼并集成，頻繁的集成幫助項目在早期發現項目的風險和質量問題，還可以在任何時間發布可以部署的軟件。 測試驅動開發有助于編寫簡潔可用和高質量的代碼，有利于重構并加速開發過程。持續集成和測試驅動開發是迭代的基礎。

在敏捷團隊中，愿景和軟件一起演化，每次的迭代，團隊需改進系統設計，使設計盡可能適合于當前系統。這種做法并不是要放棄架構或者設計，而是增量地演化出系統最佳架構和設計方式。正是敏捷軟件開發方法的這些優勢，使得越來越多的企業來采用實踐。但隨著實踐的發展，出現的問題也越來越多。

2 問題

敏捷軟件開發的核心就是以最低的成本、最快速的為客戶提供價值。基于這一優勢，越來越多的軟件開發企業開始采用敏捷軟件開發方法，由于許多企業缺少在軟件開發方法研究上的經驗，在實施敏捷過程中往往會出現一些問題，從而未能達到預期的目標。下面總結了一些經典問題。

2.1 任務對人依賴問題

很多團隊在進行任務分派時，由于諸多不合理的任務分解，導致任務分解的粒度較大。開發過程中，對于大粒度的任務，安排的開發人員需要花費較其他小粒度任務更多的時間，使得其他開發人員已完成手頭工作但無法插手到此大粒度任務中，因為這些大粒度的任務具有連續性，從而出現任務對人依賴的現象。例如，項目組一共7人，迭代周期為2周，一共8個story，在開發進行一周后，4人已經完成各自的story從而閑置，但又無法加入其他三人的story。因為其他三人的story已經開發了一半，而且這些story具有連續性，閑置的4人無法領到這些story下的任務。整個迭代不可能讓閑置下來的人員無事可做，等著另外三個人，所以不得不使本次迭代提前結束。

2.2 工作量非飽和問題

在常見的軟件開發迭代周期內，不同職責的人員，任務的工作量可能明顯不同。例如，在某軟件開發的第m個周期內，開發人員的工作量繁重，而需求分析人員和測試人員的工作量則相對輕松。從第m+1個周期開始，情況卻相反。這種分工不均導致不同職責人員的工作量在迭代周期內不能達到相對飽和，很大程度上降低了項目的開發效率和進度。

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

3 三重迭代模型

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

通過對項目的規模大小、需要的開發資源、技術的難度等級評估建立研發團隊。下面詳細的介紹從項目開始到交付的各迭代過程。

3.1 需求設計迭代過程

3.1.1 項目的初始階段

需求設計人員通過初始階段與客戶的交互，獲取對開發目標的初步認識。并與客戶及其開發和測試人員確定產品迭代周期以及最終產品交付的預期。

3.1.2 三重迭代階段

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

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

3.2 編碼設計迭代過程

3.2.1 項目的初始階段

開發人員根據對當前項目的了解和評估，構建最初的設計。

3.2.2 三重迭代階段

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

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

3.3 測試迭代過程

3.3.1 項目初始階段

在項目初期階段，測試人員參與并確定產品的可測性，了解用戶需求，確定需要引入何種測試工具或平臺。設計測試用例時就會對用戶的場景和預期的行為做一個描述，能夠彌補產品人員考慮不到的情況，這樣便可以更加完善需求，提升產品的體驗和質量。

3.3.2 三重迭代階段

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

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

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

4 模型的特點和優勢

相比于現有的其他模型，三重迭代模型具有明顯的特點以及由此帶來的優勢：

（1）需求、開發和測試人員不需要嚴格同步，根據自身的特點，選擇適合自身的迭代周期，從而避免了需要等待其他人員完成當前迭代而浪費時間的現象。提高了人員的利用率，加快了項目進度。

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

（3）通過一次次的迭代和發布，項目進入了一種可預測、舒適的開發階段。每個人都知道將要做什么，以及何時去做。客戶能夠經常地、實實在在的看到項目的進度。

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

5 三重迭代模型的實踐及總結

5.1 模型的項目實踐

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

5.2 結束語

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

參考文獻

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

[2]賈子河.輕松Scrum之旅：敏捷開發故事[M].電子工業出版社，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]李必信.面向對象軟件耦合的度量和驗證[J].東南大學學報（自然科學版），2006，36（03）：446-451.

[9]薛蓓燕.大小迭代軟件開發模型及迭代規模制定研究[D].上海交通大學，2008.

[10]玄躋峰.面向軟件Bug倉庫的數據分析及其應用[D].大連理工大學，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]張燕麗.供應商關系管理（SRM）系統基本功能[J].計算機系統應用，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]鐘林輝，謝冰，邵維忠.青鳥軟件配置管理系統JBCM及相關工具[J].計算機工程，2000，26（11）：82-84.

作者簡介

馬佳俊（1990-），男，江蘇省南通市人，碩士研究生，研究領域為軟件開發方法與應用。

羅翊坤（1992-），男，碩士研究生，研究領域為軟件開發方法與應用。

作者單位

江南大學物聯網工程學院 江蘇省無錫市 214122