软件开发流程（框架性草稿，细节还需要完善，修改中）
团队组成
项目经理、配置管理员、业务顾问、项目组员。
其中项目经理是必须的，配置管理员和业务顾问可按情况单独配置或与其它项目共用。
进展控制
在开发前先根据项目要求设定一个总体的完成期限，并且根据经验设置若干个项目里程碑，里程碑规定了项目进展所达到的要求，在整个开发流程中采用迭代循环的方式进行渐进式开发，每个项目的迭代周期应由项目经理根据迭代目标和实际情况进行确定。每次迭代前确定迭代目标和迭代周期，一般是把需求优先级最高和技术风险最大的用例首先实现，每次迭代都要以得到一个达到迭代目标并明确可运行的版本为结束标志。
需求分析
原则上不限制需求分析过程，但是建议采用UP流程进行需求分析，必须编写详细的文本方式的用例说明（UML图形为可选件）。进行需求分析时采用头脑风暴会议方式，要求项目组所有人都必须参加和讨论。所有的用例和设计都必须保存到配置管理库中。
软件开发
采用敏捷开发过程和持续集成。
测试先行，开发时，先编写对应的TESTCASE后经项目经理审核，并编列入开发文档后，方可进行功能代码编写，功能代码和单元测试代码都由必须同一个人完成。单元测试行覆盖率要达到90%以上。
每天下班以前必须签入当天的工作代码，并通过单元测试。如有特殊情况不能完成，需要向项目经理说明。
每次签入必须说明签入结果，比如增加成了什么功能，修复了什么BUG等等。
一般情况下组员都应该采用结对方式工作，两人同时使用一台电脑。碰到特殊情况由项目经理安排。
除非迫不得以，尽量不要采用IDE的DEBUG方式来进行单步跟踪，而是采用记录日志和设置断言的方式来进行DEBUG。
每次发现BUG，必须修改单元测试以至让单元测试可以检测到该BUG的存在。如有特殊情况不能完成，需要向项目经理说明。
会议要求
每次会议必须记录下需要解决的问题和会议结果，并且用摄象机录制整个会议过程，并存档。
注：
许多朋友在看过这个规定之后，提出了许多好建议和善意的批评，这里非常感谢大家，特别是肯.索夫特朋友（以上兰色部分为他的修改意见）。
说实话，我的职业大部分是一个程序员，也没什么太多的管理经验，我想每个程序员在工作的时候都会有这种感觉：提高生产力除了提高技术，优秀的管理手段也是非常重要的一个因素。
其实在国内很多企业，把程序员当工人一样管理，但是软件和传统工业相比还是有许多特殊的地方，但是管理人员并不知道，比如在我以前的一家公司，还在采用瀑布模型，需求人员做好了需求给设计人员，设计人员做好了设计给程序员，程序员基本上没有资格参与需求分析和设计，但是一程序员拿到最终设计时却发现无法下手，只好凭着自己的想象去做，最终是什么结果可以想象。但是管理人员还认为他的管理手段非常先进，实现了“流水线作业”。这种巨无“可操作性”的制度，最后竟然也被“操作”下来了，并且还做了几个项目。。。
虽然我们并不是管理人员，但是在面对不合理的制度的时候，我们除了抱怨制度的合理性，能不能主动一点提出一些自己的理想中的建议呢？
我承认我的经验不足，太理想化，在这个规范中，确实有许多地方不完善，也有许多部分还没有考虑到，比如软件测试等等。所以希望大家在批评之后，最好能提出一些修改意见或补充，或者把自己心目中设计的或实际运行中优秀制度提出来给大家分享和参考，再次感谢大家。
