敏捷的项目管理精选(九篇)

第1篇：敏捷的项目管理范文

【关键词】敏捷开发;敏捷测试;敏捷实践;测试策略;TDD BDD极限编程项目管理

本文分为以下主题介绍敏捷实践活动的测试策略：

1.敏捷实践启动

在项目启动阶段，通常被称为“sprint 0”或“0 Scrum的迭代”，这个目标是让你的团队根据需求分析找到正确的方向。虽然主流敏捷社区不喜欢谈论这么多，事实是这一阶段的持续时间可以从几个小时到几周 取决于项目的性质和组织的文化。实际这个阶段有个重要的任务就是为了给客户演示未来软件模型而搭建的测试，主要任务是，组织各种方法测试并开始建立测试环境。这个阶段你的项目，你会做初期要求的构想。作为这一努力的结果，你及你的团队应该通过简单的测试获得更好的需求理解，并且制定一些验收标准。

1.1 测试环境搭建

在项目的开始，你需要开始设置你的环境，包括设定你的工作区域，您的硬件，并开发工具（命名一些东西）。有几个策略，来组织你的测试环境：

①采用开源软件（OSS）工具的开发。

②采用开源软件与商业的独立测试工具。

③有一个共同的错误/缺陷跟踪系统

④投资于硬件测试。团队可能需要的硬件上做测试。

⑤投资虚拟化和测试实验室的管理工具。

⑥投资持续集成（CI）和连续部署（CD）工具。

1.2 缺陷管理

缺陷管理往往是交付团队结合自己的需求管理和缺陷管理策略来简化他们的整体变更管理过程。这是因为缺陷是另一种类型的要求。要求也是一种缺陷，事实上，一些敏捷团队甚至捕捉使用缺陷管理工具的需求 。

采用这一战略的主要障碍，是把需求的处理和缺陷处理同等对待。在敏捷交付团队形势估计时，顾客通常需要支付新的需求的开发费用，但是不会同意在项目中支付缺陷的修复费用。在这种情况下，简单有效的做法是将工作项目标记为需要付费的（或不）。这种定价策略是把你的需求和缺陷管理过程合并为一个单一的简单的改变，这也是过程改进的机会。

2.整个团队测试策略

2.1 整个团队测试策略

敏捷社区中常见的一个组织的战略，团队需要包括人的分析能力，设计能力， 编程技能，领导能力，测试。显然这个列表没有罗列全部的团队的能力，同时，也不是每个团队成员都能拥有如上的能力。但是，在敏捷团队中，每个人都能以任何方式快速地学习新的技能，尽可能的通过学习去尝试并且分享给队友，从而提高团队的整体生产力。这被称为自组织“团队”。

如图1所示，我们可以看到传统和敏捷开发流程的不同。在传统瀑布模型下的团队，程序员是常见的（专家） 编写代码，然后把它扔来给测试人员（也是专家）。 虽然比没测试好，但是这样的独立作业，带来的是昂贵的花费和时间的开销。在敏捷团队的程序员和测试人员一起工作，并随着时间的推移，这两个角色之间的区别变得模糊。敏捷社区中一个有趣的哲学是，开发人员应该尽早尽量验证自己的工作，尽自己的能力，努力获得更好的这样做过的效果。

图1 传统和敏捷开发比较

2.2 开发团队测试策略

如图2所示。Ambysoft 2008测试驱动开发（TDD）的调查，TDD的测试技术在实践中的运用。有趣的是受访者明确表示，他们不只是做TDD也不是人人做TDD，令人惊讶的是。他们中的许多人也在做回顾和检查，结束生命周期测试，和平行独立测试 ，活动敏捷的纯粹主义者似乎很少。

图2 敏捷团队测试/验证实践

2.2.1 持续集成（CI）

持续集成（CI）是一种实践，每隔几小时至少一次，最好是更多的时候，你应该：

①建立你的系统。这包括编译你的代码和潜在的重建您的测试数据库（的）。这听起来简单，但大型组成的系统的子系统，你需要一个战略去思考怎样建备份系统以及真实的系统的整体。

②运行你的回归测试套件。你将需要确定的测试范围的大小。对于小的系统，你会得到一个单一的测试 套件的所有测试，但在更复杂的情况下，配置好测试用例是非常重要的。

③执行静态分析。静态代码分析是一个质量技术在自动化工具检查代码中的缺陷，经常寻找如安全缺陷或编码风格的问题类型。

先进的团队，特别是那些在一个敏捷的规模的情况下，会发现他们也需要考虑将CI工作自动化实现并且部署，这样可以推广到其他的环境建设，或如果有一个工作建立在一天结束的时候，你可能想将它部署到演示环境，你的团队以外的人可以看到进展。

2.2.2 测试驱动开发（TDD）

从图3可以看出，有效的TDD方法提供的测试用例比较详细的规格说明更能被工程师很好的把握和操作。有效的单元测试已经是开发文档的重要部分，同时，定义清晰的可被接受的测试用例也会在将来成为产品的一个验收标准的一部分。

图3 测试驱动开发（TDD）是一种敏捷开发技术的实践

图4 一个程序员标准的一天的工作安排

可被接受的TDD的测试用例的开发需要程序员根据需求，已经测试人员的反馈不断调整，同时，自我驱动代码重构及实现。根据图 4显示，其实一个程序员在拿到需求之后，更乐意去不断的寻找之前的类似相关代码的实现然后撰写测试用例，所以相关测试用例最好能够被系统集成并且被分享，这样可以节约开发的时间，也能够为客户的验收测试提供帮助。

2.3 独立的测试团队

整个团队参与敏捷实践的测试工作已经可以协助开发团队发现简单的功能性的测试用例的开发，然后在大规模的复杂开发团队，我们还需要一个独立的测试团队来做独立的完成阶段已经生命周期结束量产前的测试。独立的测试团队努力的目标是找出系统性的问题（整个团队的测试通常是在验证性试验），独立的测试团队将专注于更复杂的体验的测试，区别于整个团队测试，独立的测试团队将支持多个项目团队。大多数组织有许多开发团队并行工作，往往有几十几甚至百名开发人员，所以需要有一定规模的独立的测试团队支持实现规模效应。这将大大减少你所需要的测试工具的许可证数量，分享昂贵的硬件环境，并使测试专家能够分享支持多个开发团队。

从规模效应的角度来看，敏捷开发团队跟独立测试团队的人员配比往往会15：1或20：1，大量的测试人同时工作在多个不同项目组中，而之前传统的人员比率往往接近3：1或1：1。

2.3.1 平行的独立的测试

独立的测试小组报告缺陷给开发团队，这些缺陷被视为需求并被开发团队加上优先级放入工作项栈在下次版本的时候解决。

许多开发团队可能没有所需要的资源进行有效的系统集成测试，从经济角度来看资源必须在多个团队共享。该含义是，你需要一个独立的测试团队的工作 并行地跟解决这些问题的开发团队工作。系统集成测试往往需要昂贵的环境这不是哪个单个项目团队所能承担的。

采用独立的测试的方法依然是现有的质量/测试人员仍然以传统的方式进行的，我们需要帮助测试人员克服这些文化上的挑战，帮助他们获得的技能和心态，有更好的敏捷思维。

2.3.2 结束生命周期测试

结束生命周期测试对于很多敏捷团队来说是一个重要的努力成果，系统准备投产项目即将结束。如果独立的平行试验尽早开始，那么最终通过最后的生命周期测试可以很短，因为问题早已已基本被覆盖。独立测试工作延伸到交付的每个重要的里程碑，一旦解决方案的交付可用，独立的测试团队立即平行地进行完整的测试。

综上所述，敏捷测试贯穿整个项目的生命周期，直至整体解决方案交付完成，在这个期间影响软件质量，测试效果的不单单是独立的测试团队，整个团队的每个利益相关者都需要参与，灵活的测试环境以及便捷的缺陷管理，敏捷的灵活的测试策略能够帮助我们交付一个完美的整体解决方案给客户。

参考文献

[1]徐德华，应翔翔.论知识共享模型及其在中小型企业中的应用[J]. 经济论坛，2010，12.

[2]王敏.基于Scrum敏捷开发的软件过程管理研究[D].昆明理工大学，2010.

第2篇：敏捷的项目管理范文

[关键词] 制造企业 项目管理 敏捷响应

我国已经成为世界级的加工制造中心。在全球化的竞争背景下，面对跨国公司的强势进入，我国制造业的竞争优势和持续发展，仅仅靠低劳动力成本是不够的。目前，我国的制造业整体上在产品的创新能力、成套能力、生产的自动化和优化水平、企业的管理和协作能力及竞争核心技术的开发等方面和国际先进水平方面还存在不小的差距[1]。更为严重的是多数的制造企业缺少现代化管理的理念、方法和手段，众多的企业处于经验管理阶段。小而全、大而全的庄园式企业缺乏快速响应市场的能力，严重制约着企业的生存和发展。企业持久的竞争优势和持续的发展源泉是不断的企业创新，管理模式创新作为企业创新的一个重要方面，对我国制造企业发展具有重要的意义。一个国家如果没有企业管理创新机制和现代化的企业管理模式，就不可能产生具有国际竞争力的现代制造业。为此，我国要适应世界管理发展趋势，探索自己的制造企业管理模式，不断提升制造企业参与国际市场的能力，进一步提高我国制造行业的整体竞争能力。

一、制造企业敏捷响应模式

1.企业生产经营体制的转变

近十几年来，信息技术的发展和企业组织结构的变化冲击了原有的生产经营体系，推动了制造企业生产经营体制的变革。制造行业买方市场的形成，使企业由单纯的经营管理领域逐渐地向服务拓展，产品越来越受到消费者个性化需求的影响。消费需求个性化增加了产品的复杂性，功能的多样化，单一或者几个企业难以通过简单的联盟来完成产品的生产。制造企业要想实现竞争中的持续性发展，必须在生产经营体制上实现一种转变。越来越多的企业意识到实现由传统的物流体制向先导物流与供应链管理方向的重要性。物流（Logistics）和供应链（Supply Chain）如今已经成为企业寻求长远发展，提高竞争力的主要源泉。企业在充分利用电子商务和现代物流管理的成果，增加生产的快速响应能力。从企业的战略角度上重视物流的再构筑和供应链体系上的联盟活动，在企业发展战略的基础上，实现企业生产经营体制的转变。

