敏捷软件开发的三重迭代模型

《敏捷软件开发的三重迭代模型》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

1、敏捷软件开发的三重迭代模型1概述如今随着信息化时代的发展，软件的需求量不断增加，软件开发方法也一直处在不断发展的过程中。在众多的方法中，敏捷软件开发凭借其以人为核心，快速迭代，及时响应客户需求的特征，成为众多高效团队的胜利之道。敏捷软件开发有多种，包括SRCRUM，特征驱动软件开发（FDD），自适应软件开发（ADP）以及极限编程（XP）等。这些方法都有以下主要特征：1.1迭代计划迭代是周期性较小的交付，从而实现用户的一些需求，在每次迭代结束时，会给客户演示迭代生成的系统，以得到他们的反馈。1.2用户反馈需求的具体细节很可能随时间而改变，尤其在客户看到集成到一起的系统。

2、有用户的反馈，再把反馈之后的需求集成到产品，这会避免很多无用功以及对需求的曲解。1.3持续集成和测试驱动开发开发人员每天会迁入他们的代码并集成，频繁的集成帮助项目在早期发现项目的风险和质量问题，还可以在任何时间发布可以部署的软件。测试驱动开发有助于编写简洁可用和高质量的代码，有利于重构并加速开发过程。持续集成和测试驱动开发是迭代的基础。在敏捷团队中，愿景和软件一起演化，每次的迭代，团队需改进系统设计，使设计尽可能适合于当前系统。这种做法并不是要放弃架构或者设计，而是增量地演化出系统最佳架构和设计方式。正是敏捷软件开发方法的这些优势，使得越来越多的企业来采用实践。但随着

3、实践的发展，出现的问题也越来越多。2问题敏捷软件开发的核心就是以最低的成本、最快速的为客户提供价值。基于这一优势，越来越多的软件开发企业开始采用敏捷软件开发方法，由于许多企业缺少在软件开发方法研究上的经验，在实施敏捷过程中往往会出现一些问题，从而未能达到预期的目标。下面总结了一些经典问题。2.1任务对人依赖问题很多团队在进行任务分派时，由于诸多不合理的任务分解，导致任务分解的粒度较大。开发过程中，对于大粒度的任务，安排的开发人员需要花费较其他小粒度任务更多的时间，使得其他开发人员已完成手头工作但无法插手到此大粒度任务中，因为这些大粒度的任务具有连续性，从而出现任务对人

4、依赖的现象。例如，项目组一共7人，迭代周期为2周，一共8个story，在开发进行一周后，4人已经完成各自的story从而闲置，但又无法加入其他三人的story。因為其他三人的story已经开发了一半，而且这些story具有连续性，闲置的4人无法领到这些story下的任务。整个迭代不可能让闲置下来的人员无事可做，等着另外三个人，所以不得不使本次迭代提前结束。2.2工作量非饱和问题在常见的软件开发迭代周期内，不同职责的人员，任务的工作量可能明显不同。例如，在某软件开发的第m个周期内，开发人员的工作量繁重，而需求分析人员和测试人员的工作量则相对轻松。从第m+1个周期开始，情

5、况却相反。这种分工不均导致不同职责人员的工作量在迭代周期内不能达到相对饱和，很大程度上降低了项目的开发效率和进度。为了解决以上问题，本文提出了一种适合敏捷软件开发的三重迭代模型。此模型对需求设计，产品编码和测试进行划分，各自迭代。这三个大类迭代的划分虽然与敏捷提倡的完整团队理念有一些差距，但是在各自迭代中，相互检视，互为交付，在一定程度上不仅弥补了非完整团队的缺陷，降低了不同职责人员任务间的耦合度，而且极大的提高了团队的开发效率和项目的研发进度。3三重迭代模型为了解决上一节在软件实施敏捷开发方法过程中遇到的问题，提出了一种三重迭代模型，将敏捷方法中的单个迭代过程分解成

6、了三大类迭代过程。通过对项目的规模大小、需要的开发资源、技术的难度等级评估建立研发团队。下面详细的介绍从项目开始到交付的各迭代过程。3.1需求设计迭代过程3.1.1项目的初始阶段需求设计人员通过初始阶段与客户的交互，获取对开发目标的初步认识。并与客户及其开发和测试人员确定产品迭代周期以及最终产品交付的预期。3.1.2三重迭代阶段（1）需求设计人员拿到开发人员发布的项目最新测试版本，演示给客户。若客户认可当前版本，则把此次迭代的任务模块和需求文档直接抛给测试人员进行测试。若客户反馈问题，保留原先的需求文档，并记录需要修改或添加的功能，加入到下一个迭代周期的任务清单中。而

7、任务清单的各任务，需通过分析其紧急性和重要性，做出优先级判定，优先级由高到低分为A、B、C、D，迭代过程中严格按照优先级顺序进行。（2）在此过程中，如果客户的需求发生改变，那么及时做出响应；若开发人员在上次迭代有任务剩余，则需重新评估确定任务优先级，并加入这次的迭代任务中。至此，此次迭代结束，把生成的需求文档抛给开发人员。3.2编码设计迭代过程3.2.1项目的初始阶段开发人员根据对当前项目的了解和评估，构建最初的设计。3.2.2三重迭代阶段（1）对于需求设计人员那里抛过来的需求文档，选择适合本次迭代工作量的任务需求，对需求进行评估，然后将任务选择分派