Scrum开发模式
名词解释
Scrum: Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色(ScrumMaster)负责维护过程和任务，产品负责人(PO, Product Owner)代表利益所有者，开发团队(Team)包括了所有开发人员
一、为什么Scrum是有效的开发组织方式
(一) 经验型流程VS预定义型流程
如果所需实现的对象清晰,技术准备充分,则适用于预定义型流程.如果所需实现的对象模糊,技术准备不充分,则适用于经验型流程.
在这里,流程不仅仅是软件开发中的流程,这是一个广义的定义,包含各个行业生产中产生的流程.对于预定义型流程,很经典的例子就是造汽车.比如造一辆奥迪A6,工作人员只需要拿到图纸,根据图纸上提供的信息去裁割钢板,定型,组装.在预定义型流程下,一辆A6将很快的开下生产线.对于经验型流程,如果还是以汽车为例的话,那就可以放在如何降低汽车的风阻?如何降低油耗?如何使驾驶人更舒服?这些事情,在以前可能做过,也可能没有做过,这就需要根据我们以往的经验去考虑问题,但这里经验起的作用只是一本字典,更多的事情,需要我们在经验的基础上去升华解决.
对于Scrum,适合的是经验型流程.在较短的迭代中(2周左右),需要我们快速的整理好PO提出的用户情景(User Story)(PO提出的需求在这里称作用户情景),然后选定技术(这个技术也可能是新技术)进行快速开发.
(二) 软件项目中的两个复杂度
简单项目=熟悉的技术+固定的需求;复杂项目=技术不确定+变更.
试想,在我们以前做过的项目中,有多少是”简单项目”呢?因此,Scrum在不断迭代的过程中,屏蔽或者减少了需求的不确定性以及不确定技术带来的弊端.
(三) 案例分析
假如公司希望迁移SharePoint服务器,并和当前流行的社交网站如FaceBook进行集成.
你觉得会有哪些问题?
1、 我们有哪些可用的技术？
2、 如何使用这些技术来实现所需功能?
3、 对于目标,我们要实现到何种程度?
4、 最糟糕的,PO并不清楚他需要什么!
解决方式:
1、 缩短迭代；
2、 增加与PO的沟通频率；
3、 将技术调研和实现放在不同的迭代中进行。
(四) 经验型流程控制
1、 需要通过检查和适应来改进流程(需要很好的透明度来支持)
2、 透明度的实现需要企业文化的支持
在Scrum模式中，团队的规模应控制在5~9人之间，充分发挥每个成员在团队中的作用。在应用Scrum模式进行开发过程中,需要建立人与人之间的信任,充分调动团队成员的积极主动性,也就是注重每个团队成员在团队中发挥的作用,而不是下派、监控这种不是以人为本的模式。那么在这种情况下，就需要很好的透明度来支持，要让团队成员知道ScrumMaster都和哪些人说了什么，PO提出了新什么需求，面临着什么新问题，甚至是上级的压迫也要上团队成员知道。
二、计划质量
(一) Scrum是否需要计划？
无可置疑，在Scrum中，需要更多的计划。在这里介绍一下戴明环。
作为帮助我们做出进一步决策的迭代型方法，戴明环通过4 个简单的步骤来验证所获取的经验，以便帮助我们做出更好的决策。
(二) 质量和成本的关系
1、 关注质量将会最终降低成本并提供更好的质量
2、 关注成本，将会牺牲质量同时远期成本反而增加
那么该如何提高质量呢？
停止使用通过检查来提高质量的方式，而通过完善的计划在产品开发的一开始就构建质量。理解起来可能稍微有点难以接受，但是集合上面的两点并结合戴明环，不难理解，质量应该是一个度，一个高度，一个保证，因为你不能保证你生产的家电永远不会坏掉。
(三) 来看Scrum的计划（Plan）和执行（Do）
Scrum通过在迭代中不断的计划和执行来推进，通过不断的计划，不断的完善计划，相应的质量也会随之提高，相比传统的（计划——执行——稳定）具有更高的可操作性和可控性。
三、Scrum”以人为本”的体现
我们可以来做一个实验来证明Scrum的优越性。
情景一：有N个小队，每个小队有一个队长，所有小队的成员成矩形聚拢在一起（很紧凑），然后每个小队的队长给队员发号施令（在矩形内移动30步，然后移动出矩形）。
情景二：有N个小队，没有队长，每个小队的成员成矩形聚拢在一起，然后每个小队成员在矩形内移动30步，然后移动出矩形。
四、Scrum角色介绍
(一) ScrumMaster：
- 保证Scrum团队可以遵守Scrum的价值，实践和规范
- 帮助Scrum团队和组织采用Scrum模式进行项目流程组织
- 指导并带领团队变得更加高效，实现更高质量
- 保护团队不要受到外界因素的干扰
- 保证各个不同角色之间的良好写作，消除障碍
- 帮助PO更好地利用团队的能力
- 不要管理团队
给ScrumMaster的一些建议：
1、协助甄选PO人选，并帮助PO了解其职责; 如果PO不了解 如何很好的利用团对的价值，ScrumMaster需要承担负责
2、ScrumMaster 永远不能同时担任PO
3、ScrumMaster 可以由团队的成员来担任，但是在这种情况下他将有很重的负担
如果打破了第二点，ScrumMaster同时兼任PO，那么就打破了Scrum的价值和规范，因为ScrumMaster+PO=PM。而在Scrum中是没有PM这个概念存在的。
(二) 产品负责人PO
1、PO 是一个人并只能由一个人来担
2、负责管理产品待办事项表（Product Backlog）并保证其 对于客户和团队保持透明度
3、对产品代办事项表进行优先级排序
4、与团队一起来进行工作量估算
5、对于项目的成功负责并保证投资回报率（ROI）
给PO的一些建议：
1、 客户项目：最佳的PO人选应该由客户的代表来担任
2、 内部项目：最佳的PO人员应该由业务经理担任
3、 PO可以由团队成员担任，但永远不能由ScrumMaster担任
(三) 团队Team
1、 最佳团队大小：5-9 人
2、 多功能团队：程序员，测试人员，设计师，数据库管理员和架构师
3、 保证团队成员全职参与开发
4、 自我管理，没有头衔之分，不组建子团队
5、 成员更替只能在迭代之间进行，最佳方式是在发布之间进行
需要注意的是，第三点提到的全职参加是指完成了分配到的任务额即为全职参加。并不是指全程参加。
五、在每次迭代过程中包含的内容
(一) 每日站立会议
1、 站立进行
2、 在固定的时间，固定的地点
3、 问题：
你昨天完成了哪些工作？你今天要完成哪些工作？遇到了什么困难？
4、 仅仅作为信息沟通用途，不解决任何问题
5、 不向任何人汇报
6、 15分钟
(二) 发布计划会议
进行产品规划
1、仅对启动项目所必须的内容进行规划
2、在开发过程中适时进行进一步的规划
可交付物
1、 针对产品特性和功能的整体规划
2、 下一个发布的目标
3、 主要任务
4、 按优先级排序的产品待办事项表
(三) 迭代计划会议
1、进行迭代规划
2、PO向团队介绍产品待办事项表
3、团队在PO的协助下充分了解产品待办事项
4、确定迭代目标和迭代合约
迭代合约包含的内容有：
1) 团队组成（成员列表、角色分配）
2) 完成规范
3) 团队对迭代目标的承诺
4) 迭代长度
5) 迭代代办事项的估算
6) 迭代评审和下一次计划会议的时间和地点
5、对产品待办事项进行细分并创建迭代待办事项
(四) 迭代
解释：团队用来实现迭代目标（可发布产品）的时间区间。
时间区间：1-4周，最佳2周。
关键词：时间长度决定何时结束迭代，而不由工作量的完成来决定。
优点：为团队提供保障。
(五) 迭代评审会议
- 团队展示完成的功能并收集反馈
- 对未完成的功能进行描述并说明原因
- PO接受/不接受当前迭代
- 邀请所有人，包括客户参与
- 4小时
(六) 迭代回顾会议
- 那些做的好？
- 那些做的不好？
- 那些可以改进？
- 仅团队成员参与
- 4小时
六、定义需求
用户情景应该包括：作为……我需要……从而……，以及用户接受标准。
用户情景应该理解为用户+情景，不能仅仅考虑用户本身，所有的用户情景都应该从某类用户开始。
用户情景最佳实践：
1、 纵向分配原则-对于采用分层设计的业务用例实现尽可能 由一个开发人员完成所有的层次的组件实现（界面/逻辑/数据）
2、 任务的划分粒度到1个工作日内完成
3、 对于任务而言，只有完成和不完成两种状态
4、 业务用例的工作量使用的相对值，表明的是一种对于用例工作量和评定
