Scrum快速入门

背景与来源

一种敏捷方法论/框架，提交团队的效率。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是一至四周。

过程

敏捷价值观与原则

价值观
1. 个人与互动胜过过程与工具
2. 可用的软件胜过复杂的文件
3. 与客户合作胜过合同谈判
4. 响应变更胜过遵循计划

原则
1. 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
2. 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
3. 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
6. 不论团队内外，传递信息效果最好和效率最高的方式是面对面的交谈。
7. 可工作的软件是进度的首要度量标准。
8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10. 以简洁为本，它是极力减少不必要工作量的艺术。
11. 最好的架构、需求和设计出自组织团队。
12. 团队定期地反思如何能提高成效，并依此调整自身的举止表现。

SCRUM相关术语

角色/成员

1. 产品负责人 Product Owner：经常由产品经理担任，有时由业务担任，负责产品的定义，backlog的维护 。
2. Scrum主管 Scrum Master： 为Scrum过程负责的人，确保scrum的正确使用并使得Scrum的收益最大化。
3. 开发团队 Team: 由负责自我管理开发产品的人组成的跨职能团队。

工件/文档

1. 产品列表 Product Backlog：根据用户价值进行优先级排序的高层需求。
2. 冲刺订单 Sprint Backlog：要在冲刺中完成的任务的清单。
3. 产品增量 Increment：最终交付给客户的内容

活动/会议

1. 计划会 Sprint Planning Meeting：在每个冲刺之初，由产品负责人讲解需求，并由开发团队进行估算的计划会议。
2. 每日立会 Daily Standup Meeting：团队每天进行沟通的内部短会，因一般只有15分钟且站立进行而得名。
3. 评审会 Review Meeting：在冲刺结束前给产品负责人演示并接受评价的会议。
4. 反思会/回顾会 Retrospective Meeting：在冲刺结束后召开的关于自我持续改进的会议。
5. Product Backlog Refinement Meeting: 为接下来的一到两个sprint作准备

价值观

1. 承诺 – 愿意对目标做出承诺
2. 专注– 把你的心思和能力都用到你承诺的工作上去
3. 开放– Scrum 把项目中的一切开放给每个人看
4. 尊重– 每个人都有他独特的背景和经验
5. 勇气– 有勇气做出承诺，履行承诺，接受别人的尊重

工具

最基本的会用到列表管理，kanban工具。比如jira/coding/teambition/tower/禅道/wriktile等。最近新出的clickup，号称取代jira，值得关注。

常见问题

1. 迭代周期到底是多久，可以变化吗？ 概念上的迭代周期是固定的，节奏的稳定对个体的效率提升有很大的帮助。最好是可以已周的整数倍做为迭代周期，因为我们上班时按周上的；也有团队是按月或者半月的的单位来看，因为外部环境通常是按月来看的（理想情况下是东西先做好，到时间节点是上线）。 如果延后了怎么办，概念上是放入下一个迭代的，实际上要看各个具体的环境，比如强市场节点。
2. Scrum团队中需要项目经理吗/Scrum Master和项目经理冲突吗？ Scrum的本身是为了提高效率，理想情况下团队是自组织的，不需要项目经理，实际过程中，Scrum Master可能由产品经理，Team lead或者项目经理担任着，有些复杂团队中甚至team lead，scrum master, 项目经理是分别由多个人担任的。并不需要纠结于title，而是团队能够多大的程度的自组织，那些需要跟进与负责的事情是有小伙伴在跟进的；于是乎，在没那么自组织的情况下，那些不那么明确的事项由上述的特定人来处理了。
3. Scrum Master到底是跟一个项目还是多个项目？ 依照能力，通常是1到多个。
4. 第二个Sprint backlog是在什么时候制定的？ 真正的确定是在sprint开始之前，但可能的情况下需更早准备一些，产品的设计、ROI、落地的复杂度、时间估算、外部环境的变化等都将影响最后的决策。
5. 设计师与团队sprint的关系是怎么样的？ 有的团队是融入到sprint中的；有的是单独迭代走上游与需求一起的sprint。
6. DoR, DoD
   a. definition of ready更多是指需求、story已经细化好；
   • PRD、原型已完成，并已经同步给团队
   • 待确认的story细节已经得到确认
   • 已经做了初步估算，需求之间的依赖已经澄清
   • 技术方案已经评估，针对复杂的需求概要设计已出
   • 验收条件已出：即基于什么条件（Given），做什么操作后(When)，应该得出什么预期结果(Then)

   b. definition of done更多是指结果的完成，细化时还按阶段来看（比如spint的done和release的done定义是不一样的），比如

   • 已经完成内部的代码评审（Code Review）
   • 已经完成单元测试及自动化构建
   • 已经完成功能测试
   • PO已经验证
7. 需求中Epic, Feature, UserStory, Task层级怎么区分
   a. Epic 更多是大的业务方向，业务领域。应对所有人可见，这样所有人都知道所做的事情是为那个业务领域服务的。一般是数个release
   b. Feature 有的团队中没有Feature这一层级，可能是直接从Epic到了User Story。一般这一层级可以代表着端到端的一个需求场景（或是某个点的改进-这时也可以直接时user story层级），对用户感知明显，在release note中也会着重说明。
   c. User Story：细化的用户场景故事，常常用INVEST原则判定（idenpendent, negotiable, valuable, estimatable, small, testable)。对接story point, 一般在一个sprint中完成（建议持续时间不要超过1周）
   d. Task: 具体分配到人员上的任务, 对接工时

Scrum vs Kanban

以下列出从概念上的差别，但落地时常常两者混合使用

Scrum vs Lean

1. 关注：
   1. Scrum 更加关注和客户密切协作，尽早地迅速交付可用的软件；
   2. Lean可以更加关注在对客户有价值的上下文环境下消除浪费
2. 视角：
   1. Scrum视角着重于软件开发的具体开发实践和项目管理；
   2. Lean视角更加着重一体看待软件开发和它的整体业务环境

相关敏捷方法

1. 看板
2. 精益
3. XP