识别阶段 | 商务分析 | ||
收集干系人列表 | 有一个主要负责人 | ||
需求搜集 | |||
启动阶段 | 商务分析报告 | 包括该项目的价值报告 | |
概括性的功能和非功能需求列表 | 包括容量要求、可用性要求、服务连续性要求和安全性要求 | 需求详细程度足以估算工作量和做项目 计划即可 | |
发布计划 | 其中包括工作时间安排表和与项目相关 的成本。 | 评估需求的相对大小,所需的编码工作量, 以及每个需求相关的风险和所需人力资源计划 | |
测试策略 | |||
发布策略 | |||
构架评估报告 | 决定使用什么样的平台和框架 | ||
风险和问题列表 | |||
开发生命周期的描述 | |||
执行上述内容的计划描述 | |||
初始阶段 | 确保团队(分析师、经理和开发人员) 可以得到开发所需的所有软硬件 | ||
确保基本的基础设施都准备好了, 比如因特网连接、管理系统就绪 | |||
创建电子邮件账号,为大家指派访问各类 资源的权限 | |||
建立好版本控制库 | |||
建立一个基本的持续集成环境 | |||
在角色、职责、工作时间和会议时间上达成一致 | |||
为第一周做准备工作,并在目标上达成 一致 | |||
创建一个简单的测试环境和测试数据 | |||
稍微更详细地研究一下预定的系统设计 | 在这一阶段探究它的可行性是真正的 目标 | ||
做一些调研(为了验证对某个具体需求的设计而做的实现,将来会被扔掉)看,识别和缓解任何分析、开发和测试风险。 | |||
开发用户故事或需求的待办列表(Backlog) | |||
创建项目结构,使用简单的用户故事,包括一个构建脚本和一些测试,从而验证持续集成环境可以正常工作。 | |||
开发与发布 | 迭代工作的基本要求 | 软件应该一直处于可工作状态,因为每次签入代码时,都会运行自动化测试套件,包括单元测试、组建测试以及端到端的验收测试 | |
每个迭代都能将软件部署到一个类生产环境中,并向用户演示(这样可以确保整个过程不但是迭代式的,而且是增量式的) | |||
迭代长度不超过两周 | |||
迭代开发过程的关键在于划分优先级和并行化。 | |||
迭代失败的原因 | 缺乏承诺。 | ||
忽视好的工程实践。 | |||
将敏捷开发过程进行适应性调整,直到这个过程不再敏捷了。 | |||
敏捷Scrum检查单 | 你在做迭代开发吗? | 迭代周期必须少于四周,而且要固定时长 | |
在每个迭代结束时,软件的功能必须被测试 完,并能够正常工作。 | |||
在规格说明书写完之前,迭代必须开始。 | |||
你在使用Scrum吗? | 你知道谁是产品拥有者吗? | ||
产品待办列表是按业务优先级排列的吗? | |||
产品待办列表是由团队估算的吗? | |||
项目经理或其它人是否干扰了团队的工作? (项目经理应该管理风险、移除障碍) | |||
运营阶段 | 维护性发布 | 修改未发现的bug | |
满足新发现的需求 | |||
滚动开发计划的一部分 | 识别新特性、排定优先级、分析、开发、测试和发布 |
敏捷开发过程
最新推荐文章于 2022-05-06 15:13:16 发布