IT虾米网

项目微管理9 - 质量

mate10pro 2018年05月27日 程序员 1285 0
说起质量,程序员都是一把辛酸泪啊。
 
渐行渐远的质量体系

 
对于质量,不光每个公司非常重视,很多的国际化组织也非常重视,于是他们纷纷搞出了种种质量体系,于是,大批热衷于考试的同学们又有活干了,于是,大批的培训机构也从心里乐开了花。
 
 
渐行渐远的混账质量体系,四代就不愿意多想了,四代还是把目光集中在了实际的项目质量上。如何来衡量软件的质量?这个倒是大家都懂,根据Bug数量嘛!
 
提起Bug,四代想起一个段子:“问:程序猿最讨厌康熙的哪个儿子。答:胤禩。因为他是八阿哥(bug)”。
 
 
确实,Bug的数量客观的反映了软件的质量,所以大量的公司把Bug的数目列入开发人员的考核指标中的做法就不足为奇了。既然这样,为了提高软件质量,我们就减少Bug数目嘛,听起来无比正确,无比英明!甚至还有的兄弟直接提出:应该 0 Bug嘛!可是实际情况是这样的吗?
 
Bug是怎么炼成的

 
要真正的了解Bug的意义,需要首先来了解一下Bug的组成。通常来说,实际的项目运作中,开Bug会出现在如下场景中:
 
 
1. 软件实际功能与预期的表现不同
 
这个不需要多说了,实现的功能和设计的不一样,这个是狭义上Bug的全部含义,这也是传统意义上软件质量的全部含义。这帮小子,看我怎么收拾他们,哼!这是大多数项目经理看到这些Bug的第一感觉。
 
2. 软件缺少一些功能
 
少一些功能,严格来说,不是软件的缺陷,很多的公司也是采用各种文档和工具来管理这些需求,行不行?非常行!只不过作为一个以敏捷为核心理念的“互联网+”时代的团队,四代觉得不用这么麻烦。
 
敏捷精神大幅削弱文档的重要性,需求文档可以作为收集需求时的重要方式保存下来。不过对于团队来说,把它们理解后记入Bug也是一个非常灵活的方式,虽然有时候往往也会需要一份详细的设计文档来描述设计细节。
 
3. 用户对软件功能不满意
 
这货不是说功能没有,也不是说开发错了,而是开发出的功能与客户的习惯不匹配,不习惯自然就不满意了,于是电话来了,客服MM必须要安慰一下,然后开个Bug提交给研发部门,谁让客户是上帝呢!
 
 
不过很明显很多人对上帝的理解有误,认为他钱花了,就是大爷,态度非常强横,更过分的是很多人还没花钱也这么强横。
 
4. 团队对功能的改进计划
 
这一部分主要来自团队内部对软件的改进意见,大部分可能是从技术角度来说的,比如重构,架构等。
 
从长远的来看,代码的质量也严重影响着软件的质量,这里代码的质量可不仅仅包括正确性,更多指的是代码的可读性,传承性,也就是:简单,简洁,简短,灵活。
 
在四代的经历中,这几乎就是开Bug的几个最主要的动因了。除此以外,还有许多无法纳入正常分类的各种稀奇古怪的问题,大家通常的做法也是开Bug。
 
纵观上面所有的类型,简单的用一句话来总结就是: Bug是多样的,不仅仅是质量的指标,更为贴切的说,Bug是协同工作的工具
 
Bug是合作的工具

 
这么一说,你还觉的使用Bug数量来衡量开发人员的绩效还有道理吗?
 
其实在四代的经历中,只要是尝试这么做的团队,几乎都会把开发团队逼急,以致于时常看到开发和测试大撕逼的情形。
 
四代至今还清晰记得在某年的年会上,某测试团队自编的一个小品。这个小品的场景模仿的就是植物大战僵尸,只不过植物换成了开发团队,僵尸换成了高举着Bug的测试团队。
 
 
在一波波Bug的来袭中,开发和测试之间不断斗智斗勇,最终在一大波Bug来袭中,无力回天的开发们终于祭出了最强的技能-Postponed,就是延期处理,于是世界清净了。
 
