| 项目生命周期 | 项目需求 | 执行方式 | 交付方式 |
|---|---|---|---|
| 预测型 | 固定 | 整个项目仅实现一次 | 一次交付 |
| 迭代型 | 动态 | 迭代实现 | 多次交付 |
| 增量型 | 动态 | 根据需求增添功能 | 多次交付 |
| 敏捷型 | 动态 | 多次交付 |
软件的本质
复杂性
各种异常状态的处理，防止某一致命错误导致的宕机
一致性
软件开发的目标就是兼容性，保持各个接口的一致性
可变性
- 软件可以无限延展，修改容易
- 客户的需求
- 随着技术、开发语言随时变化
不可见性
瀑布和迭代的外在区别
需求分析 -> 设计 -> 开发 -> 测试
- 瀑布：按以上流程顺序，但是灵活性差，如果突然多了一个需求
- 迭代：小粒度
敏捷开发模式
极限编程
- 内环：技术实践
- 中环：团队实践(编码规范，代码管理)
- 外环：过程实践
Scrum
每个成员明确自己角色，围绕同一目标，集体行动
三个角色
- Product Owner：开发维护Product backlog——澄清需求并进行优先级管理；管理Version；需求方
- Scrum Master： 战力会议，回顾会议，迭代计划，推动团队进行(确保Team正确的做事)
- Team： 负责研发的主要实体；分功能
三个交付件
- 产品backlog
- 产品需求清单（描述，优先级，工作量）
- 迭代
- 在一轮迭代中的工作任务清单，分开优先级及估计工作量
- 燃尽图
- 显示每日直至开发团队完成全部任务的剩余工作量
四个会议
- 迭代计划
- 澄清产品需求
- 分清工作，小粒度开发工作
- 迭代验收
- 一轮迭代结束前，向PO展示工作成果
- 团队记录PO反馈问题，在下一轮迭代中改进
- 每日站立
- 限时15分钟
- 昨天做了什么
- 今天做什么
- 需要什么帮助
- 迭代回顾
- 每轮迭代结束前，分析好的经验发现改进点，促进进步
- 哪些做的好
- 哪些能做的更好
- 如何改进
敏捷宣言
个体和交互，可以工作的软件，客户合作，响应变化
原则
- 尽早的、持续的交付
- 利用变化来为客户创造竞争优势
- 经常性交付
- 业务、开发人员一起工作
- 信任
- 面对面交谈
- 可以工作的软件
- 可持续的开发速度
- 简介
- 自组织
- 反省
测试分析
- 分析需求、被测对象并建立测试设计模型(Model)
- 生成测试条件覆盖模型
- 增加测试数据以生成测试用例
- 更进一步的测试设计
story
作为..为了..我希望..
价值分析 -> 识别用户角色 -> 编写story -> 确定优先级 -> 估计工作量
价值分析“三板斧”：
- 为什么要做？
- 不做会怎么样
- 有没有代替方案
