自适应软件开发 - 实践
自适应软件开发实践基于持续适应的理念，其生命周期能够接受持续变化作为常态。
自适应软件开发生命周期致力于：
- 持续学习
- 面向变化
- 重新评估
- 展望不确定的未来
- 开发人员、管理人员和客户之间紧密合作
自适应SDLC
自适应软件开发将RAD与软件工程最佳实践相结合，例如：
- 项目启动。
- 自适应周期规划。
- 并发组件工程。
- 质量审查。
- 最终QA和发布。
自适应软件开发实践可以如下所示：
如上所示，自适应软件开发实践分布在三个阶段：
推测 - 启动和规划
项目启动
为整个项目设定时间框
确定迭代次数并为每个迭代分配时间框
为每个迭代制定主题或目标
为每个迭代分配功能
协作 - 并发功能开发
分布式团队的协作
小型项目的协作
大型项目的协作
学习 - 质量审查
从客户角度来看的结果质量
从技术角度来看的结果质量
交付团队的运作以及团队成员正在使用的实践
项目状态
推测 - 启动和规划
在自适应软件开发中，“推测”阶段有两个活动：
- 启动
- 规划
“推测”阶段有五个实践，可以在启动和规划阶段重复执行。它们是：
- 项目启动
- 为整个项目设定时间框
- 确定迭代次数并为每个迭代分配时间框
- 为每个迭代制定主题或目标
- 为每个迭代分配功能
项目启动
项目启动包括：
- 设定项目的使命和目标
- 了解约束条件
- 建立项目组织
- 识别和概述需求
- 进行初步规模和范围估计
- 识别关键项目风险
项目启动数据应在初步的JAD会议上收集，并将速度作为主要方面考虑。对于中小型项目，启动可以在集中进行的二到五天内完成，而大型项目则需要二到三周的时间。
在JAD会议期间，需求的收集应足够详细，以识别功能并建立对象、数据或其他架构模型的概述。
为整个项目设定时间框
整个项目的时间框应基于项目启动工作产生的范围、功能集需求、估计和资源可用性来确定。
众所周知，“推测”并不意味着放弃估计，而仅仅意味着接受估计可能出错。
迭代和时间框
根据项目的整体范围和不确定性程度，确定迭代次数和各个迭代的长度。
对于中小型应用：
- 迭代通常为四到八周。
- 一些项目最适合两周的迭代。
- 一些项目可能需要超过八周。
根据您的实际情况选择时间。一旦确定了迭代次数和每个迭代的长度，就为每个迭代分配时间表。
制定主题或目标
团队成员应为每个迭代制定主题或目标。这类似于Scrum中的冲刺目标。每个迭代都应交付一组可以展示产品功能的功能，使客户能够看到产品，以便进行审查和反馈。
在迭代中，构建应最好每天交付可工作的功能，从而实现集成过程并使开发团队能够看到产品。测试应成为功能开发中持续且不可或缺的一部分，不应推迟到项目结束。
分配功能
开发人员和客户应共同为每个迭代分配功能。此功能分配最重要的标准是每个迭代都必须向客户交付一组具有相当功能的可见功能。
在将功能分配给迭代期间：
开发团队应提出功能估计、风险和依赖关系，并将其提供给客户。
客户应使用开发团队提供的信息来决定功能优先级。
因此，迭代规划是基于功能的，并且是由开发人员和客户组成的团队共同完成的。经验表明，与项目经理进行的任务型规划相比，这种类型的规划能够更好地理解项目。此外，基于功能的规划反映了每个项目的独特性。
协作 - 并发功能开发
在“协作”阶段，重点在于开发。“协作”阶段有两个活动：
开发团队协作并交付可工作的软件。
项目经理促进协作和并发开发活动。
协作是共享创作的行为，它包含开发团队、客户和管理人员。共享创作通过信任和尊重来促进。
团队应在以下方面进行协作：
- 技术问题
- 业务需求
- 快速决策
以下是与自适应软件开发中“协作”阶段相关的实践：
- 分布式团队的协作
- 小型项目的协作
- 大型项目的协作
分布式团队的协作
在涉及分布式团队的项目中，应考虑以下事项：
- 不同的联盟伙伴
- 广泛的知识
- 人们互动的方式
- 他们管理相互依赖关系的方式
小型项目的协作
在小型项目中，当团队成员在物理上靠近时，应鼓励非正式的走廊聊天和白板涂鸦等协作方式，因为这种方式被证明是有效的。
大型项目的协作
大型项目需要额外的实践、协作工具以及项目经理的互动，并应根据具体情况进行安排。
学习 - 质量审查
自适应软件开发鼓励“实验和学习”的概念。
从错误和实验中学习需要团队成员尽早共享部分完成的代码和工件，以便：
- 发现错误
- 从中学习
- 通过在小问题变成大问题之前发现它们来减少返工
在每个开发迭代结束时，有四个总体类别需要学习：
- 从客户角度来看的结果质量
- 从技术角度来看的结果质量
- 交付团队和实践团队的运作
- 项目状态
从客户角度来看的结果质量
在自适应软件开发项目中，获取客户反馈是首要任务。推荐的做法是客户焦点小组。这些会议旨在探索应用程序的工作模型并记录客户更改请求。
客户焦点小组会议是类似于JAD会议的引导式会议，但它们并非用于生成需求或定义项目计划，而是用于审查应用程序本身。客户会对迭代产生的工作软件提供反馈。
从技术角度来看的结果质量
在自适应软件开发项目中，应重视对技术工件的定期审查。应持续进行代码审查。对其他技术工件（例如技术架构）的审查可以每周进行或在迭代结束时进行。
在自适应软件开发项目中，团队应定期监控自身的绩效。回顾鼓励团队作为一个团队一起了解自身和工作。
迭代结束后的回顾促进定期的团队绩效自我审查，例如：
- 确定哪些方面不起作用。
- 团队需要更多做什么。
- 团队需要少做什么。
项目状态
项目状态审查有助于规划进一步的工作。在自适应软件开发项目中，确定项目状态是基于功能的方法，每个迭代的结束都以完成的功能（生成可工作的软件）为标志。
项目状态审查应包括：
- 项目进展到哪里了？
- 项目进展与计划相比如何？
- 项目应该进展到哪里？
由于自适应软件开发项目中的计划是推测性的，因此与上述问题2相比，问题3更为重要。也就是说，项目团队和客户需要不断地问自己：“到目前为止我们学到了什么，这是否改变了我们对未来方向的看法？”