软件架构与项目管理的问题

1 项目管理案例分析

我们用一个非软件的事情举例, 让大家为这个例子作一个详细的项目计划并评估出最精确的时间。例1:请大家评估各自把我的这篇文章重新打一遍的时间。这个例子最简单了, 拿我自己来说, 我打字速度为每分钟30个汉字, 所以这篇文章重新打一遍的时间就是文章的总字数3000/30=100分钟。加上中间休息的时间, 最多就是120分钟。答案相当准确, 我想也不会有太多人有异议, 但是下一个例子可能就有些不一样了。例2:请大家解开下列的方程式:x2+px+q=0, p=2, q=1。初中的方程式阿, 但是很多人可能忘记它的通用求解公式了, 不过我们假设大家都知道这个求解公式:-p/2±sqrt (p2/4-q) 。评估时间的时候我们首先要知道我们打开计算器的时间, 输入数据的时间, 抄录结果, 并且为了保证计算准确, 我们需要进行验算。嗯, 这样估算时间的权威性恐怕不如例1那样令人信服了。

2 每个项目的区别

例1的估算方法大家都掌握, 而且执行过程中的变数最少, 因为并不需要我们去做任何的探索过程。例2的不同点是解题的方法需要外部因素的介入, 而且这个技术并不是每个人都掌握, 最重要的特点是每一个步骤我们都需要去估算它完成所需要的时间, 如果我们已经计算过一次了, 当然第二次就会估算的更准确一些。可是现实生活中的项目很少会给你机会重新做一遍。当你完成项目之后, 跟这个特定项目相关的各种方法也就失去了它的作用, 它唯一的价值就是潜入你的记忆中, 成为所谓的“项目经验”, 而这个“经验”也常常会在下一个项目水土不服。

要让项目计划贴近现实, 首先我们需要把项目中所有的工作都罗列出来, 然后把每一个步骤地工作进行细分, 以致细分到“原子级”, 也就是不能再分的程度, 从软件项目来看, 就是分到“文件”, 分到“类”甚至分到“函数”级别。然后对这些“原子级别”的工作进行评估时间, 累计综合, 最后乘上一个系数 (一般是2) , 就是最终项目所要花费的时间了。

我们再回来看例2, 如果解题的人忘记了这个求解的公式的话, 前面估算的进度是否需要调整呢?回答是肯定的。这样的时间计算就需要考虑寻找资料的时间, 只要找到公式, 计算出结果就不是问题了, 而找公式所花费的时间, 在有通畅的网络连接情况下, 包括网络搜索、询问同事等等方法, 一个小时足矣!

3 工作之间的层次

从例2就可以总结出如下几个现象:工作与工作之间可以有层次关系的, 一个看似很简单的工作, 很可能会隐含着巨大的工作量, 在某些先决条件没有或者准备不足的情况下尤其如此。要准确估算一个工作所用的时间, 首先我们就要把“折叠”起来的“工作树”尽可能完全“展开”, 其次就必须要遏制工作中的“学习”、“研究”甚至“查询搜索”的工作量。总之, 在实际项目开展的时候, 就要尽可能让所有的工作都是单纯的, 可以预测的, 并且尽可能排除那些不可控、不可靠的因素。换句话说, 项目的每一个工作与时间的关系都必须是“线性”的。如果实在不能排除“非线性”的工作, 也必须在“可控”的范围内, 项目内部不允许有“不可控”的“非线性”因素存在。

4 项目管理的因素

到底项目中究竟有多少因素是属于“不可控”呢?哪些又是属于“可控”的?哪些属于“线性”因素?要回答这个问题, 我们首先来看一下我们目前的软件开发方式和流程吧: (1) 接单签订合同。 (2) 需求调研、分析。 (3) 架构设计、概要设计。 (4) 详细设计。 (5) 编码、测试。 (6) 交付、维护。

大致六个步骤, 其中三四五是和我们谈得开发过程相关联。首先我们看第三点和第四点, 他们统称为“设计”, “设计”阶段的目标是解决四方面的问题:数据结构, 软件体系结构, 过程细节, 接口性质。

传统的“设计”所解决的问题, 有相当一部分应该归纳为现在的“架构”范围内。软件架构涉及的范围主要包括如下: (1) 应用程序的层次划分 (比如界面层, 存储层等) 。 (2) 部分应用程序模块的划分 (比如初始化块, 配置模块, 权限模块等) 。 (3) 部分应用程序模块的实现 (权限、用户、组织机构管理等) 。 (4) 函数库的实现。 (5) 各模块、层之间的相互关系和通讯机制。 (6) 相关的部分数据结构定义。

如此可见, 上文中的第三和第四点最重要和最基础的工作基本就在“架构”范围内, 剩下的工作, 基本就是跟具体业务相关的了。架构设计的时间最难控制和估算, 概要设计和详细设计因为就是直接从需求条目演化而来, 而且容易细化, 所以虽然也是属于“设计”这种“非线性”工作, 但是“可控性”要比“架构”强很多。从个人的项目维护经验来看, 维护过程中产生的问题, 有相当一部分是因为用户需求突破了原先架构的能力所致, 而正是这种问题, 才是拖延时间最长, 引起客户反映最强烈, 也是维护人员最痛苦最头痛的问题。因此, “架构设计”我把它归类到“非线性”工作中, 而且是“难点”工作。

我看到很多的公司软件部门都叫做“研发部”, 用英文说就是research and development的部门, 但是我很少看到有公司把research和development分开做两个部门的。这有什么关系呢?从上文我们可以看到, 研究是一种非常耗费资源的工作, 而且风险 (尤其是技术风险) 很大, 很可能因为一个小技术难题不能突破而导致整个架构推翻重来, 而开发的风险则要小得多, 可控得多;另外一个大的区别就是研究并不直接创造价值, 而开发则跟公司的收入密切相关。基于这两个理由, 就足够把“研究”和“开发”完全分开成两个部门了。

分开之后的工作如何分配?很简单, 就是把“软件架构”和其他有难度的“非线性”工作统统交给高手云集的“研究”部门去做;具体项目相关的业务和实现交由“开发”部门去做, 因为他们对技术要求不高, 而且成本较低。说到这里, 我是不是在主张每一个公司都需要专人去“研究”技术呢?恰恰相反, 我主张大部分公司都不需要设立“研究”部门, 至少大部分公司不要去研制甚至试图研制所谓“自己的”软件架构。因为软件架构相比具体业务有一定的独立性, 并没有一种“特别适合”于某类业务的“软件架构”存在, 即使有, 它也是应该经过N个项目的M年考验之后才会出现 (N*M>10年) 。我相信SAP会有这样的架构, 但是国内公司基本不会有。现在市面上有很多开源的架构存在, 选一个吧, 然后去培训你的员工, 不断地培训, 指导他们能够熟练地将这个架构应用到项目中去为止, 即使这样, 你的总花费也还远远小于请一个“高手”开发一个失败架构的投入。

摘要：软件项目管理过程中暴露的最大问题是什么?不同的人的会有不同的答案, 但是大致这样的答案我想大部分人都是会认可的, 那就是“进度拖延”。以下文章会解释每个项目的详细情况。

关键词：软件架构,项目管理