第一步当然是需求的采集，怎么做？
先和用户交流，弄清楚项目的目标，这个通常是几句话，用户的语言，但你必须理解，并且文字记录下来。然后我们需要做第二件事情，即软件需要提供哪些功能，来实现项目目标。当然，这和用户的作业流程、业务规则、具体岗位是有关系的，这里的产品是一份功能清单。第三个则是功能清单的说明，通常也就是一段话，使用用户的语言。 一般没有必要记录非常详细的业务规则，在交流过程中这些通常会变得清晰。我们的问题是：做什么？而不要涉及太多的细节。
这三项工作完成之后，需求也就告一段落。我们的团队，将至少有一个人，完全明了这个项目的目标、我们需要实现哪些功能、这些功能主要是做什么的。关于业务细节，可以通过交流然后形成文字、简单的也可以忽略。但这个过程中，负责需求分析的先生，必须完全能够说服自己。
此后，划分阶段，这需要一定的经验。功能清单，对应的工作时间。嗯，是有理想工作日的概念----我个人觉得不用管它，将自己初步测算的时间乘以2就是不错的选择。也有人认为此时是比大小的阶段，即找出最简单的功能，将其大小看着1，其他每项功能按比例赋值---嗯，那其实也是很麻烦。虽然那些书生给我们讲课的时候，比较鄙视估算时间这一说，但时间毕竟是最直接的的概念。 估算时间的作用，是考虑分阶段完成。 时间紧张的项目，尽量2周一个阶段，略长的则可考虑四周一个阶段。
划分阶段的依据是什么？4个原则：1、最快的投入使用；2、均匀分布到每个阶段；3、考虑各种风险因素；4、每项功能在每个阶段都必须是彻底完成，不要做成半成品 我们需要在将每个阶段的目标用一到三句话记录下来。
此后我们开始第一个阶段，这通常是和用户交流一个工作日之后1到2天的事情，不要拿起架子做多少多少准备工作。这里，我不推荐所谓的小组评估功能大小、用户决定哪些先做哪些后做，这类花头第一是浪费时间、第二是缺乏可行性。
然后项目负责人，可以考虑为第一阶段的各项功能，做用户体验设计，并划分开发任务，这里也需要一定的经验：1、一项功能，需要考虑哪些事情？菜鸟和老手是有非常大的差异的。2、这些任务的开发顺序，尽量要自然一些。3、在这些任务中可能碰到哪些问题，也要列出来。这些问题可能是业务方面的，需要布置文档任务；可能是技术方面的，需要解决并写成文档形式，以免团队其他人同样花费时间解决这些问题。4、有哪些地方是需要测试的----不要追求覆盖全部。
之后，程序员将开始第一阶段的开发工作。 这里，对每个程序员来说，首先遇到的或者是数据库设计、类设计、界面设计这类问题。我们每项功能涉及到哪些表格，这个阶段就创建数据库、设计好这些。类设计原则上是每个程序员针对自己的任务要做的事情，但如果涉及到多个程序员都会遇到的，项目经理必须预先在任务中说明，并且最好先建立空白的类。关于常见的ORM的问题，没有必要使用某个ORM框架，从我个人的经历来看，将数据库当作一个仓库，放进去、拿出来就行了。出于性能考虑、开发耗时的考虑，依赖某个Orm框架未必是好主意。
每天项目经理自己判断，是否有必要询问哪位：进度慢了？遇到问题了？做的是否有错？不需要所谓每天的站立会议之类。这个过程中鼓励程序员多看看项目中其他程序员的代码，新手初哥，实际上是在模仿的过程中形成团队接近统一的风格的。
至于代码规范，未必要太讲究，只要不是那种惨不忍睹的形式就可以，笼统要求一下，尽量模仿开发环境生成的代码的风格就行。项目经理若有时间，或者有耐心，不妨偶尔修改一下程序员的代码。
程序员完成某项任务，告知项目经理，然后会接到下一项任务。项目经理在合适的时机，执行重要功能测试，并将相应的问题作为bug记录，并指定人员修复。一项功能的所有任务完成，测试没有发现问题，开始做下一项，直到这个阶段的所有功能开发完毕。此时可以邀请客户看看效果，一般是由他们自己来操作，记录下他们的想法和意愿，下一阶段考虑。
如此循环，直到项目结束。
小结一下，流程是这样的：项目目标(几句话的文档)->功能清单->划分阶段(包括各阶段功能和阶段目标说明这样的文档)->第一项功能的用户体验设计->第一项功能的开发任务、问题分配到人-->项目中公用的任务(数据库、界面体系、公用类设计、说明、安排人员)->程序员逐项完成任务->第一项功能完成->重点功能测试-->开始下一项功能...
业务细节的文档，需要写的时候才写，作为项目任务安排进去。
作为项目经理，可以反思一下，自己在编程的时候是什么状态：心情不好的时候，是不是会整天没办法做事？集中精力做了2个小时，会不会感到头昏眼花，需要休息3个小时？碰到问题解决不了的时候，连续被挂上好几天，是不是厌烦到极点，能不能暂时搁置一下？ 其实每个程序员都是这样的。 早上可以出去跑跑步，10分钟，有氧运动会令大家的心情奇怪的变好一些。程序员进度明显停滞的时候，要有耐心等待，不要催。可以问问他遇到什么问题了，可以考虑是否能提出合适的建议。这是很正常的现象。 工作一到两小时，完全可以集体休息一会，聊聊天。在进度没有很明显问题的情况下，不要绷得太紧张。
进度出现问题的情形下怎么办？ 嗯，按照这种过程，一般不会崩溃，因为用户最需要的功能在前面已经完成了，但你若遇到过于认真的客户，基本上没有多少办法：将不急的功能放在最后，某些功能想办法说服用户不做，一些功能用更简单的办法实现，要求强手担负更多的工作，或者项目经理赤膊上阵？我想，这些大家基本上都经历过。我的意见仍然是：基本上没有多少办法-----时间的减少，导致程序品质的下降，是有临界点的。公司如果在承诺的时间做的是超出能力的工作，软件过程是不能真正解决这个问题的。
最后的结果仍然是：加班，前提是项目经理承担更多。加班的现实作用是增加紧迫感，这可以从外部倒逼程序员有略多的专注工作时间。所谓加班不能解决问题，加班本身就意味着项目失败这种说法，不适合中国人。
当然，我们需要一套比较简易的项目管理工具，我使用的是team fundation server，上面提到的阶段、功能、任务、问题、bug、测试和源代码管理，基本上都能够简单的解决。即使是个人项目，我也使用Tfs。我推荐以基本模式安装，也就是不用管报表之类的东西，这样的话备份简单，备份一个数据库就行了------复杂的备份过程是很浪费人力、并且抑制备份欲望的，这不安全。