# Agile as a methodology 敏捷方法论

p.21

• Practices and processes to accomplish a project
  完成项目的实践和流程
• Repeatable
  可重复的
• Agile is a set of methodologies to deliver projects
  敏捷是交付项目的一套方法
• Scrum, XP, Kanban, Lean …
  敏捷，XP，看板，精益……

# Issues with Waterfall… 瀑布问题

p.23

• Projects resist change
  项目抵制变化
• Sometimes the process becomes more important than the project
  有时，过程变得比项目更重要
• Teams can commit to technical solutions too early in the project
  团队可以在项目早期就做出技术解决方案
• Signing off on requirements that are not fully understood
  签署尚未完全理解的需求
• Stakeholders need to wait months to see product
  利益相关者需要等待几个月才能看到产品
• Stakeholders need to wait so long to see product, outcome may not be what is desired
  利益相关者需要等待很长时间才能看到产品，结果可能不是期望的

# About Agile 关于敏捷

p.24 - 26

• Teams can conduct experiments to see what works best (a.k.a. “spikes”)
  团队可以进行实验以查看最有效的方法（又称 “峰值”）
• Team input makes for optimal decisions
  团队投入可做出最佳决策
• Self organizing teams; work is distributed by team consensus rather than authority
  自组织团队；工作是通过团队共识而不是授权来分配的
• Team meets daily (daily standup) to take status
  团队每天开会（每日站立）以取得地位
• Information ”radiators” are posted for all to see
  信息 “散热器” 发布给所有人看
• The team relies on itself to resolve issues
  团队依靠自己来解决问题
• The team embraces change; even late in the project
  团队拥抱变化；甚至在项目后期
• Customers are engaged
  客户参与
• Customers are expected to change their minds
  希望客户改变主意
• Small frequent releases
  少量频繁发布
• Customers have fast access to working deliverables
  客户可以快速访问可交付成果
• Retrospectives allow for the team to improve iteration to iteration
  回顾使团队能够不断改进迭代

# When Agile works best… 什么时候敏捷最有效

p. 27

• Complex decision making is required
  需要复杂的决策时

# The AgileManifesto.org 敏捷软件开发宣言

• Individuals and interactions over processes and tools
  个体和互动 高于 流程和工具
• Working software over comprehensive documentation
  工作的软件 高于 详尽的文档
• Customer collaboration over contract negotiation
  客户合作 高于 合同谈判
• Responding to change over following a plan
  响应变化 高于 遵循计划

While there is value in the items on the right, we value the items on left more
(you will need to memorize these)
尽管右侧的项目有价值，但我们更重视左侧的项目（你需要记住这些）

# Principle 1: (p. 47)

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

Comment: Agile teams get software into the hands of clients quickly and work if prioritized by the client.
敏捷团队可以快速将软件交付客户，并在客户优先考虑的情况下进行工作。

# Principle 2: (p. 48)

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

Comment: Agile expects that requirements will change and that the team will welcome the changes as a way to obtain competitive advantage.
敏捷期望需求将改变，并且团队将欢迎这些改变，以获取竞争优势。

# Principle 3: (p. 48)

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

Comment: The point is to get working product into customer’s hands as soon as possible to get feedback as soon as possible.
关键是尽快将工作产品移交给客户，以尽快获得反馈。

# Principle 4: (p. 49)

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

Comment: Business representatives are typically included in meetings, and when possible they are in the same physical space as the development team.
业务代表通常包括在会议中，并且在可能的情况下，他们与开发团队在同一物理空间中。

# Principle 5: (p. 49)

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

Comment: Self explanatory
自我解释

# Principle 6: (p. 50)

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

Comment: In general, the entire team team has access to all conversations. “Osmotic communication” is where team members informally overhear each other's conversations and learn from them.
通常，整个团队都有权访问所有对话。“渗透交流” 是团队成员非正式地互相听取对方的对话并向他们学习的地方。

# Principle 7: (P. 50)

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

Comment: Some teams become so obsessed with documentation it overshadows the product’s software.
有些团队对文档如此着迷，以至于使该产品的软件黯然失色。

# Principle 8: (p. 51)

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

Comment: this avoids burnout and exhaustion. It supports working at an optimal pace.
这可以避免倦怠和疲惫。它支持以最佳速度工作。

# Principle 9: (p. 51)

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

Comment: Self explanatory
自我解释

# Principle 10: (p. 51)

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

Comment: keeping things simple is essential.
使事情保持简单是必不可少的。

# Principle 11: (p. 52)

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

Comment: self explanatory.
自我解释。

# Principle 12: (p. 52)

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

Comment: this is called the retrospective. It is held at the end of each sprint.
这称为回顾。它保存在每个冲刺的末尾。