四代用大拇指都可以想象得到,演这场戏的时候,测试团队是多么的无奈,而开发对于Bug是多么的抵制。因为Bug代表着绩效不好,代表着实际利益的损失,这就是很多开发团队一听到开Bug就急眼的原因。在这种情形下,Bug代表否定,这就是开发团队的后顾之忧,安全隐患。
 
而对于斗争的另一方-测试团队来说,一旦Bug数量也成为衡量团队的绩效的指标的话,那么效果立竿见影,开发团队和测试团队立即水火不容,这对于团队来说真的是最为糟糕的事情了。
 
 
于是,四代在确立考评精神的那个时刻开始,就立即将Bug排除在外了。这样,开发没有了后顾之忧,测试没有了利益驱动。
 
而且四代还会不断的强化Bug合作的功效,鼓励大家有什么问题就多开Bug,于是大家可以平心静气的对待Bug了,大家不再害怕Bug了, Bug终于恢复了其本来的面目:合作的工具,质量的表现!
 
论项目经理技术必须过关

 
这样一来,很多人一定觉得天可能会塌下来,对于那些滥竽充数的开发来说,没有质量的概念了,那还不就随便搞了,继而,劣币驱逐良币,整个团队就不好了。是吗?很多人一定是这么想的,四代如是说!
 
在四代的周围存在大量这样的人,事事追求完美的结果,如果不可以就不会去做了。这样的同学总是期待通过考评一件事把所有的绩效问题都解决,也希望通过Bug把所有的质量问题都解决。这样考虑问题往往缺乏系统性,四代以前也是这么思考问题的。
 
不过,四代现在的思路就是,既然单点发挥了最大的优点,但是有缺点怎么办?那就通过系统的其他点来补充,这就是 四代的团队建设理念:以系统代替单点,系统内通过互补来达到平衡!
 
 
如果你足够细心的话,你会发现,上述Bug类型中有两类是与代码质量息息相关的,就是第一个和最后一个:功能的缺陷和代码改进计划。对于这两类Bug,代码质量起着至关重要的作用。
 
于是,对于四代来说,非常大的一部分时间就应该花在代码质量上,而这不仅要求四代本身的代码质量水平要比较高,因为他要判别代码的质量的好坏,而且要求四代拿出一些规范来约束团队的开发流程和测试流程。
 
从这两个角度来说,做好一个项目的质量管理,至少需要两个方面的准备:技术上的准备和管理上的准备,对于很多的传统的公司来说,需要两个人来完成,一个是技术经理,一个是项目经理。
 
不过在“互联网+”时代,团队小微化。四代觉得,完全可以由“项目经理一个人来主导,团队配合”来达到这个效果。由于要主导这件事,所以,四代一直坚定的认为:软件项目经理必须首先是一个优秀的程序员,否则他不会深刻的认识到代码对软件质量的巨大影响。
 
 
四代见识过太多的这样的半吊子项目经理了,本身技术根本不过关,但是机缘巧合走上了管理的路子,虽然他们也知道质量很重要,但是也就仅仅知道而已了。
 
他们根本不知道项目的代码可能已经乱的一塌糊涂,他们意识上根本没注意到这个,他们还在满天找些不太靠谱的原因来解释这种现象。稍微好点的项目经理也许还会制定些合作规范来改善外部的条件,殊不知根本原因就藏在项目内部-代码质量,它根本没有被重视!
 
历史上无数团队或国家的灭亡都归结于一件事:祸起萧墙,软件也是一样。
 
项目质量保证二重奏

 
为了保证项目的质量,四代做了两件事:第一件事是制定代码规范和审查机制,这个已经运行,这是从代码上保证,也就是代码质量;另外一件事就是建立团队唯一正式,也是最重要的文档-测试文档,这是从测试和文档上保证,也就是软件质量!
 
俗话说的好“冰冻三尺,非一日之寒”!代码质量也不是一步达到的,而是经过多次精心的修改而来的,这个过程就是重构!那么重构到底是在干些什么呢?

评论关闭
IT虾米网

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