1、瀑布式开发
| 流程 | 关键词 | 关键人员 | 输出 |
|---|---|---|---|
| 立项 | 简述、周期、预算 | 领导 | 立项申请表、立项评审表 |
| 策划 | 计划 | 项目经理、QA、CM | 各种计划书（项目、配置、测试等），评审 |
| 需求 | 功能 | 项目经理 | 功能列表、需求规格书、需求开发计划等，评审 |
| 设计 | UML | 开发 | 设计（概要、详细、数据库）、分析、评审 |
| 编码 | 写代码 | 开发 | 源码、单元测试、安装包、产品集成、代码审查 |
| 测试 | 测试 | 测试 | 需求测试、集成测试、系统测试、缺陷跟踪、评审 |
| 手册 | 使用文档 | 项目经理 | 安装手册、操作手册 |
| 验收 | 发布、验收 | 客户 | 确认表、验收单 |
| 结项 | 评价 | 领导 | 总结报告 |
| 质保 | 维护 | QA | 检查表、问题跟踪表 |
2、Scrum
2.1 简述
Scrum是迭代式增量软件开发过程，是敏捷方法论中的重要框架之一
百度百科：https://baike.baidu.com/item/Scrum/1698901?fr=aladdin
推荐博客：https://blog.csdn.net/a715167986/article/details/128716292
2.2 术语
角色
产品负责人 Product Owner： 负责维护产品订单的人，代表利益相关者的利益。
Scrum主管 Scrum Master： 为Scrum过程负责的人，确保scrum的正确使用并使得Scrum的收益最大化。一般不翻译。
开发团队 Team: 由负责自我管理开发产品的人组成的跨职能团队。
工件
产品列表 Product Backlog：根据用户价值进行优先级排序的高层需求。
冲刺订单 Sprint Backlog：要在冲刺中完成的任务的清单。
产品增量 Increment：最终交付给客户的内容
活动
计划会 Sprint Planning Meeting：在每个冲刺之初，由产品负责人讲解需求，并由开发团队进行估算的计划会议。
每日立会 Daily Standup Meeting：团队每天进行沟通的内部短会，因一般只有15分钟且站立进行而得名。
评审会 Review Meeting：在冲刺结束前给产品负责人演示并接受评价的会议。
反思会/回顾会 Retrospective Meeting：在冲刺结束后召开的关于自我持续改进的会议。
其他
冲刺 Sprint: 一个时间周期（通常在2周到1个月之间），开发团队会在此期间内完成所承诺的一组订单项的开发。
2.3 用户故事
用户故事（user story）是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：
角色： 谁要使用这个功能。
活动： 需要完成什么样的功能或目标。
商业价值：为什么需要这个功能，这个功能带来什么样的价值。
用户故事通常按照如下的格式来表达：
英文：
As a <Role>, I want to <Activity>, so that <Business Value>.
中文：
作为一个<角色>, 我想要<活动>, 以便于<商业价值>
举例：
作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”
需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。
关于用户故事，Ron Jeffries用3个C来描述它：
卡片（Card） - 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。
交谈（Conversation）- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
确认（Confirmation）- 通过验收测试确认用户故事被正确完成。
用户故事的六个特性- INVEST
INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable
独立性 可协商性 有价值 可以估算性 短小 可测试性
- 独立性（Independent）— 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。
- 可协商性（Negotiable）— 一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。
- 有价值（Valuable）— 每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
- 可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
- 短小（Small）— 一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
- 可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。
2.4 史诗、特性
敏捷中需求通常被分为史诗、特性、用户故事三大类别，逐层往下，粒度越来越小。需求直到被分解至用户故事时，才能放入Scrum迭代。
史诗：由多个较小的故事组成的史诗。
特性：一组相关的故事，有价值的单方向功能集合。
用户故事：独立的较小用户的价值交付单元。有可能不足以单独发布。
2.5 猪与鸡
2.5.1 鸡和猪的故事
一天，一只鸡散步时遇见了猪。
鸡对猪说：“嗨，我们合伙开个餐厅吧。”
猪说：“好啊，那准备取什么店名呢？”
鸡说：“要不，就叫火腿和鸡蛋吧。”
猪直接拒绝了：“那可不行。我要割肉，你只要下蛋。这样下去，我迟早要完蛋。”
2.5.2 保护“猪”，兼顾“鸡”
这个故事实际上反映了软件开发过程中的2种不同角色，即需要完全投入的“猪”和只要部分投入的“鸡”。真实项目过程中，往往会发生这样的现象，产品经理或领导，喜欢临时往项目中新增任务，打乱原先的开发节奏，导致程序员压力倍增，士气低落，项目延期。
而Scrum，就是为了保护“猪”这种角色，兼顾“鸡”的感受，从而确保整个项目正常交付。它是一套敏捷开发流程。
2.6 Scrum用到的工具
- 用户故事。迭代计划会议用到，Product Owner以用户的角度去描述需求。如，作为一个学员，我希望能在做完一份试卷后，系统能针对我的薄弱点提供相应的指导及练习。
- Product Backlog。迭代计划会议用到，Product Owner事先将所有的用户故事按优先级排好，放到一个列表内，这个列表就是Product Backlog。
- Sprint Backlog。迭代计划会议用到，整个开发小组通过估点将用户故事按优先级移入到迭代计划内，迭代计划中待完成的用户故事列表即为Sprint Backlog。
- 估点。主要用于评估用户故事的大致工作量。下一篇文章会额外介绍估点。
- 燃尽图。主要用于迭代进度的管控。下一篇文章会额外介绍燃尽图。
2.7 Scrum标准流程
2.7.1 Scrum标准流程之Sprint Planning Meeting
迭代计划会议中，整个小组通过估点的方式，按优先级将用户故事从Product Backlog中移入到Sprint Backlog，表示整个小组承诺本迭代要做完的任务。做完的标准是测试通过，除非此任务不可测试。
2.7.2 Scrum标准流程之Daily Stand Up Meeting
迭代计划会后，小组成员按个人喜好领取自己的任务，并在每天的站立会议上讲一下自己昨天做了什么，今天准备作什么，大概什么时候完成，以及遇到了什么问题。当有人提出遇到难题时，Scrum Master需要在会后安排人帮忙解决，而不是在会议上直接解决。每个人大概30秒-1分钟，整个会议一般不超过15分钟。每一个工作日结束后，需要画燃尽图（下一篇文章会额外介绍）。
2.7.3 Scrum标准流程之Review Meeting
一个迭代开发阶段结束后，进入内部演示会议，工作成果给整个小组演示（包括Project Owner）。EduSoho的做法是，bug及小优化不演示，点数较大的功能点做演示。
2.7.4 Scrum标准流程之Restrospective Meeting
内部演示结束后，整个小组（包括Project Owner）召开一个迭代回顾会，回顾本迭代中大家哪些做的好，哪些做的不好，每人各列举3个好的以及不好的，列的时候只讲现象，不分析原因，不找解决方案。然后整个小组投票选出3个不好的，分析原因，寻找解决方案，并指定执行者。
为什么只解决3个不好的？每个小组的精力有限，如果要一个迭代内解决全部问题，不太现实，先优先解决3个最重要的，多次迭代后，会发现整个小组的变化越来越明显。