软件项目“免坑”指南

发表于:2012-4-25 11:11

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:womendu    来源:51Testing软件测试网采编

  “谁也无法改变现状,唯有无数程序员血洒大地,才能使项目重建天日。”这一点也不夸张,软件项目做烂了就是个坑,参与者也不过是填坑的。就像是在魔兽世界战场遇到国家队一样,你赢也赢不了,出也出不去。

  一、坑有多深?

  当我们进入一个项目时,通过不断观察我们可以发现我们的项目到底是不是一个坑。造坑的项目,往往具有某些“臭味”,以下是我的一些认识,这些“臭味”即是项目健康状态不佳的明显标志:

  ● 编码规范形同废纸,代码质量低下。每个项目都有编码规范,但真正严格实施却是另一回事。太多的项目把编码规范作为形式的存在,没人在乎让开发人员写出“人能读懂的程序”,注释和命名也成了开发人员的随心所欲。project上永远只有开发任务,而几乎找不到单元测试的时间和代码审查的时间。在高压进度之下的项目,显得如此山寨。当我们还在抱怨自己工资低的时候,就先看看我们的程序还能称作OOP吗。

  ● 缺乏文档或文档质量低下。前期文档很重要,不论是框架的API使用手册,还是需求或设计文档,以及各种既定流程的规范,不同种类的模板及核对表,等等这些文档,对于项目来说都是非常重要的资源。而往往有些项目,这类文档就是交由非软件行业的人员来编写,或者前期根本不打算在文档上浪费时间。这就导致了,缺少相关文档或文档质量低下,在软件构建过程中,开发者和团队,不得不为这种“表面工程”的产物而纠结。甚至会退回到前期准备工作,完成所需的文档。有些文档可以在后期补,但有些必须在前期进行准备,以保住团队降低风险,减少缺陷引人的几率并提高编码质量,如果前期这类文档没有做好,那么就会像考前不复习一样,自食恶果。

  ● 无尽的需求变更,永远追不上的进度。这是最常见也是最可怕的,因为无论怎样,我们都无法完成它。客户可能认为改个程序,就像改个Excel一样简单省事,甚至会使用可动用的一切权利和资源来推行变更。好吧,我承认这样的客户我遇到过很多。当我向客户解释过变更的代价并提供备选方案后,也就只能等待客户的选择了,这多少有些运数的成分,但也是无奈之举。

  ● 仅仅靠加班应对进度落后。进度落后并不可怕,可怕的是仅靠加班来追赶进度。这是问题的关键,长时间的赶工仍然无法赶上进度,这只意味着项目有某种更深层次的问题,已经不是单开赶工可以解决的了。留意那些长时间加班的项目,他们往往在管理上存在很大问题,发现这些问题,在你成为PM时,不要犯类似错误。

  ● 沟通无门。如果你在一个“叫天天不应,叫地地不灵”的项目里,那你最好省心吧。项目中沟通很重要,但总有些项目,领导的工作太忙,人就是找不到,发出去的邮件就是没人回,遇到问题就是自己扛。在这样的项目里也有一些好处,比如锻炼自己的自学能力,以及磨练意志与根性。不过这些,也都是我的自嘲。低效的沟通将导致不必要的返工,这才是我所痛恨之处。我最为恼火的一段经历是,甲方要进行变更,开了一周的会没人通知我,我的小组在这一周里完成了原计划的数个需求并进入到测试阶段, 但这些需求均被砍掉 。本来只有甲方告知是可以调整进度开发其它模块的,但最终演变为资源的浪费。可见,沟通是多么的重要。

  ● 没人关心质量。因为软件构建属于专业领域,客户并不具备相应领域的知识,由于这种信息不对称,助长了软件的质量低下。我们开发的软件可以是“低等级高质量”的,但不能够是“高等级低质量”的。但是,太多的项目不在注重编码质量,这与软件构建的复杂度有关,也与整个行业的风气有关。但不管何种原因,提高代码质量仍然应该作为团队的努力方向。团队应该奖励那些,编写高质量代码的程序员。如果你的团队奖励的是那些,“BUG杀手”(每天修改上百个BUG),而冷落那些缺陷检出数量很低的程序员,那么,你的PM是个不懂技术的,至少我本人认为,任何有技术背景的PM都应该奖励那些正在保持职业操守,认真对待需求,保证代码质量的程序员。他们为项目付出了更多,更多的异常处理, 更多的测试调试,更多的检查,更多的重构,虽然他们的进度并不快,但他们引人的缺陷数量很少。每个做过开发的人都会在质量和进度上做出取舍,而我敬佩那些选择质量程序员,因为他们才是真正拿开发当事业的人。在此,向所有努力提高代码质量的程序员致敬!

  ● 没人为缺陷买单,没人为自己的成果负责。需求产出了低质量的文档,设计没有进行充分的迭代,开发可以怎么简单怎么写,测试可以随意测测,没人为自己的成果中的缺陷买单,除了项目经理,他为项目承担唯一责任。当项目组所有人员都在混时,就是在给自己挖坑。这种缺陷的堆积,会像放射性元素在食物链中的堆积一样,早晚项目会因此而崩溃。

  ● 过高的离职率。这个是最明显的“臭味”,这说明我们的同行已经在这里无法忍受了。它所带来的恶略影响不光体现在可用资源的减少,还体现在对成员士气的极大影响。如果不及时改善,这将是一个非常恶性的循环,当往一个进度落后的项目中添加资源只会使进度进一步落后,而非正离职导致必须补充新的资源,资源从入职到培训都会对对团队产生震荡,并降低现行团队的生产力。一个频繁处于形成阶段的团队,很难要求其有什么凝聚力,团队问题将会凸显,尤其是在沟通上,在项目忙的时候很少能照顾到新人。花费在对新人进行培训,和与其沟通上的时间,很可能得不偿失。

  ● 团队中的不良情绪。不同团队开始扎堆并相互敌视,例如开发组认为设计组是一帮搞业务的白痴,根本不懂编程;测试组认为开发组的人就是垃圾,BUG提交了多少便还是无法关闭;PM开始抱怨,自己的成员不配合;成员开始抱怨,PM是个纯管理没资格指挥内行做事。等等,诸如此类的怨念会在团队中积累,并以某个导火索为契机爆发。面对现实吧,至少,我远没有自己想象的那样高尚。我承认我曾经会和别的程序员说:“你看XX他们写的代码...什么呀...”,这样的话。在过去我也吐槽过别人代码,这种做法是错误的,我为此表示歉意。现在,如果有必要,我会说代码有缺陷,但绝不会说他的代码不好。我希望,我们能彼此尊重。对于技术人来说,不尊重他的成果就是不尊重他的人,所以我还是建议PM在管理工作中,多用“缺陷”,少用“不行”、“不对”。但是,项目中也总是有些人,靠鄙视别人的成果来彰显自己的实力。这些人,有,但很少。至少我遇到的很少,遇到过几个,让他们的话语成为你学习的动力吧。我曾经被人讽刺UI做的太丑,之后我学会了SL和FLEX;被人鄙视基础太差,之后开始阅读《CLR Via C#》;我朋友被人嘲笑过数据库设计,现在人家也开始买书深造。团队中就是这样,我们无法管住别人的嘴,但我们可以管住自己的。少说多听,一鸣惊人,乃上上之策。不要受情绪的影响,保持一个平静的心。

  ● 没有项目或阶段的后评价。不对项目的阶段进行后评价,也意味着没人在乎你到底干了些什么,所有人都只是进度是否完成,而没有对完成的好坏进行评价。这也意味了,仅靠做好你的工作,你是无法得到领导的重视的。最终只有那些加班时间最长的程序员被领导认可。而能力强,口碑好的成员也只能在团队和客户中间留下传说。

41/41234>
《2023软件测试行业现状调查报告》独家发布~

精彩评论

  • 测试新新手
    2012-4-25 15:57:45

    太精辟和贴近现实了!必须赞一下!里面的问题都碰到过....

  • rossini23
    2012-4-25 12:48:31

    完了,这里说的问题在我们公司的每个项目上都有

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号