IT虾米网

项目微管理8 - 流程详解

admin 2018年05月27日 程序员 149 0
流程可以说是非常惹人讨厌的东西了,四代见过太多的公司实行的繁冗的流程了。
 
为了办一件事,要走太多的步骤,效率低下不说,最终还会形成一种叫“官僚作风”的习气。这种如同癌症一样的顽疾不断毁灭着一个又一个的团队。那么没有流程不就行了!大多数创业团队如是说。
 
创业团队也需要流程吗?

 
从四代的经历看来,不是创业初期没有流程,没有流程大家怎么合作呢?
 
创业初期有的是流程,只不过没有书面化而已!仅仅是没有书面化而已!比如,什么时候规划,什么时候测试,什么时候发布,怎么解决问题,怎么响应反馈,哪一个不需要一套对应的流程?
 
只不过创业初期人比较少,当面交流就可以了,不需要一套书面化的流程。而书面化的流程应该在团队磨合到能正常产出的时刻起,就应该书面化作为正式的团队文档,这样由于有了个正式的开始,当创业团队逐渐壮大,人数越来越多的时候,就可以不断的充实和调整这个流程,让它随着团队的成长而成长。
 
 
 
这就是即使PC团队目前只有两个人,四代仍然坚持要创建团队工作流程的初衷。
 
版本发布流程

 
研发团队最主要的流程应该就是版本发布流程了,也就是常说的Release流程,她真正的描述了每个版本完成的基本工作,包括完成的内容,完成的时间,完成的标准,对紧急情况的处理等等。
 
在经过数次的修正和调整后,四代的团队目前试着实行的版本发布流程如下:
 
需求收集

 
流程的起点是收集本次版本需要完成的需求列表。收集需求可以说是软件工程中最难搞的一部分了,偏偏它们还是软件研发后面各个步骤的基础,俗话说的好“不满足客户需求的软件都是耍流氓!”。
 
不过对PC团队现状来说,这件事又不是什么困难的事,因为PC软件的研发停滞了一个阶段,客户对软件的需求早就堆成了小山。
 
四代需要做的就是将这些需求整理一下,结合软件的现状,给它们设定好优先级和顺序。不过为了应对一些紧急的需求,四代还是增加了一个环节:需求收集阶段。
 
 
在需求收集阶段,四代会面向全公司成员,包括研发人员,测试人员,设计人员,客服和市场,发布征集软件本次研发功能的建议,也就是从所有人那里收集一些客户紧急需要的功能。
 
这个阶段不是必走的步骤,当四代觉的这个版本的功能研发任务已经足够紧急的时候,就不会发布这个公告。不过四代还是觉得,正常情况下每个版本计划的第一件事就是发布这个公告,这样能保证研发不会偏离客户太远,这个太重要了!
 
当然了,这种做法也有个不好的地方,那就是需要各团队所有人配合,坦诚的发表自己的想法。
 
这个似乎有一些难度,因为沟通几乎是每个团队最难的事了,何况还是跨团队,人家理不理你还是个问题呢,那还谈得上配合。所以实际操作的时候,四代都是拜托各个团队的直属经理,让他们帮忙收集,效果还是会好一点点,不过大部分时候,也可以忽略不计。
 
上面这个环节主要是对外的需求收集,紧接着就是对内需求收集的环节。结合目标管理的理论,这一部分需求的收集包括三个部分:产品经理的需求,他代表公司,项目经理的需求,他代表团队,团队成员的需求,他们代表自己。
 
需求筛选

 
收集到需求后,接下来就是需求筛选了。
 
这个不用多说,四代自然是需要先按照优先级排好序,再根据规划的Release的时间的长短选择合适的需求。
 
 
经过多次的试验,四代觉得一个Release在10个周左右对PC团队比较合适。在这个时间中,真正用于编码的时间是4周,其中还包括1周专门用于修复比较严重的Bug。其余的6周包括测试,发布,紧急情况处理,小版本处理等。正常情况下,需求筛选就可以按照这个时间来。
 
编码开始

 
需求筛选好以后,就是团队成员自行领取任务了。
 
接着,四代会和团队成员一起把自己手上的需要设计的任务设计一下,并组织项目所有相关人员举行几次会议,把这些设计过一遍,需要的调整的就调整,达到大家对所有这些的需求的理解是一致的。
 
虽然事先大家不可能想清楚所有的细节,不过认真的思考总是会为大家带来一个好的开端。在开发的过程中,还会发现很多新的细节,不过没关系,设计从来不是死的,设计从来都需要一个良好的起点,然后在此基础上不断演化。
 
在编码的开始阶段,四代会和团队每个人把他们的任务细分到可以每1-2天都能提交的程度,这样可以很方便的控制任务的进度和时间分配。
 
 
在编码的过程中,四代唯一强调的就是代码规范,这是四代的底线。做不到的人,四代会试着了解做不到的原因,并提供适当的方法帮助其做到。在四代帮助下仍然做不到的人,四代也绝不姑息,四代应该会马上进行劝退,不过到目前为止还没有发生。
 
