02-Scrum实践

advertisement
感谢

Dong Shao
敏捷价值观之敏捷宣言
 个体与交互
重于 过程和工具
 可用的软件 重于 完备的文档
 客户协作
重于 合同谈判
 响应变化
重于 遵循计划

来源:www.agilemanifesto.org
什么是Scrum

一个轻量级的软件开发方法
 Scrum是一个敏捷开发框架,是一个增量的、迭代的开
发过程。在这个框架中,整个开发周期包括若干个小的
跌代周期,每个小的的跌代周期称为一个Sprint,每个
Sprint的建议长度2到4周。
 在Scrum中,使用产品Backlog来管理产品或项目的需求,
产品backlog是一个按照商业价值排序的需求列表,列表
条目的体现形式通常为用户故事。Scrum的开发团队总
是先开发的是对客户具有较高价值的需求。在每个
Sprint中,Scrum开发团队从产品Backlog中挑选最有价
值的需求进行开发。
 Sprint中挑选的需求经过Sprint计划会议上的分析、讨论
和估算得到一个Sprint的任务列表,我们称它为Sprint
backlog 。 在每个迭代结束时,Scrum团队将交付潜在
可交付的产品增量。
一个简单的框架
Sprints
 Scrum的项目过程有一系列的Sprint组成。
 Sprint的长度一般控制在2-4周,推荐3周。
 通过固定的周期保持良好的节奏。
 产品的设计、开发、测试都在Sprint期间
完成。
 Sprint结束时交付可以工作的软件。
 在Sprint过程中不允许发生变更。
Scrum框架
Scrum角色之产品负责人
 产品负责人(Product
Owner)的职责如
下:
 确定产品的功能。
 决定发布的日期和发布内容。
 为产品的profitability of the product (ROI)负
责。
 根据市场价值确定功能优先级。
 每个Sprint,根据需要调整功能和优先级(每个
Sprint开始前调整)。
 接受或拒绝接受开发团队的工作成果。
○ Product Owner参与Scrum planning。
Scrum角色之ScrumMaster
 作为Team
Leader和Product owner紧密地
工作在一起,他可以及时地为团队成员提
供帮助。 他必须:
 保证团队资源完全可被利用并且全部是高产出




的。
保证各个角色及职责的良好协作。
解决团队开发中的障碍。
做为团队和外部的接口,屏蔽外界对团队成员
的干扰。
保证开发过程按计划进行,组织 Daily Scrum,
Sprint Review and Sprint Planning meetings。
Scrum角色之团队
 一般情况人数在5-9个左右,最好7人
 团队要跨职能
(包括开发人员、测试人员、
用户界面设计师等)
 团队成员需要全职。(有些情况例外,比
如数据库管理员)
 在项目范围内有权利做任何事情已确保达
到Sprint的目标。
 高度的自我组织能力。
 向Product Owner演示产品功能。
 团队成员构成在sprint内不允许变化。