企业的生产体制实现了推式经营（Push Marketing）向拉式经营（Pull Marketing）的转变。从本质上讲，推式经营体制通过大量生产、伴随大规模物流体制而实现的批量商品处理和商品的运输，实现单位成本的下降。推式经营体制利用大规模集中生产、物流和流通库存达到规模经济效应。但是，在交易过程中产生的交易费用却很大。

随着竞争的加剧，推式经济体制的制度安排出现了较为严重的缺陷，同时，市场环境在消费者需求行为的变化、流通格局的变化和产品生产线的融合与经营网络的形成等几个方面的变革催生了企业生产经营理念从强调以正确的价格提供正确的商品过渡到提供正确的价格（right price）、提供正确的商品（right commodity）、在正确的操作成本（right cost）前提下，以正确的时间（right time）送到正确的地点（right place），实现依靠的是商流、物流、信息流和资金流的完美结合的拉式生产经营体制。拉式生产经营体制强调市将销售地点信息同步的传输给商品策划、设计、生产以及库存地点，通过销售地点的信息设计、生产、物流和经营决策。

2.业务外包格局的出现

实现项目产品的大批量和个性化，关注质量、完工时间和缩短项目的生命周期是制造企业现阶段的重要任务。在这种情况下，制造企业的规模趋于小型化，在保证核心及增值流程事业领域的基础上，减少非核心业务，增加对于市场的敏捷响应。

业务外包已经成为制造行业的一种重要的形式，其特点是业务流程中的动态联盟和供应链上的协同。从系统的角度来看，动态联盟实质就是一个系统，通过系统的优化实现供应链上成本的不断降低。通过信息化平台实现跟踪消费的个性化需求，提高敏捷响应的能力。系统的动态性决定了制造企业敏捷的特性。

3.敏捷响应模式

生产经营体制的转变使企业的视角转向销售导向，业务外包格局的出现加强了企业之间的协同，实现发展战略和灵活生产经营形成敏捷响应模式。制造企业的市场敏捷响以核心竞争能力为基础。通过信息化平台，总装项目产品在虚拟企业范畴内进行。制造企业敏捷响应实现的基础――项目团队在不同产权主体形成的动态联盟中成为基础的单元。敏捷模式的核心――项目团队不仅仅是制造计划的执行者和制造信息的快速响应者，还是大量制造实时信息的集散地。这些制造实施信息的快速采集、传递和利用的效率体现敏捷能力，在很大程度上决定了企业的生产进展、上市时间、生产成本、生产质量等关键目标，决定了企业对于市场的整体响应能力。

图1显示了联盟制造企业与项目产品对应的结构图。项目团队在项目办公室的领导，既要符合动态联盟，又要符合制造企业公司层面战略需要，具有虚拟性和继承性[4]。美国著名的科学家David I. Cleland指出，在应对全球化的市场变动中，战略管理和项目管理将起到关键性的作用[2]。在20世纪90年代提出的企业项目管理和项目组合管理正是项目管理理论和方法在企业中应用的一种体现。结合图1，在动态联盟中，以项目团队运作的方式把项目订单当作项目进行运作形成制造企业项目管理运作模式，在一定程度上实现敏捷响应。

制造企业项目管理是一种敏捷模式下制造企业运作的基础，它拓展了传统的项目管理理论，集成其他先进管理模式形成的面向整个项目产品供应链的战略，以提供客户个性化需求产品为宗旨，通过跟踪虚拟产业链上主制造企业总装项目产品的生产计划，实现企业对于需求的敏捷响应，通过按项目进行管理，实现产品成本、交货期和质量等因素的集成以及项目组合资源分配，以达到资源的优化、降低成本、缩短功能集成单元的生产周期，从而整体上提高总装项目产品上市的时间。

二、制造企业敏捷响应模式框架与知识体系

1.敏捷响应模式框架

制造企业的敏捷响应，就是企业建立能够对外部市场环境能够做出快速响应的组织结构和战略规划，通过改造传统的生产模式来增加对于市场的快速响应能力。敏捷响应不仅仅是一种战略上的敏捷，更是一种作业层面的敏捷，这两种敏捷通过柔性化的组织结构实现。如图2所示：

从战略层面，从企业发展的战略出发，通过项目的优选评价，确定项目的优先级。

从企业作业层面上，实现项目时间、成本、质量、设备利用率和员工安全度等目标的集成控制。

从企业作业层面上，进行项目的组合管理实现企业多项目资源分配的优化。

通过以上的分析我们可以看出，制造企业项目管理围绕作业层面展开，通过改善生产流程，优化过程管理，提高企业敏捷响应能力，实现敏捷响应战略。

2.敏捷模式知识体系

敏捷模式下制造企业项目管理注重人的因素、顾客、柔性、变革。本文认为，敏捷模式下的制造企业项目管理知识框架包含以下五个要素：项目管理目标、项目管理组织、项目管理信息系统、项目管理系统方法和项目管理文化。

(1)项目管理目标

项目管理目的是在企业敏捷战略指引下制定企业项目管理目标，即企业项目管理者的着眼点应以企业战略目标的达成为指导，而非局限于作业层面的“项目交付”。企业的战略目标是一种成果性的目标，比如持续的发展和企业绩效的提升等等。

(2)项目管理组织

项目管理组织是维持持续不断的企业管理活动，是项目成功实施的必要条件。项目管理组织的重要特征是柔性化。

(3)项目管理信息系统

信息系统通过优化整个信息流程，在合适的时间把合适的信息传递给需要信息的人员，这些信息包括项目管理理论与方法的管理支持信息，企业自身及其外部可以提供支持的信息，是一种全方位立体性的信息网络。

(4)项目管理系统方法

制造企业的发展需要关注各个利益的相关体、接近顾客群体，影响企业经营的因素越来越多，系统的观念对于企业经营的影响日渐显著。分析研究各要素之间的相互联系，需要从系统整体的角度进行优化经营。

(5)项目管理文化

企业文化要做相应的调整以适应企业战略项目管理的要求，形成统一标准化的语言，以使企业项目管理融入企业战略、战术决策及各项活动之中，成为员工一项自觉的行为。

敏捷模式下制造企业项目管理知识框架如图3所示。

三、制造企业敏捷响应模式关键技术

图2可以看出，制造企业敏捷响应模式解决、作业层面的单项目多目标集成、项目组合资源优化和公司战略层面的项目优选评价。

1.单项目多目标集成

项目订单中涉及成本、质量、交货期、设备利用率和员工安全度五个方面的目标构成一个系统，目标的完成是一个系统集成优化的过程。作业层面的多目标集成管理包含主动控制、被动控制和项目评估三个方面的内容。本质上看，多目标集成管理是一种多目标决策，由于目标的不可公度性，可以通过多极模糊评判法找到各因素的相对权重实施控制。

2.项目组合资源优化

资源的有限性促使企业不断的提高资源利用的效率。项目资源的优化通过释放关键资源，降低项目组合中单个项目占用资源的无效时间。

3.项目优选评价

在敏捷响应模式下,保证项目的组合能够综合有效的利用企业的资源。因此，确定项目执行的优选次序是制造企业项目管理的关键工作。项目评价标准直接影响到项目的优先顺序，进而影响到项目执行的顺序。对企业待选项目进行评价排序将保证实施的项目与企业敏捷战略紧密相连，项目优选顺序的确定也将影响到企业的持续发展。因此，科学实用的项目组合优选评价体系将是项目组合管理和制造企业项目管理成功的重要保证。一般地，需要从与企业战略的协同程度、竞争优势、降低运营成本、满足客户的需要或期望和对企业的价值贡献几个方面出发进行评价。

四、结语

项目管理作为一种近些年发展起来的一种新的管理模式，已经成为制造企业应对激烈竞争的市场环境的一种有效的方法。从战略的角度，通过战略管理和项目管理的结合的制造企业项目管理将成为企业实现持续发展，保持核心竞争能力的必经之路。这一模式的深入研究和应用将有助于实现组织、技术和人三者的有机结合，有效的应对制造企业面临的激烈竞争。

参考文献：

[1]戴勇马万太:生产过程数字化管理[M].科学出版社，2004年第一版

[2]Yang Xiaoyuan，Song Guanxing. On the intelligent evaluation system for agility of enterprises. In∶Proceedings of 1st International Conferenceon Engineering Design and Automation,EDA’97,Bangkok Thailand,1997, KY40026 USA∶Integrated Technology Systems Inc,1997

第3篇：敏捷的项目管理范文

关键词：敏捷；风险管理

1，敏捷及敏捷软件开发

20世纪90年代中期，起源于瀑布模型的软件开发过程被认为是缓慢、低效和官僚主义的，有悖于快速高效的工作。作为回应，各种敏捷软件开发方法学适时提出。敏捷软件开发是以人为本，自适应性，通过沟通、协作等方式进行迭代，循序渐进的软件开发方法。每一次迭代通过一个完整的软件开发周期，包括规划、需求分析、设计、编码、单元测试和验收测试，把一个可运行的工作产品展示给利益相关者。这有助于降低整体风险，并快速适应和调整内外环境的变化。

2，项目风险管理

项目的风险来源于不确定性。一个典型的项目风险管理包括风险规划、风险评估、风险应对和风险监控四个过程，其中风险评估又包括风险识别和风险分析。风险规划从战略角度确定了风险管理的过程以及实施方案。风险评估是利用事件发生的概率及结果来识别、分析、量化项目中的风险。风险应对是以降低风险至理想程度为目标的计划和执行过程。风险监控是系统化的风险追踪过程。

3，敏捷软件开发的风险管理

敏捷软件开发风险管理的思路是：首先分析敏捷软件开发的特点，然后结合风险管理过程进行管理。敏捷软件开发通过其执行结构规避和减轻了常见的软件开发风险，但这也引进了开发过程的不确定，因此也蕴含了大量的风险。

