课程咨询 :13623629309

太原PHP培训 > 达内新闻 > 太原php培训:软件项目免坑指南(二)
  • 太原php培训:软件项目免坑指南(二)

    发布:太原PHP培训      来源:伯乐在线      时间:2016-08-17

  • 二、谁在造坑?

    太原php培训班

    软件项目涉众众多,造坑的多为项目实施团队内部,而究其原因也是多方面的,但是始终离不了项目的四个维度——时间、范围、成本、质量。很多时候客户并不具备软件项目的实施经验,而实施团队为了迎合客户意愿,也会多多少少的在这四了维度上做文章。资源、时间不足,轻质量重功能,往往成为造坑的契机。所以,不用怀疑,造坑的往往是我们自己。很难理解,真正挖出大坑的人,最后也是填坑的人。一个人很容易被外部事务所左右,就如“同假的多了,真的到成假的了一样”,多数人不愿意在一个新环境中表现得特立独行。但也有老的程序员对我说过:“当别人做错了,你就不要跟着去做!”所以,我认为工作就是工作,不需要我们在其中融合多少兴趣,也不要求我们有过多的付出,但对于工作的成果则要求我们认真的对待。俗话说:“拿多少钱,办多少事!”如果多少有些团队意识,能够对自己的工作负责,那至少在意识上,我们能给自己少造些坑。

    三、如何免坑?

    (一) 清除盲区

    以下观点,仅是我对软件项目中一些错误认识的归纳:

    写出能用的程序就行啦!

    我们应该首先清楚我们做的是什么,一个成熟的团队产出的可交付成果应该包括软件编程产品,相关文档,项目实施过程中的经验教训已经其它一些非形式的成果(培训)。这里,我们必须清楚的认识到,我们所开发是是编程产品,而不是我们个人的技术实践或大学的毕设。对于编程产品,我们必须认识到,其是产品级别的,必须保证质量,必须提高用户体验,必须考虑系统的诸多特性或维度。这一过程远比我们自己写个程序要复杂的多。设计需要不断地进行迭代;开发人员需要遵守严苛的规范,编写大量的注释和大量的异常处理;测试人员需要不断地进行各种重复测试,但是正是这种全局的规范,全体团队的不懈努力,才保证了我们的编程产物可以称之为产品。所以,一定要明确,我们要完成的是一个产品,而不是一个毕业设计,它不是一个人的技术实践,而是整个团队倾注精力去完成的最佳成果。我们可以轻松的实现客户的某些需求,但需求背后的某些东西,需要我们认真对待,比如安全性和性能等。实现功能的程序谁都会写,而写出高质量的程序的才是真正的艺术。

    尽快开始编码吧 !

    软件构件是一个精心设计的过程,其前期准备十分重要。在后期修复缺陷的成本要远远高于前期。因此,在项目执行前,前期的规化十分必要。在前期每发现一个缺陷,都会为后期节省大量的成本。

    需求怎么变了! 没有不变的需求。

    进度落后了就招人呗!

    这是种典型的错误认识,《人月神话》中已经说明的很清楚了——往一个进度落后的项目中注入资源,只会使进度进一步落后。虽然,这本著作成为PM必读之作,其思想也被业界所广泛认可,但是,还是会有很多管理者单纯的认为,通过注入资源能解决问题。对于这些人,只能让实践来检验真理了。

    软件质量保证是测试的工作!

    这是一种逃避责任的说辞。如果把代码质量比喻为减肥,那么测试无疑是一个磅秤,减肥工作还是要有开发人员来完成。所以,不要将代码质量都寄希望于测试工作上。即使是大规模的用户测试,其错误检出率也不足五成。而真正挑起代码质量重担的是代码审查。

    程序员你8小时就写了这么点代码? 让开发人员将全部时间都花在编码上是不可能的。开发人员需要时间预读文档,需要与相关干系人进行沟通,需要花时间来搜索资源。此外,可能还需要编写文档,参加会议,培训以及处理个人事务等等。这些时间都会无情的夺走编码的时间。程序员大约有近似20%的时间甚至更多会用在与编码无关的事情上(不算上班或聊QQ),所以不要错误的以为每个程序员每天能写8小时的程序。

    你今天写了这么多行代码真有效率!

    编码不是在扫地,比谁扫的面积大。不能单纯用行数来评价开发人员的工作量。评判的标准应该结合模块的复杂度,编码的缺陷检出量以及最终交付时可用代码的比例(实践表明,我们报废了大量的无用代码)。

    他今天把自己100多个BUG都改了,我们得在组里表扬下他!

    在我看来这样的领导不跟也罢,这就是让人相当无语的行为。好的开发者在提交测试前,觉得会对自己的代码进行走查和调试,甚至使用单元测试工具,因此其代码的缺陷检出量很小。这样的程序员,才值得被表扬。而那个一天改了自己100多个BUG的人,作为管理者应该想想,流程哪里错了,需要进行改进。

    设计我来定,开发你闭嘴!

    这样的例子也不少,这种做法有一种听起来非常合理的理由——保证项目架构的概念完整性。其解释为,如果将设计人员从开发人员剥离,那么就可以将架构的概念完整性统一,因为设计人员的数量比开发人员是数量要少的多,更容易统一认识。而这样做的项目组,也默认地认为设计组的技术实力要明显高于开发组。他们往往从开发组中选择优秀的设计人员到设计组,但也会有走眼的时候。其一,硬手没有被提拔。这时候多半是硬手对设计不满,并对团队管理层产生质疑,并想法设法进行沟通。如果处理的好,可能硬手会被重视,如果沟通无门,那之后,可能会充斥着抱怨和不满,以及人际关系的恶化。

    有些强硬些的可能会选择拒绝不合理的设计或更为极端的是离职。走眼的另一种情况是,挑的人干不了设计。这样往往就是让他锻炼,而不是撤换(彼得原理——每个人都会被晋升到他不适合的岗位)。这就郁闷到极点了,设计者将会与相应的数名开发人员进行一场旷日持久的暗战。其中,已经不只是个人的抱怨,甚至会演变成成员集体的士气低落,并最终促成小组的重组。我认为,有必要将开发人员纳入设计活动。应该参考开发人员的意见,其原因有三:其一,开发人员对实现相当熟悉,往往发现设计中的不足;其二,通过授权开发者参与设计,能让其感受到认同感,提升其参与项目的欲望,和责任心;其三,让开发参与设计,可以对设计人员进行储备,在需要时作为备选资源使用。

    客户(领导)说必须完成,我也没办法!

    这就是“领导一句话,劳动人民跑断腿!”这是非常典型的加班借口。软件构建过程如同耕种,你每次只处理它的一小部分,一点一点的加到整个系统,使系统一点一点的“生长”。这也暗示了,工作应该按部就班,正如春种秋收一样,各个环节有强硬的逻辑存在。所以,我们必须学会对不合理的要求说“不”。这里并不是说要拒绝客户的需求,而是指应该向客户说明情况并提出相应的备选方案以供参考。例如通过通过削减范围来达到按时完工的目的。PM需要向客户说明情况,并向其提供几套可行的解决方案,以促成项目向良性发展。

    我是领导,我来排进度!

    工作进度的安排不能是领导的单方决策,而应该参考做了解这项工作的人的意见。

    系统上线了,项目就算结束了!

    只有当可交付成果成功移交,项目进行的相应的收尾工作,项目的经验教训文档被总结和归纳,一个项目才算真正意义上的完成。

    (二) 参考建议

    做好前期准备

    前期准备很重要,如果在开始构建之前认真的地进行适当的准备活动,那么项目会运作的良好。充足的准备防止我们制造一个错误的产品。前期工作的好坏,多少会为这个项目的成功和失败打下基础。即使进入构建阶段,如果我们发现前期工作做的不好,也完全有理由退回去。前期准备工作和核心目标就是降低风险——一个好的项目规划者能够尽可能早地将主要的风险清除掉,以使项目的大部分工作能够尽可平稳地进行。目前,对后期影响最严重的风险是糟糕的需求分析和项目规划,因此准备工作就倾向于集中改进需求分析和项目规划。

    预先行其事,必先利其器 用软件武装团队提高生产效率,例如:版本控制,错误跟踪,信息发布,自动发布,CASE工具,调试工具,测试工具,文档管理,代码生成工具等等。

    分析项目类型,在管理和构建之间找寻平衡

    商业系统、使命攸关的系统、性命攸关的系统在整个项目阶段具备不同的控制粒度。需要根据项目的具体类型来确定管理的严谨程度,避免“过度控制”或“控制不足”。

    需求必须被冻结

    需求必须被冻结,如果需求不能冻结,那么谁来了都没有用。再强的团队也无法完成一个无尽的任务。

    变更必须走流程

    正确应对变更,变更并不可怕,可怕的是失控的变更。以下建议希望对读者有所帮助:

    在构建期间处理需求变更

    核对需求,评估质量:如果需求不够好,停下来,把它做好再开始。

    确保每一个人都知道需求变更的代价:让客户知道需求办更并不像在Excel上进行几个修改那样容易,“进度”和“成本”是你最有力的武器。

    建立一套变更控制程序:固定的变更控制程序让你知道在什么时候处理变更,让客户知道你会处理他们的提议。

    使用能适应变更的开发方法:迭代与增量。

    放弃这个项目:如果以上提议没有一条奏效,需求变更极其频繁,那么,评估你的项目,考虑放弃它吧,继续下去你只会越陷越深。

    注意项目的商业案例:性价比,没必要满足超出项目成本的需求。

    关于加班

    做IT的加班是很正常的,但加班要加的有意义,而且不应该长期加班。必须针对关键路径上的工作进行赶工,而不是做些无法加快整体进度的工作。而且,应当安排调休,而不是支付加班费。其主要原因也是我不赞成加班的原因——疲劳更容易引人缺陷。加班无疑会使人疲劳,每个人都想尽快结束手上的工作后回家休息。在长期疲惫的情况下,人员的工作效率会下降,士气会低落,非正常离职率增加,最重要的是疲惫的团队很难保证软件的质量,缺陷在不知不觉中引人,在后期无疑会为此付出代价。项目的总成本和周期,都会随着引人缺陷的数量的增加而倍增,而且发现的越晚越严重。

    做好版本控制和配置管理

    版本控制和配置管理是必须有的,即便是再小的项目也不能忽视,必须加以重视,一旦版本混乱,多多少少会对构活动造成影响。所以,平时不要偷懒,管理好每个基线。

    授权的好处

    授权好处多多,包括:一,减少管理者工作量;二,对人员有意识地进行锻炼,培养储备人才;三,提高人员对项目的参与度,从而提高士气。

    乐观管理与悲观管理

    乐观与悲观完全取决于人的性格,一般来讲多数倾向于乐观,应该清楚这两种性格在项目中的优势与劣势。

    我本人倾向于悲观,可能是性格使然,但悲观的管理至少不会误事。乐观管理的优势在于,很容易营造气氛,擅长给客户或领导描绘一个美好的未来。这种作风,前期很舒服,但后期可能要吃苦了。乐观管理容易出现的问题是对风险的预计不足,不能预留充足的缓冲时间,没有准备足够的预防措施。其表现就是,在进行进度计划时,总是认为今天的问题今天可以解决,已经修复的BUG将不会再次出现,用户需求是最后一次变更,等等诸如此类的乐观想法会使管理者蒙蔽双眼,而没有做足风险应对,其结果就是不管怎么加班就是赶不上进度,因为进度计划被设计为最顺利的情形,而不是现实场景。

    悲观管理的好处是,为潜在风险做足了准备。但悲观管理有一个非常大的缺陷,就是“过度控制”,可以比喻为“疑心病”(小心的都有些病态了)。其表现是为:按照之前的措施,发现遗漏了一个问题,那么悲观管理者会在之前措施基础上增加新的保障措施,然后又发现遗漏了一个问题,之后会继续追加保障措施。乍看之下没啥问题,因为是在不断地进行过程改进,但问题出在保障措施的增长速度过于惊人,称其为“疑心病”一点也不为过,悲观管理者容易在很小的地方施加过多的控制,造成人日的浪费,而忽略掉本应该关注的更为重要的问题。不管那种性格的管理,清楚自己的弱点总是好的。

    有效的沟通,不要踢皮球

    软件项目因为其本身的复杂度和涉众众多,所以更加需要沟通。沟通问题是所有大型项目都共用的问题,在大多数团队中往往也不认为沟通是个问题。但我还是想请读者认真对待沟通,比如邮件。邮件可以回复的慢,但请回复邮件。当我在一个连发出的邮件都没人回复的团队中工作时,除了无法解决问题,让我感受到的只有无奈以及冷漠。

    客户是我们的朋友

    把你的客户当成朋友,客户是我们做重要的资源之一。在每个客户背后往往隐藏着更多潜在的客户。我们必须清楚,客户作为非专业人士,其可能并不理解我们的工作,在项目执行阶段产生摩擦是难免的。但是,这些都不能成为我们迁怒客户或故意在工作中放水的借口。即便是为了项目能成功收尾,我们也必须维护好与客户的关系。

    不要超前设计,不要项目镀金

    超前设计和项目镀金都是不可取的,因为他是在浪费资源。满足需求以外的东西,不会对你的项目有任何好处,但是却可能引人缺陷。

    总结经验教训

    必须对阶段进行经验教训总结,没有什么比这些收获更有价值。这样文档就是组织的资产,是以后类似项目的参考和依据,并在持续优化方面发挥更为重要的作用。

    不要让会议和文档拖了团队的后腿

    “当船快要沉的时候,我们需要的是一个发号施令的领袖,而不是开会。”软件项目的核心问题是降低复杂度,越是复杂的项目就越需要沟通,但别让开会拖了我们的后腿。没有必要的会尽量少开或不开,要常开会,开小会,每次会议就几个相关干系人碰头沟通下就可以了,没有必要扩大为全员参与。冗长的讨论应该适时的终止,毕竟会议室上只能做出决策,而解决问题还得在会下。所以我认为应该精简那些冗长的会议,别然开会成为我们的工作。此外,要时刻谨记客户最终需要的是可以良好运行的软件产品而不是华丽的文档。所以,文档要恰到好处,写的再漂亮的文档没有完备的系统也不过是废纸一堆,别丢了西瓜捡芝麻,可以正常工作的软件才是我们的工作重心。

    核对表的你的好助手

    就像飞机工程师在检查飞机时使用核对表一样,软件项目也可以大量使用核对表。核对表可以帮助检验文档的质量,降低缺陷数量,以及改进项目管理。好的核对表,是你工作中的好助手。

    小范围的受控好过大范围的失控

    要注意控制的粒度,事无巨细。根据项目规模,人员构成,要采用不同的控制粒度。评估可控范围,并不是控制越广越好,控制不了就是失控。 对无暇顾及的地方授权别人管理是个可行的做法。 即便是小范围是受控,也好过大范围的失控。一个失控的项目,谁也不知道其会走向何方。

    达内时代科技集团致力于培养面向电信和金融领域JavaC++C#/.Net3G/Android3G/IOSPHP、嵌入式、软件测试、UID、网络营销、网络工程、会计、UEDwebUnity3D、大数据、童程童美等17大方向中高端软件人才课程与少儿教育课程。选择太原php培训,不再孤军奋战,轻轻松松做IT高薪白领。太原达内培训带领有明确目标的学子迈向成功之路!想找工作的求职者可以加QQ3373924515(太原达内就业服务部)咨询了解。

上一篇:太原php培训:软件项目免坑指南(一)

下一篇:中国将在2030年前后率先建成全球量子通信网

最新开班日期  |  更多

php高级开发名企定制班(剩2个名额)

php高级开发名企定制班(剩2个名额)

开班日期:12-29

php高级开发周末班(剩5个名额)

php高级开发周末班(剩5个名额)

开班日期:12-29

php高级开发免费试听(剩5个名额)

php高级开发免费试听(剩5个名额)

开班日期:12-29

更多高级开发工程师精品班

更多高级开发工程师精品班

开班日期:12-29

  • 地址:山西省太原市小店区学府街长治路高新国际A座24层
  • 课程培训电话:13623629309     全国服务监督电话:400-827-0010
  • 服务邮箱 ts@tedu.cn
  • 2001-2016 达内国际公司(TARENA INTERNATIONAL,INC.) 版权所有 京ICP证08000853号-56

    在线客服系统