# Introduction

# Why Agile? 为什么要敏捷？

• Long term planning methodologies less supportive of projects currently done
  长期规划方法论不足以支持目前完成的项目
• Highly changing environment
  瞬息万变的环境

# Agile Alliance 敏捷联盟

Snowbird, Utah February, 2001
Created Agile Manifesto

# Shift 转移

• Big up front design to iterative incremental development
  从前期大设计到迭代增量开发
• Drive toward higher quality software in shorter time frames (MVP)
  在更短的时间范围内向更高质量的软件发展（MVP）
• Requirements and solutions evolve through collaboration and self-organizing cross functional teams
  需求和解决方案通过协作和自组织跨职能团队而发展

# The foundation of Agile is found at…. 敏捷的基础位于

AgileManifesto.org

# Manifesto for Agile Software Development 敏捷软件开发宣言

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
我们一直在实践中探寻更好的软件开发方法，
身体力行的同时也帮助他人。由此我们建立了如下价值观：

1. Individuals and interactions over processes and tools
   个体和互动 高于 流程和工具
2. Working software over comprehensive documentation
   工作的软件 高于 详尽的文档
3. Customer collaboration over contract negotiation
   客户合作 高于 合同谈判
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.
也就是说，尽管右项有其价值，
我们更重视左项的价值。

Please memorize these values
The word is “Over” not instead of…this is very important

# Principles Behind the Manifesto 宣言背后的原则

We follow these principles:
我们遵循以下原则：

1. Our highest priority is to satisfy the customer
   through early and continuous delivery
   of valuable software.
   我们最重要的目标，是通过持续不断地
   及早交付有价值的软件使客户满意。

2. Welcome changing requirements, even late in
   development. Agile processes harness change for
   the customer's competitive advantage.
   欣然面对需求变化，即使在开发后期也一样。
   为了客户的竞争优势，敏捷过程掌控变化。

3. Deliver working software frequently, from a
   couple of weeks to a couple of months, with a
   preference to the shorter timescale.
   经常地交付可工作的软件，
   相隔几星期或一两个月，倾向于采取较短的周期。

4. Business people and developers must work
   together daily throughout the project.
   业务人员和开发人员必须相互合作，
   项目中的每一天都不例外。

5. Build projects around motivated individuals.
   Give them the environment and support they need,
   and trust them to get the job done.
   激发个体的斗志，以他们为核心搭建项目。
   提供所需的环境和支援，辅以信任，从而达成目标。

6. The most efficient and effective method of
   conveying information to and within a development
   team is face-to-face conversation.
   不论团队内外，传递信息效果最好效率也最高的方式是
   面对面的交谈。

7. Working software is the primary measure of progress.
   可工作的软件是进度的首要度量标准。

8. Agile processes promote sustainable development.
   The sponsors, developers, and users should be able
   to maintain a constant pace indefinitely.
   敏捷过程倡导可持续开发。
   责任人、开发人员和用户要能够共同维持其步调稳定延续。

9. Continuous attention to technical excellence
   and good design enhances agility.
   坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

10. Simplicity--the art of maximizing the amount
    of work not done--is essential.
    以简洁为本，它是极力减少不必要工作量的艺术。

11. The best architectures, requirements, and designs
    emerge from self-organizing teams.
    最好的架构、需求和设计出自自组织团队。

12. At regular intervals, the team reflects on how
    to become more effective, then tunes and adjusts
    its behavior accordingly.
    团队定期地反思如何能提高成效，
    并依此调整自身的举止表现。

# Summary 12 principles 总结 12 条原则

1. Customer satisfaction
   顾客满意度
2. Welcome changes
   欢迎更改
3. Frequent delivery
   频繁交付
4. Work together
   一起工作
5. Motivated individuals
   有动力的人
6. Face-to-face contact
   面对面的接触
7. Working software
   可工作的软件
8. Constant/sustainable pace
   恒定 / 可持续的步伐
9. Continuous attention
   坚持不懈地追求
10. Simplicity
    简洁
11. Self-organization
    自组织

# Empirical Process Control 经验过程控制

• Scrum is based on it
  敏捷基于此
  • Transparency; the process itself and all communications
    透明度；流程本身和所有通讯
  • Inspection; Frequent inspection and the utilization of frequent reviews of the product service or results
    检查；经常检查和使用对产品服务或结果的频繁检查
  • Adaptation; embrace uncertainty and changes and manage risks accordingly
    适应；把握不确定性和变化并相应地管理风险
