Scrum 实践.

Presentation on theme: "Scrum 实践."— Presentation transcript:

1 Scrum 实践

2 感谢 Dong Shao

3 敏捷价值观之敏捷宣言 个体与交互 重于 过程和工具 可用的软件 重于 完备的文档 客户协作 重于 合同谈判 响应变化 重于 遵循计划
个体与交互 重于 过程和工具 可用的软件 重于 完备的文档 客户协作 重于 合同谈判 响应变化 重于 遵循计划 来源：

4 什么是Scrum 一个轻量级的软件开发方法
Scrum是一个敏捷开发框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发周期包括若干个小的跌代周期，每个小的的跌代周期称为一个Sprint，每个Sprint的建议长度2到4周。 在Scrum中，使用产品Backlog来管理产品或项目的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum的开发团队总是先开发的是对客户具有较高价值的需求。在每个Sprint中，Scrum开发团队从产品Backlog中挑选最有价值的需求进行开发。 Sprint中挑选的需求经过Sprint计划会议上的分析、讨论和估算得到一个Sprint的任务列表，我们称它为Sprint backlog 。 在每个迭代结束时，Scrum团队将交付潜在可交付的产品增量。

5 一个简单的框架

6 Sprints Scrum的项目过程有一系列的Sprint组成。 Sprint的长度一般控制在2-4周，推荐3周。
通过固定的周期保持良好的节奏。 产品的设计、开发、测试都在Sprint期间完成。 Sprint结束时交付可以工作的软件。 在Sprint过程中不允许发生变更。

7 Scrum框架

8 Scrum角色之产品负责人 产品负责人（Product Owner）的职责如下： 确定产品的功能。 决定发布的日期和发布内容。
为产品的profitability of the product (ROI)负责。 根据市场价值确定功能优先级。 每个Sprint，根据需要调整功能和优先级（每个Sprint开始前调整）。 接受或拒绝接受开发团队的工作成果。 Product Owner参与Scrum planning。

9 Scrum角色之ScrumMaster 作为Team Leader和Product owner紧密地工作在一起，他可以及时地为团队成员提供帮助。 他必须: 保证团队资源完全可被利用并且全部是高产出的。 保证各个角色及职责的良好协作。 解决团队开发中的障碍。 做为团队和外部的接口，屏蔽外界对团队成员的干扰。 保证开发过程按计划进行，组织 Daily Scrum, Sprint Review and Sprint Planning meetings。

10 Scrum角色之团队 一般情况人数在5-9个左右，最好7人 团队要跨职能 （包括开发人员、测试人员、用户界面设计师等）
团队成员需要全职。（有些情况例外，比如数据库管理员） 在项目范围内有权利做任何事情已确保达到Sprint的目标。 高度的自我组织能力。 向Product Owner演示产品功能。 团队成员构成在sprint内不允许变化。

11 产品Backlog

12 The Product Backlog

13 Good Requirements (see http://www.pragmaticmarketing.com/)
Necessary Concise (minimal, understandable). Implementation free. Attainable (achievable or feasible). Complete (standalone). Consistent. Unambiguous. Verifiable. [i] “Characteristics of Good Requirements” by Pradip Kar and Michelle Bailey, given at the 6th INCOSE Symposium. Available at

14 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.

15 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.

16 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.

17 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 技术故事 技术故事或非功能性条目。 例如： 安装持续集成服务器 设计系统架构，编写系统设计概览 设计系统统一风格的界面。

19 Story -> Task 故事是可以交付的东西，是产品负责人所关心的。任务是不可交付的东西，产品负责人对它不关心。
将Story分解为Task后，对Story进行估算会更加容易，并更准确！

20 不将任务拆分放在产品backlog中： 1、任务拆分的随机性比较强，在sprint中经常会发生变化。 2、产品负责人不需要关心这种程度的细节。

21 Sprint计划会议

22 Sprint计划会议 估算：Story时间 vs 团队时间 团队从产品backlog中挑选他们承诺完成的条目。
创建Sprint Backlog 选择产品Backlog中条目，标识其具体的任务并为任务做估算 由团队协作完成,而不是Scrum Master 考虑了高层设计 Scrum中任何事情都有时间盒 一个迭代周期将其中的story完全做完！达到可以交付的状态。

23 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.

24 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. The consequence of the time box is that there will be inaccuracy.

25 使用计划纸牌做时间估算 每个成员都会参与所有故事的估算。 计划纸牌

26 The Sprint Backlog

27 计划会议产物 1、sprint目标和演示日期。 2、经过团队认可、要添加到这个sprint中的故事列表。 3、每个故事的估算值。
4、每个故事如何演示。 5、生产率和资源计算。每个人承诺的工作量。 6、明确每日例会的时间地点。 7、把故事拆分成任务。

28 让别人了解我们的sprint,信息页

29 工作环境 让团队坐在一起！ 互相听到 互相看到

30 每日例会 站立会议，少于15分钟 更新任务板 三个问题

31 1 2 3 团队成员需要回答3个问题 昨天你做了什么? 今天你将要做什么? 你有需要帮助的地方吗?
对于 ScrumMaster来说这些问答不是工作进度报告 他们是团队成员彼此的承诺

32 开发！

33 几天以后

34 技术架构与界面 最高优先级任务：形成一个端到端运行的系统，能够进行持续集成。 形成团队成员共同认可的技术架构（以后可以修改）。
如果界面工作由多人承担，首先设计相应整体导航界面，作为第一个迭代的一部分。

35 持续集成 使用集成工具(Ant)进行自动化集成。 团队一个成员负责配置管理与集成。
每个人要养成工作前update，测试后commit的工作习惯。

36 编码规范 http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
代码静态检查工具 checkstyle

37 结对编程 所有的活动（设计，开发，文档）都是两个人共同完成的。
两个人用一台机器，一个人控制键盘鼠标，进行实际工作（driver），另外一个人进行策略性思考（navigator）。 可以互换。

38 TDD 先写测试，后写代码。 单元测试工具。
测试驱动开发意味着你要先写一个自动测试，然后编写恰好够用的代码，让它通过这个测试，接着对代码进行重构，主要是提高它的可读性和消除重复。整理一下，然后继续。

39 简单设计与重构 Simple design Refactor
"Do the Simplest Thing that Could Possibly Work" YAGNI: You Aren't Going to Need It" Refactor Bad smell Design time

40 Scrum仪式之Sprint评审会议 Sprint评审会用来演示在这个Sprint中开发的产品功能给Product Owner. Produc Owner会组织 这阶段的会议并且邀请相关的干系人参加。 团队展示Sprint中完成的功能 一般是通过现场演示的方式展现功能和架构 不要太正式 不需要PPT 一般控制在2个小时 团队成员都要参加 可以邀请所有人参加

41 Sprint回顾 Good：如果我们可以重做同一个sprint，哪些做法可以保持。
Could have done better: 哪些做法需要改变。 Improvement：有关奖励如何改进的具体想法。

42 reference http://www.goodagile.com/