# The Project Charter 项目章程

p. 58 - 59

• The project charter is required, even in Agile development
  即使在敏捷开发中，也需要项目章程
• The project charter is to be written in iteration zero
  项目章程将以零迭代的形式编写
• It is written before work starts
  它是在工作开始之前写的
• It should define the “need”
  它应该定义 “需求”
• Senior management needs to sign it
  高级管理人员需要签署
• It provides authority to assign resources to the project
  它提供向项目分配资源的权限
• It should provide critical success factors
  它应该提供关键的成功因素
• The preliminary budget should be provided.
  应提供初步预算。

# Team culture… 团队文化

p. 63 - 64

• Mid 1990’s it became more common to have teams determine what to do and how to do it.
  在 1990 年代中期，让团队确定做什么和如何做变得越来越普遍。
• All team members are collectively responsible for everything
  所有团队成员共同为一切负责
• Optimal team size is 7 +/- 2
  最佳团队人数为 7 +/- 2

# Team Space 团队空间

p. 65 - 67

• Best when teams are co-located
  团队共处一地的最佳选择
• Best when team members can see and interact with each other
  团队成员可以看到彼此并进行交互的最佳方法
• Best when headphones are NOT allowed
  不允许戴耳机时的最佳选择
• Information radiators should be obvious to the team
  信息传递者对团队来说应该是显而易见的

# Some information on information radiators…

有关信息辐射器的一些信息…

• Feature lists
  功能列表
• Backlogs
  积压
• Task lists
  任务清单
• User stories to be done
  要完成的用户故事
• Schedules
  日程安排
• Etc.

# If the team can’t co-locate 如果团队无法共处一室

p. 69

Use electronic tools and web cameras to keep up with each other.
使用电子工具和网络摄像头彼此保持同步。

# Conflict 冲突

p. 64

Some wise coaches and scrum masters will encourage conflict to get the team to think
一些明智的教练和 Scrum Master 会鼓励冲突，以使团队思考

# Empowered Teams 授权团队

p. 70 - 71

“In order to build a properly empowered team it is important to have the customer and/or product owner co-located with the team.”
“为了组建一支拥有适当权力的团队，让客户和 / 或产品所有者与团队共处一处很重要。”

Empowered means that team members are able to make decisions and carry out those decisions in their work.
授权意味着团队成员能够做出决定并在工作中执行那些决定。

• Organizational buy-in
  组织买进
• Alignment with corporate goals
  与企业目标保持一致
• Shared vision
  共同的愿景
• Clear communication
  清晰的沟通
• Customer involvement
  客户参与
• Team accountability to the goals they set for themselves
  团队对自己设定的目标负责

# The Cone of Uncertainty 不确定度锥

Wikipedia

Cone of Uncertainty describes the evolution of the amount of best case uncertainty during a project. At the beginning of a project, comparatively little is known about the product or work results, and so estimates are subject to large uncertainty. As more research and development is done, more information is learned about the project, and the uncertainty then tends to decrease, (until the project is complete).
不确定度锥，描述了项目中最佳案例不确定性量的演变。在项目开始时，对产品或工作结果知之甚少，因此估计值存在很大的不确定性。随着更多的研究和开发完成，有关该项目的更多信息将被了解，不确定性趋于减少（直到项目完成）。

# The Vision Statement 愿景声明

p. 82

• The vision statement is one of the first things a product owner typically develops for the team
  愿景声明是产品所有者通常为团队开发的第一批内容之一

• It is a short statement about the product the team is delivering
  这是有关团队交付的产品的简短说明

• What it is, who needs it, the key features, and why it is different than other offerings in the marketplace.
  它是什么，谁需要它，关键功能以及为什么它与市场上的其他产品不同。

# The Product Roadmap 产品路线图

p. 83

• An overview of what features will be delivered in what sprints.
  概述将在哪些推进中提供哪些功能。

• It is flexible and subject to change
  灵活易变

• It may span months or years
  可能跨越数月或数年

# Wireframes 线框

p. 85

• Quick low tech diagram of how user will interact with the system
  用户如何与系统进行交互的快速入门技术图
• Gives the team and the product owner a starting point to understand what is wanted
  为团队和产品负责人提供一个起点，让他们了解需要的东西

# Epic defined 叙事的定义

p. 86

• Large chunk of functionality that typically spans across multiple sprints
  通常跨多个冲刺的大量功能

• Broken down into user stroies
  细分为用户故事

# User Stories; small/compact requirements

用户故事；小 / 紧凑的要求

• As A/I want/So that
  正如我 / 我想要的 / 所以
• Acceptance criteria
  验收标准
