Scrum团队实践——流程

过去的一年里不知道你是否有这样的感受：

有时候我们常常会想，我整天瞎比忙，还不挣钱，多TM窝心的上。其实在管理层看来却是另一种景象：你整天的瞎比忙，还不出活。领导注重的是什么，他们更注重结果，拿玩游戏来说吧，项目经理就是MT（主抗），开发者都是些DPS（输出），主抗帮我们抗住项目上的一些压力，让我们全心的去输出，但是DPS输出也是有讲究的，你不能划水，当然也不能OT（直接把问题捅到高层）。作为一个团队，如何最大化的输出，如何最敏捷的应对各种变化，如何让每个人忙的有价值？谁也不希望自己是那个猪一样的队友。这时候我们就需要使用Scrum把这些问题显现出来。我还是强调下Scrum不是解决问题的一个方法，他更强调形式，也就是形式大于内容。

上一篇主要介绍了Scrum中一些基本概念，在了解了相关概念后，我们再对Scrum的流程做一下基本的认识。

Scrum的基本流程

    1.首先我们对将要开发的产品做一个或者一组产品级别的backlog（这里假设已做好需求分析），大致内容包括产品所包含的商业和技术功能点(粗略功能)、需求列表、产品的预估开发周期。这个backlog列表要按照优先级排行顺序（产品负责人），优先级越高的要尽可能做的越详细。 

    2.制定一个sprint计划，分析和评估各个产品backlog,通过评审方式选定一些作为迭代目标。

    3.根据产品的backlog我们可以通过一个迭代计划会抽出一部分最为一个sprint（冲刺）的计划了，这一部分需要我们进一步的对具体功能项做细化的分析，于是形成了sprint backlog，sprint backlog详细列出了某个实现功能的功能点，以及分工和耗时，耗时最好精确到8小时（一天以内）以内的时间，如果时间超过8小时，说明功能划分有问题，再做细分。

    4.根据指定的sprint backlog开始迭代开发，一个sprint的周期一般为2-4周，推荐2周左右即可，一个固定的周期可以培养大家开发的节奏感。开发过程中，功能点的实现要先进行概要设计，相关责任人评审通过后，再进行详细设计，这样避免了在一开始方向上的错误。

Scrum流程和瀑布流的对比

    在这个流程图中，我们可以看出传统的瀑布流模式是一个流程一个流程的走，如果中间出现需求的改变，在这个流程中是很难快速做到应变的，而Scrum的流程是一个个的迭代，每一个迭代都是一个完整的小流程（设计、开发、测试、发布），迭代过程中，随时可以改变需求和任务优先级。

Scrum的Backlog

    产品的backlog是整个流程的关键点，它是随着需求可变的，通常backlog中的各个backlog项我们又称为user story(用户故事)，User Story是从用户的角度对系统的某个功能模块所作的简短描述。一个User Story描述了项目中的一个小功能，以及这个功能完成之后将会产生什么效果，或者说能为客户创造什么价值。我们通常把User Story写在一张小卡片上，同时在卡片上标明它的优先级和预计完成时间，以便开发人员根据任务的优先级来制定Sprint Backlog。

    一个产品backlog的样例：

    管理迭代backlog:（1）剩余工作量要每天更新 （2）团队任何人都可以添加、删除、修改任务 （3）为了迭代目标工作

    迭代backlog样例：

    这个可以结合相关工具使用，像jira,project都提供了类似功能。

Scrum会议

    会议是Scrum的一个特点，像每个sprint的计划会、总结会、评审会等，另外除了这些它还强调每天的例会，这也是Scrum形式大于内容的一个体现吧，每天的例会一般作为晨会的形式展开。

•     每天例会的属性：
  1.每天都开  2.不能超过15分钟    3.站着开会，有条件的可面对着进度白板讨论
• 目的：不是为了解决问题
• 所有相关人都参与
• 避免无关讨论

   例会会议样例：

    计划会的样例：

    到此为止，scrum的基本理论和流程已经总结完了。具体实践经验会在以后的文章中分享。