1） 敏捷软件开发的风险分类

软件开发可分为人、过程、产品和技术四个纬度，它们互相联系和统一，共同决定了软件开发的速度和效率。以下是敏捷软件开发中这四个纬度上的主要风险来源。

（1）人员风险。人员风险有沟通不畅，缺乏协作，人员变动，素质低下，矛盾和冲突，缺乏激励，士气低下，对业务不理解，缺乏优秀人才，缺乏客户介入等。

（2）技术风险。技术风险有伪敏捷，架构体系不稳定，设计不佳，缺乏技能，高估新技术等。

（3）产品风险。产品风险有功能不符，需求镀金，功能蔓延，质量低下，工期延误，成本超支，客户满意度低，低产品价值，低投资回报等。

    （4）过程风险。过程风险有缺乏计划，迭代掌握不佳，评估和规划不合理，缺乏风险管理，缺乏质量保证措施等。

2） 敏捷软件开发的风险处理

以下是敏捷软件开发从人、过程、产品和技术四个纬度进行的风险处理过程。

（1）人员风险。敏捷软件开发通过频繁沟通、每日站立会议、反馈等方式解决了沟通不畅，缺乏协作的问题；通过领导、结对编程、代码集体所有权等方式促进团队协作，提高技能素质，应对人员变动，降低矛盾和冲突；通过频繁的产品提高人员成就感和士气；通过现场客户，降低缺乏客户介入的风险。

（2）技术风险。敏捷软件开发通过迭代、测试套件、重构等方式适应变化和演进，避免了传统的开发方法在一开始就进行架构及设计，从而导致架构体系不稳定和设计不佳的风险。对于敏捷技能风险，可以通过引入敏捷教练、结对编程、学习环的方式加以应对。而对于非敏捷软件开发所特有的普适性技术风险，可以通过组织和加强内部技术人员的培训和培养，引进能解决项目关键问题的优秀人才，防止优秀人才的流失等方式进行规避。

  （3）产品风险。敏捷软件开发通过迭代、反馈、客户参与的方式解决了构建错误产品、功能蔓延、需求镀金、质量低下、客户满意度低等风险。可以通过综合考虑功能价值和风险，按照高风险高价值低风险高价值低风险低价值高风险低价值的顺序开发产品功能，渐次降低产品的价值风险；通过对净现值、内部收益率、回收期、贴现回收期等经济指标的综合分析，规避项目的投资回报风险。

  （4）过程风险。敏捷软件开发通过产品规划迭代规划任务逐渐瞄准的形式，极大地消除了各种不确定风险。对于软件开发过程的进度风险，可以通过设置功能缓冲区和进度缓冲区，从功能和进度两个方面保护项目免受不确定性的冲击；也可以从以下三个方面对进度风险进行定量分析。

  ①N=S/V(N：估算的项目总迭代数，S：项目的总故事点数，V：速率，是基于历史数据计算的每一次迭代所能完成的故事点数)。

  ②用正态分布N(μ,σ?)，得到每一次迭代的平均故事点数X和标准差σ，计算μ=(S/N-X)/σ，并得出项目按时完成的概率。

  ③综合正态分布，PERT分布，三角分布进行蒙特卡罗模拟，得出模拟的结果并绘制累计完成的概率分布。

4 结束语

敏捷软件开发是一种新型的软件开发方法学，而风险管理是软件项目管理中一个非常重要的部分。把敏捷软件开发和项目风险管理结合起来，从而有效地缓解和规避敏捷软件开发过程中的风险，是一个重要而有意义的课题。本文从人、过程、产品和技术四个纬度对如何防范和缓解敏捷环境下的风险进行了探析，为敏捷软件开发的风险管理提供了一条思路。

参考文献：

第4篇：敏捷的项目管理范文

【关键词】敏捷测试 Scrum 研究

21世纪是信息化技术全面高速发展的时代，企业之间的竞争日趋激烈，产品质量对于企业的发展重要性得以凸显，并成为企业核心竞争力的突出表现之一。软件行业也面临类似的问题，软件系统变得越来越复杂，传统的软件工程理论下软件开发周期过长、无法保证软件质量、开发过程冗长、笨重，加之频繁的人员流动、迅速变化的市场，都让传统的软件开发方法无法适应新的市场竞争环境，软件的失败率变高。软件测试越来越受到重视，敏捷测试是软件测试的重要组成部分，本文尝试基于Scrum开展敏捷测试应用进行概述。

1 敏捷测试概述

敏捷开发模式正处于逐步推广阶段，具有较大的发展潜力。现代经济生活中，很难甚至无法预测基于计算的系统如何随着时间的推移而进行演化，市场情况瞬息万变，最终用户的需求也在不断变化，新的竞争危险也毫无征兆的出现，故对于轻量级的软件开发而言，需要不断变化，以应对以上软件开发问题。敏捷开发以人为核心，迭代，循序渐进，拥抱变化是其基本动力。

敏捷过程有以下要点：

（1）通过频繁迭代与客户形成早期良好合作，及时反馈提高产品质量；

（2）客户、需求人员、开发人员进行有意义频繁的交互，以及早发现问题；

（3）衡量功能实现的唯一标准是该功能的开发测试已完成，并测试通过。

敏捷测试以沟通、简单、反馈、勇气、尊重为核心价值观，在敏捷软件开发过程中开展的测试便可称为敏捷软件测试，测试人员适应变化，与技术人员、业务人员进行良好的协作，立即测试记录需求、驱动开发思想。敏捷测试法继承了敏捷软件开发原则，作为一个优秀的敏捷测试人员，需要遵守以下原则：提供持续的反馈，为客户创造价值，进行面对面的沟通，勇气，简单化，持续改进，相应变化，自我组织，关注人，享受乐趣。敏捷测试不仅仅是测试软件本身，而是包括软件测试的过程与模式，敏捷测试的目的是为了尽可能使功能与客户预期一致，确保开发、管理过程正确。敏捷测试人员需要参与所有的团队讨论与决策，测试人员需要开展更多的与测试无关，但与团队目标直接相关的工作。

相较于传统的测试，敏捷测试与开发并行，甚至优先于开发，测试团队也是开发团队的一部分，除却绝对的必要，工作软件即是文档，及时应对变化参与所有的团队会议、团队决策，极力促进团队沟通、团队与客户沟通。

2 基于Scrum的敏捷测试

Scrum是当前应用最广泛的敏捷开发方法，过程清晰有效，适合敏捷经验不足的团队使用，以下就此进行概述。

2.1 Scrum过程

Scrum过程包含三个过程：

（1）设计计划与体系结构，即将产品功能需求、缺陷、更新用户需求等待开发项，作为优先级排成等待开发项目，然后根据列表，进行风险评估，制定产品交付规则。其次，需建立体系结构，将待开发的项目分解为一系列的“问题包”，每个问题包包含一组对象集合，再将问题包按照同样的原则划分为迭代小组，在此基础上，团队建立独立的开发测试运行环境。

（2）迭代过程，包含多个迭代，每个迭代都对应相应的时间段，通常而言，一个迭代周期为2-4周，每个周期结束后开始下一个周期，每个迭代周期都需要相应的设计、测试、编码活动，每个迭代结束后，都需要完成计划内的待开发项目。

（3）交付过程：当开发产品经风险评估后，边可以进行验收测试，进入交付阶段，组装项目组，系统测试、回归测试，完成最终文档等步骤。在基于Scrum过程开发过程之中，需要达到风险评估标准才能停止开发，交付过程的最终目的在于是否在迭代过程中出现被忽视问题，为下一阶段的开发做准备。每次迭代，订单订单项不允许修改。

2.2 Scrum测试管理

（1）需要做好人员的配置，按照与项目的关系，将人员分为实际参与人员以及项目组外人员，包括经理以及最终用户等，前者主要包括管理者、产品负责人与团队，Scrum管理者不是项目经理，由能力较强熟悉Scrum成员承担。产品负责人是指一个角色，来自于用户、客户、销售部或开发部门的需求分析者，易于协作、沟通，具有代表性，有一定的授权，熟悉需求。

（2）需明确测试角色，软件开发工程师复杂编写代码，完成白盒、黑盒测试、单元测试。自动化测试工程师需要负责测试脚本、工具代码。测试工程师需要了解产品需求、编写测试案例、追踪产品，客户负责验收。

2.3 Scrum测试模型

Scrum测试过程中，做好需求分析、分解测试的需求，及时与研发产品人员沟通的是关键。测试的一阶段，需要根据软件设计、需求，完成确认对所需要使用的测试工具，包括需求管理工具、测试案例、缺陷管理工具等，大规模公司可开发适应本公司的管理工具。在迭代阶段，每个迭代周期结束前，都需要提交方针，测试该周期或上个周期完成功能，以评价开发功能是否达到预期。

2.4 Scrum测试过程管理

首选，需要编制Scrum下的测试计划，以文档形式呈现，对整个测试过程都需要有相应的测试计划书，每个迭代阶段计划书都有相应的功能性文档修改。

计划书需要突出以下几点：

（1）产品的基本信息，记录Sprint各个阶段测试情况与结果，开发测试所有角色任务列表；

（2）确认测试计划包含的测试范围，根据新开发的功能及其相关的原有功能，需要定义划入测试产品功能，进行冒烟测试；

（3）划分测试阶段、明确方法与任务。在每个测试过程中，都需要有计划书、案例，测试过程中需要提交缺陷至相应的管理系统，在测试过程中需要明_监控测试的方法，搭建测试环境，评估进度计划风险，安排测试时间。

3 小结

基于Scrum的敏捷测试非常适合小型软件开发企业，容易上手，但作为一种科学管理方法，想要完整的掌握也有一定的难度。软件开发企业需要与时俱进，掌握该方法的精髓，即重视迭代管理、团队协作，勇于创新。

参考文献

[1]杨娜，严振亚.基于Scrum方法的敏捷测试探讨[J].数字技术与应用，2017（01）：51-53.

