# Agile as a methodology 敏捷方法论
- Practices and processes to accomplish a project
- Agile is a set of methodologies to deliver projects
- Scrum, XP, Kanban, Lean …
# Issues with Waterfall… 瀑布问题
- 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… 什么时候敏捷最有效
- 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
- Task lists
- User stories to be done
# If the team can’t co-locate 如果团队无法共处一室
Use electronic tools and web cameras to keep up with each other.
# Conflict 冲突
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 不确定度锥
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 愿景声明
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 产品路线图
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 线框
- 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 叙事的定义
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
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 渐进式细化
As you continue working on the product it becomes more refined
# Test First Development (TFD) 测试优先开发
- 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 完成的定义
- 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 故事点大小
# Iterations/Sprints 迭代 / 冲刺
迭代 = 冲刺
- 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 持续整合
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 速度
- 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
# Burn Rate 刻录率
How much your agile team costs in a given time period
Useful in budgeting
# Product Backlog 产品积压
- 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”
- Detailed appropriately 适当详细
- Estimable 可估计的
- Emergent (the product backlog changes with time)
# Sprint Backlog 冲刺积压
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 团队关注
“…workers lose about 20% to 40% of their productivity when they multitask.”
“…… 当他们执行多任务时，工人的生产力将损失约 20％至 40％。”
# Refactoring 重构
- 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 信息辐射器
- Information on work completed
- Current and planned sprints
- Progress on User Stories
- Work in progress (WIP)
# Osmotic Communications 渗透通讯
- 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 增量传送
- 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 尖刺
An experiment to determine the correct path forward
# Daily Standups 每日站立会议
- Purpose: team communication and awareness
- 15 minutes long
- 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?
- What did you do yesterday?
# Work in Process (WIP) Limits 进行中的工作的限制
- 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 利益相关者沟通
- 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 团队动力
- 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 谈判：积极聆听
- Listening 倾听
- Understanding 理解
- Retaining 固位
- Active responding 积极回应
Active listening can reduce confusion and team conflict.
# 5 Levels of Conflict 冲突的 5 级
- A problem to solve
- Contest (win-lose mentality)
- Fight or flight (us or them)
- Intractable situation (win at all costs)
# Servant Leadership 仆人领导
- 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.