产品Backlog
11
The Product Backlog
Good Requirements
(see http://www.pragmaticmarketing.com/)








Necessary
Concise (minimal, understandable).
Implementation free.
Attainable (achievable or feasible).
Complete (standalone).
Consistent.
Unambiguous.
[i] “Characteristics of Good Requirements” by
Pradip Kar and Michelle Bailey, given at the 6th
Verifiable.
INCOSE Symposium. Available at
http://www.complianceautomation.com
Good Requirements
(see http://www.pragmaticmarketing.com/)


Necessary. The stated requirement is an essential
capability, physical characteristic, or quality factor of the
product or process. If it is removed or deleted, a
deficiency will exist, which cannot be fulfilled by other
capabilities of the product or process.
Concise (minimal, understandable). The requirement
statement includes only one requirement stating what
must be done and only what must be done, stated
simply and clearly. It is easy to read and understand.
Good Requirements
(see http://www.pragmaticmarketing.com/)


Implementation free. The requirement states what is
required, not how the requirement should be met. A
requirement statement should not reflect a design or
implementation nor should it describe an operation.
However, the treatment of interface requirements is
generally an exception.
Attainable (achievable or feasible). The stated
requirement can be achieved by one or more developed
system concepts at a definable cost. This implies that at
least a high level conceptual design has been
completed and cost tradeoff studies have been
conducted.
Good Requirements
(see http://www.pragmaticmarketing.com/)
Complete (standalone). The stated
requirement is complete and does not need
further amplification. The stated requirement will
provide sufficient capability.
 Consistent. The stated requirement does not
contradict other requirements. It is not a
duplicate of another requirement. The same
term is used for the same item in all
requirements.

Good Requirements
(see http://www.pragmaticmarketing.com/)
Unambiguous. Each requirement must have
one and only one interpretation. Language used
in the statement must not leave a doubt in the
reader's mind as to the intended descriptive or
numeric value.
 Verifiable. The stated requirement is not vague
or general but is quantified in a manner that can
be verified through inspection, analysis,
demonstration or test.

技术故事
技术故事或非功能性条目。
 例如:

 安装持续集成服务器
 设计系统架构,编写系统设计概览
 设计系统统一风格的界面。
18
Story -> Task
•故事是可以交付的东西,是产品负责人所关心的。任务是
不可交付的东西,产品负责人对它不关心。
•将Story分解为Task后,对Story进行估算会更加容易,并
更准确!
19
不将任务拆分放在产品backlog中:
1、任务拆分的随机性比较强,在sprint中经常会发生变化。
2、产品负责人不需要关心这种程度的细节。
20
Sprint计划会议
Sprint计划会议



估算:Story时间 vs 团队时间
团队从产品backlog中挑选他们承诺完成的条
目。
创建Sprint Backlog
 选择产品Backlog中条目,标识其具体的任务并为任
务做估算
 由团队协作完成,而不是Scrum Master



考虑了高层设计
Scrum中任何事情都有时间盒
一个迭代周期将其中的story完全做完!达到可
以交付的状态。
22
Segment One: Four Hours
The Product Owner selects the ideal
backlog for the coming Sprint and
communicates its meaning and
importance to the team.
 Chickens may be invited to provide
clarification, but they are immediately
dismissed.
 Team may ask questions.

Segment Two: Four Hours
The Team decides how much it can
commit to delivering in the coming Sprint.
 The Product Owner answers questions
but does not direct the team’s choices.
No chickens allowed.
 The outcome is the Sprint Backlog.

使用计划纸牌做时间估算
每个成员都会参与所有故事的估算。
 计划纸牌

25
The Sprint Backlog
计划会议产物







1、sprint目标和演示日期。
2、经过团队认可、要添加到这个sprint中的
故事列表。
3、每个故事的估算值。
4、每个故事如何演示。
5、生产率和资源计算。每个人承诺的工作
量。
6、明确每日例会的时间地点。
7、把故事拆分成任务。
27
让别人了解我们的sprint,信息
页
28
工作环境

让团队坐在一起!
 互相听到
 互相看到
29
每日例会

站立会议,少于15分钟
更新任务板

三个问题

30
团队成员需要回答3个问题
昨天你做了什么?
今天你将要做什么?
你有需要帮助的地方吗?

1
2
3
对于 ScrumMaster来说这些问答不是工作进
度报告
 他们是团队成员彼此的承诺
开发!
32
几天以后
33
技术架构与界面
最高优先级任务:形成一个端到端运行的
系统,能够进行持续集成。
 形成团队成员共同认可的技术架构(以后
可以修改)。
 如果界面工作由多人承担,首先设计相应
整体导航界面,作为第一个迭代的一部
分。

34
持续集成
使用集成工具(Ant)进行自动化集成。
 团队一个成员负责配置管理与集成。
 每个人要养成工作前update,测试后
commit的工作习惯。

35
编码规范
http://java.sun.com/docs/codeconv/html/
CodeConvTOC.doc.html
 代码静态检查工具
 checkstyle

36
结对编程
所有的活动(设计,开发,文档)都是两
个人共同完成的。
 两个人用一台机器,一个人控制键盘鼠标,
进行实际工作(driver),另外一个人进
行策略性思考(navigator)。
 可以互换。

37
TDD
先写测试,后写代码。
 单元测试工具。
 测试驱动开发意味着你要先写一个自动测
试,然后编写恰好够用的代码,让它通过
这个测试,接着对代码进行重构,主要是
提高它的可读性和消除重复。整理一下,
然后继续。

38
简单设计与重构

Simple design
 "Do the Simplest Thing that Could Possibly
Work"
 YAGNI: You Aren't Going to Need It"

Refactor
 Bad smell
 Design time
39
Scrum仪式之Sprint评审会议



Sprint评审会用来演示在这个Sprint中开发的产品功能
给Product Owner. Produc Owner会组织 这阶段的会
议并且邀请相关的干系人参加。
团队展示Sprint中完成的功能
一般是通过现场演示的方式展现功能和架构
 不要太正式
 不需要PPT
 一般控制在2个小时
团队成员都要参加
 可以邀请所有人参加

40
Sprint回顾
Good:如果我们可以重做同一个sprint,
哪些做法可以保持。
 Could have done better: 哪些做法需要改
变。
 Improvement:有关奖励如何改进的具体
想法。

41
reference
http://www.goodagile.com/
 http://www.mountaingoatsoftware.com/
 http://www.scrumcn.com/
 http://www.infoq.com

42
Download