Scrum基础知识

agile和scrum的基础知识，主要概念。

敏捷软件开发宣言(4大价值)

Manifesto for Agile Software Development

项番	详细（英文）	详细（中文）
No.1	Individuals and interactions over processes and tools	个体和互动 高于 流程和工具
No.2	Working software over comprehensive documentation	工作的软件 高于 详尽的文档
No.3	Customer collaboration over contract negotiation	客户合作 高于 合同谈判
No.4	Responding to change over following a plan	响应变化 高于 遵循计划
结论	That is, while there is value in the items on the right, we value the items on the left more.	也就是说，尽管右项有其价值，我们更重视左项的价值。

敏捷宣言遵循的原则（12原则）

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

Principles behind the Agile Manifesto

项番	详细（英文）
No.1	Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
No.2	Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
No.3	Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
No.4	Business people and developers must work together daily throughout the project.
No.5	Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
No.6	The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
No.7	Working software is the primary measure of progress.
No.8	Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
No.9	Continuous attention to technical excellence and good design enhances agility.
No.10	Simplicity–the art of maximizing the amount of work not done–is essential.
No.11	The best architectures, requirements, and designs emerge from self-organizing teams.
No.12	At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

SCRUM三大理论基础

项番	详细
No.1	透明性（Transparency）
No.2	检验（Inspection）
No.3	适应（Adaptation）

3个角色

项番	详细
No.1	产品负责人（Product Owner）
No.2	Scrum Master
No.3	Scrum团队

3个工件(artifacts)

项番	详细
No.1	产品Backlog（Product Backlog）
No.2	SprintBacklog
No.3	燃尽图（Burn-down Chart)

5个活动(events)

项番	详细
No.1	Sprint计划会议（Sprint Planning Meeting）
No.2	每日站会（Daily Scrum Meeting）
No.3	Sprint评审会议（Sprint Review Meeting）
No.4	Sprint回顾会议（Sprint Retrospective Meeting）
No.5	产品Backlog梳理会议（ Product Backlog Refinement）

5 core values of scrum

项番	详细（英文）	详细（中文）
No.1	Focus	专注
No.2	Courage	勇气
No.3	Openness	开放
No.4	Commitment	承诺
No.5	Respect	尊重

常见术语

英文	中文解释
Lean	精益
Agile Manifesto	敏捷宣言
Empirical Process	经验性过程
Product Owner	产品负责人 简称PO
Scrum Master	简称SM, 一般不翻译
Development Team	Scrum开发团队
Scrum Team	指PO,SM和开发团队
Scrum Roles	Scrum角色，指PO,SM和开发团队
Product Backlog	产品待办列表，指需求清单
Sprint Backlog	Sprint待办列表，指Sprint任务清单
Sprint Burn-down Chart	Sprint燃尽图，团队用于做Sprint内的进展跟踪
Release Burn-down Chart	发布燃尽图，产品负责人做发布进展跟踪
Sprint Planning Meeting	Sprint计划会议
Daily Scrum Meeting	每日站会
Sprint Review Meeting	Sprint评审会议
Sprint Retrospective Meeting	Sprint回顾会议
Product Backlog Refinement	产品待办列表梳理
Product Backlog Item	产品待办清单条目，简称PBI
User Story	用户故事，指一条需求
Story Point	衡量用户故事的工作量大小的计量单位
Sprint Task	实现一条需求需要做的一个技术任务
Definition of Done	DoD，完成的定义
Backlog	待办列表
Artifact	工件
Scaling Scrum	大规模Scrum

诞生

Scrum原始含义是指英式橄榄球次要犯规时在犯规地点对阵争球。

时间	milestone
1986	竹内弘高和 野中郁次郎在New New Product Development Game文章首次提到将Scrum应用与产品开发
1993	Jeff Sutherland首次在Easel公司定义了用于了软件开发行业的Scrum流程，并开始实施。
1995	Jeff Sutherland和Ken Schwaber规范化了Scrum框架，并在OOPSLA 95上公开发布。
2001	敏捷宣言及原则发布、敏捷联盟成立，Scrum是其中一种敏捷方法。
2002	Ken Schwaber 和Mike Cohn共同创办了Scrum联盟。

Scrum团队的规模

开发团队最佳规模是小到足以保持敏捷性,大到足以完成重要工作。
少于 3 人的开发团队没有足够的交互,因而所获得的生产力增长也不会很大。
小团队在 Sprint 中可能会 受到技能限制,从而导致无法交付可发布的产品增量。
大于 9 人的团队需要过多的协调沟 通工作。大型团队会产生太多复杂性,不便于经验过程管理。

User story的3个C（Ron Jeffries的3个C）

项番	详细
卡片（Card）	用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。
交谈（Conversation）	用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
确认（Confirmation）	通过验收测试确认用户故事被正确完成。

User story的6个特性（INVEST）

INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable

项番	详细

User story的通常表达方式

英文	中文
As a , I want to , so that	作为一个<角色>, 我想要<活动>, 以便于<商业价值>