项目，从零开始

转自: http://www.blogjava.net/Jack2007/archive/2008/02/27/182368.html

一.   调研需求

<<理论部分>>
     由于专业的限制，用户很难准确地把系统需求传达给开发商；由于业务的限制，开发商也很难准确获取用户真实的应用需求。需求描述的错位，容易引起系统设计的缺陷，最终导致系统应用不理想甚至系统失败。可以说，需求调研是信息化建设的第一步，也是关键一步。
   需求调研涉及三个问题。一是如何确定调研对象，二是如何确定被调研对象，三是采用何种调研方法。调研对象的组成应以互补为原则，至少要由三类人员组成：技术人员、业务专家和管理者。被调研对象主要是人员和业务两类，其间主要涉及人与人、人与事物、事物与事物等三种关系。
    其中，关键是确定调研范围。调研范围包括关键域和关键活动。而关键活动又由关键流程加关键点构成。找到关键域，明确关键流程和关键点，对需求调研至关重要，需要专家或咨询顾问介入。而能否把握这一时机并找准需求提炼的关键点，是考验需求调研人员的重要方面。优秀的需求调研人员不仅能认识问题之所在，还能藉此获取足够多的知识，最后成为问题领域的专家。
    调研方法一般有问卷法、面谈法、数据采集法、用况法、情景实例法以及基于目标的方法等。此外，还有知识工程方法，如场记分析法、卡片分类法、分类表格技术和基于模型的知识获取等。然而最基本的方法还是问卷法和面谈法。

<<实战部分>>
 需求说白了就是用户需要什么样的软件，客户拿它来做什么。

    做需求：

 1.        尽可能的熟悉用户的业务，把握其工作流程，这就需要有效沟通。

 2.        把我们的用户进行分类，看他们的大概技术水平，并进行记录，对不同用户设计不同的视图界面，满足不同层次的用户。

 3.        了解一下我们客户的客户，分析他们之间关系，来发现隐式的需求。

 4.        再就是看看他们经常使用的报表，并进行分析、整理。

 5.        派遣人员到客户公司实习工作一段时间, 体验实际。

 6.        还有就是试探性的问，让他们找问题———我们先说出一个原型，他们看到不对的地方他们提出来，也就是让他们找错

       这部分需要给客户一个<<投资计划书>>或<<商业理由>>

 

二.   分析需求

<<理论部分>>

需求工程是继软件工程之后的又一热点工程。从理论上说，包括调研需求、模拟和分析需求、需求描述、需求认可、需求演进这五个层次，并且逐层递进、螺旋式上升。需求分析是需求工程的核心，贯穿于系统整个生命周期。

需求分析的出发点在于：对调研的需求进行进一步提炼并指导需求的抽取；帮助需求分析人员发现问题。需求模拟则帮助检查验证对问题的理解。需求分析和模拟又包含三个层次的工作：需求定义、需求建模、需求模拟。

需求定义，是对经调研获取的需求进行初步整理，抽取其中基本需求和关键需求予以界定，并为需求建模提供必要的需求元素。

需求建模，是把抽象的需求通过概念、符号、数学模型及逻辑结构表现出来。表现形式有自然语言、半形式化（如图、表、结构化英语等）和形式化表示等三种。自然语言形式具有表达能力强的优点，但不利于捕获模型语义；半形式化表示可捕获结构和一定的语义，也可进行一定的推理和一致性检查；形式化表示具有精确的语义和推理能力，但构造一个完整的形式化模型，需要较长时间和对问题领域的深层次理解。相对而言，图表形式的需求模型直观常用，比如组织结构图、系统流程图、网络拓扑图等。
       描述需求的任务是撰写软件需求规格说明书，这是需求调研和分析的直接成果。好的需求规格说明书需求层次清晰、语言专业且简练、基本需求描述完整、特定需求既有现实性又有前瞻性、流程和结构定义准确、有可操作性、可逆性等。

   需求规格说明书的主要服务对象可能来自于用户、系统分析员、软件需求分析员、软件开发者、程序员、测试员、项目管理者等。但归根结底还是要尊重用户发展战略和机构运行策略所必需的现实的和潜在的期望。
   需求描述完成并不意味需求工作的结束，需求认可和需求演进是确保系统持续改进的必经之路。需求认可就是让上述人员对需求规格说明达成一致。需求演进的必要性是明显的，因为用户需求不断变化，系统开发又总是落后于客户需求的变化和增长，如何及时感知需求变化并系统整理成为系统进化的首要问题。可以说，基于需求演进的管理效率直接决定了系统能否支持用户的持续变革。