[2]张晓静.敏捷测试在移动App开发中的研究与应用[J].电子科学技术，2015（02）：211-213.

[3]孙笑，张小晶.Scrum敏捷测试――从敏捷测试中寻找发展机遇[J].科技创新导报，2014（25）：255.

[4]曹栋.敏捷测试在银行IT领域中的研究与分析[J].电子技术与软件工程，2014（16）：98-99.

第5篇：敏捷的项目管理范文

【关键词】 软件质量管理 GJB5000A 敏捷开发

一、引言

在国防信息化程度的不断提高的今天，军事领域中的软件产品已经成为了和硬件产品比肩而立的重要存在，军用软件的质量高低也成为了决定军事和武器系统质量的关键因素。随着武器装备系统中的软件规模迎来爆炸式增长，只有对过程质量的全面控制，才有可能最大程度的降低风险，提高软件产品质量。我单位从2011年开始试推行GJB5000A软件研制过程管理，到如今已实现了军用软件研制能力二级管理的全面覆盖，期间为兼顾不同专业领域、不同项目类型、不同规模和军兵种的要求，对体系进行了持续改进。改进焦点在执行GJB5000A标准的大框架下尽可能解决特异性问题上，同时在开发方法及操作层面上鼓励项目组团队在现有质量体系策略要求下进行创新式探索。其中利用敏捷开发的方法与CJB5000A管理体系的融合就是一种有益思考。

二、GJB5000A质量管理体系结合敏捷方法在科研院所的适应性

2.1 GJB5000A在科研院所的落地实施

GJB5000A-2008《军用软件研制能力成熟度模型》作为框架模型，体现了业内软件研制过程最佳实践集，其采用分级表示的方法，按预先确定的过程域来定义组织的改进路径，同时规定了软件研制和维护活动中的主要软件管理过程和工程过程的实践。模型五个级别中共定义了22个过程域，每个过程域由不同个数的专用目标和相同个数的共用目标组成，每个目标又推荐了不同的实践。在GJB5000A的定义中，目标是必需的部件，实践是期望的部件，我们用满足所有目标来确定过程域的实现，用实践来指导过程改进和评估。换句话说，GJB5000A标准允许我们用规定的实践或可接受的替代实践来满足目标。所以科研院所要想真正实现标准落地就必须按照单位自身产品特点和用户要求将实践本地化。

在实现本地化过程中，组织会按照大多数项目的模式定义标准过程，但却无法确保所有过程适用于所有项目，同时在执行自由度上也遇到了很大困扰，强约束导致了项目缺乏灵活性，而降低约束度则可能带来质量和进度的双重风险。此外，即使组织开放了项目组利用替代实践实现目标，但南于团队人员的经验不足，也很难找到恰当的替代实践，组织还必须承担面对评估时替代实践有效性的质疑，所以在组织层面上定义多种开发方法供项目选择就显得尤为重要。

2.2 敏捷开发方法在军用软件研制过程中的适用性

软件敏捷开发是一种相对于传统软件开发而言的轻型开发方法，它改变了传统开发中以文档为驱动的开发模式，以人为主要驱动核心，目前常用的基本敏捷实践方法有很多，如极限编程（XP）、Scrum方法、特征驱动开发（FDD）等，每种方法的实践过程都有不同，但基础都是基于增量和迭代的过程。软件敏捷开发有四大价值观：个体和交互胜过过程和工具；可以工作的软件胜过面面俱到的文档；客户合作胜过合同谈判；响应变化胜过遵循计划。这些特点使得敏捷开发方法灵活、适用多变需求，可快速交付，但应用在军用软件研制过程中可能会带来以下问题：1、敏捷开发方法应用的是需求的快速迭代，每一个迭代作为一个计划阶段，很难对项目的整体目标有完整计划。2、敏捷开发方法更注重有效代码的快速交付，而非文档，这对有严格军标约束下的文档编制提出了更高的要求。3、敏捷开发最重要的开发方式是与客户一起开发，因军用软件的需方往往是部队使用方，面对面开发的形式较难实现。4、敏捷开发方法对开发人员的能力要求极高，人员要不但要精通设计、编码、测试相关工作，而且要能参与项目的需求分析和架构设计，能对频繁变更的需求做出快速响应。

既然敏捷方法会带来以上问题，我们为何还要考虑在军用软件承研单位引入敏捷开发过程呢？这是因为随着军用软件研制领域中引入的竞争机制，出现了越来越多需要直接进行代码交付的PK项目，如果再应用传统研发方式，就失去了市场竞争优势。所以，对于规模小、周期短、需求变动频繁、现场开发为主要形式且已经具备了较稳定的开发技术架构的项目而言，敏捷开发方法既能让项目组在短时间内针对需求拿出有效代码，而且在快速迭代中能总结大量有用的文档信息。只要我们可以偏重组建成员技术水平在同一层面上的成熟开发团队来承接这样的项目，必然起到事半功倍的效果。

三、GJB5000A质量管理体系下的敏捷开发方法实施

3.1 用敏捷开发方法定义过程

在组织级，GJB5000A三级过程域中的组织过程定义（OPD）可以帮助组织建立起自己的敏捷开发方法下的过程定义，包括过程和过程元素的说明，过程剪裁指南，敏捷开发方法下的生命周期，标准工作环境、组织测量库、组织资产库等。有了组织级定义，项目组就可以按照集成项目管理（IPM）实现方法对组织标准过程进行剪裁，形成项目的已定义过程（P'DP），这个过程就可以直接指导项目的过程实施。从项目级的角度看，GJB5000A的过程管理关注的是项目做了什么，而敏捷开发方法正是提供了该怎么做的具体开发方法，敏捷开发方法中的活动经过合理替代和剪裁的实践方法以实现GJB5000A目标是完全可行的。

3.2 敏捷开发方法实践

1.实践方法的选择。在敏捷开发的众多方法中，我们选择了以Scrum为基本敏捷实践，以持续集成（CI）和测试驱动开发（TDD）为扩展方法的敏捷开发架构。Scrum方法是敏捷开发中最典型的模型框架，它把产品需求的实现分为若干个Sprint来完成，每个Sprint完成后进行产品演示，收集、细化直至实现用户需求，整个过程为一个迭代式增量过程。持续集成提倡利用一个全自动的过程，在一天中根据代码变化进行多次构建（包括编译、和自动化测试）来验证集成结果和发现集成错误。测试驱动开发技术（TDD）基本原理是在开发功能代码之前，先编写单元测试用例代码是持续集成的验证手段。

2.项目定义过程。Scrum结合CI与TDD的过程可以简单描述为：一开始先由项目负责人确定一个ProductBacklog（产品需求列表），而后召集项目团队召开Sprint计划会议对列表中的需求进行工作量预估和安排，从中挑选出一个story作为本次迭代完成的目标，形成SprintBacklog（迭代需求列表）分配给项目组成员，每个成员接收到任务后将任务进一步细化，在每日例会上汇报自己的完成情况和对下一步工作作出承诺，同时在公示板上标注出自己的工作情况（燃尽图法等方法）。每个项目组成员对工作进行每日集成，集成后利用测试驱动开发构建测试来快速评估集成结果，如果发现问题马上修改，再次集成测试，反复循环，直到一个迭代结束形成可用的代码。

3.用GJB5000A过程管理敏捷开发方法下的研制。从项目层面看，Scrum方法可以结合GJB5000A过程域中的需求开发，项目策划、项目监控等，CI与TDD可以结合产品集成、配置管理等，当敏捷开发的方法在GJB5000A的过程管理方法约束下，可以得到更精确的控制和工作产品反馈。下表我们就给出了部分实践的实施方案。

第6篇：敏捷的项目管理范文

2005年，英国电信集团开始

用以Web为中心的架构取代日益老化的、基于Unix的电话流量监控系统。目的是让流量管理人员能够更迅速地改动交换机及其他物理设备，从而处理这家公司的庞大电信网络上任何一个部位的网络负荷变化，又不至于导致系统负荷过大。

新系统在2005年年底推出，它大大简化了那些电话流量控制人员均衡网络负荷的工作。英国伊普斯威奇的首席软件开发员Kerry Buckley曾参与这个项目，他表示，当时，公司里面甚至没几个人知道旧系统是如何工作的。

但这个开发项目最显著的地方在于: 项目是在英国电信仅用了90天的敏捷开发周期框架内完成的。这家总部设在伦敦的电信业巨头在2005年改用敏捷开发方法之前，第三方开发人员征集需求就可能需要3～9个月的时间，据英国电信设计公司的CEO兼英国电信集团的CIO Al-Noor Ramji介绍，随后的开发本身可能至少需要18个月才能完成。

Ramji表示，传统的软件测试周期通常在编码工作完成后进行，会使项目再延后好几个月。他说，公司改用90天、常常是30天的软件迭代周期（software iteration cycle）至少把开发周期缩短至原来的1/4。这意味着，他们能大大加快交付最终产品的速度。敏捷开发的核心思想就是迅速编码、充分检验已编好的代码、修复任何问题，然后开发新项目。

虽然许多电信公司过去与像敏捷开发这样的先进开发方法并没有联系，但英国电信的IT部门需要加快系统开发周期，帮助尽快交付新的移动服务及其他类型的电信服务。

英国电信向敏捷开发转型，这也意味着其3000人的全球开发部门将与最终用户更紧密地合作。伦敦英国电信设计公司的服务设计总经理J.P. Rangaswami说，这在需求收集阶段更是如此，以便能更好地了解及满足用户需求。

Rangaswami说，为了提高开发人员的沟通技能、加深对敏捷开发的认识，英国电信让编程人员参加一系列课程和实际动手的培训课。公司还在过去的两年里从多个行业招来了具有敏捷开发经验的IT专业人士（人数未透露），他们帮助指导对这套方法还比较生疏的其他开发人员。

改变观念

Ramji和Rangaswami都表示，虽然英国电信从传统的瀑布开发技术改用敏捷开发大大提高了生产力和业务效益，但不是一夜之间就成功的。对于像英国电信这样规模庞大、分布广泛的公司来说，也不是轻易就能成功的。

