为什么项目总是失败?

  1. 云栖社区>
  2. 博客>
  3. 正文

为什么项目总是失败?

zting科技 2017-10-11 20:58:00 浏览624
展开阅读全文

做了很长时间的开发,也带过一些项目,有过很多成功和失败的经历。

一些失败的项目不断促使自己思考如何才能把项目做成功,也看了一些关于项目管理和敏捷开发方面的书籍。

自己总结下来,发现项目失败的原因大概是两方面:

1. 缺少方法, 不知道如何应当使用那些方法来保障项目的成功。

这个方面可以通过请教、多看书、不断实践来提高。

2. 还有一个重要原因是人性的弱点,"超越规则"的侥幸心理。

近期报道的中国式的过马路,凸显了国人不遵守规则的心理。因为人总会认为自己是个特例,明知道规则的情况下,总是认为自己能够超越规则而能够成功或者避免惩罚。

这也是软件项目中同样的失败案例不断重现的原因,即使我们有前人总结过的经验教训。

比如:

你明知道这个项目不可能在3个月内完成,但是迫于老板的压力,你会觉得自己能够超越当前开发效率满足这个不切实际的幻想。

下面是我总结的一些团队开发的规范,只是初稿,非常欢迎园友有其它的建议或者补充。

"你我是朋友,各拿一个苹果彼此交换,交换后仍然是各有一个苹果;倘若你有一个思想,我也有一种思想,而朋友间交流思想,那我们每个人就有两种思想了。"

 

项目经理

1. 项目开始前组织培训
使用的工具和技术, 如git, log4net, Resharper, Redmine, NAnt等
项目编码规范
项目使用的框架和设计培训
2. 每日构建
每日构建要能够自动化执行。
覆盖以下内容来保证项目质量:
单元测试的代码覆盖率达到90%,每日构建能够成功通过
所有代码运行过程, log4net可跟踪
通过自动化的验收测试
每天使用NAnt做每日构建,运行单元测试,代码质量检查,代码重复检查,安装包制作和发布
3. 关于测试数据
在项目开始时,着手准备建立和维护一套数据库结构和测试数据,测试数据要达到以下要求:
测试数据应当全员用一套,可以方便的导入和恢复到初始状态
测试的数据库结构和数据要有版本管理
测试数据应当用相对有意义的数据,比如User Name 不能用asdfasdfas这种, 而用Peter, Jim等。
当bug发生时,如果可以通过补充特例的测试数据达到覆盖bug的效果,应当补全这部分测试数据
4. 每日的站会和分享
组织项目成员站会,关注项目block issue
成为站会的组织者而不是领导者,发挥集体成员的主动性来解决问题和分享经验。
分享的内容与重要,大小无关。可能只是发现了一个更好的Api的使用,一个变量命名不好的错误等。
让团队成为一个自主的,自我提高和修正错误的团队。
5. 关于知识分享工具
团队中不断建立的规范、知识、用户需求等,需要有种方式记录和传播。以避免进入新的成员时,只能依靠经验和记忆等不可靠手段来传递的方式。
推荐使用Wiki
6. 关于项目中使用的第三方API或控件
使用第三方API或控件时, 任何对商业使用收费,或者免费但不开源的,都需要得到客户的认可和同意付费
团队需要考虑第三方API或控件的稳定性,和可维护性,避免开源项目暂停或者停止维护等问题
如果是和客户的技术团队合作,即使使用开源和免费的,也需要得到对方的同意。


开发人员规范:

添加注释
1. 类注释
类的注释,需要描述类的功能、依赖和如何使用
2. 代码注释
复杂的逻辑应当添加注释
3.使用Region
使用关键字region注释使代码更加整洁
4.全局变量注释
每个全局变量需要写注释
5. 程序流程变化注释
switch, if, while 等条件判断地方必须写注释
6. public方法注释
public的方法体中的代码,需要写好详尽的注释


编码规范
1. 单行代码宽度不能超过150, 单个.cs文件长度不能超过600行. if, while, for, switch等的嵌套必须<=3
2. 少定义委托,多使用Event, Func, Action 和 Predicate
3. 对于public的函数, 不要太长,可以分拆成多个private方法减少代码长度.
4. 变量命名
4.1 控件的名称,不允许是button1, textbox1这种无意义的名字
4.2.使用能读懂的命名(尽量使用全名)
4.3 Event等delegate的命名
Event的命名要体现出事件, 如...Changed, 体现发生了什么,而不是告诉要做什么
bad: publicEventHandler ExtendOrderDetails;这里直接告诉别人做什么
good: public Action<bool> OrderTrackTypeChangedToOther; 这里只是告诉别人发生了什么

5. 关于注释的代码
如果注释的代码具有通用性,就提取到公共类中
如果一些代码确定没有用处,注释的代码最好删除掉(如果不确定, 暂时保留,也不要超过2天)
不要担心, 可能由于需求改动,又会改回原来的代码,因为:
* 可以通过SVN获取
* 我认为敏捷的一个重要思想是,小步快(稳)走, 关注当前。 所以不要为未来不确定的东西支付成本

保留注释代码一般用于:
1. 为了调试作用,暂时注释代码
2. 一些关键的配置代码, 比如IsLive变量用来判断当前系统是否上线, 可能会有
IsLive = True;
//IsLive = False;


单元测试
1.尽量在项目中覆盖单元测试,依据项目不同,团队可以制定自己的标准(如代码覆盖率等)
2.修复bug前,先写单元测试覆盖bug, 然后再fix bug



1.单一职责
业务逻辑类中不要包含界面相关代码
切实保证这个类中的代码,和类的名字(定义)一致。
只告知外界本类内部发生的事情,不要直接发指令让外界做什么。例子: 类中的delegate, event, 是用来告诉类内部发生了什么,不要指导外界做什么。
尽量隐藏类内部的实现细节。比如MS的File类,包含操作文件的方法实现,但是外界不需要知道具体如何实现的。


2.类应当尽量依赖其它小的类,依赖的其它的类应该尽量放到构造函数中
假如有一个拧螺丝的功能类,只需要一个扳手就能解决问题,那么不要让这个类依赖于一个工具箱


3.减少依赖于类, 应当更多的依赖于接口
把上面的扳手类抽象成一个接口,让拧螺丝的功能类依赖于接口


4.尽量少的使用全局变量
全局变量需要写好注释,解释全局变量的作用
全局变量不要在类中的私有方法中使用


测试人员

参考下面的文章
如何有效地报告 Bug

其它相关文章:

对于getting real开发结合自己的工作的一些思考

韩非子中的管理故事1(明辨人才)

韩非子中的管理故事2 (赏罚)



本文转自JustRun博客园博客,原文链接:http://www.cnblogs.com/JustRun1983/archive/2013/03/31/2988213.html,如需转载请自行联系原作者


网友评论

登录后评论
0/500
评论
zting科技
+ 关注