<<实战部分>>

      a) 需求分析是整个项目管理中需要重点控制的几个关键节点之一，首先思想上一定要重视。

b) 需求分析报告的编写者要参与到需求的搜集工作中，准确领会客户的意图，并转化成软件能够实现的功能。对于说不清楚需求的客户，要善于问关键问题，引导客户提出自己的需求。可以采取的措施是事先编制一个问卷调查之类的文档，详细列举需要客户回答的问题，以便防止遗漏。

c) 需求报告的编写者要能够对客户需求进行深入分析，区别出哪些需求存在日后变更的可能，哪些需求属于相对固定的，哪些需求能够实现，哪些需求需要变通才能实现，以便于指导后面的功能设计。

d) 需求分析报告对功能细节的描述不能有歧义，描述一定要全面、准确，防止开发方和客户只见对同一个问题有两个截然不同的理解。可以通过评审，用大家的力量来避免这种情况发生

e) 需求报告的每个关乎功能的描述都要让客户明白和理解，客户在理解之上的确认才能够保证日后一旦出现问题不致出现双方互相推托责任纠缠不清的情况。

f) 需求报告一定要经过一个有技术人员和业务人员参加的评审，要充分发挥团队的力量，重视每个人的才智，一个模块一个功能的逐一的过，让大家来共同找出需求报告里不合理的、有歧义的、不完善的、遗漏的等等问题

g) 帮助客户去理解提交给他的需求分析报告而不是只等签字，对于有能够用好几种方式实现的功能，尽量做到能让客户去比较和选择。不要让客户对报告中的部分产生歧义。只有客户对报告的完全的理解，才能在日后客户提出的修改被认为是需求变更的时候能够得到客户的理解

h) 最后，需求分析报告一定要双方共同签字确认

   该阶段的最终结果就是详细的《软件需求规格说明书》

 

三.   组建团队

项目成形，资金到位。接下来就是要组建团队来实现之前的构想。当然组建团队要看你是什么项目，以及项目的规模，一般项目人员在 6 到 10 人最佳。根据项目定出几个角色，定多少角色以能完成项目为准，然后一个萝卜一个坑的去选人，先在公司内部选择适合人员，没有就去招聘（可以到人才市场，可以到人才网站，也可以通过同事朋友介绍，当然也可以到 blog 等网站挖挖人才），总之为每个角色找到最适合的人，记住是最适合的，不一定是最强的人。

