Scrum 过程实践小记
严格来说,不能算是真正的scrum实践,但实践敏捷的过程本身也是一种“敏捷方法”,所以就算是“敏捷实践之敏捷开发方法-scrum过程”吧。
一、理论参考:Scrum的实践(该部分摘自网络)
1.Scrum团队(5-7个人的小项目组)。
2.
Backlog: 急待完成的一系列任务,包括:未细化的产品功能要求、Bugs、缺陷、用户提出的改进、具竞争力的功能及技术升级等,按优先级定义出来,这些任务可能不是完整的,甚至可能随时会更改或添加。
3.
Sprint(冲刺): 通常为30天的迭代时间,把Backlog中的每一项安排在Sprint中,由团队估算出所需要的时间(按小时记)。
每一次Sprint之后,一定要有可以交付使用的功能。
4.
Scrum会议: 这是与传统方式最大的区别,每天15-20分钟的Scrum会议,通常在每天的同一时间和同一个房间内举行(通常在午饭后举行)。 Scrum团队所有人都参加,也可以有旁听者(但不允许旁听者指手划脚)。
在这个15分钟的会议上,Scrum Master会询问每个成员三个问题:
a) 自上次Scrum会议后的1天里你做了什么?
b) 从现在到下次Scrum会议的1天时间里你准备做什么?
c) 你在工作中遇到了哪些困难?
每个成员在Backlog条目上所花费的时间会被记录到Spring
backlog中。 Scrum Master在会上对存在的问题提出即时的解决方案或指导,使团队不断向着目标前进。Scrum会议不同于项目会议,对团队来说,它起到了快速简报的作用。
5. 通过Sprint Backlog的分析,可以了解Backlog的进度,尽早的了解所发生的问题;
6.
管理者不在是项目或者团队的``老板", 而是帮助团队解决问题的协调者或是助手;
7. 每一次Sprint之后要review,团队按照既定的Sprint Backlog目标来演示完成的内容。
二、实践小记:
1.目前的团队刚好7人,且项目背景提供了可实践scrum的良好土壤;
2. 小版本迭代:从项目启动开始,采用最多不超过3周的阶段计划;各个阶段根据情况发布系统内部版本;
注意与传统方法区别,没有按固定周期月之类定计划,而是按目前能预见的周期内定计划。事实也是如此,根据几个月的实践经验,最多只能预测三周。
3. 每次阶段计划的时候:功能要求、Bugs、缺陷、用户提出的改进、具竞争力的功能及技术升级等,先从各成员处收集汇总成为项目任务,并以半天为单位,预估工作量;集体讨论确定优先级,然后排工作量,优先级低的任务被去除;
可惜的是无法做到让客户来帮我们定优先级;
不过期间我们通过“现场开发”(与客户方常驻一起)的方式,尽量让客户每天能看到系统,提出修改意见;实践证明,这种开发效率的确要高很多。
4. 每次阶段计划末:统计上个阶段每个人任务完成情况、团队阶段任务完成情况、成员工作自我评估满意度等,并在一个较大周期(一般是3月5日个小阶段)后绘制统计曲线;
注意这个曲线一方面可作为项目绩效参考,一方面也能够清楚反映项目计划、进度控制中的各种问题;
5. 每周都进行有1-2次进度沟通(每次20-30分钟):互相了解开发进度、遇到什么问题如何解决,需不需要调整细节计划、内部调整;其中一次是随机的,一次是固定的,每周五例会。
注意,在周五例会的时候,除了正常的工作沟通,还会进行心情指数、压力指数调查,并安排相应的娱乐活动,关注每个成员的情绪状态和满意度;
关于心情指数,压力指数,工作满意度等也会在一个大周期后绘制统计曲线,作为项目阶段总结,以持续改进;
其实每周例会最忌讳的是“公事公办”,应该尽量随意点,成为大家坦诚沟通的平台,谈工作,谈生活,发牢骚,情绪宣泄越畅快越好;有条件就到室外去开。
后来我们在周例会中还加入了30分钟技术交流时间,轮流有人自发就本周工作中的体会或经验进行简短技术交流,不用花太多时间准备,但对团队知识积累非常有益(交流完了,资料要求进入知识库)
6. 核心任务,或项目中的关键路径,采取更紧凑的日进度沟通:通常是对里程碑任务和新加入成员,采取日进度沟通。形式上不是“站立式会议”,多以该面对面随意聊天、或即时消息、个人或团队工作日志进行。
个人更推荐随意的面对面聊天,更符合我们的习惯,主导该关键任务的人,每天 早上来了,跟任务相关的人打打招呼:
“hi,搞定了没?”
“这么快啊,你家伙很厉害嘛。。。”
“哦,请假了啊,没关系的,先让××帮你看看。。。”
通过这种很随意的方式,即达到了进度沟通的目的,又让大家觉得亲切如朋友。如果太严肃,反而会隐藏很多问题。
7. 持续改进:一般在3-5个阶段过后,往往会进入项目下一“新进程”,这个时候把前面所有的进度统计、成员满意度统计、问题跟踪统计、技术问题等资料统统收集起来,进行分析总结,并确定下一阶段的改进措施和工作目标。
问题和改进措施非常重要。一般的做法是让每个人都提3-5个认为团队工作最需要改进的方面;然后集体再去排优先级,讨论可行的改进措施,然后制定成问题改进跟踪表(有个软件平台最好),到下个进程再循环;
以我们的实践经验,只要前面做好了,这份总结很容易,半天就可以整理好。
总结中一个非常重要的方面,就是对成员的管理。这个大阶段内,有人进步非常快,有人一直承担核心任务,有人总是赶在进度之前(是不是下次应多分配点任务),有人进度延迟较多,满意度也不高(是不是个人情绪问题,生活中有什么事情影响了工作?)
针对这些情况,私下里或正式或随意的面谈沟通非常重要。不解决好人员问题,后面就有很多不可控的风险。
8.
人员管理为核心:团队成员角色识别、个性搭配、技术能力搭配、团队成员技术发展目标和能力发展目标,及时面谈沟通等。
“授之以渔,非授之以鱼”:任何能够让成员提高的事情,都要绝对遵循这个原则,哪怕相对要花较长时间,但绝对是值得的;任何团队都会受制于很多现实条件,或许
团队里面有2个猪八戒,或许团队里面除了一个孙悟空,其他的都还不及沙僧,或是人员变更,这都是不可避免的,所以要提前做好预测,识别团队角色上的缺陷,尽早进行培养,才不至于落得被动。
关于成员发展问题,以前的太简单了,好像成员就是发展为项目经理,这就叫职业规划了,其实完全不对路。团队里面,当确定目标的时候,一定要从小处入手:如技术方面,某一方面的技术能力获取突破成为公司专家;某一技术弱项快速提高,达到中等层次;知识面拓宽;
如工作能力方面:语言表达、沟通能力达到团队最好水平,文档能力达到团队最高水平;如角色方面;发展为技术管理角色;发展为集成员和质量保证角色;发展为管理角色等。
这种发展目标实实在在,每个人都能很快看到自己的进步。当然,如果某位成员有成为项目经理的机会,也要鼎力向上级推荐。
9.
关于“结对”编程:在某些关键任务的设计、调试阶段,采用结对方法;
另外:新成员学习期间,每天有1-2小时的结对时间;项目进行单元测试期间,“变相结对”,首先:交换测试(你实现的我测,我实现的你测),然后共同解决问题。
10. 其他,针对项目经理:
1) 你是否还在当“队长”,而不是当“教练”?你是否还在“管事”,而不是“管人”?你是否还在惧怕你的成员能力超越了你?如果是,后面都不用看了,无法做到的。
2) 要做到前面所说,前期铺垫是非常重要的,你的团队成员都接受了你?你是否已经初步和他们建立了坦诚、同甘共苦的合作关系?
3) 你是否真的花了70%的时间在沟通和协调?
4) 你的团队角色都选好了吗?你的工作是否得到了上级支持?
5) 你是否总是主动向客户和上级汇报工作进展,书面的,面对面的?
6)你是否持续用分解的小目标来鼓励士气?
7) 是否经常在小目标达成之后通过各种方式激励大家(公布问题改进跟综表让大家随时看到团队的进步?一起活动,上班期间半小时聊天休息,邀上公司领导一起聚餐)
8)除了工作外,你是否了解每个成员的个人生活状况,并随时能灵敏感觉到部分成员的消极情绪?你是否尽全力帮他们解决了工作上,甚至生活上的问题?
9) 在去除某个资源障碍时,你是否真正做到了绝对客观和问心无愧?