敏捷开发工作流
敏捷开发框架
Scrum 通常被认为是一个敏捷开发项目管理框架，它描述了一组协同工作的会议、工具和角色，以帮助团队组织和管理其工作。
从图中可以看到，主要流程如下：
- 产品分析用户需求，按照商业价值依次排序估算，输出计划产品功能列表。
- 经过计划会议讨论，按照计划面板梳理功能列表，输出产品版本迭代任务。
- 进入开发迭代周期，按照任务面板增量迭代开发，输出可交付的迭代版本。
- 进入评审验收环 节，按照发布面板汇总问题原因，输出迭代周期报表数据。
产品 BACKLOG
用户需求，分析转化，产品 BACKLOG
这个部分的内容由 PM（项目经理）具体负责，主要的工作内容如下：
- 用户调研、需求分析，确定产品迭代功能，出具产品 BACKLOG。
- 决定产品的发布日期与发布内容，给迭代计划预设目标。
- 根据 RIO（商业价值/工作量）排序优先级，考虑必要风险。
- 制定 Sprint 计划，根据实际情况调整功能与优先级。
由产品负责人维护管理的一个已排序，已估算，可渐进的需求清单列表，可参考PRD文档中的功能模块记录列表或者产品需求池的记录列表。在一般的情况下，会根据功能模块对应的用户故事流程来表示 BACKLOG 条目内容。在每个 Sprint 结束或者临时需求变更时，都需要更新优先级的排列顺序。
下面是实际的方法
用户故事
1、什么是用户故事？
2、用户故事的 INVEST 原则
- 独立性（Independent）：要尽可能的让一个用户故事独 立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。
- 可协商性（Negotiable）：一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。
- 有价值（Valuable）：每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
- 可以估算性（Estimable）：开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
- 短小（Small）：一个好的故事在工作量上要尽量短小，最好不要超过 10个理想人/天的工作量,至少要确保的是在一个迭代或 Sprint 中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
- 可测试性（Testable）：一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。
用户故事拆分指南
1、用户故事样例
2、用户故事的颗粒度要求
3、用户故事的拆分指南 可以从以下几个视角拆分用户故事：
- 首先，按照角色进行用户故事拆分。
- 其次，按照同一角色的业务行为来拆分用户故事。
- 再次，对同一业务行为，按照业务数据类型和项目来拆分用户故事。
Sprint 计划会议
这个部分的内容主要由 SM 负责，主要工作内容如下：
- 确定高价值的需求进入高优先级的 BACKLOG。
- 将产品 BACKLOG 拆分为在本次 Sprint 中可细化的 Sprint BACKLOG。
- Sprint BACKLOG 中的开发任务以小时估算，预计 1-16 小时的工作量化。
- 根据开发优先级管理 Sprint BACKLOG，随时更新 Sprint BACKLOG 状态。
- 每个团队成员都可以自主挑选任务，修改 Sprint BACKLOG。
由开发负责人维护管理的一个 Sprint 任务清单，根据产品 BACKLOG 细化而来，细化为开发过程中可用的产品功能任务，每个任务用小时估算时间，团队成员可自行管理任务，每天的任务进度会更新到对应的任务面板上。
不需要在 Sprint 计划会议上就分配好所有的任务，团队根据用户故事的测试要点、技术实现，进行任务拆分，例如：前端页面开发任务、后端逻辑开发任务、数据库开发任务、接口开发任务等，然后会议结束后再让对应的开发细化具体的工作项目
任务面板是“任务状态/工作进程”的二维工作面板，便签颜色可代表团队成员，便签内容代表团队成员所负责的开发任务。任务状态一般可划分为：ToDo，Doing，Tested，Reviewed，Finished 五个状态，在一块方形划分区域中贴满了颜色便签，随时更新任务面板状态，保证团队所有成员随时随地都可以了解 Sprint 周期内的整体开发进度
迭代开发周期
这部分内容主要由开发团队共同推进，主要工作内容如下：
- 依照 Sprint BACKLOG，开始开发工作，更新工作任务面板。
- 参加每日例会，明确各团队的整体开发进度与开发难点。
- 保证整体开发进度不大幅度的偏离预设的 Sprint 燃尽图。
- 高度的自我组织管理，保持良好的跨职能团队沟通，确保实现 Sprint 目标。
燃尽图是指在 1个Sprint 周期内，工时/工作量的二维图表，主要是为了让团队成员明白在 Sprint 截止时间点前剩余开发工作量的整体情况，通过实际燃尽图与理想燃尽图的线性对比，可快速调整开发节奏，降低 Sprint 版本交付存在的风险。
Sprint 开发代码方式
双周迭代集中发布：需求 F 分支做完一个后就合并到 f-release 分支上，统一时间点合并到 release 分支上，上生产环境。
需要紧急修复的 BUG 才会开 B 分支，紧急发布
预发布环境是正式发布前最后一次测试，所有的功能和配置，数据库都已经与线上环境高度相似，仅准入本次需要上线的功能代码，测试人员确认代码在测试环境经过测试用例测试没有问题后，提交预发布环境进行测试。因为在少数情况下即使预发布通过了，都不能保证正式生产环境可以 100% 不出问题；
预发布环境的配置，数据库等都是跟线上一样；有些公司的预发布环境数据库是连接线上环境，有些公司预发布环境是单独的数据库；如果不设预发布环境，如果开发合并代码有问题，会直接将问题发布到线上，增加维护的成本；
验收发布版本
这部分内容主要由 Sprint 团队成员共同参与，主要工作内容如下：
- 产品开发团队通过操作演示的方式展示 Sprint 中完成的功能与架构。
- PM 根据产品 BACKLOG，验收开发交付的迭代版本，发布产品迭代版本。
- 收集 Sprint 问题反馈，寻找根本原因，讨论解决方法，改善 Sprint 过程。
SM 和 PM
SM（Scrum Master）和 PM（Product Manager）是 Scrum 团队中的两个重要角色，他们的工作区别如下：
PM 具体的工作职责
产品经理核心职责
- 对产品的市场成功负责，决定产品要做什么。
- 非常清晰的将产品的路线图、需求传递给团队。
- 确保团队按照产品的路线图和需求，交付正确的产品。
产品经理的关键活动
1、主导活动：
- 通过协调各方干系人（客户、用户、管理层等）确定产品的目标、愿景和发展路线图。
- 需求分析、识别和定义产品 Backlog。
- 统一把控需求的优先级。
- 制定版本发布计划。
- 管理产品的版本发布。
- 讨论产品的业务实现方案、UI 和交互设计方案。
- 每个迭代前，组织团队梳理产品 Backlog。
- 在特殊情况下，组织进行 Sprint 的变更：用户故事的置换、Sprint 目标的调整，Sprint 的终止。
- 向干系人汇报产品的开发状态。
- 定义发布交付件清单，以及交付件的验收质量标准（团队提供支持）。
2、参与活动：
- 参与 Sprint 计划会议，定义 Sprint 目标。
- 关注迭代开发进展。
- 澄清 Sprint 目标及用户需求。
- 参加 Sprint 演示会议，验收团队交付物，并给予反馈。
产品经理要避免的事情
- 直接给出技术方案，告诉团队如何做开发。
- 直接安排开发任务，破坏团队的自组织。
- 在 Sprint 中轻易变更 Sprint 目标和用户故事。
- 不参加 Sprint 计划会议、Sprint 演示会议。
- 开发团队发现他其实不知道客户要什么。
- 没有向团队提供足够的透明性。
- 没有准备好就让团队开 发，例如没有完成产品 Backlog 的梳理。
SM 具体的工作职责
- 更新和检查目前冲刺的燃尽图报表。
- 如果团队落后于时间表，SM 需要帮助团队想办法追上进度。同时，SM 需要确保所有完成了的任务都已经被标记成了完成（通过管理工具自动化实现），这样燃尽图表的数据才准确。
- 检查 Sprint 待办列表里的条目和相应的任务情况。
- 团队的 Scrum 教练，确保 PM 和团队按照敏捷的原则和实践开展工作。
- 协调团队的各种会议、活动，对流程负责。
- 帮助团队发现问题、解决障碍（团队无法独立解决的障碍）。
- 促进团队的良性协作。