敏捷开发概述
- 我们的首要任务是通过尽早和持续交付有价值的软件来满足客户。
- 欢迎需求的变化，即使是在开发的后期。敏捷过程利用变化为客户提供竞争优势。
- 经常交付可工作的软件，从几周到几个月不等，优先于较短的时间尺度。
- 在整个项目中，业务人员和开发人员必须每天一起工作。
- 围绕有动力的个人建立项目。给他们需要的环境和支持，并相信他们能完成工作。
- 向开发团队和开发团队内部传递信息最有效和有效的方法是面对面的交谈。
- 工作软件是衡量进步的主要标准。敏捷过程促进可持续发展。
- 发起人、开发人员和用户应该能够保持一个稳定的步调下去。
- 持续关注技术卓越和优秀设计提高敏捷性。
- 简单——最大化未完成工作量的艺术——是必不可少的。
- 最好的架构、需求和设计产生于自组织的团队。
- 团队每隔一段时间就会思考如何变得更优秀有效，然后相应地调整其行为。
对敏捷开发原则的第八条进行风险评估
需求变更风险
软件需求本身不清晰或者开发商对产品的需求特性理解不准确有偏差，这样导致最终开发的产品功能可能不是用户真正想要的功能。在项目的后期用户总是不停的提出需求变更，从而影响设计、代码，并且最终反映到测试中来。需求变更后，测试用例没有及时更新；更重要的是在项目的后期频繁的需求会导致测试的时间不充分。所以在项目开发过程中的每一个阶段，尽量让有决策权的核心用户看到产品已经实现的每个阶段的功能，如果不是用户想要的东西尽早提出来，总之要让用户参与进来。另外对于后期用户不停的提出需求变更作为开发商来说，应该多和有决策权的核心用户多沟通，争取更充分的研发时间和测试时间，或者最好能把后期提出的功能放到下一个版本中实现。
进度与预算风险
实行敏捷开发时，在开发前的准备时需要注意量化衡量团队的执行力的指标：完成度、评估准确度、计划合理度。这里会有一个误区就是从开始阶段你需要考虑到所有的一切，并且一定要等到模型非常完美之后才敢向前进。项目方并没有认识到自己不能考虑到所有的细枝末节，并且没有将足够的空间给到开发人员。所以不管你的最初所作的规格说明书有多好，但注定代码会很快地与之失去同步，即便是你自己建模自己编码。这是评定整个进度的很重要的指标，也是让迭代更好的进行下去的准则。
人力资源与员工技能风险
存在核心测试人员的请假、离职；工作态度不端正、工作状态差；以及测试技术不足，比如说产生测试的思维定势的情况。从而无法及时在项目完成进度上做出推进，项目方如果不能及时调整策略，便无法进一步得到新的用户体验，使项目无法保持稳定的进展速度。对于核心的测试人员可能离职而延误测试的情况，作为测试管理者可以在平时给这些核心人员配置一些可以候补的测试人员来向他们学习，以避免这些核心人的请假、离职的时候，可以立即补充上来。另外，对于一些关键的业务和技术一定要有文档。另外可以通过对测试工程师进行考评的方式监督他们每天的工作情况，看看其工作态度是不是尽心尽力符合目前的项目测试工作，如果发现不符合的话，测试管理者可以找其单独谈话督促其改正。每个测试工程师的思维方式肯定有差别，所以测试管理者多让这些工程师在测试每一轮后，在进行不同模块的交叉测试。
