文章存档
相关博文
- ·
- ·
- ·
- ·
- ·
- ·
- ·
- ·
- ·
- ·
分类： 项目管理
2007-01-12 10:05:00
谈到架构，人们最常想到的就是建筑。这得感谢亚历山大大叔的功劳。另外，设计模式的成功引入到软件工程，也是一个促进。这个成功案例让很多人都去拜读《建筑之永恒之道》。
最近在讨论中，突然发现楼房在构建的时候，大部分都是采用迭代式开发的。感觉甚是有意义，特拿出来和大家分享。
我们将楼房中的每一个房屋比喻成软件中的功能。那么在开发过程中，如何计划这些功能的开发顺序，以及每一个功能的开发步骤，就是一个非常大的学问。相信每一个经历过项目的人都知道。安排不好，就会导致无谓的相互等待。
我们以前默认的工作方式是，将所有的功能模块，全部分出去。先做区域性划分。比如，什么类型的模块，由什么小组来负责。然后在此基础上，每个小组再安排自己的模块。因为人手一定是比模块数少的多的，所以必然有一部分认为不重要的模块被安排在后面。
请注意上面的模块安排方式。整个功能的安排，是根据开发小组的特性来安排的，加上层级的划分，对于软件工程整体计划的把握性越来越低。特别是项目在每一个时刻的整体状况不好判断。你说写完了一半的模块的软件是什么状况？不好说吧。我们一般可能会采用另外一种容易接受的方式来描述：
“嗯，现在的软件可以完成基本功能了。下周就可以交付客户验证业务流程了。”
这种描述，由于是从最终结果来描述的，所以往往能被领导和客户所接受。如果你细心点的话，你就会发现这里面有一个问题，如何衡量进度？软件工程目前并不成熟，所以才导致进度衡量非常麻烦。其中最麻烦的就是软件模块的整合。每一个人对于整合都是持怀疑态度的。观察一下其他成熟行业，特别是建筑行业，高度的规格化建设，保障了其在整合的时候的低风险。有一句话常常说，工业化就是规范化。一个软件公司或一个软件项目，如果做不到这些规范化，那么就会一直担心整合。对于进度的把握就会存在问题。
废话少说，我们看看楼宇的迭代过程。先来做基础，越高的房子，地基越要打号。再做框架部分，一般是浇筑钢筋混凝土；然后填补减力墙；水、电管道；装饰装修。显然，每一次里程碑的划分，并没有按照模块的多少，而是按照大楼的整体结构。
我们软件做不到类似建筑这样成熟的划分。但是我认为可以从需求角度，进行几个里程碑式的划分。
第一、完成系统基础技术的工作。类似于建筑的地基。
第二、完成系统中功能组合关系的框架。所有的功能都可以在这个框架下进行增加、调试。这里面要完成系统在架构过程中要求的模型及各种应对业务变化的模式。
第三、完成系统的基本功能。什么是基本功能？软件的目的是解决问题，如果能用使用我们的软件，虽然比较繁琐，但是已经可以解决问题了。那就是完成了基本功能。比如一个邮件系统，已经可以发送收取邮件了，那么基本功能就完成了。
第四、完成基础易用性需求。什么较基础易用性？我们软件在业务分析的时候，必然考虑了用户的一些基本需求。这时候已经是一个完整的软件了。但是没有什么亮点。
第五、完整实现系统的规划。将最后展现给用户的功能完全实现。其实用户只看到这些，其他的他们都不是很在乎。当然了，虽然他们会一直使用。就比如你住的房子，你最关注的是房子里的装修。但是如果没有水、电，房子有危险，你肯定会非常不满意。
我们一直在说迭代，但是基于迭代的方法及步骤却没有细化下来。建议我们来多做做这方面的知识积累。大家也多分享一些迭代的过程，共同成长。上面的里程碑划分，是参考建筑来做的，我在实践中并没有完全按照上面的方式，一般遇到第四个里程碑的时候，就会出现混乱。大家想法不容易在一个层次上集中。不过总算是一个想法吧。
from : http://blog.csdn.net/xiammy/archive/2007/01/11/1479913.aspx
最近在讨论中，突然发现楼房在构建的时候，大部分都是采用迭代式开发的。感觉甚是有意义，特拿出来和大家分享。
我们将楼房中的每一个房屋比喻成软件中的功能。那么在开发过程中，如何计划这些功能的开发顺序，以及每一个功能的开发步骤，就是一个非常大的学问。相信每一个经历过项目的人都知道。安排不好，就会导致无谓的相互等待。
我们以前默认的工作方式是，将所有的功能模块，全部分出去。先做区域性划分。比如，什么类型的模块，由什么小组来负责。然后在此基础上，每个小组再安排自己的模块。因为人手一定是比模块数少的多的，所以必然有一部分认为不重要的模块被安排在后面。
请注意上面的模块安排方式。整个功能的安排，是根据开发小组的特性来安排的，加上层级的划分，对于软件工程整体计划的把握性越来越低。特别是项目在每一个时刻的整体状况不好判断。你说写完了一半的模块的软件是什么状况？不好说吧。我们一般可能会采用另外一种容易接受的方式来描述：
“嗯，现在的软件可以完成基本功能了。下周就可以交付客户验证业务流程了。”
这种描述，由于是从最终结果来描述的，所以往往能被领导和客户所接受。如果你细心点的话，你就会发现这里面有一个问题，如何衡量进度？软件工程目前并不成熟，所以才导致进度衡量非常麻烦。其中最麻烦的就是软件模块的整合。每一个人对于整合都是持怀疑态度的。观察一下其他成熟行业，特别是建筑行业，高度的规格化建设，保障了其在整合的时候的低风险。有一句话常常说，工业化就是规范化。一个软件公司或一个软件项目，如果做不到这些规范化，那么就会一直担心整合。对于进度的把握就会存在问题。
废话少说，我们看看楼宇的迭代过程。先来做基础，越高的房子，地基越要打号。再做框架部分，一般是浇筑钢筋混凝土；然后填补减力墙；水、电管道；装饰装修。显然，每一次里程碑的划分，并没有按照模块的多少，而是按照大楼的整体结构。
我们软件做不到类似建筑这样成熟的划分。但是我认为可以从需求角度，进行几个里程碑式的划分。
第一、完成系统基础技术的工作。类似于建筑的地基。
第二、完成系统中功能组合关系的框架。所有的功能都可以在这个框架下进行增加、调试。这里面要完成系统在架构过程中要求的模型及各种应对业务变化的模式。
第三、完成系统的基本功能。什么是基本功能？软件的目的是解决问题，如果能用使用我们的软件，虽然比较繁琐，但是已经可以解决问题了。那就是完成了基本功能。比如一个邮件系统，已经可以发送收取邮件了，那么基本功能就完成了。
第四、完成基础易用性需求。什么较基础易用性？我们软件在业务分析的时候，必然考虑了用户的一些基本需求。这时候已经是一个完整的软件了。但是没有什么亮点。
第五、完整实现系统的规划。将最后展现给用户的功能完全实现。其实用户只看到这些，其他的他们都不是很在乎。当然了，虽然他们会一直使用。就比如你住的房子，你最关注的是房子里的装修。但是如果没有水、电，房子有危险，你肯定会非常不满意。
我们一直在说迭代，但是基于迭代的方法及步骤却没有细化下来。建议我们来多做做这方面的知识积累。大家也多分享一些迭代的过程，共同成长。上面的里程碑划分，是参考建筑来做的，我在实践中并没有完全按照上面的方式，一般遇到第四个里程碑的时候，就会出现混乱。大家想法不容易在一个层次上集中。不过总算是一个想法吧。
from : http://blog.csdn.net/xiammy/archive/2007/01/11/1479913.aspx
给主人留下些什么吧！~~