• Empiricism involves learning and adapting as needed
  经验主义需要学习和适应

Please memorize the three pillars of empirical process control.
请记住经验过程控制的三个支柱。

• Iterative
  迭代式
• Incremental
  增加的
• Frequent Reviews
  经常评论
• Adaptation
  适应
• Uncertainty and risks during execution
  执行过程中的不确定性和风险
• It isn’t a “defined” process; it’s a way of being and doing
  这不是一个 “定义” 的过程；这是一种存在和做事的方式

# Scrum Values 敏捷价值观

https://www.scrum.org/resources/scrum-values-poster

• COURAGE 勇气
  Scrum Team members have courage to do the right thing and work on tough problems
  敏捷团队成员有勇气做正确的事并解决棘手的问题

• FOCUS 专注
  Everyone focuses on the work of the Sprint and the goals of the Scrum Team
  每个人都专注于冲刺工作和敏捷团队的目标

• COMMITMENT 承诺
  People personally commit to achieving the goals of the Scrum Team
  人们亲自致力于实现敏捷团队的目标

• RESPECT 尊重
  Scrum Team members respect each other to be capable,independent people
  敏捷团队成员相互尊重，成为有能力的独立人

• OPENNESS 开放性
  The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work
  敏捷团队及其利益相关者，同意对所有工作和执行工作所面临的挑战持开放态度

# Agile is an umbrella for… 敏捷是…… 的保护伞

• XP 经验值
• Scrum
• Kanban 看板
• Others

# Scrum Team Defined 敏捷开发团队的定义

# Main Ideas about a Scrum team 关于敏捷开发团队的主要想法

• Team is 7 +/- 2 members (optimally)
  团队为 7 +/- 2 名成员（最佳）
• Cross functional
  跨功能
• The “Team” owns the code base, specific programs are not ”owned” by a single person.
  “团队” 拥有代码库，特定程序不是一个人 “拥有” 的。
• Product Owner provides User Stories on the Product Backlog and ranks them
  产品负责人在产品待办事项列表上提供用户案例并对其进行排名
• Team Helps refine the product backlog
  团队帮助完善产品积压
• Scrum Master Coaches the entire team & removes impediments
  流程管理员 (Scrum Master) 指导整个团队并消除障碍

# Scrum Team has 3 parts 敏捷开发团队包括 3 个部分

• Product owner 产品负责人
• Scrum master 流程管理员
• Team 开发团队

# Product Owner 产品负责人

• Creates User Stories for the scrum team to work on.
  创建供 Scrum 团队使用的用户故事。
• Work with dev/test while revising User Stories on the backlog
  与开发人员 / 测试人员合作，同时修改积压的用户故事
• Prioritize backlog
  优先安排积压
• Approves:
  批准：
  • work products as they complete
    工作产品完成
  • test plans
    测试计划
• Explains User Stories to Dev/Test team (ongoing).
  向开发 / 测试小组说明用户案例（正在进行中）。
• Negotiates User Story content when there are technical (or other) limitations
  在存在技术（或其他）限制时，协商用户故事内容
• May actually execute the “demo” for all appropriate stakeholders
  可能实际上为所有适当的利益相关者执行 “演示”

# Prioritization of User Stories 用户故事的优先级

• The vison of the organization
  组织的形象
• Client’s immediate needs
  客户的即时需求
• NPV (if possible)
  净现值（如果可能的话）
• Story points of the User Story
  用户故事的故事点
• Risks (to the team and to the business)
  风险（对团队和业务）
• Perceived value of the User Story
  用户故事的感知价值
• Weighted Shortest Job First (WSJF)
  加权最短作业优先
• Dependencies
  依存关系
• Must have, Could have, Should have, Won’t have (MoSCoW)
  必须拥有，可能拥有，应该拥有，不会拥有

# Development & Test 开发与测试

• Team ownership of all code
  团队所有代码的所有权
• Helps to refine user stories on backlog
  有助于完善积压的用户案例
• Commits specific User Stories into Specific Iterations
  将特定的用户故事提交到特定的迭代中
• Applies story points (by mutual consensus)
  应用故事点（通过相互协商）
• Has work approved by product owner as it completes – does not wait for “demo” at the end of sprint for approval.
  完成产品所有者的工作后，无需等待 sprint 结束时的 “演示” 即可获得批准。
• Does the actual work:
  实际工作：
  • Coding
    编码
  • All things related to Testing
    与测试有关的所有东西
  • May do environment support
    可以提供环境支持
  • Etc.
    等等。