Ramji表示，首先，公司的IT领导人必须消除公司内外业务客户的一些误解。他们以为，敏捷开发意味着可在开发周期过程中频频要求更改软件特性，以满足自己一时想到的要求。

另外，公司改用敏捷开发更容易被高层主管和初级员工所接受。中层管理人员对于敏捷开发给自己带来的影响反倒持比较怀疑的态度。Rangaswami表示，反对派包括IT基础设施管理人员，他们习惯于针对新软件或者对现有系统的功能改进拿出更正式的说明文档。

为了帮助消除这些怀疑，公司邀请业务客户前往英国电信的开发部门，亲眼看看90天的开发周期是如何运作的。由于每天与英国电信的软件开发人员进行郊游，连一些外部客户也开始完全相信这套方法，因为这可以让他们大大加强控制项目开发工作的能力，Ramji说。

英国电信的开发部门投资了近500万美元来启动敏捷开发项目，包括针对开发人员的研习班培训所需费用。公司还改变了自身在如何管理及执行项目方面的观点。Rangaswami表示，快速、迭代的敏捷开发方法有助于这样的软件项目: 开发队伍在不同地方（如伦敦和印度）协同工作。

Ramji、Rangaswami及英国电信的其他IT领导人还要说服IT管理人员和员工，敏捷开发未必意味着贬低软件质量保证和测试的重要性。Rangaswami 说: “在过去，我们在系统投入生产环境之前经常进行十六七次测试。如今，我们认为只有一种测试是重要的―从客户概念到软件完成的测试。”

第7篇：敏捷的项目管理范文

关键词：敏捷开发模式；软件架构；重构技术；迭代

中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2015）06-0091-02

软件开发通常需要在完成问题的定义和规划的基础上，经历需求分析、软件设计、编写代码和软件测试等四个阶段[1]，其过程是一个复杂、甚至循环反复的过程。传统的开发方法通常需要在进行具体的开发之前确定用户的全部需求，然后据此制定一个跨越整个软件项目开发周期的详细计划，之后的开发过程均以此为依据。这种开发模式的优点是可以很好地保持整个软件设计的一致性，而缺点就是一旦情况发生改变，需要调整框架结构，这个详细的计划就有可能作废，导致产生大量的没有应用价值的复杂文档，无谓地提高了软件开发的成本和难度。为了规避上述这些传统的重型开发方法的弊端，近年来出现一种新的轻量级软件开发方法――敏捷开发方法，该方法是一种典型的轻型软件开发方法，它集众多轻型软件开发方法的优点，强调以人为本，突出“适应性”的特点[2]，能够快速根据软件开发过程中的各种变化及时作出调整，最大限度降低软件开发的成本和风险。

本文在比较敏捷开发与传统开发方法的优缺点的基础上，分析了敏捷开发模式的核心思想和设计理念，结合具体项目探讨了基于敏捷开发模式的软件架构的设计方法，包括采用的设计技术、构建思路和执行规范等。

1 敏捷开发模式与传统开发方法的比较

敏捷开发是近来备受关注的软件开发方法，它是一种基于迭代思想的软件开发方式，以人为核心驱动整个软件开发流程的实施和推进，它是管理软件开发过程的一种新方法和新思路。在敏捷软件开发中，软件项目被划分成若干个子项目，通过多次迭代细化完成，每次迭代都有明确的目标并能快速交付可运行的软件[3]。敏捷开发侧重概念和软件架构的设计而简化软件的详细设计部分，为后期留下调整的空间。采用敏捷开发的软件项目时，其软件架构在初期的设计只是做到刚好满足需求即可，后期根据对于软件需求的理解和更新需求，采用重构技术逐步调整设计。敏捷开发由一组简单却相互依赖的实践步骤结合而形成的有机整体，突出了存在于“人”之间的关联，包括程序员之间的沟通、开发团队与客户之间的反馈，注重双方创新的勇气和软件系统的简单 [4]。通常从软件项目启动之初，就强调通过周期性的软件测试来获得需求反馈，程序员尽可能早地把软件初稿交给客户使用，并配合客户通过使用该软件发现其中的漏洞，进而对软件的初稿进行优化，同时及时应对客户对软件提出的新的需求。表1显示了敏捷开发模式与传统开发方法的区别和优势。

表1 敏捷开发模式与传统开发模式的比较

[开发阶段＼&方法对比＼&敏捷开发模式＼&传统开发模式＼&需求分析＼&将用户需求进行分解，形成开发故事，通过迭代细化，增加新的用户故事＼&开发初始阶段获取用户需求，制作详细的需求分析文档，该文档指导整个开发周期＼&软件设计＼&根据客户的当前需求进行设计，最简单的既是最好的，不过分构建，不做预先设计＼&获得用户需求文档后，严格按照文档实施设计＼&代码编写＼&利用重构技术简化代码，编程人员与测试人员结对编写通过测试的代码，持续集成＼&由编程人员编写，由测试人员对代码进行审核＼&软件测试＼&在编写代码之前先编写测试代码，自动化完成测试＼&编码完成后单独进行各种测试＼&]

从表1可以看出，敏捷开发对传统的软件开发的四个阶段都进行了相应的改进，模糊了“阶段”的概念，避免了传统软件开发方法的繁琐和死板，使其更加灵活，可以及时响应客户的最新需求动态调整开发过程和软件架构，将简单的、不多的开发步骤不断迭代细化、优化改进为用户最为满意的结果。

2 基于敏捷开发模式的软件架构设计

通过前面的分析，基于敏捷开发的架构设计包括三方面的核心要素：一是敏捷架构设计的整体思路；二是敏捷架构设计所采用的关键技术；三是设计和执行过程的规范化管理。

2.1 设计思路

敏捷开发的突出优势在于以快速的、增量式的开发方式，第一时间将可工作的软件交付客户手中，然后根据与客户的交流，反馈软件的使用情况，根据客户需求调整软件结构。它是一种始终以人为核心的，迭代升华、循序渐进的开发方法，这一思想贯穿敏捷软件开发的方方面面。对于软件架构的设计也遵循这一原则，图1显示了基于敏捷开发模式的软件架构设计过程。

从图1可以看出，敏捷型软件的开发过程也是软件功能逐渐完善，版本逐渐升级的过程。换句话说，敏捷开发中架构设计采用的是进化式的设计方法，即在软件开发的整个周期中，通过一次又一次的迭代细化来修改、完善和充实设计方案，使得架构获得最优化，最大限度满足客户对软件的需求。需要注意的是，采用进化式的软件架构方法应遵循三个原则：1）当前迭代架构的设计应当最大限度避免伤害已经实现的架构和功能；2）当前迭代架构的实际应当与邻域模型始终保持一致，避免邻域误解而造成开发成本的增加；3）架构设计要完整，架构模型的各个层次应当统一。

在敏捷开发中，每一次迭代的架构设计过程大概需要经过6个环节，首先根据用户的整体需求提取出当前迭代中的需求，然后进行邻域建模，随后根据该模型进行概念性架构设计，若此次设计符合客户需求，下一步进行软件架构的细化，之后是对该架构设计进行用户的验证，如果用户的需求发生变化，则重新进行第一阶段的需求分析。

2.2关键技术

敏捷开发中的关键技术有两个方面，一是重构技术，在敏捷开发中就是通过重构技术快速适应不断变化和频频变更的设计环境的。所谓重构，就是充分利用软件现有的功能，通过对整体架构和程序代码的局部调整，提高软件质量和性能，使软件架构的设计模式更加合理化，提高软件的延伸性。本质上说，重构就是在尽量保留软件现有功能的基础调整软件的内部结构，降低软件的升级成本。重构技术贯穿软件开发的整个过程，包括架构重构、设计重构、代码重构和业务重构等[5]。二是设计模式，在软件的重构过程中，通常使用设计模式来改进已有的设计。设计模式实际上是众多软件开发人员在开发过程总结出来的技巧和设计经验，可以反复借鉴。在敏捷开发中，代码重构阶段可以借助设计模式，使程序更加可靠和便于理解。敏捷开发中的设计模式如图2所示。

2.3 过程管理

根据敏捷开发的简单、沟通、反馈、勇气、快速交付可工作软件等基本原则，一个成功的敏捷架构需要开发团队相互合作共同完成以下四个步骤：第一，由产品负责人制定产品列表，并对列表中用户故事按照优先级进行排序，然后从中选择一组作为当前设计目标，罗列出其中的子任务；第二，由架构师制定初始架构，包括架构愿景的确立、架构样式的定位和设计模式的建立等；第三，架构师和团队增量维护架构，即在客户对于交付的产品有新的需求或者需求发生改变时，应及时给予响应，架构师应当与团队之间不断进行沟通，促进整个团队与整体架构的认识，通过重构的方式增量维护架构；第四，确定每次迭代架构增量内容，通过架构师和团队成员的沟通，获得对于架构的反馈意见，获得新增的架构内容。

一般来说，所有的建模都是在白板上完成的“足够”的建模，通过以上四个步骤，模型会随着每次迭代慢慢成长、逐步改进，最终完全符合用户的需求。

3 敏捷开发模式在“在线教学系统”项目软件架构中的应用

该在线教学系统是一个面向高职院校的中小型软件开发项目，由于项目的开发周期较短，用户需求不明确，因而该系统的客户需求极可能发生变化，此种情况下，采用简单快捷、适应能力强的轻型敏捷开发模式再合适不过。下面结合该项目的开发实际阐述敏捷软件开发方法的具体应用。

3.1 初始化功能模块的确定

敏捷软件开发强调现场客户的参与。在软件开发过程中，开发人员随时与该软件的主要客户，如教师、学生登沟通相关业务问题、、汇报项目进展情况，并获得反馈与支持。根据此项目的用户需求，确定了最初的用户故事，选择在线考试子模块为优先实现的功能模块，如图3所示。

3.2 迭代式开发

