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 作为一个<角色>, 我想要<活动>, 以便于<商业价值>