以之前做的 <<网上作业系统>> 项目为例。参与项目的共 6 个人（本来 3 人就可以完成，但由于时间问题，增加到6个）。一个项目经理 PM，一个开发经理DM，一个测试经理TM，一个开发人员，两个测试人员。TM 兼任 UI 美工设计。PM 对项目做整体安排规划，DM 对系统做整体架构设计，TM 负责测试用例，美工和文档编写。PM,DM 和一个开发人员负责代码编写。

   “一支程序开发团队之所以成立，是为了承担并完成某项由任何个人都无法独立完成的任务”。在我看来，这是对程序开发团队一个比较贴切的定义，通常在软件企业里，会有若干支开发团队，它们因某一项目或产品而存在，项目完成了，团队也随之解散，程序员在各个团队中得到不断地学习与提高，除了技术能力，还有沟通能力、交际能力、协作精神等等，所以鄙人认为，团队工作比孤军奋战更有助于个人的成长。
   在现代的软件企业中，分工合作正成为企业中一种工作方式的潮流而逐渐被更多的公司所提倡。因为只有团队合作，才能将复杂的事情变得简单，将简单的事情变得容易，使做事的效率倍增，可以说，团队合作正推动企业向简单化、专业化、标准化的方向发展。在软件这个特殊的行业，更需要如此，国内的软件企业长不大，出不了好的产品，第一大原因就是管理，第二大原因可能就是没有一个出色的团队。

   组建团队的目的是希望通过最小的代价获得最佳的开发效果。因此我们尽可能找到出色的程序员，并根据他们的特点与优点，进行适当的分工，团队成员间需要相互补充，才能更好地实现团队协作的功能。众所周知，人与人的合作，不是人力的简单相加，而是要复杂和微妙得多，温伯格在这一方面总结了一个大致的规律：“由3名程序员组成的团队，只能够完成1名能力相当的程序员所完成之工作量的2倍。另外，如果每个开发组分别由3名程序员组成，那么基于同样的原因，3个这样的开发组协作完成的工作量，将是单个开发组的2倍，或者说是单个程序员所能够完成的工作量的4倍。因此，假设某个工程由单个程序员需要8个月才能完成，如果我们希望在4个月内得到结果，那么我们就需要派上3名程序员；而如果我们希望在2个月内完成工作，就必须分配出9名程序员。”

想想看，是不是有一定的道理？但这不是绝对的，在项目的进程中，有太多太多不确定的因素随时出现，我们大多的项目总不能按时完成。刚开始做项目计划时我们总喜欢一厢情愿地将开发过程中的所有条件都设想为最好的，但在实际的开发过程中，总会冒出一些乱七八糟的事情，有人生病了，有个呕气了，有人离职了，有PC总有故障，有一些BUG花太多的时间……

能在一个出色的团队中工作是一件很幸运很开心的事情，你不仅学到很多的知识，而且系统的成功开发也让你很有成就感。那么如何来组建程序开发团队呢？

温伯格认为：首先规划出程序的理想结构，然后按照最优的方式，选取最合适的人选来承担对应的工作。

 

 

四.   开发，测试

人马到位，就急需一次圆桌会议，项目主要干系人，产品经理，项目经理，系统分析员等讨论立项问题，软件公司和客户完成签字仪式，可以开工了。

开发前期由于需求不稳定，急需客户支持，必要时可协商客户派代表参与开发。

项目经理，系统分析员通过协商选择一合适的开发过程，比如 RUP 过程, 敏捷过程, 微软过程等等。两个角色预先熟读《软件规格需求说明书》，并对需求在开发组内展开讨论，目的是让每个人都熟悉需求，项目经理制定开发计划，任务以及相关文档的编写，他负责和产品经理，客户代表和测试组沟通，同时项目经理和系统分析员要对需求进行分解，将大系统分解成多个子系统，对每个子系统排序，每个子系统又分为多个功能模块，对功能模块排序。接下来就要精确估计开发时间和成本，并对系统分出迭代次数，可以横向分也可以纵向分。

系统分析员负责系统的概要设计和详细设计。这些可能需要一段时间，在这段时间内，开发小组，测试小组可以熟悉需求，有问题及时交流，测试小组着手写测试用例，及部分文档。

分工会议，捉个功能分配人员，让每个人选择自己想要开发的功能并给出大概开发时间。这样第一此迭代开始了，项目经理可以监督组员工作情况，每周写项目进展报告，每个星期收集已经完成的功能已邮件的形式通知测试组下个星期的测试任务。

每次迭代要有缓冲时间，整个开发时间也要留有缓冲时间。时间多少由项目和具体时间而定。

PM 一定要灵活，项目开发过程中，对特殊情况及时作出调整以保证开发进度和软件质量。

 

五.   实施，收尾

每次迭代都会有一可运行版本发布，供测试小组和公司内部人员测试，即内测。当整个开发周期完成之后，就需要业务人员，技术支持人员，开发人员和管理人员到客户那里验收。验收可能需要一定时间，或者需要几次验收，直到和客户签字。

项目收尾了不代表项目周期的结束，客户软件还需要我们维护。比如公司可免费为客户维护一年。之后每年必须缴纳维护费用。