一、需求调研与分析
客户来了，领导和项目经理吹嘘一番，项目就接下来了（这个时候什么都能做，只要给钱，哈）。 需求呢？只有客户发来的一张纸：“我们需要XX系统，要实现XX，XX功能”。没有太长的调研过程，因为项目经理急着要所有人开工，客户急着看到界面效果。分工，所有人开始查资料，写需求分析。
经过两三个周的集体努力吧，需求说明书出来了，也有了几个简单的界面原型。没有每个需求的细致、深入的沟通，客户又看不懂专业的SRS（需求规格说明书），虽然在项目组内会有多次的评审及修订，那大都是自己揣摩的，不一定符合用户要求，没有评审的标准，因为没人清楚用户在想什么，最搞笑的是，客户虽然看不懂，但却不承认自己看不懂。反正客户想：“等你们做出来，看看不行再改，软件嘛，又不是盖楼。
”需求阶段验收“顺利”通过。
二、开发
到开发人员上场了！！
开发人员最愿意干的就是写代码，而不是慢慢悠悠地写设计文档，因为没有成就感。如果这时候项目经理不约束，不加以控制，弄不好项目结束时你就看不到详细设计！（^_^）没有详细设计，SRS是自己写的，写代码的时候根本不用参照什么，也没什么参照。很快，程序写完了。。
做软件最怕什么？怕“新”。新手，新技术，新业务。如果只点一项，项目还是有保障的。如果项目中有那么三两个人这三项全点，很快写出来的程序质量能好到哪去？你想去吧。
没有正规的代码评审，因为代码太多了（十几万行？），问题也太多了，虽然不致于每行都有问题。技术好的慢慢看一遍吧，唉，一般做为技术高手，容不得问题，看到就想改。这么多代码与问题，能看完改完吗。这段时间，成为技术高手的最忙期和普通开发人员的最闲期。
三、客户体验
这个时候因为软件大体能用了，按照极限开发的理论，增加客户体验。客户不懂SRS，不懂数据库结构，不懂代码，但这时候他看到界面了，懂了。。“原来这帮人忙来忙去，就做出来这么个丑陋还总出错的东西”，“界面不好看、用语不准确、操作不习惯、甚至流程根本不对嘛。。。”，问题全来了。
所有开发人员都在解决属于自己的Bug，毕竟客户提出来的，能不改吗？
“早干嘛去了，都快做完了，又改动这么大？”
“上次不是早这样改吗？怎么又改回去了？”
“前天客 户提出来的问题改了吗？”“我看看代码”
“这个地方为什么改成这样？基于什么需求改的？”
。。。
在软件开发出来的早期阶段，关注点本来应该是功能走正常流程的正确性，现在我们全盘关注，所以好累啊！客户提出变更的时候，我们没记录（或者说没有全员理解的记录），解决完了也没记录，所以每次都在回忆中理解和修改代码。
开发、用户提出需求、修改、变更、再修改。。。很多Bug，我们自己甚至都怀疑自己的能力，怎么界面打开就报错？怎么又执行不下去了？怎么又有脚本错误？
四、系统测试
我们觉得自己应该抓紧做内部测试，要不然客户老提问题，这时更别说进度了。谁做测试呢？对系统熟悉的人做测试，测出问题谁修改？对系统不熟悉的人做测试，怎么知道对还是错，又没有标准。为什么没标准，因为到现在为止，客户的需求大多还装在客户的脑袋里，我们哪个文档详实地记录了客户的需求？
测吧，感觉有问题就提出来，有问题就直接找相关的开发人员，抓紧解决。开发人员和测试人员都不确定，这时应该找客户确认，而且应该抓紧确认（所以我感觉应该给项目经理报销电话费，至少配个固定电话，呵）。有时感觉自己的想法就对，就这么定下来吧，改吧，最后可能才知道是错的，或者有的功能都是多余的。
测出来的问题怎么管理的呢？邮件、口头、MSN。别人再见到类似的问题或相关的问题如何处理呢？继续走上面的流程，时间在流失，成本啊！
五、结局
写代码烦了，测试也做烦了，都在报怨“客户为什么还不验收完！？”
终于，所有人不堪重负，项目草草收尾。
结果是，领导报怨为什么用这么长时间，花这么人力物力；
客户报怨不按期交付，质量又差，提问题让修改吧，自己都烦了；
研发小组报怨太辛苦，加班又没有加班费；
项目经理报怨这些人真不会干活，质量差不说，态度还不好；
再然后，名声越来越不好，能接到的项目少了，入不敷出，于是有人要降工资，有人就辞职走人，再然后：“怎么和原来的公司一样？”、“其实原来只要哪个方面再做得好点，不至于今天这样”。。。
第二节 开发过程的改进
资本主义的生产性为什么高？因为有了社会分工。我们也来把项目人员区分一下看看有什么效果：
项目经理(PM)：我们意义上的项目经理其它有两个角色，项目管理和程序规划经理。
负责资源调度、人员管理、进度控制、制定开发计划、与客户商定需求、
书写需求设计文档，需求变更管理等。
开发人员(Dev)：这个我们最熟悉了，因为我们都是开发人员，：）
编码、写详细设计（写不了详细设计的，不要强压，项目经理负责写），做单元测试
测试人员(Tester)：这一直是我们的软肋，虽然我们一直对外宣称有专业的测试人员。。。
写测试计划、测试用例、根据项目经理的需求设计文档做模块和系统的验证测试，还有其它的一些非功能测试，我不是专职测试的，谁明白那些压力测试、冒烟测试、强化测试、容量测试、等等怎么做，请告诉我！
以上是我们大家都非常熟悉的人员体制，我们的项目大体也是按这个体制进行的，但是我们的职责清晰吗？每个人每个阶段具体要做什么呢？有什么制度或工具来保证上面的流程走下去吗？为什么项目难以管理，进度都要依赖于项目经理的口头或邮件督促？为什么项目中有人忙得要命，有人却没事做？
我们来分析一下上面的开发过程中有哪些最重要的问题：
1.没有弄清楚用户需求
需求，还是需求！最让开发人员痛苦的事情，真是生也为它，死也为它。有很多方法来描述需求，数据流图、UML用例图、时序图，连开发人员看起来都比较费劲，客户会理解它吗？
建议使用客户、开发人员、测试人员、领导都能看明白的方式来描述需求。客户和开发人员明白，就会降低开发完还有大量不一致的地方；测试人员明白，就能知道测试的依据；领导明白，呵，如果老板不明白，他就不知道这帮家伙到底在干嘛，是在真正干活还是在偷懒，到底工作量是大是小，软件功能是复杂还是简单。老板如果不明白，他在给预资源和时间上就会很谨慎，会处处设防。
有什么好办法呢？用户提需求时东一句西一句，总是跟我们程序员的严谨形成鲜明对比。如何和用户一起整理这乱乱的需求？
想让人能从千丝万缕中理出头绪，于是脑图软件上场。把各个分支来龙去脉表现清楚。
到了描述某个节点的时候，PPT上手。一页PPT想当于一个界面窗口。每页PPT的图形模仿了菜单、输入框、按钮。按钮按下，还可以跳转到其它的PPT页上，和软件操作流程非常类似。
关于PPT的详细描述，如字段、流程、特殊注意事项、特殊控制事项，都用word说明为好。
遇到有报表功能的时候，用Excel把报表画出来，让程序员喜闻乐见。
这些需求从用户的角度出发，不需要描述怎么实现，什么JavaScript、数据库结构、框架等等都扔到一边，它们最早也应该在概要设计里面出现。如何写好客户需求，请看《写好MRD的10种技巧》。
2.设计阶段丢失
在没有考虑清楚软件功能如何实现之前，请勿开始敲代码，Boy, Slowly, Slowly...
设计分为概要设计和详细设计
概要设计做什么？
·分析系统架构
·从用户需求中提炼业务功能，并转化为工作量差不多的功能点，得到功能点列表
·项目经理根据功能点的优先级，开始编写概要设计说明书。
每个功能点的概要设计应包括：
界面草图或用PPT画出来的示意图
界面上每个字段的说明（如默认值、不可为空、输入约束、等等）
业务流程，用文字或流程图表示
运行要求，如易用性、安全性、性能、数据量、并发性等等
此时得到的概要设计说明书，还缺少表结构和对数据表的操作流程。但是不急，针对用户的操作流程是否合乎需求？需要将这份文档交由测试人员仔细审核，测试人员根据需求分析的结果，逐项对比，保证设计的正确性、可测试性、完整性。
确认概要设计和用户需求一致后，我们开始设计数据操作流程。由经验丰富的开发人员来全盘考虑，从性能、扩展性等方面，设计出可用的表结构、视图和存储过程。
有了表结构，就可以在设计文档中补充数据操作流程了。
详细设计。。。详细设计还需要设计什么？应该由谁来写？写到什么程度，函数接口级还是伪码级？不同的项目，不同水平的开发人员，应该区别对待。
3.代码Review
项目经理并不是一下子把所有功能点的设计文档全写完。根据功能的优先级和关联性，先写重点功能及其关联功能，写出一个就可以由开发人员编码实现，在每个开发人员都写完一个模块的代码时，应该组织一次正规的代码Review。
代码Review可以有多种方法：
·各人在自己的电脑上通读代码，发现问题记录，然后汇总，开会讨论，统一解决。（华为就这样，呵）
·各人先熟悉一下要评审代码的基本流程，然后开Review会议，由开发者从头逐行讲解，每人都可以提出疑问，记录并讨论，统一解决。（NEC是这样的，呵）
代码Review有什好处呢？
·避免后续的开发出现同类问题：经过一次深入细致的讲解，把常见问题都解决，后续犯同类问题的可能性大大降低；
·项目经理根据开发人员的代码及反馈，在写设计时会更有针对性
代码Review形成文档，并应该注意积累常见问题及解决方法，在所有项目中都适用的。
4.测试出的Bug处理流程
测试人员测出问题，交给相应开发人员解决，测试人员验证是否修改。上述看似是Bug处理的最短路径。
首先，测试人员发出的问题真的是问题吗，由谁来确认？
还有，这个Bug是怎么解决的？什么时间解决的？
其他人是不是还有可能犯同样的Bug？
由于没有专门的工具或系统来记录这些Bug是怎么产生的，是怎么解决的，给后续的开发和统计造成很大的难度。
换一个流程试试：
· 测试人员发现Bug，记录到Bug管理系统中，需要记录的数据有：操作步骤，输入的数据，结果什么样，应该是什么结果，责任人是谁（可以直接写项目经理）。。。
· 项目经理看到Bug列表之后，分析Bug是否需要解决，要让谁解决，然后就可以转给相关开发人员
· 开发人员重现Bug，检查代码，修改，记录原因和如何修改的，然后转给测试人员验证。
· 测试人员验证以后，关闭这个Bug。
有了Bug管理系统中的数据，上面的问题还存在吗？
5.需求变更的流程
客户发现问题或又提出新的变更，不管是电话还是邮件，都应该详细的记录下来，并且应该是项目全员都应该知晓。
记录了客户新提出的需求或对原始需求的变更，我们在讨论时就有据可查，客户说不对时也有证据。就算是暂时不实现的需求，也可以有备案，等后续系统升级时，就有针对性。
建议每当客户提出新的需求或变更时，都要开项目会议，把需求讲明白，并使用上面提到的脑图+PPT+Word+Excel工具，把这个需求描述的清清楚楚。
6.项目经理权力分割
项目经理现在需要做这些事情：立项、需求调研、建立开发计划、配置管理、编写需求规格、编写设计说明书、人员管理、控制进度、Bug分析和任务分派、与客户沟通、向领导汇报、总结与分析、控制风险、客户验收、结项，甚至有时候还得写大量代码，还甚至写测试用例、做测试、发布版本。。。
项目经理的权力太大了，想做项目经理，但这么多事，在有限的时间能做完吗？能做好吗？我觉得应该把项目经理分为两个，一主外，一主内。暂且称为项目经理和开发组长吧。
项目经理有以下职责：立项、需求调研、建立开发计划（只定好大的时间点）、编写需求规格、人员管理、Bug分析、与客户沟通、总结与分析、控制风险、客户验收、结项
开发组长有以下职责：建立详细开发计划（具体到模块）、编写设计说明书、控制开发进度、Bug分析和任务分派、总结与分析，有时间的话，写一些代码。
项目经理主要从客户的角度关注需求，从较高的层面关注项目进展，其它的都分下去吧，否则真够累的。
发布版本是谁的活呢？ 我认为在小项目组内应该是测试人员。测试人员控制软件的版本和发布，因为每个版本的质量由测试人员把关，他说能发布才发，有问题可以拒绝发布。由于版本号由测试人员统一来定，客户的软件出了问题，是哪个版本的，便于定位。
版本号怎么定义，大家可以看一下微软的一些软件版本编号：8.5Release2 Build 3，这什么意思，测试人员去研究。：）
7.开发任务的分配
某个任务什么时候给谁分配的，什么时间做完的，出了多少问题。这涉及到项目经理和开发组长的两个职能：总结与分析、控制开发进度。
总结是为了给上级领导汇报工作、给客户反映进展情况；
分析是为了发现规律，如什么问题经常发生，谁经常犯错，谁的进度总是赶不上，。。。，当然也是为了控制开发进度。
实际上一个Excel表格就能记录开发任务进展的所有数据。谁来维护这个开发任务表呢？开发组长还是开发人员？
建议由开发组长列出功能，分配任务，规划时间点，开发人员补充结束时间和当前状况，也可以由开发组长主动询问进度，更新到这个表格中。
8.功能的优先级
如果系统划分出来的功能点较多，超过50个，最好应该考虑分阶段开发。
第一阶段完成重要的业务功能，还需要尽量保持系统的完整性，完成后就可以做集成测试和发布，这样有利于提高大家的积极性和成就感。
第二阶段完成应该包含的功能，需要重新计划，因第一阶段做完后，一般技术或业务能力都有较大的提升，这个阶段应该比较短。
第三阶段完成最好包含的功能，如果时间不允许，分到这个阶段的功能点可以暂时不实现，把精力集中到前两个阶段的成果上，保证质量。这些功能点可以留到下一个版本中。
之前的项目虽然有对功能点的分级，但这个级别没有对项目计划的制定起到太大作用，而且功能点非常多，细分的话有一两百个，导致每个阶段的时间特别长，每个人都容易疲劳。
第三节 Bug管理系统有什么好处？
1、建立起Bug记录的统一平台
Bug的一生和人的一生是一样一样的，从出生（创建）到成长（调查、解决），再到死亡（关闭）。也有的Bug没有这个生命周期，还没出生就欧了。。那它肯定不会Bug
2、实现工作流程的自动化
计算机如此发达的今天，你还愿意跑来跑去吗？
3、知识积累
新老员工之间的差别在哪里？我觉得很重要的一点就是老员工有解决各种Bug的方法。
某个单位来了一个新员工，只要管理员给他注册一个帐号，给他一个口令，他自己上网就可以看到符合他身份的权限范围内的企业内部积累下来的各种知识，这样就减少了很多培训环节，而且能够使新员工迅速进步。
4、绩效考核
这一点非常重要，因为它关系到我们的工资与奖金。但却总是被很多项目经理忽略。来看看如何统计每个人在项目中的工作量及工作质量吧。。。
项目成员主要归项目经理来考核，那就是要考核开发人员和测试人员。（根据大部分中小IT企业，测试人员没有独立的小组或部门）
开发人员：开发了多少个功能点，共产生多少Bug，Bug的分布情况，对应了多少需求变更；
测试人员：测试了多少个功能点，有多少测试用例，测出多少Bug，测出Bug的重要程度；
如果没有Bug管理工具，关于测试用例与Bug数量的统计这些至关重要的度量数据谁来计算？
谁来证明你的水平高呢？如果没有数据，就没人信服，更不会让领导重视。
谁来证明你的工作量？如果我们每周给领导看一下我们本周开发了多少功能，对应了多少需求变更，解决了多少Bug。。。
领导还认为我们每天都在那装做很忙吗？要求加薪的时候我们要用数据说话，而不是“累死累活”、“加班加点”、“没功劳有苦劳”。。。
还有一点我不得不说，项目进度和质量取决于谁呢？想一下木桶原理。。。应该是水平最低的那个吧。怎么找到这么关键的人，在开发过程中给予更多的关注呢？
第四节 需求管理、开发任务管理、Bug管理三者的关系
需求管理是对客户提出的需求进行维护，有新需求，有变更，有是否已实现。。。
开发任务管理是开发组长给开发人员分配的，有新分配的任务，有任务的状态，也可能有任务的转发。。。
Bug管理是测试人员提给开发人员的，有新Bug，有Bug的状态，有Bug是如何解决的过程。
三者有共同点，当然也有部分不一样的信息，有没有办法使用同一套系统来管理这三块内容呢？有很多公司已经这么做了，哈。。。具做怎么做，让我们一起来慢慢研究吧。
第五节 我们倒底需要什么？
我们一直在追求CMM，一直宣称以CMM3的流程来开发项目，实际做到了吗？如何做好项目管理，如何做好需求调研，如何改善产品质量，如何调整和老板的关系，如何提高员工的工作能力和工作积极性。一大堆问题摆在面前，引入自动化测试也不好用，引入版本管理也不好用，引入日清日毕也不好用，到底一个团队该如何管理呢？也看了CMMI、RUP的书，但不解决问题。
也许我们需要想，就我们目前能拥有的权力和资源，我们如何一点点改进？
各成员主要职责
再次复习一下项目团队中各个角色的主要职责：
项目经理：立项、需求调研、建立开发计划（只定好大的时间点）、编写需求规格、
人员管理、Bug分析、与客户沟通、需求变更管理、
总结与分析、控制风险、客户验收、结项
项目经理需求很高的技术水平吗？你看呢。。
项目经理是客户与研发小组，领导与研发小组之间的窗口。
每周的周报是必要的，让客户和领导都明白当前的状态。
开发组长：参与评审项目经理写的需求规格，建立详细开发计划（具体到模块）、
编写设计说明书、控制开发进度、Bug分析和任务分派、总结与分析，
有时间的话，写一些代码
是项目经理和开发人员，测试人员和开发人员之间的窗口。
开发人员不应该脱离开发组长单独行动。
开发人员：参与评审项目经理写的需求规格，评审开发组长写的设计文档，
根据详细设计编写代码，单元测试，修改Bug
测试人员：参与评审项目经理写的需求规格，评审开发组长写的设计文档，
写测试用例，执行测试，提出Bug，验证Bug，汇总测试状况、
软件版本的管理、软件的发布、配置管理
日常学习各种测试方法
其实还遗漏了两个重要角色：美工和文案，算了，公司没有，而且成本也不低，每个成员都努力吧。
做为需要经常与客户及时沟通的项目经理，以下工具必备：
邮件、MSN、QQ（客户大多喜欢QQ）、固话。咱公司封QQ、不配备固定电话，唉，可惜了两种好工具。脑图软件、PPT、Word、Excel，写需求规格必备！做为项目经理，你写的需求得让所有人明白，所以把开发相关的事交给开发组长，努力把需求写明白，写清楚吧；需求管理工具。记录需求是基于什么提出的，为什么变更，是否已反应在产品中等等。
开发组长需要的工具不多，总结起来就两个模板和一套系统：开发任务分配模板、概要和详细设计模板、Bug管理系统。
开发人员越专心越好，所以一套IDE集成开发环境，一套CVS/VSS足矣。
测试人员最常用的就是Bug管理系统，写测试用例用它，执行测试记录Bug用它，汇总测试状况还用它。
人力配备
项目经理 1
开发组长 + （1-3）名开发人员 做为一组
测试人员 1
开发组长除管理开发人员的进度和任务分配外，还有可能自己也参与一部分代码的编写。所以最多只能管理两三名开发人员。如果项目规模较大，参与的人较多，就要配备不止一个这样的小组，那项目经理的职责还需要有协调各个开发小组。测试人员根据规模不同，可配备一到两名。
第六节 质量与时间成本
有人问了，把人力这么一分，实际写代码的人少了好几个，开发速度不就大降低了吗？这套方法有实用性吗？那么我们来分析一下开发质量与速度或者说时间成本的关系。
几乎所有人都希望我们做项目时，质量又好，速度又快。
传统的观点认为：功能、质量、成本是铁三角的关系，在功能不变的情况下，不可能在提高质量的同时降低开发成本。
但是我们想一想，我们在开发过程中，本来想以牺牲质量来加快速度的时候，文档不写了，该记录的不记了，该评审的和统计分析的也不做了， 结果反而花了更多的时间，项目一拖再拖，质量也牺牲了。
把每一步都做好，从开发的前期来看，花的时间可能比别人多，但从整个任务来看，反而有可能以别人几倍的速度完成。
但是做到什么程序才算好呢？是否追求完美？那当然不可能，如果一个软件没有Bug，那它肯定没有任何功能，也没有任何价值。所以必须找到一个中间质量点，低于这个质量点，想牺牲质量来赶进度，只会适得其反，质量越低耗时越长，高于这个质量点，想提高质量就得增加成本。
图1.时间和质量的关系
如上图所示，我们必须找到一个合适的中间质量点，不同类型的项目，不同行业的项目，中间质量点应该是不同的。
精确的质量点，我们找不到，所以只能确定一个小的范围。中间质量点在项目中体现为什么呢？不知道大家是否记得在华为做项目时每个阶段验收时的质量目标。我们不应该为了达到质量目标而去调整评审结果，去故意把提示性的问题改为一般性问题，反过来也不对。如果我们的文档或产品没有达到这个质量目标，差距还较大的话，极有可能会影响开发进度，即使投入了大量人力，还是挽回不了拖期的结果。
我们应该根据不同的行业，和不同类型的软件，根据开发经验和数据，得出我们自己的质量目标。航空航天类的系统要求比较严格，每个阶段的质量都应达到95%以上吧，企业管理类的85%就不错了。如果平时不注重积累，没有评审和Bug的记录，我们什么时候才能总结出质量目标呢，怎么判断是否可以进行下一阶段了呢？
第七节 除此之外
除了上面的体制建立和各阶段的工作方法，我希望能够形成以下几个简单的工作习惯：
1.每日汇总
每天下午5：00，由开发组长统计开发人员的进度，询问遇到的问题，更新工作任务表；
2.晨会制度
每天早上，项目全员开会，大约只用十分钟时间
· 项目经理说一下昨天有没有变更，说一下当前的总体状况，需要注意什么问题；
· 开发组长说一下开发人员的任务安排，自己设计说明书的进度；
· 每个开发人员说明一下自己负责模块的开发情况，什么时候结束，有没有困难，是否需要代码评审，需要什么支持，如缺少外部接口。。。
· 测试人员说一下测试用例的编写情况，测试情况，遇到什么问题
3.周总结
每周五，项目经理总结本周工作进展，设计、开发、测试的进度，简述一下有什么问题，下周有哪些工作重点。发送给客户、部门领导， 抄送CTO、项目全员
4.阶段总结
每个阶段结束，由项目经理把我们的工作量和质量状况汇报一下。
比如共计设计了多少功能点，写了多少行代码，评审出多少质量问题，是否达到质量目标，进度是否有偏离计划。发送给客户、部门领导，抄送CTO、项目全员
并且把客户需要的文档、说明书、帮助等整理后发送。
5.项目总结
项目结束时，每个人都要积极地把一些零散的资料、文档整理起来，归档到服务器，为以后的开发与维护做好准备。
不要以为客户一验收完，我 们什么事都没了。项目总结会议，每人都做好个人总结，开会时都说一下自己的体会与心得，还有对以后项目的建议等。