【转】工作分解结构在软件开发中的应用

1　概述

通过对项目管理的系统学习，我个人对于工作分解结构在软件中的应用有很深的感触，对于工作分解结构在软件开发中的应用有一些个人的看法和见解。

首先我们看一下项目分解结构的定义，工作分解结构是进行范围规划时所使用的重要工具和技术之一，是面向可交付成果的对项目元素的分组，它组织并定义了整个项目范围，未列入工作分解结构的工作将排除在项目范围之外。它是项目团队在项目期间要完成或生产出的最终细目的等级树，所有这些细目的完成或产出构成了整个项目的工作范围。

从项目分解结构的定义和我们的学习我们知道，项目分解结构主要针对的是可交付物以及工作细分。同时通过学习我们知道，项目分解结构产生于项目计划阶段过程，在项目执行过程的控制中对项目进行考核和控制，最后在项目结束阶段为整个项目的考核提供参考。但是，我个人认为，如果从软件开发的角度来看的话，项目分解结构这个工具在需求定义期间也能起到很好的应用，也是非常有意义的，我将会再下面的示例中进行阐述。下面结合实际工作案例对项目分解结构在软件开发项目中的应用作一个简单的描述。

2　软件项目存在的普遍性问题

1、工作范围界定

首先我们来看一下什么是软件开发，说白了，软件开发其实就是让电脑在我们设定好路线上行走的一个实现过程。而人的思维是逻辑的、发散性的，电脑的思维是单一的、指令性的。就此而言，在电脑软件的实现过程中需要对人的思维和操作方式进行整理，形成一个符合电脑工作的一个流程，在这中间就涉及到了工作范围界定，和各种信息的综合筛选。

2、工作量估算

通过几个软件项目的完工，我又这样的一个感触，一个软件项目如果完成时间超过预计时间15%以下就算是一个很不错完成时间。从我接触的几个项目上来看，最长的一个项目甚至延期了将近半年的时间，而最初的预期开发时间只有三个月。从后来对项目最终评估结果看来，除了由于客户的一些行政和人事原因引起的延时，很大一部分原因还是因为对项目的工作量把握不够，在一些关键的模块上产生了很严重的超时。

3、需求难以明确

在软件项目启动阶段，不管是甲方还是乙方，对于软件的估算都是不足的，项目的需求都有一个从模糊到清除的过程，在项目启动阶段，总是需求最模糊的一个阶段，而这个阶段却是项目的一个重要阶段，明确地需求直接关系到开发的成本和报价，怎样与客户通过沟通得到较为一致且明确地需求就显得非常重要。

4、软件开发过程控制

在软件开发过程中，沟通和交流的直接明了非常重要，通畅准确的沟通可以很好的提高开发效率和明确的得到最终交付物，但是如果光靠通过口头交流来说的话容易产生一定的偏差，通过文字来交流话又不是很直观。难以满足对项目及时调整、管理、甚至决策的需要。

从以上的各个问题来说，事实上我们需要的是一个统一的、规范的沟通标准，利用此标准可以是项目的各个参与方进行有效的信息沟通，同时可以确保业余与项目管理方获得准确实时的项目信息，以便高校的对整个项目的进度、成本、质量进行统一的计划和控制。

3　工作分解结构的具体应用

在这里我简单的描述一下项目，该项目是针对电力行业的一个MIS项目，在项目的执行过程中我们事实上没有完全按照项目管理的规范来做，但是，在项目的各个环节中我们都很多的用到了工作分解结构这样的一个工具，在这里我们分阶段进行应用阐述。

1、启动阶段

项目在最初定义阶段，不管是客户还是软件开发人员，对于系统的了解总是基于大模块的，而对于模块的局部结构的了即就比较模糊了，在需求定义和明确的过程中，首先通过软件人员的头脑风暴形成一个最初的软件分解结构，然后以此为基础与客户进行沟通就比较直观明了，便于客户形成直观的概念。但是，在这个阶段里面，项目里面的很多内容往往是不清晰和不确定的，在这里我们就可以很好的利用项目分解结构这个工具来进行有效的沟通。

我们可以从以下的三个图来说明这种情况，这几个图是在对MIS项目就行需求分析时产生的。首先图一表示的是通过开发人员的最初调研形成的组织分解结构图，然后在此基础上，通过与客户的交流发现MIS结构的模块分布式是上并不是原想的组织结构。我们了解到，电管站的电费最终也是收入到营销部，从电费归属的意义上来说的话，电管站最终也归营销部管理，所以我们对组织结构图进行了再一次的整合和修改。形成了第二个组织结构图，在大的模块的到确认的前提下，对其中的各个模块进行进一步的细分，对各个模块以最终可交付物为单位形成各个模块的细分结构，如图三，其他模块省略。这样就同时对软件开发人员和系统使用人员都形成了一个直观可行的模块印象。

在这里我们可以看出，在需求定义阶段，项目分级结构可以作为一个很好的客户与调研人员沟通的手段，可以更好的对项目的构建形成一个统一的认识，同时界定出项目的模块范围，为以后软件开发产生需求变更提供参考依据。

同时由于组织分解结构是以最终交付物为单位的，以一人两周的开发周期作模块分解的依据。所以，当最终的项目分级结构形成之后，可以依据项目分解结构计算出项目所需要的工期以及开发人员资源，并以此为基准计算出项目的可估算成本。

2、计划阶段

虽然在项目启动中，我们已经生成了一个简单的项目分解结构图，但是那其实还是远远不够的，项目分解结构图纸是项目分解结构的一个部分，在计划阶段，我们需要对项目分解结构进行再次的细分，清楚地定义出项目的各个工作包以及对应的各种资源，同时产生WBS字典。经过这个步骤就可以非常明确的定义出需求，同时可以完成对项目人员的工作具体分配。在这个基础上做出项目的完整工作计划。这样就形成了项目的基线。项目接下来的工作就按照基线按部就班的来完成。

3、项目开发阶段

在项目开发阶段，项目的进度过程中难免出现各种问题，例如项目人员的调动；项目人员没有按时地完成工作；模块功能定义时忽略了一些细节；项目研发过程中由于一些难以逾越的障碍造成项目时间的延长等等，这些事情都是在所难免的。

由于有了项目分解结构这些问题的控制和解决都变得简单了许多，我们知道，项目分解结构是基于最小的可交付成果，在项目分解结构定义的过程中都遵循了可定义、可管理、可估计、可估量、独立、专业、完整、可适应这么九个原则。在这样的前提下，通过人员的调整，各种资源的投入，项目经理可以较好的对项目中可能拖后腿的环节进行及时的控制，防止开发时间偏离预计的基线也就是预计的项目分解结构。

同时由于项目分解结构和字典的直观详细性，可以很好的为项目组成员对自身工作的认识和把握提供参考，减少了很多沟通上的障碍。

4、项目结束阶段

项目分解结构一个项目执行过程的基线，他定义了项目的最终可交付物。所以，在项目结束阶段，项目分解结构也就自然而然的成为了考核项目成功与否的一个参照，同时也可以作为对项目组成员进行项目考核的一个重要判断依据。

4　应用软件分解结构带来的好处

1、项目团队效率的提升

通过项目分解结构的制定，项目组成员可以对系统的整个架构有一个比较全面充分的认识，减少在项目过程中的不必要的争执和沟通障碍。同时在项目的执行过程中，可以让项目组的各个成员对自己的工作做到心中有数，便于项目经理对项目的控制。提升编写代码的效率。从而在整体的层次上提升整个项目团队的研发效率。

2、增进客户对软件的认识

通过在调研过程中的多次沟通，客户与软件开发团队成员形成了一定的默契关系。同时，客户能够从软件人员的描述中了解到软件开发的一般性规律，为后期的工作做好了一定的铺垫工作。

另外，通过工作分解结构，使得客户在比较直观明了的情况下对程序的功能构架有了了解，同时在反复的过程中也引起了客户自身对软件功能需求的重新认识和定位，为系统的开发定出了比较清晰的目标，减少了后期需求变动的可能性。

3、工期预计作用以及比较有说服力的成本概算

通过工作分解结构，我们比较好的定义出了软件所要实现的具体功能，在这个意义上来说的话，我们同时也就可以从中看出各个模块所需要的人员以及工期等相关因素。我们在前面已经提到了，这个软件主要是从打开行业局面为主要目的，所以我们从人员工资以及相关的工期中就可以比较有说服力的计算出相关成本，然后加上一定的对水系数我们就提出了我们对于客户的一个相对便宜而对公司来说又可以基本上持平的一个软件研发费用。虽然事实上，最终的工期和成本都与计算的有所出入，但是出入不是很大，在25%左右，我们认为这还是一个很有价值的数据，为以后的成本计算提供了比较好的参考值。

4、强有力的质量、成本、时间控制工具

我们知道，项目的三个互相制约的因素是质量、时间和成本，三者之间的平衡是一个项目成功与否的关键。项目分解结构是一个项目执行的基线，项目经理通过项目各个阶段的当前情况与基线进行对比可以发现项目中出现的偏差，然后根据项目的当前情况对项目中各个环节的成本时间进行控制。

5　总结

通过上面的阐述，我们可以看出，项目分解结构这个工具在软件项目的应用超过了项目管理中定义的范围，我个人认为可以在需求定义的时候就开始定义。用分解结构对项目中的团队效率控制，开发目标定义，过程控制都有非常实际的使用。

从实际工作出发，一般来说，项目分解结构定义越细致，对完成任务的时间、费用估计也就越准确。但是，任何事物都是对立统一的，在能够获得这些好处的同时，过度细分项目分解结构也会造成管理方面的工作量上升加重，因此，在项目的实际实践过程中，对于这个度的把握就成为了项目经理必须注意的一个问题。