Scrum实战——读书笔记及感想
Posted 我们的开心
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Scrum实战——读书笔记及感想相关的知识，希望对你有一定的参考价值。
文/李涛
最近拜读了Mitch Lacey所著《Scrum 实战》一书，深有感触，作为一本项目管理的书籍，从敏捷理论讲到实践中的每一个问题，内容扎实，贴合实际，让我对项目管理、人的自我管理有了更深刻的认识。我们的项目管理，也应该从每一个实践场景出发，耐心而细致，改进每个人和每个团队工作的习惯、提升产出，这不仅可以成就团队，也可以成就我们每个人自身。
起步
敏捷的内功心法
专注、尊重、承诺、勇气、开放。
Scrum拥抱变化
变化是困难的，但是拥抱变化就是为了改变困难的现状。作者讲到了“死亡行军”——形容交付日期日益迫近的工程在开发过程中垂死挣扎的感觉。不断的加班、条目的变更、无法预料的结果，对开发者、用户和项目本身来说都是一场灾难。这些大家应该都深有感触。
Scrum适用哪些项目
有一定复杂度并且需求或者技术方案可能会常变化的项目适合使用Scrum，太简单的项目或者需求非常明确且不会发生变化的项目，是不需要的。
建设学习型团队
学习型团队——在组织中，人们为了创造自己真心渴望的成绩而持续拓展能力；在组织中，各种开阔的新思想得到培育；在组织中，集体的热情得到释放；在组织中，人们不断的学习如何共同学习。建立一个人们既能提高自己的技能也能完成业务目标的团队结构是一个挑战。通俗而言，要达到需要既能使得成员们能刷装备、涨经验，又能给团队提供稳定输出，甚至给团队带来革新。
Scrum框架概述
三大角色
ScrumMaster、产品负责人和开发团队。
三个重要工件
产品列表、Sprint列表和燃尽图。
四个建议的会议
每个Sprint第一天召开的计划会议、每日站会、Sprint审核会议和团队Sprint回顾会议。
实践
速率
合适的速率安排很重要，如果长时间很疲惫，那么工作是很难持续的。相反，如果大家很闲，会造成人力资源的浪费，大家没有成就感，无法提升自己，留不住有用的人才，这是对大家的不负责任。
三大角色与能力
角色 |
能力 |
ScrumMaster |
建立信任 帮助他人发现问题 通过影响来发挥领导力 喜欢与他人合作 在压力面前保持冷静 |
产品负责人 |
通过倾听客户的要求，确定客户真正的意图 能够使项目干系人与客户在系统功能要求上取得一致 具有产品管理的专业知识 具有基本的财务经验 对于正在开发的产品，有一定的行业背景 |
团队成员 |
具有开放的心态 期待提高自己和帮助别人而变得更好 具有团队合作的态度 值得尊重 谦虚 |
Sprint长度
选择合适的Sprint长度是指确定一个合适的刺激——反应周期。Sprint长度可以参考以下这些参数：
项目的期望期限（这决定了可以有多少次迭代，有多少次发现问题的机会）；
客户/项目干系人多久可以提供反馈和指导；
Scrum团队的技术能力、Scrum经验、分解工作的能力。
DoD
指的是团队成员、客户之间以及项目本身需要有明确的完成定义。以我们正在开展的某平台迁移项目为例，每个迭代的DoD至少应该包含：
用户故事（需求） |
迭代 |
1.代码都提交test； 2.完成所有单元测试； 3.自动生成所有接口文档并导入草稿箱； 4.完成集成测试并提交集成测试报告； 5.所有源文件、配置文件代码都需要符合规范； |
1.每个Sprint迭代完成当前迭代的任务更新； 2.本项目每个迭代无法严格按周期增量交付，但可以明确检查是否完成并据此调整进度，因此应该检查完成程度，并更新本迭代需要提供的文档。比如迭代一需要完成接口开发，那么这个迭代完成就需要检查所有接口文档； |
测试 |
投产 |
1.讨论充分、评审通过的测试案例； 2.所有的缺陷应该是已关闭状态； 3.功能测试报告； 4.性能测试与调优； |
1.程序版本、基线、代码合规性检查； 2.投产相关材料； 3.接口发布； |
团队有一个DoD，有助于所有项目干系人为满足业务与客户的需要而承诺尽全力将工作做到最好。对于使用它的团队，DoD开始成为一种生活方式，也是一个对卓越的承诺。
最佳拍档
测试驱动开发、代码重构、持续集成与更频繁的提交、结对编程、自动化集成测试与验收测试，这些都是Scrum的最佳拍档。
发布计划
业务会关注需求什么时候完成，领导也会考核项目各项周期指标，如果项目跟计划出现很大的偏差，那项目经理肯定要负责。因此，制定发布计划还是很重要的。
可持续的工程与Scrum
维护老的系统和接口、统计和支持的工作给人带来的成就感比较低，工作往往重复、枯燥。这样的工作难以给人带来激情，难以得到领导的认可，士气可能会受挫；但如果支持不到位，也会对项目有一定影响。所以，旧系统和接口的维护问题，是项目经理或者职能经理应该关注的问题。
缺陷管理
缺陷管理，是我们应该何时解决缺陷的问题，以及开发和测试之间沟通的问题。
通常早修复缺陷比晚修复缺陷明显成本更低，书里给出的工业标准数字是1:10:100，试想我们日常的场景：
阶段1：在开发阶段，大脑里存储了一堆临时变量，如果发现问题及时解决，通过思考、查资料、断点跟踪，10分钟就可以解决。
阶段2：假如我们放弃阶段1的解决问题，草草的交付测试同事测试，然后去做别的事情，过了10天，测试的小伙伴找来说出BUG了，这时候大脑会一片空白，当时的逻辑全忘了，由于代码库几天没更新，原来的解决方案运行不起来了，测试数据也得重新找，最终花了一上午加上午饭的时间把问题解决了（感觉自己工作认真又辛苦），测试报告多了一条缺陷，庆幸，现在项目考核没有这个了，过关。
阶段3：投产前版本验证，变更流程已经在走了，版本验证阶段发现BUG，好吧，整个流程都因为这个事情无法向前推进，但是好在自己紧赶慢赶，终于把问题基本解决了（整个团队都为此捏了一把汗），万幸的是没有给客户带来损失。
阶段4：投产之后出BUG了......此处省略1万字。
所有过往都足以让我们相信最好的做法是实时修复缺陷。
此外，缺陷优先级的分类方案：
优先级 |
|
P0 |
灾难：系统主要功能不可用，且无变通的方案 |
P1 |
高：系统主要功能不可用，且有变通的方案 |
P2 |
中等：系统使用性受损 |
P3 |
低：影响较小，无关紧要或者不便利，可以等到下次发布时解决 |
如果是P0或者P1的缺陷，建议必须立刻解决。如果是P2或者P3，根据实际情况，可以确定解决方案的时机。
Sprint审核会议
审核会议至少应包含如下议题：
1.Sprint目标
2.我承诺完成的用户故事
3.我已完成的用户故事
4.我未完成的用户故事
5.Sprint中的关键决策以及进展情况（比如需求变化、架构变化、部分需要完成的关键操作）
6.度量（可以是代码的度量，部分SM提供的项目进展的度量）
7.演示完成的工作
8.下个Sprint优先级审核（这个可以放到下个Sprint启动会议讨论也OK）
以上是本书一些学习心得和感悟，写出来同大家分享，以便一同学习和成长，写的不对之处也欢迎批评指正。
敏捷是给人带来激情的工作方式，受制于篇幅，本文记录的比较简短。喜欢敏捷的同事可以读读此书，和作者的心灵碰撞绝对让你大呼过瘾，最后致敬本书作者Mitch Lacey。
轮值总编：刁翔宇
责任编辑：魏娜
美编：程静
技术支持：苏静辉
我们的开心 · 总编辑部
（读 吧）
以上是关于Scrum实战——读书笔记及感想的主要内容，如果未能解决你的问题，请参考以下文章