软件项目“免坑”指南
转自:http://www.cnblogs.com/MeteorSeed/archive/2012/04/08/2427966.html
目录
“谁也无法改变现状,唯有无数程序员血洒大地,才能使项目重建天日。”这一点也不夸张,软件项目做烂了就是个坑,参与者也不过是填坑的。就像是在魔兽世界战场遇到国家队一样,你赢也赢不了,出也出不去。
当我们进入一个项目时,通过不断观察我们可以发现我们的项目到底是不是一个坑。造坑的项目,往往具有某些“臭味”,以下是我的一些认识,这些“臭味”即是项目健康状态不佳的明显标志:
软件项目涉众众多,造坑的多为项目实施团队内部,而究其原因也是多方面的,但是始终离不了项目的四个维度——时间、范围、成本、质量。很多时候客户并不具备软件项目的实施经验,而实施团队为了迎合客户意愿,也会多多少少的在这四了维度上做文章。资源、时间不足,轻质量重功能,往往成为造坑的契机。所以,不用怀疑,造坑的往往是我们自己。很难理解,真正挖出大坑的人,最后也是填坑的人。一个人很容易被外部事务所左右,就如“同假的多了,真的到成假的了一样”,多数人不愿意在一个新环境中表现得特立独行。但也有老的程序员对我说过:“当别人做错了,你就不要跟着去做!”所以,我认为工作就是工作,不需要我们在其中融合多少兴趣,也不要求我们有过多的付出,但对于工作的成果则要求我们认真的对待。俗话说:“拿多少钱,办多少事!”如果多少有些团队意识,能够对自己的工作负责,那至少在意识上,我们能给自己少造些坑。
(一) 清除盲区
以下观点,仅是我对软件项目中一些错误认识的归纳:
(二) 参考建议
在构建期间处理需求变更
- 核对需求,评估质量:如果需求不够好,停下来,把它做好再开始。
- 确保每一个人都知道需求变更的代价:让客户知道需求办更并不像在Excel上进行几个修改那样容易,“进度”和“成本”是你最有力的武器。
- 建立一套变更控制程序:固定的变更控制程序让你知道在什么时候处理变更,让客户知道你会处理他们的提议。
- 使用能适应变更的开发方法:迭代与增量。
- 放弃这个项目:如果以上提议没有一条奏效,需求变更极其频繁,那么,评估你的项目,考虑放弃它吧,继续下去你只会越陷越深。
- 注意项目的商业案例:性价比,没必要满足超出项目成本的需求。
优质内容筛选与推荐>>
- 关于加班做IT的加班是很正常的,但加班要加的有意义,而且不应该长期加班。必须针对关键路径上的工作进行赶工,而不是做些无法加快整体进度的工作。而且,应当安排调休,而不是支付加班费。其主要原因也是我不赞成加班的原因——疲劳更容易引人缺陷。加班无疑会使人疲劳,每个人都想尽快结束手上的工作后回家休息。在长期疲惫的情况下,人员的工作效率会下降,士气会低落,非正常离职率增加,最重要的是疲惫的团队很难保证软件的质量,缺陷在不知不觉中引人,在后期无疑会为此付出代价。项目的总成本和周期,都会随着引人缺陷的数量的增加而倍增,而且发现的越晚越严重。
- 做好版本控制和配置管理版本控制和配置管理是必须有的,即便是再小的项目也不能忽视,必须加以重视,一旦版本混乱,多多少少会对构活动造成影响。所以,平时不要偷懒,管理好每个基线。
- 授权的好处授权好处多多,包括:一,减少管理者工作量;二,对人员有意识地进行锻炼,培养储备人才;三,提高人员对项目的参与度,从而提高士气。
- 乐观管理与悲观管理乐观与悲观完全取决于人的性格,一般来讲多数倾向于乐观,应该清楚这两种性格在项目中的优势与劣势。我本人倾向于悲观,可能是性格使然,但悲观的管理至少不会误事。乐观管理的优势在于,很容易营造气氛,擅长给客户或领导描绘一个美好的未来。这种作风,前期很舒服,但后期可能要吃苦了。乐观管理容易出现的问题是对风险的预计不足,不能预留充足的缓冲时间,没有准备足够的预防措施。其表现就是,在进行进度计划时,总是认为今天的问题今天可以解决,已经修复的BUG将不会再次出现,用户需求是最后一次变更,等等诸如此类的乐观想法会使管理者蒙蔽双眼,而没有做足风险应对,其结果就是不管怎么加班就是赶不上进度,因为进度计划被设计为最顺利的情形,而不是现实场景。悲观管理的好处是,为潜在风险做足了准备。但悲观管理有一个非常大的缺陷,就是“过度控制”,可以比喻为“疑心病”(小心的都有些病态了)。其表现是为:按照之前的措施,发现遗漏了一个问题,那么悲观管理者会在之前措施基础上增加新的保障措施,然后又发现遗漏了一个问题,之后会继续追加保障措施。乍看之下没啥问题,因为是在不断地进行过程改进,但问题出在保障措施的增长速度过于惊人,称其为“疑心病”一点也不为过,悲观管理者容易在很小的地方施加过多的控制,造成人日的浪费,而忽略掉本应该关注的更为重要的问题。不管那种性格的管理,清楚自己的弱点总是好的。
- 有效的沟通,不要踢皮球软件项目因为其本身的复杂度和涉众众多,所以更加需要沟通。沟通问题是所有大型项目都共用的问题,在大多数团队中往往也不认为沟通是个问题。但我还是想请读者认真对待沟通,比如邮件。邮件可以回复的慢,但请回复邮件。当我在一个连发出的邮件都没人回复的团队中工作时,除了无法解决问题,让我感受到的只有无奈以及冷漠。
- 客户是我们的朋友把你的客户当成朋友,客户是我们做重要的资源之一。在每个客户背后往往隐藏着更多潜在的客户。我们必须清楚,客户作为非专业人士,其可能并不理解我们的工作,在项目执行阶段产生摩擦是难免的。但是,这些都不能成为我们迁怒客户或故意在工作中放水的借口。即便是为了项目能成功收尾,我们也必须维护好与客户的关系。
- 不要超前设计,不要项目镀金超前设计和项目镀金都是不可取的,因为他是在浪费资源。满足需求以外的东西,不会对你的项目有任何好处,但是却可能引人缺陷。
- 总结经验教训必须对阶段进行经验教训总结,没有什么比这些收获更有价值。这样文档就是组织的资产,是以后类似项目的参考和依据,并在持续优化方面发挥更为重要的作用。
- 不要让会议和文档拖了团队的后腿“当船快要沉的时候,我们需要的是一个发号施令的领袖,而不是开会。”软件项目的核心问题是降低复杂度,越是复杂的项目就越需要沟通,但别让开会拖了我们的后腿。没有必要的会尽量少开或不开,要常开会,开小会,每次会议就几个相关干系人碰头沟通下就可以了,没有必要扩大为全员参与。冗长的讨论应该适时的终止,毕竟会议室上只能做出决策,而解决问题还得在会下。所以我认为应该精简那些冗长的会议,别然开会成为我们的工作。此外,要时刻谨记客户最终需要的是可以良好运行的软件产品而不是华丽的文档。所以,文档要恰到好处,写的再漂亮的文档没有完备的系统也不过是废纸一堆,别丢了西瓜捡芝麻,可以正常工作的软件才是我们的工作重心。
- 核对表的你的好助手就像飞机工程师在检查飞机时使用核对表一样,软件项目也可以大量使用核对表。核对表可以帮助检验文档的质量,降低缺陷数量,以及改进项目管理。好的核对表,是你工作中的好助手。
- 小范围的受控好过大范围的失控要注意控制的粒度,事无巨细。根据项目规模,人员构成,要采用不同的控制粒度。评估可控范围,并不是控制越广越好,控制不了就是失控。 对无暇顾及的地方授权别人管理是个可行的做法。即便是小范围是受控,也好过大范围的失控。一个失控的项目,谁也不知道其会走向何方。
1、python爬网页中文乱码问题
2、对搜狗输入法的评价
3、AndroidMainfest.xml文件分析【转】
4、实现easyui datagrid在没有数据时显示相关提示内容
5、Myeclipse学习总结(3)——Myeclipse中的代码格式化、注释模板及保存时自动格式化