进入内测

 
编码完成以后,就是PC团队内测了。
 
这一部分测试全部是围绕新功能和修复的Bug展开,毕竟把一个漏洞百出的软件交给测试人员测试实在是丢人的一件事,所以四代会带领所有开发人员全身心投入到内测中。
 
 
由于开发人员对代码十分了解,一般经过一定时间内测和修复后,除了一些不易修复或者不是很严重的缺陷,大部分主要流程中的缺陷都会被修复。
 
当然了,这是理想情况,在后面实行的过程中,还是出现了在开发时间很紧的情况下,内测做不好的情况,这是四代需要思考和调整的,四代需要顶住来自各个方面的压力。
 
集成测试

 
再接下来就是开发人员和测试人员共同参与的集成测试了。
 
 
集成测试是最重量级的测试,目前都是手动执行的。
 
集成测试的第一阶段和开发内测的目标是一致的,就是保证新功能和修复的Bug工作正常,发现问题就评估,然后根据重要程度修复。
 
第一阶段测试结束后,第二阶段就是全面的测试了,说白了,就是软件所有功能的测试,非常辛苦而且枯燥,但是又不得不做。
 
这一阶段测试内容非常多,包括软件所有功能的测试,各种版本的测试,各个平台的测试,用户真实数据的测试,大数据量的测试。这些固定的测试内容很多也是后面自动化的目标。
 
第三阶段是探索型测试,说白了,就是无限制测试,也就是脱离测试文档和常见的套路,完全不按常理出牌,执行一些不合理的操作,测试软件的稳定性。
 
这个测试三板斧非常重要,它们结合起来基本做到了对软件全方位的覆盖,所以也是非常耗时的过程。经过几次的试验,这些测试的时间平均都在3周左右,和编码时间也差不了多少了。
 
四代相信,只要成本允许,测试多花点时间,收益总是正的。
 
发布标准

 
为了便于划分测试的优先级和重点,四代把软件的所有功能分成两类:核心功能和辅助功能。核心功能指的是最为核心的资源管理模块,辅助功能指的是登录,注册,人员管理等模块。
 
 
四代和团队决定是否发布软件的标准:就是在当前版本中,核心功能没有1级的Bug,辅助功能没有0级的Bug。
 
所谓0级Bug指的就是不修复软件就不能使用,或者用户强烈要求修复的Bug。而1级的Bug指的是不修复该Bug的话,软件用起来不方便,但是有方案可以替代的Bug。所以PC软甲发布的标准简单来说就是当前版本没有0级Bug,核心功能还不能有1级Bug。
 
无奈的审核和收录

 
测试以后发布就比较固定了,就是加密打包,然后拿到各大流氓的软件管理中心进行审核和收录。为啥叫“流氓”呢?大家都懂的,卸载又卸不干净,不认识的软件就报可疑,或者是直接杀掉。针对这件事,四代与鼬已经不记得与他们交涉过多少次,费了多少唾沫星了!
 
收录成功后就发布升级包,客户端软件检查到升级包就进行升级。
 
发布后的事

 
发布以后,如果有一些紧急的问题,然后就是2周左右研发小版本的时间。
 
小版本的测试比较简单,基本都是根据代码的修改范围,划定测试的功能范围,有重点的测试一下,然后再测试一下核心流程就可以发布了。
 
 
发布成功后,接着就是团队面对反馈和进行反思的时间了。
 
这个部分怎么强调都不过分。因为不接受反馈,不进行反思的团队就像一潭死水一样,永远无法成长为成熟的团队,所以四代无论多么忙,多么没时间,在发布后都会找时间完成反馈反思会议。
 
团队功能的细化

 
在后面的实践中,随着专业的产品团队和设计团队的成立,产品的研发细节也在不断的调整中,很多需求方面的事情不再由开发团队完整的负责,而是有了专门的团队去主导。这样有了专门的分工,产品更加专业了,但是总体上说,这一套流程基本还是没有太大的变化。
 
 
 
好吧,整个过程和大部分的敏捷过程都差不多,确实也没有什么太多的奥秘在里面。如果非要说奥秘的话,那就是参与度,四代不断尝试在各个环节中增加团队成员的参与度。
 
当然不仅仅是在研发流程中,四代还有一整套的方案来在各个方面提高大家的参与度,所以,即使是流程,也是和团队的其他方面息息相关的,并不是孤立的存在,比如说与产品质量,就是密不可分的。
 
说起质量,很多人都会立即表示无语,甚至激进的测试团队会当开发人员的面,大声骂娘。唉,测试的那帮妹子也不容易哈,四代想。

发布评论

分享到:

IT虾米网

微信公众号号:IT虾米 (左侧二维码扫一扫)欢迎添加!

项目微管理7 - 始计详解
你是第一个吃螃蟹的人
发表评论

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。