软件工程管理之《系统开发方法与项目生命周期的矛盾冲突》

各位读者大家好，由于本文章是我在闲暇时间来迭代补充编辑的，并不是一次性编辑完成，如果影响大家的阅读感受，尽请大家谅解！！！

 >>第一章：项目管理者情况

        很高兴能与大家一起分享及探讨关于软件项目管理中的核心内容，即系统开发方法的选定。开发方法虽然不能决定项目的需求边界，但是可能影响客户冲突概率，导致项目生命周期长度不可控。在谈论具体内容之前，我们先来分析一下软件行业中，正在从事或者准备从事软件项目管理工作的工作者情况。

        从项目管理者（项目经理）的专业程度来看，可以将项目管理工作者分为四种情况，当然，这是按我本人的理解及归纳总结进行的分类。

        第一类，属于大白，没有任何代码开发经验、需求调研与分析经验及大项目管理工作经历的工作者，可能是刚毕业的优等生，也可能是跨界的大拿。

        第二类，是做过程序员或者需求分析师的，是指具有一定的软件技术基础理论或者客户需求分析与架构设计能力的从业者，非通过机构认证而直接进阶成项目经理的，其自身并没有过系统的项目管理方法论的理论学习经历，此类大多是计算机专业的。

        第三类，是有过系统的项目管理方法论的理论学习经历，并获得了相关认证的工作者，但是不具备程序员或需求分析师的工作经历，这类可能是计算机专业，也可能是跨界者。

        第四类，同时具备了二类、第三类的工作经历与能力，逐步进阶到此阶段的从业人员，同样也包括各种来源。

        那么，为什么要分为这四类项目经理呢，因为如果你是第一类、第二类或第三类的项目经理，并且从业时间很短，那你如果没有读过本文章，可能还要经历很多项目的洗礼才能充分理解本题目所有讲的内容。当然，不论你是哪一种情况的项目经理，在读过本文后，相信对你来说都是一次很好的学习经历，对你个人来说，在工作中会带来很大的帮助。

>> 第二章：项目经典开发方法

        所有的理论都是从推理论证及实践工作中验证总结而来的，这是不变的事实，软件项目管理也是如此。但并不是所有的基础理论都需要你逐个去实践验证。所以，被实践证明的理论，最好的掌握方法就是通过学习来快速吸收，并能为自己所用，这样不仅少走弯路，还能提升自己的职业技能。

        所以大家可以自己对照看看自己属于哪一类，不同的类别对项目成功概率影响很大。

        本文，不再细致解释那些基础管理方法论的内容，而是直接讨论我们的命题“系统开发方法与项目生命周期的矛盾冲突”。

        从过往软件项目管理的经典理论（系统开发方法）来看，我们重点来看这几个，包括：结构化方法论、面向对象方法论、原型方法论、面向服务方法论，其实这4个方法论是按照时间的线轴逐渐衍生总结而来的。

        为了让不同读者都能读懂本文，这里还是需要用简单白话概述一下这几个方法论。

        首先，结构化方法论，就是让客户一次性提出完整的业务需求，然后软件服务商给出完整的设计，在编码之前，必须让客户与开发方同时在需求设计（规格说明书）上签字，此输出文件作为项目实施的指导性文件，包括最终的验收标准，均按照次文件进行。这个有点像菜市场买菜，挑好了一次性付款，买完了要想退货重买，还是比较麻烦的。

        该方法的优点是倒逼客户认真思考分析自己的需求，尽量的全方位考虑到所有可能的情况，避免一些大坑。因为客户要对设计的签字负责，并且认可，所以用户签字前会考虑到如果将来频繁变更需求则是对自己前期工作的否认，从而会事先反复论证系统设计，这就有利于项目的顺利实施及验收。

        该方法的缺点是客户一旦签字确认，再想变更就很麻烦，需要走需求变更流程，记录需求变更事件，并重新评估项目风险、项目成本、项目计划，计划的变化自然也就影响项目生命周期的长短，并且为了避免这些产生，也会导致签字确认时间较长。

        然后，面向对象方法论，该方法过多的执着于对技术框架以及封装的使用了，我个人认为不应该将该方法纳入常规项目管理方法中，因为此方法更加适合对服务类产品、开发平台、应用平台等应用开发中，其更多是符合行业标准、国家标准或世界标准的，是面向大宗用户应用的系统，所以很适合按照封装、继承、多态的，高内聚低耦合的形式来开发。

        那到底什么是面向对象呢？其实就是将由低到高的用户需求、企业需求、行业需求中，对很多具体的对象（例如：人、车、或者一件具体事务）的标识、状态、行为的描述，并最终将这种描述转换为一个技术对象，例如java中的类，我们可以将人的属性，包括姓名、身份证号、状态、特长、工作履历等进行结构化封装，并可以对其进行访问操作。更高级一些的还可以将很多对象的共同特征进行抽象、泛化，进行再次封装，形成一个特有对象。

        该方法的优点是从事务的本质考虑，进行分门别类单独开发，最后再通过对各个对象的集散调用完成项目的构造工作，有利于减少冗余的开发工作，对象的重复利用率及可塑造性更高，利于项目后期的运维及升级建设。

        该方法的缺点是如果项目内容比较单一，未来很少扩展升级，那么这种方法未必能对项目的成本带来好处。

        此方法不作为本文最终论述中使用的方法论，因为它可以作为其他三种方法的细分子方法使用。

        其次，原型方法论，该方法讲究的是在探索中不断研究、挖掘、完善用户的各种需求，包括业务需求、系统需求、用户需求、设计需求等。

        该模式的优点是在一定程度上允许用户站在更加粗略的设想上即启动项目的实施工作，在反复快速实现原型过程中来确定自己最终的需求，更容易达到完美的项目状态。比较适合很难梳理的项目，大项目的实施开发。

        该模式的缺点是虽然客户的需求事先已经确定，但是由于频繁地试验，可能导致需求架构的大量调整，然而，其需求的设计，以及最终的原型实现，将会突入巨大的开发工作，这与结构化方法是矛盾冲突的。另外，该模式有可能导致项目成本不可控，对项目双方人员的业务能力、管理能力、设计能力要求高。

        、、、、、、下回待续！