众所周知，Scrum不仅能够管理软件开发项目，同样还能够用于运行软件维护团队，或者作为计划管理方法：Scrum of Scrums，在本次开发中，我们的主要内容如下：
角色
scrum定义了许多角色，其中有些是在Scrum过程中全身投入项目的各种角色，他们在项目中承担实际工作。
1-产品负责人
产品负责人代表了用户最终想要什么样的产品，保证了Scrum团队在做从业务角度来说正确的事情。产品负责人编写用户故事，排出优先级，并放入产品订单。
2-Scrum主管（或促进者）
Scrum主管促进Scrum过程，他的主要工作是去除那些影响团队交付冲刺目标的障碍。Scrum主管并非团队的领导（因为团队是自我组织的），而是一个负责屏蔽外界对开发团队的干扰的角色。Scrum主管确保Scrum过程被按照初衷使用。Scrum主管是规则的执行者。
3-开发团队
负责交付产品的团队。一个团队通常由5至9名具有跨职能技能的人（设计者，开发者等）组成，承担实际的开发工作组的成员并不是实际Scrum过程的一部分，但是必须考虑他们。敏捷方法的一个重要方面是使得用户和利益相关者参与到过程中的时间。参与每一个冲刺的评审和计划，并提供反馈对于这些人来说是非常重要的。
4-用户
软件是为了人而开发的。有人说，“假如森林里有一棵树倒下了，但没有被人听到，那么它算是发出了声音吗？”同样地，人们可以说，“假如软件没有被使用，那么它算是被开发出来了么？”
5-利益相关者（客户，提供商）
影响项目成功的人，但只直接参与冲刺评审过程。
6-经理
为产品开发团体搭建环境的人。
经验：
1.Scrum主管开发的时间可能不会很多，一般来说也不适合参与开发，因为排解外部干扰，解决项目组障碍都会花去很多零碎时间进行沟通以及其他事务，都会干扰个人的正常开发。
2.建议不要让开发主力担任Scrum主管，应当由擅长沟通，有较深技术底蕴，对产品比较熟悉或者理解深刻的人员担任。
3.Scrum主管与开发人员是平级的，身份对等，所做的工作更有点偏向于服务形式。其本身基本上可以看做是一个“人形文档”，项目执行中任何需要产品文档的地方，比如咨询，需求变更，新成员培训等等都由Scrum主管负责。
4.对一个项目来讲，Scrum主管非常重要，其他成员可以变更，但绝对要避免Scrum主管的变更。Scrum主管的责任也很杂，需要擅长处理并发事件的人来担当此角色。
5.Scrum的效率核心就是“排除干扰”，开发人员可以为一个项目全力以赴。Scrum主管对干扰的排除能力直接决定了项目执行效率。
6.所有的分歧交由Scrum主管来敲定，因此其技术能力与现实业务解决能力不能忽视，应当从开发人员中抽取人员负责此工作。考虑到离开开发岗位一段时间，技术能力会有所退化，建议轮岗。
会议
在冲刺中，每一天都会举行项目状况会议，被称为“scrum”或“每日站立会议”。每日站立会议有一些具体的指导原则：
1会议准时开始。对于迟到者团队常常会制定惩罚措施
2欢迎所有人参加，但只有scrum主管”可以发言。
3不论团队规模大小，会议被限制在15分钟。
4所有出席者都应站立。（有助于保持会议简短）
5会议应在固定地点和每天的同一时间举行。假设会议定在每天下午下班前，在会议上，每个团队成员需要回答三个问题：
a.今天你完成了那些工作？
b.明天你打算做什么？
c.完成你的目标是否存在什么障碍？（Scrum主管需要记下这些障碍）每一个冲刺完成后，都会举行一次冲刺回顾会议，在会议上所有团队成员都要反思这个冲刺。举行冲刺回顾会议是为了进行持续过程改进。会议的时间限制在4小时。
经验：
1.Scrum会议的核心是：不要太长！应当尽量避免任何可能导致会议延长的事情。
2.项目开发开始前的会议不要过长，主要确定方向，任务与最关键的技术细节。应提供一个技术预备期供大家分享要使用的技术知识或者制定开发规范。
3.项目开发正式开始前，必须达成必要的开发共识，必须完成基本的开发约定。每个人并不是只维护自己的代码。
4.Scrum会议的督促作用非常明显，但也会给成员带来相当的压力。Scrum主管有必要注意排解成员压力。
下面几点有助于降低成员压力：
1.让开发人员领取自己喜欢和擅长的任务。
2.项目开始前充分预估时间，务必实事求是，并考虑到成员的开发能力。
3.开发前（或者日常）最好能进行几次技术培训，避免成员在开发中遇到不熟悉的技术冲刺订单
冲刺订单（sprint backlog）是大大细化了的文档，包含团队如何实现下一个冲刺的需求的信息。
4任务被分解为以小时为单位，没有任务可以超过16个小时。
5如果一个任务超过16个小时，那么它就应该被进一步分解。
6冲刺订单上的任务不会被分派，而是由团队成员签名认领他们喜爱的任务。
7一个任务分todo，开发中，自测，提交测试，完成几个阶段。
经验：
WEBIM项目实施白板左边的用户故事，实际上是对冲刺订单的分类。订单一开始都在todo的下面，每个开发人员到实施白板前，审核还有那些订单在todo当中，从中选择自己喜欢或者相对擅长的订单，写上自己的名字，放在开发中，然后回去开发相应组件。当组件基本开发完毕，就将订单放在自测栏下面。如果准备将该组件提交测试，就将订单放在测试栏下面。如果组件通过测试，就放在完成栏下面。这样一个组件就走完了整个开发流程。实际开发中发现，由于测试实际上是在所有组件都完成开发后才执行的，所以订单放到自测阶段就基本上可以视为开发完毕，开发人员就应该去领新的订单了。
WEBIM项目中订单用便签实现：
WEBIM开发中，每个订单对应的是一个开发组件，标记了组件名称，类别，开发人员，预估时间。对应开发组件模型如下：
Name Events
Extends
Property _$events
Methods addEvent
removeEvent addEvents
removeEvents fireEvent
SP 0.25
Name为组件名称，也是开发时的小文件名称。
Extends为该组件继承自哪一个组件。
Property为组件应当具有的属性。
Methods为组件应当具有的方法。
SP为开发该组件可能的耗时。
1SP表示1个工作日（单个成员8个工作时）项目开始前的集中会议非常重要，需要所有开发成员集中在一起执行。应当集群体之力一起分析项目，拆解组件，但注意非关键性的细节不要过分追究，避免会议耗时。应当有一个文档保存所有画出的组件模型。燃尽图燃尽图可以非常形象的表现项目执行进度。
以下图举例：
X轴原点为项目开始日期，末端为项目结束日期。每天为一格。
Y轴为预估的工作时。
在项目准备会议结束时，冲刺订单已经预备好，就可以统计出预估的总工作时，将其标在
Y轴顶部。
每天检查实施白板，确认哪些订单已经完成，然后计算剩下的总工作时，然后在图上标记一个点，点的
X位置为第二天的日期，
Y位置为剩下的总工作时。
在起点坐标（X为开始日期，Y为总时间）和终点坐标（X为结束日期，Y为0）之间画一条直线，这就是理想状况下的项目完成进度曲线。
在项目执行中，发现曲线高于理想曲线，说明项目有可能延期，需要增派援手，或者催促成员加快进度。如果曲线低于理想曲线，说明项目有可能提前完成。
经验：
先看一下WEBIM项目的燃尽图：不可思议的是曲线一开始居然还有个增高。这说明一开始时间预估就不完善，开发中增加了预估时间。一开始认为订单放到完成，才能从工作时中减去时间，但由于测试实际上是在所有组件开发完成后，所以当订单放在自测，就从工作时中减去时间。这个图后期并没有完成。实际上是因为项目组件提前在12日都开发完成，但是新的问题出现：组件完成后还有一个联调的时间，未被预估在内。还好最终还是保证了项目按期联调完毕。
燃尽图后期的陡峭往往说明了任务分割与时间估算的不完善。但是有时这不可避免，可以考虑用完成度百分比乘以工作任务，或者将任务分阶段（将预备阶段，开发阶段与测试阶段分开）来平缓燃尽图曲线，达到更细致描绘工作进度的目的。可以考虑联调前的订单被开发完成了70，联调完毕才标记为100%，然后从总工作时中减去剩下百分比的时间。一开始预估完总工作时间后，应当乘以一个系数（大于1，从未预估过时间，建议这个系数接近甚至大于2，否则建议为1.5）。以这个时间为总工作时间，以应付项目执行中可能遇到的突发事件。
总结
Scrum效率相当明显，执行过程中可以使成员中开发速度缓慢的地方被迅速暴露出来，使得项目中可能存在的问题被极早暴露，以便进行针对性的解决。
开发中要求成员有充分的自发性，自己如果能提前完成订单，应当负责起其他订单的开发任务，减轻项目整体的开发负担。
一开始的沟通会议非常重要，必须当面进行沟通会议，不可以有缺席。以保证每个成员对项目的细节都有所了解，可以负责任意一个组件的开发。
Scrum不仅仅用于软件开发，它是一种计划管理方式，适用于被限制时间，需要多人协作的团队项目。
网友评论