<ul><li>《硝烟中的 Scrum 和 XP 》导读 </li></ul>
<ul><li>Scrum 是一味药,仅此而已 </li></ul><ul><li>硝烟中的 Scrum— 从哪里开始 </li></ul><ul><li>我们才刚上路 </li></ul>
<ul><li>药?还是良好的生活习惯? </li></ul>
<ul><li>Scrum 不能解决我们的问题,能解决问题的是我们自己 </li></ul><ul><li>一支出色团队靠的不是技术,不是流程,而是有良好素质的团队成员。良好素质包括进取心、责任心、良好的习惯、热情…… </li></ul><u...
<ul><li>药名: Scrum </li></ul><ul><li>种类:敏捷软件开发方法 </li></ul><ul><li>适用症: </li></ul><ul><li>重量级流程导致的软件开发环节复杂 </li></ul><ul><l...
<ul><li>软件开发周期与质量的关系 </li></ul><ul><li>资源一定的情况下,软件开发周期跟质量相互制约,但不是反比 </li></ul><ul><li>以 T 代表某个项目的开发时间, B 代表项目的 Bug 数(类比质量)...
<ul><li>Scrum 是一味药,仅此而已 </li></ul><ul><li>硝烟中的 Scrum— 从哪里开始 </li></ul><ul><li>我们才刚上路 </li></ul>
<ul><li>Scrum 角色和职责 </li></ul><ul><li>产品负责人 – 定义开发目标,需要实现的 feature 和优先级 </li></ul><ul><li>Scrum Master –  保证团队高效而不受打扰地工作,优...
<ul><li>Scrum 过程 </li></ul><ul><li>前期:产品负责人整理业务需求,形成 Product Backlog 库 </li></ul><ul><li>执行:以 Sprint 为单位迭代式地完成 Sprint Back...
<ul><li>看上去没什么特别?别着急,我们来看 Scrum 的精髓 ---- </li></ul>Scrum 是一个“检查并适应”的框架,在三个角色(产品负责人 /Scrum Master/ 团队)、三种仪式( Sprint 计划 /Spr...
<ul><li>XX  部门这样实施 Scrum—Sprint 前 </li></ul><ul><li>产品负责人( PM )收集整理产品需求,形成产品 Backlog </li></ul><ul><li>产品 Backlog 按照统一格式定义...
<ul><li>XX  部门这样实施 Scrum—Sprint </li></ul><ul><li>产品负责人、 Scrum Master 和团队成员(包括 QA )召开 Sprint 会议, Scrum Master 主持会议 </li></...
<ul><li>XX  部门这样实施 Scrum—Sprint </li></ul><ul><li>整理一面任务墙,将 Sprint 内的 Backlog 和任务按照未开始、进行中、已完成等状态进行归类;同时展示 Sprint 的燃尽图 </l...
<ul><li>XX  部门这样实施 Scrum—Sprint </li></ul>任务墙快照
<ul><li>XX  部门这样实施 Scrum—Sprint 后 </li></ul><ul><li>Scrum Master 召集、组织 Sprint 回顾会议 </li></ul><ul><li>回顾会议以头脑风暴的方式 Review S...
<ul><li>XX  部门这样实施 Scrum— 归纳用到的实践 </li></ul>实践 参与角色 目的 / 好处 注意事项 Backlog 产品负责人 以简单的、面向目标的方式描述需求 愿景比需求细节更重要,团队需要知道为什么做而不光是做...
<ul><li>XX  部门这样实施 Scrum— 归纳用到的实践 </li></ul>实践 参与角色 目的 / 好处 注意事项 Backlog 演示 产品负责人 QA 团队成员 检查产品是否达到需求要求和测试要求 建议在 QA 测试环境进行 ...
<ul><li>XX  部门这样实施 Scrum— 归纳用到的实践 </li></ul>实践 参与角色 目的 / 好处 注意事项 Double Check 团队成员 交叉检查项目制品是否达到要求 关键制品如设计文档、核心代码、 Release ...
<ul><li>XX  部门这样实施 Scrum— 归纳待实践 </li></ul><ul><li>其他尚未开始的实践一览 </li></ul>实践 参与角色 目的 / 好处 注意事项 单元测试 团队成员 采用测试优先的方式保证代码质量 结对编...
<ul><li>Scrum 精神 </li></ul><ul><li>团队目标重于岗位职责 </li></ul><ul><li>团队工作优于独立作战 </li></ul><ul><li>高效沟通强于标准化的文档 </li></ul><ul><l...
<ul><li>好了,忘掉一切招数,看看软件开发最原始最淳朴的目标 ---- </li></ul>在资源一定的情况下,尽可能快地完成高质量的软件开发
<ul><li>Scrum 是一味药,仅此而已 </li></ul><ul><li>硝烟中的 Scrum— 从哪里开始 </li></ul><ul><li>我们才刚上路 </li></ul>
<ul><li>XX  部门团队做的还不到位的方面 </li></ul><ul><li>还没找到很好的方式促进开发和 QA 融合为统一的 Scrum 团队 </li></ul><ul><li>有些有价值的实践没有实施到很有意义的程度,执行不坚决...
路漫漫其修远兮 吾将上下而求索
<ul><li>我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作,我们形成了如下价值观: </li></ul><ul><li>   个体与交互  重于 过程和工具 可用的软件  重于 完备的文档 客户协作  重于 合同谈判 响应...
<ul><li>我们的最高目标是,通过尽早和持续地交付有价值的软件来满足客户。  </li></ul><ul><li>欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更,帮助客户获得竞争优势。  </li></ul><ul><li>...
Upcoming SlideShare
Loading in …5
×

Scrum上路

6,437 views
6,271 views

Published on

我们的Scrum实践

Published in: Technology, News & Politics
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
6,437
On SlideShare
0
From Embeds
0
Number of Embeds
75
Actions
Shares
0
Downloads
244
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide

Scrum上路

  1. 1. <ul><li>《硝烟中的 Scrum 和 XP 》导读 </li></ul>
  2. 2. <ul><li>Scrum 是一味药,仅此而已 </li></ul><ul><li>硝烟中的 Scrum— 从哪里开始 </li></ul><ul><li>我们才刚上路 </li></ul>
  3. 3. <ul><li>药?还是良好的生活习惯? </li></ul>
  4. 4. <ul><li>Scrum 不能解决我们的问题,能解决问题的是我们自己 </li></ul><ul><li>一支出色团队靠的不是技术,不是流程,而是有良好素质的团队成员。良好素质包括进取心、责任心、良好的习惯、热情…… </li></ul><ul><li>Scrum 提供了一套实践方法,帮软件团队养成良好的习惯 </li></ul><ul><li>好吧,如果这样说有点空洞,让我们走进一步看 </li></ul>
  5. 5. <ul><li>药名: Scrum </li></ul><ul><li>种类:敏捷软件开发方法 </li></ul><ul><li>适用症: </li></ul><ul><li>重量级流程导致的软件开发环节复杂 </li></ul><ul><li>面向任务、面向职责的开发模式导致的各司其职、流程环节衔接不畅,项目进度的掌控困难 </li></ul><ul><li>以上两条导致的项目 / 产品开发周期过长 </li></ul><ul><li>药物原理: </li></ul><ul><li>目标驱动,在统一的软件交付目标下组织团队 </li></ul><ul><li>依靠团队的智慧做项目评估、计划乃至设计、开发、测试 </li></ul><ul><li>抓住最基本的项目开发属性:周期 + 质量 </li></ul>
  6. 6. <ul><li>软件开发周期与质量的关系 </li></ul><ul><li>资源一定的情况下,软件开发周期跟质量相互制约,但不是反比 </li></ul><ul><li>以 T 代表某个项目的开发时间, B 代表项目的 Bug 数(类比质量),不同团队执行该项目的 T*B 值是一个区间 </li></ul><ul><li>良好团队就是尽可能保证 T*B 的值尽量小,挖掘可能空间的潜值 </li></ul><ul><li>Scrum 有助于塑造良好团队,降低项目的 T*B 值 </li></ul>
  7. 7. <ul><li>Scrum 是一味药,仅此而已 </li></ul><ul><li>硝烟中的 Scrum— 从哪里开始 </li></ul><ul><li>我们才刚上路 </li></ul>
  8. 8. <ul><li>Scrum 角色和职责 </li></ul><ul><li>产品负责人 – 定义开发目标,需要实现的 feature 和优先级 </li></ul><ul><li>Scrum Master – 保证团队高效而不受打扰地工作,优化工作条件、过程 </li></ul><ul><li>团队 – 自组织地完成项目开发,使用一切可行手段保证进度和质量 </li></ul>
  9. 9. <ul><li>Scrum 过程 </li></ul><ul><li>前期:产品负责人整理业务需求,形成 Product Backlog 库 </li></ul><ul><li>执行:以 Sprint 为单位迭代式地完成 Sprint Backlog 。每个 Sprint 以 Sprint Planning 开始,通过每日例会跟踪进度和 issue 。 Sprint 结束时交付可运行的产品 </li></ul><ul><li>后期:每个 Sprint 完成后,通过 Sprint 回顾发现问题和改进点,制定下个 Sprint 要引入的新的实践 </li></ul>
  10. 10. <ul><li>看上去没什么特别?别着急,我们来看 Scrum 的精髓 ---- </li></ul>Scrum 是一个“检查并适应”的框架,在三个角色(产品负责人 /Scrum Master/ 团队)、三种仪式( Sprint 计划 /Sprint 回顾 / 每日例会)和三种制品(产品 Backlog/Sprint Backlog/ 燃尽图)的基础上,你可以根据公司或者项目的情况,因地制宜引入任何有利于缩短开发周期、提高产品质量的实践
  11. 11. <ul><li>XX 部门这样实施 Scrum—Sprint 前 </li></ul><ul><li>产品负责人( PM )收集整理产品需求,形成产品 Backlog </li></ul><ul><li>产品 Backlog 按照统一格式定义,比较重要属性有:名称、重要性、估算时间、简单描述、如何演示等,详细的需求细节可以在其他需求文档中定义 </li></ul><ul><li>产品负责人可以通过任何渠道、方式获取和确认需求 </li></ul>
  12. 12. <ul><li>XX 部门这样实施 Scrum—Sprint </li></ul><ul><li>产品负责人、 Scrum Master 和团队成员(包括 QA )召开 Sprint 会议, Scrum Master 主持会议 </li></ul><ul><li>Sprint 会议上详细沟通产品负责人选定的重要性高的产品 Backlog 细节,确保团队对需求的理解无误 </li></ul><ul><li>团队就对需求的理解将 Backlog 拆分成任务,并给出每个 Backlog 的估算时间 </li></ul><ul><li>产品负责人和团队根据 Sprint 内可用的人天和 Backlog 的时间估算,选定需要排入本次 Sprint 的 Backlog </li></ul><ul><li>Scrum Master 和团队分派任务,制定 Sprint 计划 </li></ul><ul><li>一个 Sprint 的周期是两周;一次 Sprint 会议时间大约一个下午 </li></ul>
  13. 13. <ul><li>XX 部门这样实施 Scrum—Sprint </li></ul><ul><li>整理一面任务墙,将 Sprint 内的 Backlog 和任务按照未开始、进行中、已完成等状态进行归类;同时展示 Sprint 的燃尽图 </li></ul><ul><li>Scrum Master 每日早上固定时间组织团队的每日例会,确认每个成员前一天完成的工作、当天要进行的工作、工作中碰到的 issue ,并更新任务墙 </li></ul><ul><li>任何需求变更都进行实时评估,超过规划人天的 Backlog 视情况进行拆分或者推迟其他重要性低的 Backlog </li></ul><ul><li>任何完成的 Backlog 都需要演示给产品负责人和 QA 后才能提交测试 </li></ul>
  14. 14. <ul><li>XX 部门这样实施 Scrum—Sprint </li></ul>任务墙快照
  15. 15. <ul><li>XX 部门这样实施 Scrum—Sprint 后 </li></ul><ul><li>Scrum Master 召集、组织 Sprint 回顾会议 </li></ul><ul><li>回顾会议以头脑风暴的方式 Review Sprint 过程和结果,发现和列举存在的问题 </li></ul><ul><li>与会人员投票决定需要在下个 Sprint 中解决的 1-3 个问题, 探讨解决方案,确定实践方式 </li></ul>
  16. 16. <ul><li>XX 部门这样实施 Scrum— 归纳用到的实践 </li></ul>实践 参与角色 目的 / 好处 注意事项 Backlog 产品负责人 以简单的、面向目标的方式描述需求 愿景比需求细节更重要,团队需要知道为什么做而不光是做什么 Sprint 会议 产品负责人 Scrum Master 团队 集中沟通需求细节,用团队的智慧制定 Sprint 计划 控制会议时间,安排茶歇时间,分支话题另行安排讨论,所有人都参与进来 任务墙 Scrum Master 团队 使项目任务可视化 任务单位以小于等于 1 天为宜 每日例会 Scrum Master 团队 更新进度,发现问题 控制时间为 10-15 分钟,站立会议
  17. 17. <ul><li>XX 部门这样实施 Scrum— 归纳用到的实践 </li></ul>实践 参与角色 目的 / 好处 注意事项 Backlog 演示 产品负责人 QA 团队成员 检查产品是否达到需求要求和测试要求 建议在 QA 测试环境进行 Sprint 回顾 产品负责人 Scrum Master 团队 总结经验教训,反馈到后面的 Sprint ,持续改进工作方法 头脑风暴的方式,轻松的讨论氛围,每次选中小于 5 个的问题进行解决 Tech Show 团队 团队技术交流 短时间,高频率 守门员 团队 为团队成员创造安静的工作条件,增加对工作的 focus 程度 团队成员轮流做守门员,逐渐培养每个人对问题的解决能力
  18. 18. <ul><li>XX 部门这样实施 Scrum— 归纳用到的实践 </li></ul>实践 参与角色 目的 / 好处 注意事项 Double Check 团队成员 交叉检查项目制品是否达到要求 关键制品如设计文档、核心代码、 Release Notes 等必须 Double Check Checklist Scrum Master 团队 总结记录经验教训,作为后续项目的检查项 解决问题后及时更新
  19. 19. <ul><li>XX 部门这样实施 Scrum— 归纳待实践 </li></ul><ul><li>其他尚未开始的实践一览 </li></ul>实践 参与角色 目的 / 好处 注意事项 单元测试 团队成员 采用测试优先的方式保证代码质量 结对编程 团队 提高设计和代码质量,经验共享,加强合作 任务纸牌 团队 Scrum Master 增加任务评估的客观性
  20. 20. <ul><li>Scrum 精神 </li></ul><ul><li>团队目标重于岗位职责 </li></ul><ul><li>团队工作优于独立作战 </li></ul><ul><li>高效沟通强于标准化的文档 </li></ul><ul><li>高能动性的、自组织的团队胜于角色划分清晰的流水线 </li></ul><ul><li>务实的解决问题的方法好于经典理论 </li></ul><ul><li>快速实践,快速反馈,持续优化 </li></ul>
  21. 21. <ul><li>好了,忘掉一切招数,看看软件开发最原始最淳朴的目标 ---- </li></ul>在资源一定的情况下,尽可能快地完成高质量的软件开发
  22. 22. <ul><li>Scrum 是一味药,仅此而已 </li></ul><ul><li>硝烟中的 Scrum— 从哪里开始 </li></ul><ul><li>我们才刚上路 </li></ul>
  23. 23. <ul><li>XX 部门团队做的还不到位的方面 </li></ul><ul><li>还没找到很好的方式促进开发和 QA 融合为统一的 Scrum 团队 </li></ul><ul><li>有些有价值的实践没有实施到很有意义的程度,执行不坚决深入 </li></ul><ul><li>持续的方法改进工作有待加强 </li></ul><ul><li>…… </li></ul>
  24. 24. 路漫漫其修远兮 吾将上下而求索
  25. 25. <ul><li>我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作,我们形成了如下价值观: </li></ul><ul><li>  个体与交互 重于 过程和工具 可用的软件 重于 完备的文档 客户协作 重于 合同谈判 响应变化 重于 遵循计划   </li></ul><ul><li>在每对比对中,后者并非全无价值,但我们更看重前者。 </li></ul>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
  26. 26. <ul><li>我们的最高目标是,通过尽早和持续地交付有价值的软件来满足客户。 </li></ul><ul><li>欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更,帮助客户获得竞争优势。 </li></ul><ul><li>要不断交付可用的软件,周期从几周到几个月不等,且越短越好。 </li></ul><ul><li>项目过程中,业务人员与开发人员必须在一起工作。 </li></ul><ul><li>要善于激励项目人员,给他们以所需要的环境和支持,并相信他们能够完成任务。 </li></ul><ul><li>无论是团队内还是团队间,最有效的沟通方法是面对面的交谈。 </li></ul><ul><li>可用的软件是衡量进度的主要指标。 </li></ul><ul><li>敏捷 过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。 </li></ul><ul><li>对技术的精益求精以及对设计的不断完善将提升 敏捷 性。 </li></ul><ul><li>要做到简洁,即尽最大可能减少不必要的工作。这是一门艺术。 </li></ul><ul><li>最佳的架构、需求和设计出自于自组织的团队。 </li></ul><ul><li>团队要定期反省如何能够做到更有效,并相应地调整团队的行为。 </li></ul>

×