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结束语
本文从敏捷软件开发方法入手，提出了一种基于敏捷软件开发的三重迭代模型，很好的解决了诸多企业在敏捷开发之路上遇到的问题。显然，现阶段敏捷软件开发的三重迭代模型还略显粗糙，还有很多后续的工作有待完成和优化，例如结合RationalRequisitePro、Urtracker等管理工具对软件需求和测试进行集中管理等。要达到最佳实践水平还需要进一步探索及经验积累，这将在今后的研究和实践中进行改进。
参考文献
[1]马丁，马丁邓辉，孙鸣.敏捷软件开发：原则、模式与实践：C#版[M].人民邮电出版社，2013.
[2]贾子河.轻松Scrum之旅：敏捷开发故事[M].电子工业出版社，2009.
[3]ChowdhuryAF，HudaMN.ComparisonbetweenAdaptiveSoftwareDevelopmentandFeatureDrivenDevelopment[C]//InternationalConferenceonComputerScienceandNetworkTechnology.IEEE，2011：363-367.
[4]CheK，LiLL，NiuXT，etal.Researchofsoftwaredevelopmentmethodologybasedonself-adaptivemulti-agentsystems[C]//IEEEInternationalSymposiumonItinMedicine&Education.IEEE，2009：235-240.
[5]ApostolisDR.ExtremeProgrammingPractices[M].DicPress，2011.
[6]DebraySK，LinNW，HermnegildoM.TaskGranularityAnalysisinLogicPrograms[J].SigplanNotices，2004，25（06）：174-188.
[7]MartakisA，DanevaM.Handlingrequirementsdependenciesinagileprojects：Afocusgroupwithagilesoftwaredevelopmentpractitioners[J].Zookeys，2013，264（264）：1-11.
[8]李必信.面向对象软件耦合的度量和验证[J].东南大学学报（自然科学版），2006，36（03）：446-451.
[9]薛蓓燕.大小迭代软件开发模型及迭代规模制定研究[D].上海交通大学，2008.
[10]玄跻峰.面向软件Bug仓库的数据分析及其应用[D].大连理工大学，2013.
[11]IEEE.Specificationdirectedmoduletesting[J].IEEETransactionsonSoftwareEngineering，1986，SE-12（01）：124-133.
[12]SullivanM，ChillargeR，SullivanM，etal.Softwaredefectsandtheirimpactonsystem118availability[C]//SymposiumonFault-TolerantComputing.1991.
[13]张燕丽.供应商关系管理（SRM）系统基本功能[J].计算机系统应用，2004，13（12）：70-72.
[14]KoskelaJ，AbrahamssonP.On-SiteCustomerinanXPProject：EmpiricalResultsfromaCaseStudy[J].LectureNotesinComputerScience，2004，3281：1-11.
[15]AhmadN，LaplantePA.SoftwareProjectManagementTools：MakingaPracticalDecisionUsingAHP[C]//IEEE/NASASoftwareEngineeringWorkshop.IEEE，2006：76-84.
[16]IBMRationalRequisitePro.RationalRequisitePro[J].IbmCorporation.
[17]鐘林辉，谢冰，邵维忠.青鸟软件配置管理系统JBCM及相关工具[J].计算机工程，2000，26（11）：82-84.
作者简介
马佳俊（1990-），男，江苏省南通市人，硕士研究生，研究领域为软件开发方法与应用。
罗翊坤（1992-），男，硕士研究生，研究领域为软件开发方法与应用。
作者单位
江南大学物联网工程学院江苏省无锡市214122
来源：电子技术与软件工程 2017年6期
作者：马佳俊