软件开发小组根据架构师提出的初始软件架构，由编程人员和测试人员两两结对共同进行软件的设计、编码和测试，整个过程遵循简单、重构、集体所有的原则， 便于优化系统内部结构以消除冗余，提高代码的质量和可读性。开发人员应当尽快将初始的架构予以实现并交付客户试用，获得反馈意见。根据用户的反馈信息，在“在线教学系统”项目中，在线考试子模块需要增加身份验证模块、输入有效性验证以及信息加密存储等系统安全性设计内容。

3.3 小型

敏捷软件开发要求结合业务和技术情况，快速交付可工作的产品，并确定下一次的范围，即小型发。结合本系统的开发时间要求，整个开发周期的计划如表2 所示。

4 结束语

本文详细分析了敏捷开发模式中软件架构的设计方法，并系统阐述了敏捷开发实际软件开发案例“在线教学系统”项目中的应用，充分显示了敏捷开发的简洁性和灵活性的特点。

参考文献：

[1] 张海藩. 软件工程[M]. 北京：清华大学出版社，2010.

[2] 李白桦. 学生管理信息系统的敏捷开发[J].大连铁道学院学报，2006，27（4）：60-62，68.

[3] 李声威， 王爱景， 谭红星. 敏捷开发中软件架构设计与实践[J]. 电脑与信息技术，2015，23（3）：1-4，11.

第8篇：敏捷的项目管理范文

Abstract： The article is according to the characteristic of data in agile software development management mode and general definition and inference of software quality， studies and puts forward a kind of software quality measurement and tracking method， agile software quality metric method， which bases on team attributes value and the defects value per unit product size. Then the application of agile software quality measurement model， measures and tracks the software product quality under the actual production environment， researches and analyses of the data results， and summaries the general methods of improving the quality of software product.

关键词：敏捷管理；软件质量度量；质量管理

Key words： agile management；software quality metrics；quality management

中图分类号：TP311.53 文献标识码：A 文章编号：1006-4311（2016）14-0195-05

0 引言

20世纪90年代的软件危机以互联网开始蓬勃发展为背景，软件失败的经验促使软件过程不断增加约束和限制，开发过程越来越“重型化”，开发效率降低、响应速度变慢。这时，以应对快速变化的需求，一些新型软件开发方法开始出现，如极限编程、自适应软件开发、水晶方法、特性驱动开发等，这些方法和要求便逐渐形成了系统的敏捷管理模式。相对于“非敏捷”，敏捷模式更强调不同角色之间的紧密协作、面对面的沟通，频繁交付新的软件版本、紧凑而自我组织团队，注重能够很好地适应需求变化的代码编写和团队组织方法，也更注重作为软件开发中人的作用。敏捷开发管理提倡“拥抱变化”。敏捷的方法就是不断的迭代：每次都要与用户积极的交互，做那些用户最想要的那一小部分，开发完后让用户验收，避免引起工程后期的极大危害。

现今社会已经完全步入互联网时代，衣食住行、金融、商务、高科技等各行各业，互联网无所不在。互联网的爆炸式普及，离不开软件产品开发的巨大生产力，互联网时代的软件产品开发遵循新的七字诀要求--专注、极致、口碑、快，强调快速反应的同时保障产品的质量和口碑。于是适应该要求的敏捷管理模式越来越流行，并已成为互联网软件行业的主流开发模式，但目前仍然缺少对敏捷管理模式的质量管理进行系统性的研究。技术和管理相辅相成，企业需要通过技术管理来提高技术的有效性和可竞争性[1]，即管理有助于企业技术能力的提高和有效发挥。

本文主要针对敏捷模式的质量管理，结合敏捷开发管理模式的数据特点和软件质量一般定义推论，研究提出一种基于团队属性因子和单位产品规模的缺陷值的软件质量度量与跟踪方法，以便对软件产品质量进行有效度量和跟踪，为企业管理决策提供依据进而提高产品最终的质量。

1 敏捷软件质量度量法

1.1 质量与软件质量

质量是现代质量管理学最基本的概念之一，从专业的角度讲，对质量的理解应该尽量消除“模糊性”。Crosby把质量描述成“符合规格”，Juran将质量定义为“适用性”，戴明将质量描述为“可预测的一致性程度”，田口玄一认为质量“社会的损失”，国际质量标准ISO 9000：2000质量管理体系认为质量就是“一组固有特性满足要求的程度”，六西格玛（6Sigma）管理将质量定义为“顾客和供应商从商业关系各个角度共同认知的价值理念”。理解质量的这些含义后，从使用过程与商业功能的角度出发，质量应该理解为“稳定的满足客户需求的水平”[2]。

对于软件质量，Kitchenham和Pfleeger进行了比较全面的讨论，提出了关于软件质量抽象、基于用户、制造、产品、基于价值等5个观点[3]。关于软件质量的概念及依据可测数量去理解，可以追溯20世纪70年代中期。McCall、 Richards和Walters是最早依据质量因素和质量标准来研究软件质量的专家，他们认为：一种质量因素代表了系统的一个行为特征，一种质量标准是一种质量因素的属性[4]。典型的质量因素包括正确性、可靠性、有效性、完整性、易用性、可维护性、易测性、适应性、可移植性、可重用性、互操作性等。

各种各样的软件质量模型被用来定义软件的质量和相关属性，其中最有影响的包括ISO9126和CMM能力成熟度模型[5]。ISO9126质量模型是一个专家小组在国际化组织（ISO）的支持下开发的。ISO9126定义了质量的6个类型：功能性、可靠性、易用性、效率、可维护性、可移植性。CMM是美国卡耐基.梅隆大学的软件工程研究所开发的。CMM框架将一个开发过程评估为5个成熟度级别，即完成级、管理级、定义级、量化管理级和优化级。

软件研发项目中的质量管理主要是围绕着质量保证（SQA）和质量控制两方面进行的，而软件测试是软件质量保证的一个关键手段，也是软件质量控制的关键活动[6]。软件测试在达到软件产品质量和评估软件产品质量的过程中起到了重要的作用[7]。

1.2 质量度量定义与推论

定义1：软件产品质量分为开发过程质量、时质量和使用过程质量，使用过程质量代表产品最终的真实质量。

软件测试主要目的是验证功能是否符合用户需求，发现开发过程的质量问题和缺陷，并跟进修复，即通过不断地“测试-发现问题-修复”过程[8]，来提高产品的最终使用质量。产品交付或上线之前必须解决所有重大问题缺陷，甚至测试的“零bug”状态，近似认为产品交付或上线时质量最优，此时的质量评估一定是最好的结果，甚至满分状态。即产品交付或上线时，不同团队不同项目的产品质量评估都基本一致地保持最优结果，否则不会交付或上线。也即是说，产品交付或上线时的研发内部质量评估和度量在实际生产环境意义并不大，因为基本都是一样的最优结果。但是，就软件测试而言，一方面不可能进行穷举测试，另一方面即使穷举测试也不一定能发现所有的问题，所以产品的开发过程质量和时质量均不代表产品最终质量，产品交付或上线之后的使用质量才代表产品最终的真实质量（定义1所述）。

定义2：软件产品最终质量的评估可通过开发过程质量评估和度量来间接反映。

根据定义1论述，时研发内部的质量评估和度量几无意义，而软件测试过程的数据是可以直观评估和度量产品开发过程的质量，即开发过程质量是可直接进行度量的。使用过程的质量由于对用户的行为和过程、测试的数据和范围均难以掌控，显然不可能直接进行评估和度量。于是，开发过程质量和使用过程质量存在的关系，成为间接度量产品最终质量的关键，于是有定义2。

那么使用过程的质量和开发过程的质量究竟有怎样的关系呢？

一方面，不同的项目团队能力成熟度等级（技能水平、管理水平等）不一样，软件测试工作的程度和能力成熟度亦不一样，即开发过程质量即使一样，不同项目团队的产品最终使用质量也会不一样，所以产品最终质量和项目团队能力成熟度因子有关，一般而言能力成熟度等级越高，产品最终质量和开发过程质量差异越小。另一方面，测试资源和开发资源的比例系数也有关系，例如两个团队测试资源和开发资源比值分别为1：1和1：9，如果某个Sprint同样都是100人时的总资源，结果前一个团队均用50人时进行测试和开发，而另一个团队却用10人时的资源进行测试、90人时的资源进行开发，一般而言后者产品单位规模所开展的测试类型、覆盖度等均远小于前者，风险更高，所以测试资源和开发资源的比例越大，产品最终质量和开发过程质量差异越小。

综上所述，不同团队不同时间不同项目的产品最终使用质量均有差异。简言之，开发过程质量越优，组织团队能力成熟度等级越高，测试资源与开发资源的比值越大，软件产品的最终使用质量越优，于是得到推论1。

推论1：软件产品的最终使用质量，与开发过程质量、组织团队能力成熟度等级、测试资源与开发资源的比值正相关。

那么软件产品的开发过程质量如何度量？不同场景不同情况下的度量方法可以多种多样，其中文献综述也有论述学者前辈们提出的不同度量方法。一般而言，软件产品规模越大，相应缺陷量也就越大，如果单纯的使用缺陷量绝对值来衡量软件产品的开发过程质量，并不准确。比如使用产品一过程中总共10个单位规模复杂度就发现了10个bug，平均每个单位规模复杂度都有一个bug，而产品二总共100个单位规模复杂度发现了20个bug，平均每5个单位规模复杂度有一个bug，或仅20%的功能规模复杂度点有bug另外80%的规模复杂度都没有bug，显然后者的质量更高。所以，单位产品规模复杂度的缺陷值更能反映软件产品的开发过程质量，本文敏捷软件质量度量法即基于这一关键推论。

推论2：软件产品的开发过程质量可用单位产品规模复杂度的缺陷值来衡量。

通常，一个项目团队的能力成熟度等级较为稳定，如果产品所消耗的人力、物力、财力、时间等资源越多，那么这个产品的规模复杂度越高，即软件产品的规模复杂度与项目总体资源消耗量正相关。所以，产品规模复杂度的衡量基于如下推论3。

推论3：产品的规模复杂度与产品开发过程的资源消耗量正相关。

1.3 敏捷软件质量度量模型

