浅谈需求驱动的的项目管教.docVIP

浅谈需求驱动的项目管教 IT工作自上个世纪70年代繁密进展，直到目前，如何管教好软件项目还始终是大家谈论的话题。这是因为软件项目失利的太多，例如项目彻底被废止、项目标工期耽误等等。 就中国现在许多软件开发群体的切实情形来看，从某种程度上来说，讹谬的利用和依靠两个软件来管教项目是项目失利的一个重要原因。这两个软件即便Microsoft Project和Microsoft Word。就像钉钉子，总是用一把斧子。 工程项目vs.软件项目 Microsoft Project本身是一个不错的项目管教工具，能够做任务分配，Petri-NET,Gannt图，资源利用分析等等。然而，Project是用来管教工程项目标，如造房子，修大桥等等。这些工程类的项目等闲利用以任务驱动的管教措施。而软件项目和传统的工程项目有性质的差异，那即便任务的不确定性。举个例子，现在房地产很火，造什么样的房子，凡是资金到位，都能保质保量的造好。造10层楼，1层用多少人天，每天做什么，很轻率计划，分配任务，人力资源。而且需求是不会变的。没见过造房子，盖了3层尔后改主意了，拆了重新盖。 而软件就大大不同了，需求的改变是不可避免的，而且凡是做过项目标人都懂得，需求的改变切实上还挺频繁。这么一来，很轻率构成计划来不及改变，用Project定义任务，计划工期等闲要花费项目经理许多的工夫，而且没故含义。 有人问，为什么需求不能安宁下来呢?定下来就不许变。等闲工程师会问这么的问题。万一他变成了客户，他可能就不会问这个问题了。需求总是会变的。第一：出钱的总是有更多的话语权(当然改需求是要该当付费的)；第二：市场的情形在变，例如竞争对手陡然公布了一个新的产品功能，那我们也定然做出应付，这即将改变需求；第三：写需求的不是神仙，人都或犯讹谬的，犯讹谬批准修订(但犯讹谬要有处罚，即便需求改变是要付费的)。因而传统的纯瀑布式的开发措施曾经成为历史了，愈来愈多的开发群体批准极点编程，迭代的开发，来应付需求的改变。 那么软件项目标这种个性，必需与之相应的项目管教工具。用斧子钉钉子的做法就有点不合时宜了。 和传统项目还有一个很大的不同，当工程项目拖后了工期，能够多加人手，把工期赶归来。而软件就不这么容易了，新来的人要纯熟项目标内容即将花工夫，工期很难全面赶上。许多IT的老总们经验不到这个问题，总感受多加人手，加班就能搞定。恳挚的管用的项目管教是要靠一个管用的管教系统来支撑的。 需求的描写 软件项目有许多不同种类。现在我们所说的软件项目，多数指的是利用类(Application)的软件项目，而不是系统类(System)的项目，如数据库，文件系统，开发工具。系统类的软件项目和利用类的项目有很大的不同。系统类的项目花很伙计夫琢磨系统架构(Architecture)，设计系统的框架，模块之间的联系等等。而利用类的软件大约上会用现成的框架，如J2EE,或Microsoft的平台等等，重要精力放在需求的告终上。中国现在的利用系统多数是为客户做定制开发的项目，例如各大企业、政府、机构、国防等做的系统，也有一些做产品的，如中小企业的财务系统，通用办公软件等等。针对利用类的项目，我们看看利用Word写这类的需求有什么问题，为什么有问题。 等闲用Word来写必需，隐含了一个设法，即便一上来把需求都写好，定下来，然后给开发部门去告终。等闲Word文档写的需求很宏伟。而对于利用系统的开发,我提倡利用迭代的措施开发。上面提到了，瀑布式的开发曾经成为了历史。需求顺次性写好，很难。软件是慢慢生长起来的(见Microsoft Secrets)，一个milestone一个milestone的进展。象小孩子长大一样，其中可能会走弯路、错路，必需我们不短的调剂、点拨，最后他/她能力成才。你很难一开始就给他/她描摹一个终生的所有的翔实场景，让他/她按照你的蓝图走(工程项目能力做到这么)。 我们提倡先想好我们会有几个milestone，每个milestone公布哪些功能。然后描写需求，最框架性的需求要率先确定好,然后先写最近要告终的功能的需求解释。后面的需求和开发就能够并行了。这么我们的产品能够比拟快的面世，客户会及时的给出反馈。从而减小项目标危险。这里提倡写需求的时候，用UI Prototype，User Scenario措施，让用户越早看到切实利用界面和利用措施越好。 现在我们许多项目标需求是用Microsoft Word写的，动辄几十页，上百页。这么的大文档，除非上面讲到的项目管教措施上的问题，还存在下面的问题： 规模宏伟，不得体查阅。一个中小型利用系统的需求文档可多达数百页甚至更多。即方便用分卷也不得体查阅. 不利于更新。需求文档是一个活的文档，不时的增长，更新是难免的。在Word中做了更新，即利用修订形式，也不轻率看出改动的局部