1.需求

用户需求:该需求一般比较简略。(一句话)

软件需求:或者功能需求,详细描述开发人员必须实现的软件功能(一个文档)

2.BUG

说明是存在的并且正确,程序和规格说明之间不匹配是错误

从诞生到停服

需求分析,计划,设计,编码,测试,运行维护

需求分析:分析需求是否合理,需求是否完整

计划:谁开发,谁测试,开发多久,测试多久

编码:写代码

测试:测试报告

运行维护:如果线上有问题,此时测试人员要协助开发定位问题+解决问题

特点:线性的

优点:每个阶段做什么很清晰

缺点:风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会

使用项目:小型项目

优点:每个阶段都有风险评估,避免一些线上问题发生

缺点:风险分析可能分析错，需要人力财力的投入

使用项目:比较大,风险较多的项目

增量是逐步建造,迭代是反复求精

个体和交互重于过程和工具

可用软件重于完备文档

客户协作重于合同谈判

响应变化重于遵循计划

在每对比对中，后者并非全无价值，但我们更看重前者。

1.角色

scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成。

product owner(产品经理)负责整理用户故事,定义商业价值,排序,指定计划,对产品负责

scrum master(项目经理)负责召开会议协调项目,为研发团队服务

研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。

2.scrum的基本流程

产品负责人负责整理user story，形成左侧的product backlog。
发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog。
迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有明确的负责人，并完成工时的初估计。
每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。
演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由po整理，形成新的story。
回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果。