• Meta data
  元数据
• INVEST

# INVEST

p. 88 - 89

Independent 独立的

don’t overlap with other user stories
不要与其他用户故事重叠

Negotiable 可商量的

Expected to change through collaboration
预期通过协作改变

Valuable 有价值的

Must be written in a way that it can be prioritized against other user stories
必须在某种程度上被写入，它可以优先于其他用户故事

Estimable 可估计的

The team must be able to ascertain enough information from the User Story to estimate it
团队必须能够从用户故事确定足够的信息来估计它

Small 小的

User Stories must fit within one sprint
用户故事必须在一次冲刺中

Testable 可测试的

Must have sufficient acceptance criteria
必须有足够的验收标准

# Progressive Elaboration 渐进式细化

p. 92

As you continue working on the product it becomes more refined
随着您继续研究产品，它会变得更加精致

# Test First Development (TFD) 测试优先开发

p. 93

• Write test cases first
  首先编写测试用例
• Code to meet test case requirements one at a time
  一次满足测试用例需求的代码
• Test cases should be stated in a way that they are met OR not met
  测试用例应以符合或不符合的方式陈述

# Definition of Done 完成的定义

p. 95

• This should be in the team charter
  这应该在团队章程中
• May be tied to acceptance of test cases by product owner or any combination of standards a team sets for itself
  可能与产品所有者接受测试用例或团队自行设定的标准组合有关

# Story Point Sizing 故事点大小

• Effort
  努力
• Duration
  持续时间
• Risk
  风险
• Complexity
  复杂

# Iterations/Sprints 迭代 / 冲刺

p. 101

• Iteration=sprint
  迭代 = 冲刺
• Sprints are typically 2-3 weeks
  冲刺通常为 2-3 周
• When you bundle sprints that support a single product, it is called a release
  当您捆绑支持单个产品的冲刺时，称为发行版
• Sprints, once established, are of a fixed duration
  冲刺一旦建立，其持续时间是固定的

# Time Boxing 时间拳击

• Parkinson’s law states work takes the time you give it.
  帕金森定律指出，工作需要花费时间。

• Therefore, Daily Standups take 15 minutes and sprints are time-bound
  因此，每日站立训练需要 15 分钟，并且冲刺是有时间限制的

# Continuous Integration 持续整合

p. 104

• Code changes are checked in as often as possible
  尽可能经常检查代码更改

• This allows for testing of the system and fast delivery of product to the market place.
  这允许对系统进行测试，并将产品快速交付市场。

# Velocity 速度

pp. 106-107

• The number of story points a team will deliver per sprint
  团队将为每个冲刺提供的故事点数
• Velocity should increase as time passes
  速度应随着时间的流逝而增加
• If velocity goes up too fast, this might mean the team is no longer working at a sustainable pace
  如果速度上升太快，则可能意味着团队不再以可持续的速度工作
• When accepting work into the sprint backlog, velocity is the cap on story points you can accept.
  当接受冲刺积压的工作时，速度就是您可以接受的故事点的上限。
• Velocity is NOT comparable between scrum teams
  Scrum 团队之间的速度不可比

# Burn Rate 刻录率

p. 109

• How much your agile team costs in a given time period
  您的敏捷团队在给定时间段内要花费多少

• Useful in budgeting
  在预算编制中很有用

# Product Backlog 产品积压

p. 109

• Warehouse of User Stories the team has scheduled
  团队已安排的用户故事仓库
• Prioritized by value to the business by the product owner
  产品所有者按价值优先考虑业务
• When the team reviews the Product Backlog with the product owner to improve the User Stories, this is called product backlog refinement
  当团队与产品负责人一起审查产品待办事项清单以改善用户故事时，这称为产品待办事项清单提炼

# Product Backlogs should be “DEEP”

产品待办事项列表应为 “DEEP”
pp. 109-110

• Detailed appropriately 适当详细
• Estimable 可估计的
• Emergent (the product backlog changes with time)
  紧急（产品积压随时间变化）
• Prioritized
  按重要性排列，优先处理

# Sprint Backlog 冲刺积压

p. 110

• The team takes work off of the top of the prioritized product backlog and commits to it for the current sprint.
  团队从优先产品待办事项列表的顶部删除工作，并针对当前的冲刺进行承诺。

• The size of the sprint backlog should NOT exceed established velocity
  冲刺积压的大小不应超过既定速度

# Team Focus 团队关注

p. 111
“…workers lose about 20% to 40% of their productivity when they multitask.”
“…… 当他们执行多任务时，工人的生产力将损失约 20％至 40％。”

# Refactoring 重构

p. 113