敏捷项目团队一般包含多类角色，宏观上可主要分为3类，业务系统分析BA（Business Analyst）、开发人员DEV（Developer）和质量保证QA（Quality Assurance）。BA代表用户和需求分析师，主要职责是业务需求分析和系统功能设计；DEV主要包括程序员、UI等，职责是完成系统功能开发；QA包括专职测试员、质量保证等，职责是测试系统功能，确保功能正确和符合需求，保证产品质量。每类角色都有对应的Leader或经理，然后每个项目都有总的项目经理PM。良好的敏捷管理实践应该涵盖软件产品开发管理全过程，以上各类角色的工作过程和工作数据均保持高效和完备记录，有效应用过程管理工具、持续集成工具、自动化工具等，保持过程质量和软件质量可以随时跟踪和度量，风险及时可控。

综合敏捷管理实践的过程特征和前面软件质量度量的定义和推论，本节提出一种基于敏捷管理模式的软件质量度量模型如下：

设Q（t）为某考查时间t内的产品最终质量，q（t）为该段时间产品开发过程质量，L（t）为项目团队能力成熟度等级因子，s（t）为测试资源和开发资源比例系数。当一个组织团队确定，该团队的能力成熟度等级基本确定，即固定项目团队a的能力成熟度等级因子L（t）视为常量因子La。那么，

Q（t）=q（t）×[s（t）]N×La（1）

其中La和N为常量，La>0，N∈Z且N？叟0。时间t内产品开发过程质量q（t）可用产品单位规模复杂度的缺陷值来衡量，单位产品规模复杂度的缺陷值越低，产品开发过程质量越优，于是：

■=■

=■（2）

该公式中，通过Bug-Task的数量与权值因子乘积的总和来度量缺陷值，通过QA-Task、DEV-Task、BA-Task的资源消耗量与权值因子乘积的总和再乘以常量系数Ca来度量产品规模复杂度。其中，bij（t）为时间t内i类测试j类优先级的bug数量，Hij为i类测试j类优先级的bug权值因子；rqa（t）、rdev（t）、rba（t）分别为时间t内某优先级QA-Task、DEV-Task、BA-Task的资源消耗量，单位为人・时；Pqa、Pdev、Pba分别为对应优先级QA-Task、DEV-Task、BA-Task的权值因子。时间t内测试分类和优先级的I×J缺陷数量矩阵B（t）可直接通过数据统计得到，对应测试分类和优先级的I×J缺陷权值因子矩阵H视为常量，可由组织内专家或技术权威评估确定；同样的，rqa（t）、rdev（t）、rba（t）可直接通过数据统计得到，Pqa、Pdev、Pba视为常量由组织内专家评估确定。

通常，DEV-Task的资源消耗量与权值因子乘积的总和视为开发资源，QA-Task的资源消耗量与权值因子乘积的总和视为测试资源。那么，测试资源和开发资源比例系数s（t）为：

s（t）=■（3）

综合（1）（2）（3）式，可得项目团队a考查时间t内的敏捷软件质量度量模型为：

Q（t）=■

×■■

该度量模型符合前面小节的论断，即：

①其他因子基本恒定，团队组织能力成熟度等级系数La越高，软件产品的最终使用质量Q（t）越优；

②其他因子基本恒定，测试资源与开发资源的比值s（t）越大，软件产品的最终使用质量Q（t）越优；

③其他因子基本恒定，单位产品规模复杂度的缺陷值■越低，产品开发过程质量越优；产品开发过程质量越优，软件产品的最终使用质量Q（t）越优。

所以，要提高产品质量，我们可以从提高团队组织的能力成熟度等级、提高测试资源与开发资源的比值、降低单位产品规模复杂度的缺陷值等方面入手。

2 敏捷软件质量度量法的应用

2.1 敏捷项目管理模式的数据

以某互联网软件企业AN公司的敏捷实践作为研究实例，本文研究过程中采集了该公司一个敏捷模式项目COMM共12个月（2014年12月到2015年11月），约17个Sprint （该公司每3周一个冲刺）的项目过程管理数据（来源于项目管理工具Jira），截取项目COMM其中一个Sprint112的过程管理数据进行分析，其他项目的各个Sprint周期和数据结构均与之基本一致（如表1所示）。

参照表1“AN公司敏捷项目过程管理数据举例”可知，AN公司的敏捷实践过程，所有的项目工作均以Task（任务）为单位，所有成员均在对应的Task下记录工作内容和工作时间，每个Task记录包含Task Type、Key、Summary、Priority、Time Spent、Sprint、Status等属性。其中，Task Type大致可以分为五类――BA-Task、DEV-Task、QA-Task、Bug-Task、Support-Task。其中BA-Task主要包括Requirement/User Story等用户故事转化为需求功能模块的分析设计任务，对应团队角色为BA；DEV-Task主要任务是完成需求功能模块的详细设计、拆分和逐一开发实现，对应团队角色为DEV；QA-Task主要任务是测试开发完成的功能是否符合用户故事和需求，对应团队角色为QA Tester等；Bug-Task则是测试发现的缺陷报告、开发修复、测试再验证整个流程任务的跟踪管理，涉及团队各个角色BA、DEV、QA的交互；Support-Task主要包括其他支持类任务，如开发测试环境维护，版本维护，测试自动化等。Key和Summary主要是标记该任务编号和描述任务摘要，Priority描述任务的关键性程度和等级，Time Spent为该任务所花时间总和（单位秒），Sprint描述该任务属于哪个Sprint，而Status显示任务当前状态（Open、In Progress、Test、Closed等）。

通过每条Task数据记录及其属性，我们可以了解每个Sprint的敏捷实践过程、统计团队绩效、度量软件产品实现的功能规模和度量产品质量等。

2.2 模型和数据处理

敏捷软件测试是基于迭代功能模块的测试，迭代过程一般只开展功能测试，当系统基本完成和功能稳定才会开展其他测试类型，如性能测试、兼容性测试、安全测试等，所以本章把测试分类简单分为功能测试和其他测试。参照表2“AN公司COMM项目Sprint112（3周）的完整过程管理数据”可知，AN公司Bug-Task的Priority有4级（P1>P2>P3>P4），不同优先级的缺陷bug度量缺陷值的权值因子不一样，而不同测试类型的缺陷bug度量缺陷值的权值因子也不一样，AN公司专家评估确定的bug分类和优先级的2×4缺陷权值因子矩阵H转化为表2所示。

同样的，参照表2的数据，BA-Task、DEV-Task、QA-Task的Priority也有4级（P1>P2>P3>P4），不同种类不同优先级的Task度量资源消耗量的权值因子也不一样，AN公司专家评估确定的Task分类和优先级的3×4任务权值因子矩阵P转化为表3所示。

AN公司专家评估确定的属性因子为别为：能力成熟度等级系数L=4（L∈[1，5]）、产品规模与资源正比例系数C=1（C∈[1，5]）、测试资源和开发资源比例修正指数N=2（N∈{1，2，3，4，5}）。代入敏捷软件质量度量模型，结果为：

Q（t）=■

×■■（4）

根据Bug权值因子表H、Bug类的Priority 和数量可以简单计算得到Sprint112总的缺陷值为：

■b■（t）×H■=26

根据Task权值因子表P、Task类的Priority 和TimeSpent可分别计算得到，

测试资源消耗量：∑（r■（t）×Pqa）=369

开发资源消耗量：∑（r■（t）×Pdev）=511

BA资源消耗量：∑（rba（t）×Pba）=117

总的规模复杂度：

C∑（r■（t）×Pqa+r■（t）×Pdev+rba（t）×Pba）=997

代入（4）式敏捷软件质量度量模型，即可得到Sprint112的质量度量结果为：

Q（112）=■

×■■=79.98

其中，测试资源与开发资源的比值为：

■=0.72

同理，把所采集AN公司COMM项目的近一年的数据代入模型进行分析处理，可以得到每个Sprint的质量度量结果。根据本文描述的数据结构和模型算法，实现几十行电脑程序代码，对所有采集的数据进行计算处理后，最终得到每个Sprint的质量度量结果。

2.3 结果分析和结论

应用模型数据处理得到AN公司COMM项目近一年的产品质量度量结果如表4所示。

根据表4 “AN公司COMM项目一年的产品质量度量结果”可以看出，在Sprint95、Sprint96、Sprint99测试资源、开发资源、BA资源的投入均趋向0，产品规模复杂度极小并且没有产生缺陷值，说明当时项目几乎处于暂停状态，没有新的功能上线，故产品质量与之前保持一致，质量度量无意义（结果为0不代表质量最差，仅表示该Sprint质量度量无意义状态）。Sprint113、Sprint115由于超出设定的数据采集终点（2015-11-30），数据并不完整，所以质量度量结果比较异常的高，这主要跟测试过程和开发过程的数据不完整（介入程度低）、缺陷值趋向0所导致的结果，尚在开发进行之中的产品质量度量一样没有意义。综上，去掉无效的质量度量结果，为了直观的比较质量与各个因子相互之间的关系，将测试资源与开发资源的比值乘以100，产品规模复杂度除以10，可以得到COMM项目Sprint100～Sprint112共12个Sprint的有效质量结果变化曲线如图1所示。

从质量结果变化曲线中我们可以发现：

①Comm项目Sprint109的产品质量最高，Sprint104的产品质量最低。

②产品质量最低的Sprint104的缺陷值最高，而产品质量最高的Sprint109的缺陷值相对较低；但并非缺陷值最低产品质量就高，缺陷值最低的是Sprint110，由于产品规模复杂度、测试资源与开发资源的比值都较低，产品质量并不高。

③产品质量最高的Sprint109测试资源与开发资源的比值最大，产品规模复杂度与缺陷值的绝对差较大，但是产品规模复杂度与缺陷值的绝对差最大的Sprint107，却因测试资源与开发资源的比值最小促使产品质量反而较低。

综上所述，团队组织属性因子确定，即能力成熟度等级L、产品规模与资源正比例系数C、测试资源和开发资源比例修正指数N基本恒定的条件下，产品最终质量与已发现缺陷值成反比，与产品规模复杂度成正比，并与测试资源与开发资源的比值正相关。也即，符合敏捷软件质量度量模型的结论是：项目实施过程中通过提升组织能力成熟度等级、提高产品规模复杂度的同时降低缺陷值、提升测试资源与开发资源的比值，可以提高产品的最终质量。

