做了很长时间的开发，也带过一些项目，有过很多成功和失败的经历。
一些失败的项目不断促使自己思考如何才能把项目做成功，也看了一些关于项目管理和敏捷开发方面的书籍。
自己总结下来，发现项目失败的原因大概是两方面：
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
其它相关文章:
