1 引言
1.1 写作背景
本论文为我的毕业论文，是对毕业设计《Kind WebOA.Net》的开发过程的描述与开发成果的总结，在这次毕业设计项目中，我尽量的将学到软件过程、项目管理和软件设计与开发理论运用于实践，从中积累了不少的经验和心得，本论文将以此为主要内容。软件工程理论体系非常庞大，本文主要描述在中小型项目中简单有效的部分以及在Kind WebOA.NET的运用情况。同时，本文也简要描述和本毕业设计相关的主题：办公自动化系统。
1.2 项目背景
l 项目性质：这是一个产品化项目，目标在开发一个商业化产品，并做软件产品登记
l 项目周期：该项目从2003年9月开始立项，经历了几个月的前期准备（资金、人力、技术），于2004年1月启动，至2004年6月份项目验收。
l 项目规模：本项目前后大概为24人月。前后参与人员6个人。
l 项目效益：项目6月份完成后，即成功实施了两个客户，已经收回了全部投资。
l 笔者职责：我在该项目中，参与项目的整个过程，负责项目管理以及系统的总体分析与设计，并参与了部分模块的开发工作。
2 项目管理
2.1 结构化项目管理
随着软件项目的规模不断加大、参与人员的增多、对规范性的要求愈加严格，软件开发已经告别了个人英雄主义的模式，工程化的软件开发时代已经来临。由此，项目管理开始逐步地在软件研发各项活动中处于核心地位。好的项目管理比好的技术对于大部分项目来说，意义更加重大。软件项目管理旨在通过运用管理学的基本原理，调配好项目的各类资源，确保项目按进度达到预期目标。由于软件工程的复杂性，使得项目管理与软件工程多年以来并没有万能的方案。《人月神话》一书给出了一个结论：没有银弹。项目管理更多的时候需要靠经验来解决问题。即使如此，经过多年的发展，大家还是总结了一些项目管理的基本原则与方法。在《成功的软件项目管理》一书中给出了项目管理的“银弹方案”：结构化项目管理。这是多近两年对我影响最深的理论，并多次在项目中运用，效果不错。结构化项目管理的十个基本步骤是：
1. 可视化目标，关注结果
2. 给要做的事列个清单
3. 必须要有一个领导，并只能有一个领导
4. 分工明确，责任到人
5. 管理期望值和风险
6. 采用恰当的领导风格
7. 了解正在发生的事情
8. 告诉人们正在发生的事情
9. 重复1-9
10. 结果
1-5同项目计划有关，其他的则同如何实施计划有关。以下我总结一下实施这个项目管理框架的经验。
l 第一步，项目的开始就是要明确目标和范围，并将目标和范围定义为可以衡量的若干要点记录到正式的文档中，今后，除非外部因素，不要更改这个目标和范围。今后项目的一切活动都要和这个目标有关，并不超过这个范围。这里要强调的一点是：实际项目中，研发人员往往不是不能达到这个目标，而是超过了既定目标的要求去完成他的开发任务。有些技术人员缺乏时间成本与技术成本意识，总是要把事情做到最好，而忽略了一个项目的规模和时间要求，这将使项目越做越大，最终影响到项目的进度。在项目目标明确的时候，召开核心人员开次动员会议是很有必要的。可以用“他们从此过着幸福生活的”方法描述项目顺利完成后的美好场景以激励成员。士气与激情一直是项目成功的关键。
l 第二步就是通常说的WBS，大部分项目管理的书都有讲到。这里说一下任务的粒度问题。通常，任务清单也是项目进度表的主要部分。WBS是逐步细化的，一周以后要做的事基本上无需细分，只要有大致方向就可以了。至于当前的任务，最好细到以小时有单位，而且不要超过4个小时。任务细分的工作可以分割给不同的人去做，每个人去细分他的工作，但是一定要上报项目经理，最终再由项目经理确认。此项工作在项目计划中还将详述。
l 第三步，确定领导。一个项目里有且只有一个领导很重要。特别是只能有一个决策者。这个人一般是项目经理，他沟通上级、客户和团队。在一些项目中，可能了除了项目经理，还会有系分之类的上层人员，但是必须只有一个人有决策权。因为为意见分歧而争论是项目的一大忌讳。决策者可以也应该充分听取各方意见，但是只有他发出的计划和任务安排才是有效的。这也体现在需求管理上。需求的任何变化都必须经过项目经理的决策而不能由系分、架构师或者开发人员直接决定。
l 第四步实际上是第二步的基础上进一步的工作，也和项目计划有关。任务一定要负责人，否则细分任务就无太大意义。
l 风险管理相当重要。降低风险最有效的方法是控制上级和客户的期望值。这需要项目经理有比较强的沟通能力。同时，风险很多来自于需求的变化，因此有效管理需求也是风险管理的重要内容。在需求分析的时候，就要为每一项需求评估风险，并尽量将高风险的需求减少或者推倒项目主体完成后实现或者推后到项目二期。需求变更管理的关键在于控制需求变化的发生。不能轻易修改需求，所有修改必须经过审批和讨论并且在开发人员手中保持拥有一致的、最新的需求规格说明书。这项工作可以借助版本控制软件。
l 第七、八步是建立项目监督和反馈机制。可以通过以下活动来实现：每日工作报告、每周例会、双周项目总结报告、每月项目汇报。前几项是项目成员向项目经理反馈以及时发现问题，调整计划。最后一项是项目经理对领导汇报。采用何种形式不是很关键，关键在于保持沟通顺畅。面对面的谈话远比厚厚的文档更能达到交流的效果。对于目的在于沟通的文档，应该进可能减少，仅当无法面对面时才作为主要沟通方式。
2.2 项目计划与进度控制
项目管理的核心活动为制订计划并执行之。项目计划如何制定、如何贯彻，也是大家广泛讨论的话题。
项目计划的制作一般从分析项目范围入手。先划分出几大类型的工作，然后对几类工作分别做WBS，然后再对每一项任务分配负责人。由于很多任务对前一任务有一赖性，有些则要随着项目的进展才能明确，所以项目计划是不断变化的，一般每周都要审查一次，推出一个新的版本。以上的工作可以通过MS PROJECT完成。
项目计划的内容还和所采用的软件过程有直接关系并可以体现出项目的软件过程。不同的过程对项目计划的任务细分程度、时间的预算长度都有不同的策略。总的原则是，项目计划是不断迭代的，而且当周的任务应该是细分到一两个小时的。在需求明确之后，WBS关于设计与实现的任务直接来源于需求。
2.3 WebOA.NET的项目管理
本项目的项目管理基本上采用了结构化项目管理的方法，采用的软件过程以统一过程为主，后来又受了敏捷过程的影响，所以项目计划上结合了两个过程的一些特点。项目立项后，我们首先确定了项目的目标和范围：
然后着手准备各种资源。项目启动后，第一版的项目计划主要包含以下内容：
l 本项目的目标和范围
l 采用的技术体系
l 将任务分成三个集
n 管理过程级：安排项目管理需要的工作。确定了每日任务安排、每周例会总结的制度。指定了需求变更的流程。安排了若干个进度检查关键时间点。
n 研发过程级：包括需求分析、概要/架构设计、设计和实现以及测试验收的工作。但是因为项目才刚开始，所以只对需求分析做了初步细分，并对第一周的需求工作任务细分到了每个人每天有若干任务。大致制定了其他工作的时间表。
n 支撑过程级：指定了培训、配置管理的一些工作的负责人和大致时间表
本项目计划在每周的审查后都进行调整，推出新的版本。调整的主要内容是对研发过程级的不段细化。然后每周会发给每一个人一份他的一周任务清单。此工作可以通过OUTLOOK很好的完成。我不主张让每个人都清楚项目的详细计划，而是只要明确他的任务就可以了。之后，根据每个人任务完成情况的反馈来调整下一周计划。
后期，受XP的影响，引入了发布计划，每周决定要发布的可运行版本要实现的用例列表。而开发计划则围绕发布计划细分。