3 总结与展望

本文属于理论研究，基于敏捷开发管理模式下过程管理数据的可度量特征与软件质量的一般定义和推论，研究提出敏捷软件质量度量模型，最后通过敏捷软件质量度量法的应用得出如何提高产品质量的结论。不足的是，关于敏捷软件质量度量法的应用试验，对于该软件质量度量法的绝对有效性和正确性，仍缺乏较强有力的证据，后续研究可以基于此突破，通过大量的应用实证或其他研究方法，来证明或更正提出更为有效的软件质量度量方法，以促进互联网软件业的管理理论与技术发展。

参考文献：

[1]宝贡敏，杨静.企业技术管理在技术创新中的角色――基于浙江省企业的研究[J].科学学研究，2004（05）：546-551.

[2]马慧，杨一平.质量评价与软件质量工程知识体系的研究[M].北京：人民邮电出版社，2009：2-5.

[3]B.Kitchenham&S.L.Pfleeger. Software Quality： The Elusive Target[J]. IEEE Software， 1996， 01：12-21.

[4]J.A.McCall， P.K.Richards， &G.F.Walters. Factors in Software Qualitty[J]. Technical Report RADC-TR-77-369. U.S. Department of Commerce， Washington， DC，1977，10.

[5]K. Naik& P. Tripathy. Software Testing and Quality Assurance： Theory and Practice[M]. 郁莲，等，译.北京：电子工业出版社，2013：4-18.

[6]钟铭林.英伟达公司软件质量管理体系构建研究[D].兰州大学，2014.

第9篇：敏捷的项目管理范文

    1)软件使用者的主体从大型尖端领域逐渐向广泛的企业应用领域转变;

    2)人们对软件系统需求的认识提高;

    3)市场经济的发展,以及市场需求的频繁变化;

    4)面向对象技术的应用和普及。

    而今,企业面对的是快速变化的市场,在这样的市场环境下,收集用户完整的、稳定不变的系统需求是不可能的。面对无法预知和不断变化的需求,传统的软件开发流程明显已无法适应,而敏捷过程将程序代码和系统需求紧密的联系在一起,将系统需求视作流动和变化的需求的思想,则正符合现今软件开发的现状。

    1 敏捷开发的兴起

    敏捷方法诞生于2001年,由J.Highsmith和R.C.Martin发起,由一批业界专家参与成立了敏捷联盟,并概括出了一系列让软件开发团队具有快速工作、相应变化能力的价值观和原则。

    在敏捷联盟的官方网站上,可看到敏捷宣言的完整内容:

    1)个人与沟通胜过过程与工具;

    2)可工作的软件胜过面面俱到的文档;

    3)客户协作胜过合同谈判;

    4)相应变化胜过遵循计划。

    具体来说,传统的顺序开发模型(瀑布模型、V模型、W模型)的一个重要的特点就是所有的活动都是有顺序的。顺序开发模型成功使用的一个前提是软件系统具备完善和明确的需求。如果在项目开始阶段无法进行完善的需求分析和设计,则顺序开发模型就很难被成功的使用。为了解决顺序模型的不足,出现了增量迭代模型。从本质上说,敏捷开发就是一种迭代的增量的开发模型。这种模型的优点如下:能很好的适应需求的变化;早期的迭代可以降低风险;集成是持续的而不是在项目后期进行的“大动作”;在每次迭代中发现和更正缺陷并能不断反馈并改进开发过程[1]。

    如果要用一句话来描述敏捷开发,那么敏捷开发应该是:以人为本、轻载、基于时间、just Enough、并行并基于构件的迭代和增量的软件开发过程。

    2 敏捷开发的原则

    敏捷联盟成立后,又陆续形成了敏捷的十二项原则(本文不在详细展开,详细描述见敏捷联盟官方网站),其主旨思想大体如下:敏捷开发中需求是逐渐展开的,在项目初期不提倡过渡的需求分析,对需求变化的响应是动态的;敏捷项目应该分成从几周到几个月间隔的迭代周期,每一个迭代周期尽量产出潜在可交付的软件产品,用户的反馈作为下次迭代的基础;可工作的软件是衡量项目进展的主要依据;敏捷开发整个过程是持续的,带有反馈的和自我完善的轻量级的过程。

    基于敏捷指导思想,形成了不少敏捷软件开发方法(例如XP、scrum等),它们大都强调适应性而非预测性、强调以人为中心,而不以流程为中心,以及对变化的适应和对人性的关注。以XP(extreme programming)方法为例,它消除了大多数重量型过程的不必要产物,建立了一个渐进型开发过程。该方法将开发阶段的4个活动(分析、设计、编码和测试)混合在一起,在全过程中采用迭代增量开发、反馈修正和反复测试。并且它作为一种面向客户的开发模型,开发过程中对需求改变的适应能力较高,即使在开发的后期,也可较高程度地适应用户的改变。XP开发模型与传统模型最大的不同是其核心思想是交流(Communication)、简单(Simplicity)、反馈(Feedback)和进取(Aggressiveness)[2]。这种开发模型的主要优点如下:

    1)采用简单计划策略,不需要长期计划和复杂模型,开发周期短;

    2)在全过程采用迭代增量开发、反馈修正和反复测试的方法,软件质量有保证;

    3)能够适应用户经常变化的需求,提供用户满意的高质量软件。

    纵观所有敏捷开发方法,其基本都具备轻载、基于时间、Just Enough、并行并基于构件的迭代和增量的特点,而且具有类似的敏捷项目交付模型。

    3 敏捷项目交付模型

    敏捷项目交付模型是一种敏捷软件项目管理的生命周期模型,它是基于敏捷开发迭代和增量特点的过程模型[3]。该模型把敏捷软件项目的生命周期大体可分成项目规划、项目启动、迭代开发与三个阶段。各个阶段分别介绍如下:

    1)项目规划阶段

    敏捷开发中的项目规划阶段类似于传统开发过程中的项目可行性分析和早期的需求收集阶段,该阶段的主要工作如下:

    (1)就要开发系统的战略目标、业务愿景和初始项目需求等与关键涉众达成共识;

    (2)根据收集到的资料,设计与决策系统开发的关键技术架构问题;

    (3)评估项目的工作量与成本,辅助客户决策项目的可行性;

    (4)进行项目的初始计划制定。

    2)项目启动阶段

    该阶段是一过度阶段,处于项目规划后正式开发前,主要工作是为项目开启准备各种所需资源,包括开发场地布置、软硬件环境的准备和项目团队的组建等。另外,通常为了使此后的迭代开发阶段能够顺利进行,还有为第一次迭代进行详细的需求分析工作。

    3)迭代开发与阶段

    该阶段是敏捷项目交付模型的核心部分,基本上所有的开发工作都在该阶段展开与实现。在迭代开发与阶段,项目组会根据目标系统的正式版本将该阶段分解成多个重复的过程,并且每次过程基本上都是一次目标系统的增量在开发环境中实现,并从开发环境到生产环境的迁移。每次迭代开发与又可细分为迭代开发、用户验收测试(UAT)和三个小阶段。各阶段的介绍如下:

    (1)迭代开发是一个有固定时间周期的、在开发和测试环境上完成系统增量的过程,增量流程大体由需求分析活动、设计实现活动、集成测试活动、客户测试活动组成。每次迭代都会产生潜在可交付的产品;

    (2)多次迭代开发对应一次,多次迭代后每次前,会根据项目需要进行用户验收测试。目标是让客户代表从系统最终运营的角度测试系统行为,另外,该阶段也可作为项目团队完成目标的缓冲区;

    (3)过程在敏捷开发中有里程碑的作用,其业务意义大于技术意义。使用敏捷软件交付模型,第一次会在较早的时间发生,这对于提升客户投资收益,根据市场反馈调整项目走向都有帮助。

    4 敏捷开发中的测试

    对于敏捷的理解,一般认为最为关键的是需要注意两个方面,即“高速迭代”和“持续不断的客户反馈”[4]。而要达到这样的要求,传统的注重流程的规范,文档的齐备,走完整的bug处理流程的测试过程,明显已不符合敏捷的初衷。

    那么敏捷开发中测试有何特点?,简要来说,如下所述:

    首先,就测试的阶段来说,敏捷开发中的测试贯穿于整个软件开发生命周期中(传统软件开发模型中,测试只是作为编码后的一个独立阶段出现)。其次,敏捷开发是迭代和增量的过程,这就意味着测试人员在每个代码增量完成时,都要测试它,测试工作也是迭代的展开,并且时间更紧,压力更大。开发和测试是并行进行的,程序员从来不超前于测试人员(在传统软件开发模型中,编码和测试过程是串行的,先编码后测试)。再次,敏捷开发中,测试人员需要紧密的与客户合作来定义每一个需求的接收标准;而且测试过程还可以向项目组随时反馈开发中遇到的问题。而不像传统测试中,测试由详细的需求驱动,并且发生在编码之后。最后,敏捷测试中,提倡持续集成和构建,集成的频率较高,并且可为开发提供持续的反馈。

    5 结论

    其实,不管正在使用的是哪种开发模式,都会经历几乎同样的软件开发生命周期元素。敏捷的不同之处在于时间段明显变短,而且活动同步进行。因此,参与者、测试和工具都需要适应这一变化。同时,也应该看到没有哪种开发模式可以放之四海而皆准,只有不断的被实践和验证才能持续完善[5]。目前,敏捷还在不断发展,更多的项目在实践敏捷,应用的普及和成功的案例正在不断扩大。

    参考文献

    [1]郑文强,马均飞.软件测试管理[M].电子工业出版社,2010.

    [2]张友生,李雄.常用软件开发模型比较分析.中国系统分析员,2005(1).

    [3]桑大勇,王英,吴丽华.敏捷软件开发方法与实践[M].西安:西安电子科技大学出版社,2010,5.