Scrum上路

《硝烟中的 Scrum 和 XP 》导读

Scrum 是一味药，仅此而已
硝烟中的 Scrum— 从哪里开始
我们才刚上路

药？还是良好的生活习惯？

Scrum 不能解决我们的问题，能解决问题的是我们自己
一支出色团队靠的不是技术，不是流程，而是有良好素质的团队成员。良好素质包括进取心、责任心、良好的习惯、热情……
Scrum 提供了一套实践方法，帮软件团队养成良好的习惯
好吧，如果这样说有点空洞，让我们走进一步看

药名： Scrum
种类：敏捷软件开发方法
适用症：
重量级流程导致的软件开发环节复杂
面向任务、面向职责的开发模式导致的各司其职、流程环节衔接不畅，项目进度的掌控困难
以上两条导致的项目 / 产品开发周期过长
药物原理：
目标驱动，在统一的软件交付目标下组织团队
依靠团队的智慧做项目评估、计划乃至设计、开发、测试
抓住最基本的项目开发属性：周期 + 质量

软件开发周期与质量的关系
资源一定的情况下，软件开发周期跟质量相互制约，但不是反比
以 T 代表某个项目的开发时间， B 代表项目的 Bug 数（类比质量），不同团队执行该项目的 T*B 值是一个区间
良好团队就是尽可能保证 T*B 的值尽量小，挖掘可能空间的潜值
Scrum 有助于塑造良好团队，降低项目的 T*B 值

我们才刚上路

Scrum 角色和职责
产品负责人 – 定义开发目标，需要实现的 feature 和优先级
Scrum Master – 保证团队高效而不受打扰地工作，优化工作条件、过程
团队 – 自组织地完成项目开发，使用一切可行手段保证进度和质量

Scrum 过程
前期：产品负责人整理业务需求，形成 Product Backlog 库
执行：以 Sprint 为单位迭代式地完成 Sprint Backlog 。每个 Sprint 以 Sprint Planning 开始，通过每日例会跟踪进度和 issue 。 Sprint 结束时交付可运行的产品
后期：每个 Sprint 完成后，通过 Sprint 回顾发现问题和改进点，制定下个 Sprint 要引入的新的实践

看上去没什么特别？别着急，我们来看 Scrum 的精髓 ----
Scrum 是一个“检查并适应”的框架，在三个角色（产品负责人 /Scrum Master/ 团队）、三种仪式（ Sprint 计划 /Sprint 回顾 / 每日例会）和三种制品（产品 Backlog/Sprint Backlog/ 燃尽图）的基础上，你可以根据公司或者项目的情况，因地制宜引入任何有利于缩短开发周期、提高产品质量的实践

XX 部门这样实施 Scrum—Sprint 前
产品负责人（ PM ）收集整理产品需求，形成产品 Backlog
产品 Backlog 按照统一格式定义，比较重要属性有：名称、重要性、估算时间、简单描述、如何演示等，详细的需求细节可以在其他需求文档中定义
产品负责人可以通过任何渠道、方式获取和确认需求

XX 部门这样实施 Scrum—Sprint
产品负责人、 Scrum Master 和团队成员（包括 QA ）召开 Sprint 会议， Scrum Master 主持会议
Sprint 会议上详细沟通产品负责人选定的重要性高的产品 Backlog 细节，确保团队对需求的理解无误
团队就对需求的理解将 Backlog 拆分成任务，并给出每个 Backlog 的估算时间
产品负责人和团队根据 Sprint 内可用的人天和 Backlog 的时间估算，选定需要排入本次 Sprint 的 Backlog
Scrum Master 和团队分派任务，制定 Sprint 计划
一个 Sprint 的周期是两周；一次 Sprint 会议时间大约一个下午

