2、 增量的开发方式
很多小的产品版本发布，而不是一个唯一的计划好的版本发布。
3、 FIT（Framework for Integrated Test）
FIT允许用户使用简单的Word文档或HTML文档来定义他们自己的测试。FIT能产生用例子描述业务的文档。
这些给我们的提示是：
1、测试工作不仅仅由测试人员担任，其他项目组成员也承担了部分的测试工作。那么对测试的质量度量模式可能就要发生改变了。
2、沟通仍然是项目组不变的主题，但是沟通的方式更多地侧重在口头、面对面方式的交流。那么对沟通的质量度量模式可能就要发生改变了。
3、迭代、快速发布、重构等软件开发方式对如何进行配置管理的控制提出了新的要求。
何谓敏捷？
敏捷在一定程度上是一种思维方式。它鼓励个人与团队的融合，崇尚快速响应变化，抛弃繁杂的文档。这些从敏捷的宣言可以看出：个体和交互比过程和工具更有价值；能工作的软件比全面的文档更有价值；顾客的协作比合同谈判更有价值；及时响应变更比遵循计划更有价值。
敏捷的开发方式与传统软件开发方式存在很多的不同。例如，比起传统的开发模式，敏捷方式更注重人与人之间的沟通和交互；通过区分优先级并专注于尽早发布来对待进度压力；要求顾客紧密合作并参与到项目中来。
越来越多的人意识到传统软件开发模式的不足，越来越多的人开始拥抱敏捷。
质量保证在敏捷项目中的角色定位
敏捷把我们的注意力转移到精简的项目组、小步快跑、迭代发布的过程模式中来。那么实施敏捷项目管理的团队是否意味着不需要文档、不需要测试、不需要质量保证了呢？
在回答这个问题之前，我们需要考虑质量保证在敏捷项目中的角色定位问题。
抽象的思想与能工作的软件是不一样的，因此软件需求文档不能代表充分地代表软件。敏捷方法鼓励通过合作和面对面的交流来获得文档不能替代的信息沟通。那么就意味着我们传统软件工程中的对于需求的质量保证工作的方式不再合适了。
在敏捷项目中，软件测试也需要敏捷。Brian Marick分析并指出了敏捷测试与传统测试的很多不一样的地方。敏捷测试抛弃了旧有的关于测试人员沟通方式的观点。就像需求和设计文档的不充分一样，测试计划和测试报告也是不充分的。敏捷测试要求测试员与开发人员、用户充分交流和沟通，面对面的沟通。那么就意味着我们传统软件工程中对软件测试的质量保证工作不能从检查文档、评审文档出发了。
传统的软件测试作为质量保证的控制手段，起到质量把关的作用，测试人员站在顾客的角度来批判产品、检查产品质量是否达到要求，测试的服务对象是顾客。但是敏捷测试的服务对象有所改变，测试的服务对象是开发组，帮助开发人员减少由于产品的不确定性而带来的损失。也就是说，质量保证的控制手段-软件测试也有所不同了。
此文章共有4页 上一页 1 2 3 4 下一页
文章来源：中国项目管理资源网
|
Leadge.com首页 > 知识库 
