# 规划和保护
建立了Scrum团队,还需要一些技巧使项目始终保持在正轨上.
# 创建Scrum环境
Scrum团队需要合适的环境才能使之有明显的化学反应. Scrum需要:
- 稳定的团队: 项目的核心成员以及研发团队结构保持稳定
- 合适的办公环境: 我们应该保证Scrum团队能够坐在一起办公,应该保证办公环境分隔和环境的独立性
- 合理的理解估算: 估算往往是根据已有的信息做预测,可能不准确,要理解估算的定义,不能用估算去给团队试压,让团队按照"承诺"交付功能
- 互惠性的工作: 不以报酬作为工作奖励的标准,而是希望公平的报酬,如果想要关心和承诺,就要向我展示你的关心和承诺,并帮助我充分发挥自己的潜能
- 可持续的开发: 加班是项目出了问题的征兆,而不是业务的常态,Scrum需要稳定的步伐,有节奏的可持续开发
- 务实的期望: 变革和创新都是需要时间的,在变革的过程中我们任何事情都不是一蹴而就的,Scrum需要我们消除老式的命令和控制,保持耐心基于一个务实的期望培育团队成长.
# 制定Sprint计划
我们可以通过Sprint计划会来同团队一起设定Sprint时长和目标,这样团队可以有计划的开始,并明确项目的目标.
# 细化产品列表
在团队开会之前应该先初步细化产品列表.首先要确定产品负责人确定Sprint最重要的需求,另外还需要加上足够的细节来确保开发人员可以开工.这也许意味着添加更详细的验收标准,如果适用的话也可以是线框图或是模型,如果产品负责人实现能和测试专家合作开发一组粗略的测试用例来全面描述功能的内在要求,也是一个很有帮助的做法.
# 明确目标
我们大多数的人都愿意有行动目标,所以制定一个贯穿于整个Sprint的共同目标肯定是有帮助的,焦点目标通常和当前的Sprint主题相对应.Sprint目标还有助于确保每个人都专注于主题,而不是偏离主题.
# Sprint应该有多长
一旦确定Sprint长度,就不能随意修改,过去常常有人推荐Sprint时长是30天,现在我们也可以更加灵活,Sprint长度应该因团队而异,一般情况下会根据下面两个因素来决定Sprint长度:
- 团队的偏好: 有些人喜欢长的Sprint,这样有助于保持工作冲劲.有些人喜欢短一些的Sprint,这样可以使计划不至于复杂
- 需求的易变性: 如果由于产品的特点或市场情况而要求产品负责人经常修改需求,那建议短一些的Sprint
# 容量规划
团队在正式开始Sprint计划会之前,需要先确定自己在当前Sprint的容量,不是每个人在每个Sprint都能贡献自己的全部时间,有些团队成员需要跨多个项目工作,如果是这样需要确保这些开发人员不会被超额分配.
# Sprint计划会
产品计划会需要让团队知道自己将优先要做什么,以及确定这些待办的任务如何去做
# 做什么?
首先产品负责人逐条介绍产品列表里哪些条目优先级最高并期望能在这个Sprint完成,团队可以现场提出具体问题,可以用团队速率作为一个粗略的指导,让产品负责人知道需要为计划会准备多少个PBI(产品待办事项)
# 怎么做?
开发团队把PBI逐个分解成更细的即使任务并针对每个任务估计一个最接近的完成时间以帮助团队权衡决策,而且通过确定分解的过程可以使团队对Sprint结束能交付哪些内容心中有数.
开发团队在做基于承诺的计划时,需要遵循以下典型步骤:
- 从优先级最高的PBI开始
- 将每个PBI拆分为任务并估计完成需要多少小时
- 识别任务之间的依赖性
- 重复这个循环,直到将团队当前的Sprint容量填满
# 定义任务
通常任务需要满足以下几个条件:
- 一个任务应该是某个PBI中可测试的一块,而且要包括满足任务的"完成标准"
- 每个任务所需时间不能长于8小时
- 虽然多个开发人员可以同时做一个PBI,但一个任务只能由一个开发人员(或两个开发人员结对)完成
- 任务完成时需要为Sprint评审准备的必要的演示数据
# 障碍
在项目进行中有很多突发障碍会阻碍项目进展,任何事情只要阻碍团队的进展,ScrumMaster就得第一时间着手解决.
# 定义障碍
任何阻碍开发人员完成他在Sprint容量内所认领的事情都可以被定义为障碍
形形色色的障碍包括:
- 大型会议
- 病假
- 不成功的构建
- 开发工具的问题,如硬件故障,软件问题导致项目无法进行
- 不可靠的供应商
- 产品列表未细化.如果需求没有足够的细节会导致开发团队无法全新投入开发
- 只关注个人的利益,忽略了团队的协作
# 控制障碍
我们可以通过确认,诊断,去除,告知,学习这五步来试着控制障碍
- 确认: 首先我们要确认障碍到底是什么,通常我们会在站会上提出遇到了什么障碍,Sprint回顾会可以用来发现Sprint中溜过的障碍,所有的障碍都应该跟踪,直至解决为止
- 诊断: 如果同时受累于多个障碍,我们需要根据影响的大小和问题的紧迫性来判断从哪里入手
- 去除: 我们需要团队共同努力来排除障碍,我们也可以寻求其他团队的帮助让项目及时回到正轨
- 告知: 在遇到障碍时,得让Scrum团队和干系人知情,如果项目必须选择撤退方案时,尽量先告知产品负责人,让他有足够的时间消除可能带来的一系列负面影响
- 学习: Sprint回顾是分析和研究障碍的主要战场,从问题中吸取经验教训,避免在犯错,掌握解决的办法,这样一来,即使是问题复现,也不太会有严重的影响