整理一面任务墙，将 Sprint 内的 Backlog 和任务按照未开始、进行中、已完成等状态进行归类；同时展示 Sprint 的燃尽图
Scrum Master 每日早上固定时间组织团队的每日例会，确认每个成员前一天完成的工作、当天要进行的工作、工作中碰到的 issue ，并更新任务墙
任何需求变更都进行实时评估，超过规划人天的 Backlog 视情况进行拆分或者推迟其他重要性低的 Backlog
任何完成的 Backlog 都需要演示给产品负责人和 QA 后才能提交测试

任务墙快照

XX 部门这样实施 Scrum—Sprint 后
Scrum Master 召集、组织 Sprint 回顾会议
回顾会议以头脑风暴的方式 Review Sprint 过程和结果，发现和列举存在的问题
与会人员投票决定需要在下个 Sprint 中解决的 1-3 个问题，探讨解决方案，确定实践方式

XX 部门这样实施 Scrum— 归纳用到的实践
实践参与角色目的 / 好处注意事项 Backlog 产品负责人以简单的、面向目标的方式描述需求愿景比需求细节更重要，团队需要知道为什么做而不光是做什么 Sprint 会议产品负责人 Scrum Master 团队集中沟通需求细节，用团队的智慧制定 Sprint 计划控制会议时间，安排茶歇时间，分支话题另行安排讨论，所有人都参与进来任务墙 Scrum Master 团队使项目任务可视化任务单位以小于等于 1 天为宜每日例会 Scrum Master 团队更新进度，发现问题控制时间为 10-15 分钟，站立会议

实践参与角色目的 / 好处注意事项 Backlog 演示产品负责人 QA 团队成员检查产品是否达到需求要求和测试要求建议在 QA 测试环境进行 Sprint 回顾产品负责人 Scrum Master 团队总结经验教训，反馈到后面的 Sprint ，持续改进工作方法头脑风暴的方式，轻松的讨论氛围，每次选中小于 5 个的问题进行解决 Tech Show 团队团队技术交流短时间，高频率守门员团队为团队成员创造安静的工作条件，增加对工作的 focus 程度团队成员轮流做守门员，逐渐培养每个人对问题的解决能力

实践参与角色目的 / 好处注意事项 Double Check 团队成员交叉检查项目制品是否达到要求关键制品如设计文档、核心代码、 Release Notes 等必须 Double Check Checklist Scrum Master 团队总结记录经验教训，作为后续项目的检查项解决问题后及时更新

XX 部门这样实施 Scrum— 归纳待实践
其他尚未开始的实践一览
实践参与角色目的 / 好处注意事项单元测试团队成员采用测试优先的方式保证代码质量结对编程团队提高设计和代码质量，经验共享，加强合作任务纸牌团队 Scrum Master 增加任务评估的客观性

Scrum 精神
团队目标重于岗位职责
团队工作优于独立作战
高效沟通强于标准化的文档
高能动性的、自组织的团队胜于角色划分清晰的流水线
务实的解决问题的方法好于经典理论
快速实践，快速反馈，持续优化

好了，忘掉一切招数，看看软件开发最原始最淳朴的目标 ----
在资源一定的情况下，尽可能快地完成高质量的软件开发

我们才刚上路

XX 部门团队做的还不到位的方面
还没找到很好的方式促进开发和 QA 融合为统一的 Scrum 团队
有些有价值的实践没有实施到很有意义的程度，执行不坚决深入
持续的方法改进工作有待加强
……

路漫漫其修远兮吾将上下而求索

我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作，我们形成了如下价值观：
个体与交互重于过程和工具可用的软件重于完备的文档客户协作重于合同谈判响应变化重于遵循计划
在每对比对中，后者并非全无价值，但我们更看重前者。
Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
项目过程中，业务人员与开发人员必须在一起工作。
要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
可用的软件是衡量进度的主要指标。
敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
对技术的精益求精以及对设计的不断完善将提升敏捷性。
要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
最佳的架构、需求和设计出自于自组织的团队。
团队要定期反省如何能够做到更有效，并相应地调整团队的行为。

Scrum上路

by Colorful_days on Sep 14, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 70

Statistics

Scrum上路 — Presentation Transcript

http://www.slideshare.net	69
http://ctc.qzs.qq.com	1