在敏捷宣言遵循的 12 条原则中挑选 1 条原则进行风险评估。
敏捷宣言遵循的 12 条原则
- 我们最重要的目标，是通过尽早和持续地交付有价值的软件来使客户满意。
- 欣然面对需求变化—即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
- 经常地交付可工作的软件，相隔几个星期或几个月不等，倾向于采取较短的周期。
- 在整个项目过程中，业务人员与开发人员必须经常在一起工作。
- 激励项目人员，以他们为核心构建项目，为他们提供需要的环境和支持，并相信他们能够完成任务。
- 无论团队内还是团队间，最有效的沟通方法是面对面的交谈。
- 可工作的软件是衡量进度的主要指标。
- 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
- 对技术的精益求精以及对设计的不断完善将提升敏捷性。
- 以简洁为本。简洁是尽可能减少不必要的工作量的艺术。
- 最佳的架构、需求和设计出自于自组织团队。
- 团队要定期反省如何能提高成效，并以此调整团队的行为。
风险清单
- 需求变更风险；
- 进度风险、预算风险、管理能力风险、信息安全风险；
- 应用技术风险、质量控制风险、软件设计与开发工具风险、 员工技能风险；
- 人力资源风险、政策风险、市场风险、营销风险。
挑选 1 条原则进行风险评估
所选择的原则
敏捷宣言遵循的第 3 条原则：经常地交付可工作的软件，相隔几个星期或几个月不等，倾向于采取较短的周期。
风险评估
- 需求变更风险：软件的开发周期短则需求变更出现的概率变小；软件的开发周期长则容易忽略用户需求的不稳定性，一旦出现需求变更，可能会使开发进程严重受阻，并大幅度增加开发者的工作量；因此，经常地交付可工作的软件，开发周期较短的软件，发生需求变更风险的概率较低。
- 进度风险、预算风险、管理能力风险、信息安全风险。
- 进度风险：间隔几个星期或几个月就交付可工作的软件，使得软件开发的进程有序进行，一定程度上有利于进度的推进；另一方面，交付频率会增多来自用户的反馈需求，又会使原来的进度规划被打乱；但总体风险概率仍较低。
- 预算风险：软件开发周期短，消耗的预算会较少；风险概率较低。
- 管理能力风险：开发周期较短的软件，软件性能管理和开发人员管理就越容易进行；但要在较短的周期内完成软件交付，本身又要求较高的管理能力；风险概率较低。
- 信息安全风险：软件开发周期越长，则埋下的信息安全隐患会越来越多，缩短开发周期有利于减少信息安全风险；风险概率较低。
- 应用技术风险、质量控制风险、软件设计与开发工具风险、 员工技能风险。
- 应用技术风险：软件开发周期越长，则新兴的应用技术会越来越多、越来越先进，故缩短开发周期有利于减少技术进步对软件价值的影响；风险概率较低。
- 质量控制风险：开发周期较短的软件，开发人员进行质量控制的难度就会越小，这是较为有利的；但如果软件本身就需要较高程度的质量控制，缩短开发周期反而会增加质量难以控制的情况；风险概率中等。
- 软件设计与开发工具风险：软件开发周期越长，则软件设计埋下的缺陷就会越来越多，开发工具也会愈发难以满足生产需求，因此，缩短开发周期，有利于控制软件设计与开发工具风险；风险概率较低。
- 员工技能风险：软件开发周期越长，则软件规模、软件功能建设的难度都会越来越大，这意味着对员工技能的要求也会越来越高，因此采取较短的开发周期，可以避免人才不足、需要补充人才或者培训员工的风险；风险概率较低。
- 人力资源风险、政策风险、市场风险、营销风险。
- 人力资源风险：软件开发周期越长，则软件开发过程中发生人力资源变动变动的概率会越来越大，员工流动对工作的接手、预期的进度影响很大，影响开发效率；员工管理的难度也会因此提高；所以开发周期较短的软件，人力资源风险发生的概率较低。
- 政策风险：软件开发周期越长，则新政策的推出，可能会使开发出的软件需要进进行额外的调整，也可能需要承担来自其他方面的额外负担，甚至软件会因此被迫停止开发，此时风险的损害程度大、概率高；所以开发周期较短的软件，政策风险发生的概率较低。
- 市场风险：软件开发周期越长，市场的变动就会越大，市场是难以预测的，在软件开发的初期很难精准规避将来可能遇到的市场打击，开发周期长的软件可能会面临定位不当、收益不佳的局面；所以开发周期较短的软件，市场风险发生的概率较低。
- 营销风险：软件开发周期越长，说明在软件开发期间需要投入的成本越多，企业无收入的时间也越长，这意味着落在营销人员的预期收入越高，要求的营销效率越高，工作压力也越大；而开发周期长也导致市场风险等恶劣情况越多，连带增加了营销风险；因此，开发周期较短的软件，营销风险发生的概率较低。