• Fixing up code when it was written in haste or not to standards.
  在匆忙编写代码或不按标准编写代码时进行修复。
• Regression test refactored code to make sure it still works as expectetd
  回归测试重构代码，以确保其仍能按预期工作

# Information Radiators 信息辐射器

p. 114

• Information on work completed
  有关工作的信息
• Current and planned sprints
  当前和计划的冲刺
• Progress on User Stories
  用户故事的进展
• Work in progress (WIP)
  进行中的工作（WIP）
• Etc.

# Osmotic Communications 渗透通讯

p. 114

• When you are co-located you will overhear valuable conversations.
  当您在同一地点时，您会听到宝贵的谈话。
• Good for sharing culture, best practices, and helping new members acclimate
  非常适合分享文化，最佳做法，并帮助新成员适应环境

# Burndown Chart 燃尽图

Publicly available charts that display ideal progress vs. actual work remaining.
可公开显示图表，显示理想进度与实际剩余工作量。

# Scrum Vs. Kanban

# Incremental Delivery 增量传送

p. 120

• Gets software into the hands of customers quickly
  快速将软件交付客户
• Allows for prototyping like behaviors
  允许进行类似行为的原型制作
• Allows the team to gain valuable knowledge and feedback about deliverables
  使团队能够获得有关可交付成果的宝贵知识和反馈
• Most valuable software gets out the door first.
  最有价值的软件会首先发布。

# Spikes 尖刺

p. 122

An experiment to determine the correct path forward
进行实验以确定正确的前进方向

# Daily Standups 每日站立会议

p. 128

• Purpose: team communication and awareness
  目的：团队沟通和意识
• Daily
  日常的
• 15 minutes long
  15 分钟长
• Same time and place each day
  每天相同的时间和地点
• Entire project team attends (and not others)
  整个项目团队都参加了（其他人没有参加）
• Questions 问题
  • What did you do yesterday?
    你昨天做了什么？
  • What do you plan to do today?
    您今天打算做什么？
  • Any impediments you are facing?
    您面临任何障碍吗？

# Work in Process (WIP) Limits 进行中的工作的限制

p. 132

• Sets a cap on work in progress for a specific type of work
  为特定类型的工作设定进行中的上限
• The team sets the limit for each type of work
  团队为每种工作设定极限
• This actually speeds up work
  这实际上加快了工作速度
• Work is pulled from the previous swim lane when work in a swim lane is not up to the WIP limit.
  当泳道中的工作未达到 WIP 限制时，工作将从先前的泳道中拉出。
• This is the idea of the Kanban board
  这是看板委员会的想法

# Stakeholder Communication 利益相关者沟通

p. 133-135

• Stakeholders should be identified and the best method to communicate with them should be identified
  应当确定利益相关者，并确定与他们进行交流的最佳方法
• Transparent communication is expected
  期望透明的沟通
• Involve the appropriate stakeholders when the project is in trouble
  项目遇到问题时，请适当的利益相关者参与
• But, stakeholders and their expectations must be managed
  但是，利益相关者及其期望必须得到管理

# Team Motivation 团队动力

p. 135-136

• Sustained high performance is the goal
  持续的高性能是目标
• Support: when the right people are involved in the project from the start
  支持：从一开始就让合适的人参与项目
• Team Participation: everyone’s contribution is valued
  团队参与：每个人的贡献都得到重视
• Ground rules: write them, shared them, and get agreement from the team on them
  基本规则：编写，共享，并征得团队的同意
• Team Performance Visibility: team members must see how their contributions contribute to the team’s overall success.
  团队绩效可见性：团队成员必须了解他们的贡献如何为团队的整体成功做出贡献。

# Negotiation: Active Listening 谈判：积极聆听

p. 139

• Listening 倾听
• Understanding 理解
• Retaining 固位
• Active responding 积极回应

Active listening can reduce confusion and team conflict.
积极倾听可以减少混乱和团队冲突。

# 5 Levels of Conflict 冲突的 5 级

pp. 141-142

• A problem to solve
  要解决的问题
• Disagreement
  意见分歧
• Contest (win-lose mentality)
  比赛（输赢心态）
• Fight or flight (us or them)
  战斗或逃跑（我们或他们）
• Intractable situation (win at all costs)
  棘手的情况（不惜一切代价取胜）

# Servant Leadership 仆人领导

p. 143

• The team leader needs to be “hands on” (engaged in the daily work)
  团队负责人需要 “动手”（参与日常工作）
• The team leader needs to model agile behavior
  团队负责人需要对敏捷行为进行建模
• They are typically co-located with their teams
  他们通常与团队位于同一地点
• They are a servant to the team first and a leader second.
  他们首先是团队的仆人，其次是领导者。