敏捷软件开发宣言

我们一直在实践中探寻更好的软件开发方法，身体力行，同时也帮助他人。由此我们建立了如下价值观：

个体和互动 高于 流程和工具

工作的软件 高于 详尽的文档

客户合作 高于 合同谈判

响应变化 高于 遵循计划

也就是说，尽管右项有其价值，

我们更重视左项的价值。

SCRUM 是一个用于开发和维护复杂产品的框架

Scrum 是一个用于开发和维护复杂产品的框架 ，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周(互联网产品研发可以使用1周的Sprint)。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。

Scrum流程如下图：

SCRUM框架包括3个角色、3个工件、5个事件、5个价值

3个角色

产品负责人（Product Owner）

Scrum Master

开发团队

3个工件

产品Backlog（Product Backlog）

SprintBacklog

产品增量（Increment）

5个事件

Sprint（Sprint本身是一个事件，包括了如下4个事件）

Sprint计划会议（Sprint Planning Meeting）

每日站会（Daily Scrum Meeting）

Sprint评审会议（Sprint Review Meeting）

Sprint回顾会议（Sprint Retrospective Meeting）

5个价值

承诺 – 愿意对目标做出承诺

专注– 把你的心思和能力都用到你承诺的工作上去

开放– Scrum 把项目中的一切开放给每个人看

尊重– 每个人都有他独特的背景和经验

勇气– 有勇气做出承诺，履行承诺，接受别人的尊重

SCRUM理论基础

Scrum以经验性过程控制理论（经验主义）做为理论基础的过程。经验主义主张知识源于经验, 以及基于已知的东西做决定。Scrum 采用迭代、增量的方法来优化可预见性并控制风险。

Scrum 的三大支柱支撑起每个经验性过程控制的实现:透明性、检验和适应。Scrum的三大支柱如下：

第一：透明性（Transparency）

透明度是指，在软件开发过程的各个环节保持高度的可见性，影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容。也就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于他们对完成的定义。

第二：检验（Inspection）

开发过程中的各方面必须做到足够频繁地检验，确保能够及时发现过程中的重大偏差。在确定检验频率时，需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能容许的程度，那么就会出现问题。幸运的是，软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和积极性。

第三：适应（Adaptation）

如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么便需要对过程或是材料进行调整。调整工作必须尽快实施，以减少进一步的偏差。

Scrum中通过三个活动进行检验和适应：每日例会检验Sprint目标的进展，做出调整，从而优化次日的工作价值；Sprint评审和计划会议检验发布目标的进展，做出调整，从而优化下一个Sprint的工作价值；Sprint回顾会议是用来回顾已经完成的Sprint，并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意，并且工作更快乐。

story points 评估

#1 story point是用来评估一个任务（Product Backlog）的难度，跟小时数没有必然的关系。Story point需要使用斐波那契数列来表示（1,2,3,5,8...）。只所以用这个序列是要更好的显示差异。

#2 对管理层和team的作用是，你一个sprint完成了多少个point能进行显示，那么经过多个sprint之后你就能看到这个team的velocity了！

#3 Scrum是头对头，因此是所有的team成员进行投票。每人一副12358的扑克牌，进行投票并对决讨论为什么这个story point是这个数字。此时不知道谁是执行人，减少认知偏差。

#4 不蛋疼。a.如果是一个难度是3的PBI，甲程序员完成可能10h，乙程序员可能需要8h，这个是一个方面。b.Sprint planning的时候你需要输入每个人的capacity吧，输入这个小时数就能看见一个程序员是不是超工作量了。c.输入完orginal time和remaining time就能产生burning down chart。这个chart对开发过程的重要性不用多解释了吧。