# Scrum Master 流程管理员

• “Servant leader,” not a project “manager”
  “仆人式领导”，而不是项目 “经理”
• Guide team toward Scrum thinking
  指导团队进行敏捷思维
• Keep team moving in efficient manner
  保持团队高效运作
• Keep team moving as one unit
  使团队保持整体移动
• Impediments
  障碍
  1. Coach team to remove impediments independently
     教练团队独立消除障碍
  2. Actually remove impediments (but avoids this to keep the team thinking “on their own,” and not dependent on the scrum master to the greatest extent.
     实际消除障碍（但要避免这种情况，以使团队保持 “独立思考”，并且在最大程度上不依赖于 Scrum 管理员。
• Must be competent with respect to technology and application.
  在技​​术和应用方面必须胜任​​。
• Ensure team logs hours and expected remaining hours into a software tool like Jira. (to make the burn down chart)
  确保团队将小时数和预期的剩余小时数，记录到 Jira 之类的软件工具中。（制作燃尽图）

# Scrum Masters are “Servant Leaders” 流程管理员是 “仆人式领导者”

Defined 定义

“The servant-leader is a servant first”
“仆人领导首先是仆人”

Mission 任务

Continually “ensuring that other people’s highest priority needs are being served.”
不断 “确保满足其他人的最高优先需求。”

Focus 重点

“… the growth and well-being of people …”
“…… 人们的成长和福祉……”

What is Servant Leadership?

# Scrum Masters are “leaders” not managers 流程管理员是 “领导者” 而不是管理者

A Main Idea of Leadership…
…Leadership is based on a “Vision” of a better tomorrow
领导力的主要思想…… 领导力是对美好明天的 “愿景”

# Leaders … 领导者...

• Inspire trust
  激发信任
• Focus on people
  专注于人
• Have, and share with their team members, the long-range vision
  拥有并与团队成员分享远景
• Associate the “vision” directly to the work the team is performing
  将 “愿景” 直接与团队正在执行的工作相关联

Inspired by Warren Bennis, as originally written in his best selling leadership book: “On Becoming a Leader”
受沃伦・本尼斯（Warren Bennis）的启发，最初写在他最畅销的领导力著作中：“论成为领导者”

# Repositories & User Stories 储存库和用户故事

# 2 User Story Repositories 2 个用户故事存储库

Product backlog 产品积压

• all un-worked User Stories Start Here
  所有未使用的用户故事从这里开始

Iteration backlog 迭代积压

• The team pops work off the top of the prioritized backlog and puts the Uses Stories into the iteration-backlog.
  团队将工作从优先积压的顶部弹出，并将 “使用案例” 放入迭代积压中。
• Team members actually “commit” to the work before placing it in the iteration/sprint backlog.
  团队成员实际上将其 “投入” 到工作中，然后再将其放入迭代 / 冲刺积压中。

# Product backlog 产品积压

• All User Stories start here
  所有用户故事从这里开始
• User Stories that are worked are selected from here, based on their priority, as assigned by the Product Owner.
  根据产品所有者指定的优先级，在这里选择有效的用户故事。
• Low priority User Stories may never get done.
  低优先级的用户故事可能永远不会完成。

# Refining the Backlog 完善积压

• The Team and the Product Owner work together to review and revise it; this is called backlog refinement
  团队和产品负责人一起进行审查和修订；这称为积压细化
• This process happens on a regular basis
  此过程会定期发生
• Product Owner ranks and prioritizes User Stories based
  产品负责人基于用户故事对用户故事进行排名和优先排序
  • organizational vision & mission
    组织愿景与使命
  • customer needs
    客户的需求
  • MoSCow (Must have, Could have, Should have, Won’t have)
  • Duration of User Story, cost of User Story vs. Value (Weighted Shortest Job First - WSJF)
    用户故事的持续时间，用户故事的成本与价值（加权的最短作业优先 - WSJF）

Low priority items may never get done
低优先级项目可能永远无法完成

# Iteration Backlog 迭代积压

• Subset of the Product Backlog
  产品待办事项的子集
• What the Team commits to for this iteration
  团队对此迭代所做的承诺
• Iterations can last 1 week to 2 months, with a preference for shorter Iterations
  迭代可以持续 1 周到 2 个月，但建议使用较短的迭代

# User Stories Content 用户故事内容

VERY IMORTANT – Likely on the Exam

• “As A,” “I Want,” “So That” format
  “作为一个”，“我想要”，“如此” 格式
• Acceptance Criteria (what the product owner will be testing the User Stories for)
  验收标准（产品负责人将测试用户故事的内容）
• Meta data (who created the User Story, the date the User Story was created, the state of the user story, etc.)
  元数据（谁创建了用户素材，创建用户素材的日期，用户素材的状态等）
  • This is how far along in the process the User Story is.
    这是用户故事进行中的过程。
  • As an example (only – the flow will be different in every company): Waiting, investigating, detail design, coding, unit testing, integrated testing, and approved by the Product Owner.
    作为一个示例（仅 – 每个公司的流程将有所不同）：等待，调查，详细设计，编码，单元测试，集成测试，并得到产品负责人的批准。

# Burndown Chart 燃尽图

How to use The Sprint Burndown

# User Stories Observations 用户故事观察

• The duration of a User Story is always less than 1 iteration
  用户故事的持续时间始终小于 1 次迭代
• User stories contain a lot of information
  用户故事包含很多信息
• Refined by the team prior to committing them to an iteration
  在将团队提交迭代之前，由团队进行完善
• Prioritized by the Product Owner
  产品负责人优先

Following the Scrum cycle should be a habit. To learn more about forming habits you can read (optional): The Power of Habit: Why We Do What We Do in Life and Business, January 7, 2014
遵循敏捷周期应该是一种习惯。要了解有关养成习惯的更多信息，您可以阅读（可选）：习惯的力量：我们为什么要在人生和商业中做

# How to decompose User Stories

如何分解用户故事

# Story Points 故事点

• The dev/test team mutually applies a story point estimate to all user stories, especially those that will likely be in the next iteration
  开发 / 测试团队将故事点估计相互应用于所有用户故事，尤其是那些可能在下一次迭代中出现的故事
• A relative sizing of “user stories”
  “用户故事” 的相对大小
• Modified Finocchi sequence: 1,2,3,5,8,13,20,100
  修改后的 Finocchi 序列：1,2,3,5,8,13,20，100

  These numbers are near the official Finocchi sequence numbers, but not exactly.
  这些数字接近于官方 Finocchi 序列号，但不完全相同。

• The idea is from “20” and beyond, the User Stories are so big:
  这个想法来自 “20” 及更高版本，用户故事是如此之大：
  • They should be decomposed
    他们应该分解
  • Rounding the story point value to “20” and ”100” gives the correct impression that the estimate is far from exact.
    将故事点值四舍五入为 “20” 和 “ 100” 会给人以正确的印象，即估计值远非准确。

Here is a great video on story points:
有关故事要点的精彩视频：

4 Things that compose a Story Point 构成故事点的 4 件事

• Relative size based on perceived:
  相对大小基于感知：
  • Effort
    努力
  • Duration
    持续时间
  • Complexity
    复杂
  • Risk
    风险

# Story Points: Why? 故事要点：为什么？

• A history will be created as to how many story points a team actually works iteration over iteration
  将创建一个历史记录，说明一个团队在迭代过程中实际工作的故事点数
• After about 3 iterations, a new scrum team should have a pretty good idea as to how much work they can safely take in, based on story points.
  经过大约 3 次迭代，新的敏捷团队应该基于故事点，对自己可以安全地从事多少工作有一个很好的主意。
• Once a team has an idea of how many story points it can take on during an iteration, this is called “Velocity”
  一旦团队知道在一次迭代中可以处理多少故事点，这就是 “速度”
• Velocity, when used as a maximum amount of story points a team can commit to during an iteration, will keep people working at a sustainable pace, most of the time
  速度，当用作团队在迭代过程中可以承诺的最大故事点时，将使人们在大多数情况下以可持续的速度工作
• Scrum teams are to work at a “sustainable pace.” This means they can see their families because they are not working tons of over time all the time.
  敏捷团队将以 “可持续的速度” 工作。这意味着他们可以看到自己的家人，因为他们一直没有长时间工作。

# INVEST: A criteria for all User Stories所有用户故事的标准

• Independent
  独立
• Negotiable
  面议
• Valuable
  有价值
• Estimable
  估计
• Small (At most, one iteration long)
  小（最多一次迭代）
• Testable
  可测试

# Acceptance Criteria 验收标准

• Part of a User Story
  用户故事的一部分
• Written by Product Owner and refined by the team during “Backlog Refinement”
  由产品负责人撰写，并由团队在 “待办事项细化” 期间进行细化
• Can easily be converted into test-cases
  可以轻松转换成测试用例
• Every User Story has Acceptance Criteria
  每个用户故事都有接受标准

# Metrics 指标

• Commitments made/missed
  作出 / 未履行的承诺
• Story points accepted vs velocity
  故事点被接受与速度
• Velocity trend
  速度趋势
• Scope changes during sprint
  冲刺期间范围的变化
• Resource utilization
  资源利用率
• Defect leakage
  缺陷泄漏

# The Scrum Process 敏捷过程

# Itegration Events 迭代事件

# Demonstration 演示

• Once per iteration
  每次迭代一次
• It is a time to:
  现在是时候：
  • Show off all the completed work to the Product Owner at one time
    一次向产品负责人展示所有已完成的工作
  • Get any last minute approvals
    获得最后一分钟的批准
  • Product owner could get some new ideas
    产品负责人可能会得到一些新的想法
• It is best if the Team holds a practice Demonstration before the actual Demonstration to work out any last minute kinks before the Product Owner sees them at the actual Demonstration
  最好的是，团队在实际演示之前进行一次实践演示，以在产品负责人在实际演示中看到它们之前解决所有最后的纠结。
• This may stimulate new ideas in the Product Owner’s mind.
  这可能会激发产品负责人的新想法。
• Time boxed
  装箱时间

# Daily Standup (DSU) 每日站立

• Daily
  日常的
• Same time
  同时
• Same duration 15 minutes Daily Stand Up + 15 minutes for issues
  持续时间 15 分钟，每日站立时间 + 问题的 15 分钟
• Can schedule to meet at another time for more involved issues
  可以安排在其他时间开会以解决更多相关问题
• The agenda for each person is: “What I did yesterday”/”What I’ll do today”/”Any impediments”
  每个人的议程是：“昨天我做了什么” /“今天我要做什么” /“任何障碍”
• For a face-to-face environment, team members actually stand for the entire DSU
  对于面对面的环境，团队成员实际上代表着整个 DSU
• Keeps everyone up to date as to what the team is doing (transparency)
  使每个人都了解团队的最新动态（透明性）

# Retrospective 回顾

• What went right
  正确的事
• What could be improved next time
  下次有什么可以改善的
• Best if improvement items are within team’s control
  最好的改进项目在团队的控制范围内
• Good focus points: Quality, scope, relationships, commitments (kept and missed), processes, tools etc.
  良好的重点：质量，范围，关系，承诺（保留和遗漏），流程，工具等。
• Should NEVER be used to punish people for mistakes!
  永远不要用来惩罚别人的错误！

# Definition of “Done” & “Done-Done”

• The team defines what done (a complete) user story is, in their social contract. Typically this will mean the coder and tester have completed their work, and the product owner has approved it.
  团队在其社交合同中定义完成的用户故事（完整的故事）。通常，这将意味着编码人员和测试人员已经完成工作，并且产品所有者已经批准了该工作。

  Good Scrum Teams create a “social contract” for themselves. It defines their social norms (how they behave with respect to each other), coding standards, conflict negotiation process, etc.
  优秀的 Scrum 团队会为自己创建一个 “社会契约”。它定义了他们的社会规范（彼此之间的行为方式），编码标准，冲突协商过程等。

• “Done – Done” typically means the User Story was accepted by the product owner, and, delivered into production.
  “完成 - 完成” 通常是指用户故事已被产品所有者接受，并交付生产。

• Typically related to approval of acceptance criteria in User Story by Product Owner
  通常与产品负责人批准用户故事中的验收标准有关

# Scaling Scrum & Kanban

# Scrum of Scrums

• Typically attended by scrum masters (but others are invited as needed)
  通常由 Scrum 主管参加（但根据需要邀请其他人）
• This is the first layer and simplest way to start scaling Scrum.
  这是开始扩展 Scrum 的第一层和最简单的方法。
• Dependencies between Scrum Teams are discussed and resolved
  讨论并解决了 Scrum 团队之间的依赖关系
• Deal with issues that are faced by more than 1 team on an effort
  处理一个以上团队所面临的问题
• Typically weekly or bi-weekly
  通常每周或每两周一次
• Track cross-team impediment resolution
  跟踪跨团队的障碍解决方案

# Scaled Agile Framework (SAFe) 可伸缩的敏捷框架

# Kanban

# What in Jenkins

# What is ScrumBan?