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