冬Blog

醉心技术、醉心生活
  博客园  :: 首页  :: 新随笔  :: 订阅 订阅  :: 管理

微型项目实践感悟

Posted on 2006-09-27 20:37  冬冬  阅读(20169)  评论(24编辑  收藏  举报
 

微型项目实践感悟

1什么是微型项目

微型项目是指绝大部分工作由一个人员负责的项目,这个核心成员负责项目的系统分析、构架、及绝大部分的编码工作。项目的持续时间一般不会超过一个月。项目的参与人员除了核心的程序员外还可能一部分辅助人员,包括第二程序员(负责一部分编码工作)、美工(负责界面设计)等。

微型项目的规模一般很小,业务逻辑也比较简单,价格一般也不会超过10K。程序员通常直接和对方领导打交道。客户大多没有任何技术背景。需要程序员直接负责系统的需求分析。

2微型项目分析

2.1一般流程:

微型项目的流程可以说没有什么特别的,因为项目较小,通常谈不上工程学方法。但是因为系统需求的不确定性较大,一般来说,敏捷得思路比较适合。流程如图所示:

1,      需求分析。

2,      构架设计

3,      撰写代码

4,      增量交付

5,      应对需求变更

6,      最终交付

以上过程有时候并没有什么明显的界限。鉴于项目的规模,大多时候在分析需求的时候,构建就慢慢的形成了,在形成构架的过程中,很多编码上的难点也就了然于胸了。对于需求上的变化,几乎是必然的。很多时候,项目预期一个月,但是一个星期就可以做完,剩下的三个星期都是在应对需求的变化。

2.2需求分析

这种小型项目的需求可能会千奇百怪,从常见的OA到医院的药房管理。从用户的角度看,他们通常是为了方便自己的工作,提高效率。但是什么样的程序才能满足他们的要求,他们也不知道。所以程序员就需要自己找到需求。

怎样进行需求的分析呢,一般是从用户沟通和对用户工作流程的观察出发。

在和用户的沟通之中,用户一般不会有系统的想法,或者用户的想法不现实。我们要做的就是把用户的想法记下来,然后从中提炼出真正的需求,打个比方:在一个医院药房管理系统中,用户说药材会分为中药和西药。真正的需求其实是药材需要进行分类,否则当项目开发出来用户或许就会要求增加中西合剂。当然,这里是要求敏锐的捕捉到用户的真正需求,而不是无限制的做猜想而增加项目不必要的复杂性。还有一些是不清楚的需求描叙,仍然用那个药房管理系统为例,用户要求记录入库出库信息。这条描述其实很不清楚:要记录哪些信息?纪录多长时间内的信息?信息需不需要有汇总和统计?当然需求的分析是一个渐进的过程。这里不但要求分析人员有敏锐的捕捉能力,还要求和用不断的和用户沟通,更多的让用户参与到系统的开发中来。

一般交付之后用户的需求都会变更,这是因为用户没有技术背景,根本不可能清楚的描述系统的需要。所以用户一旦看到最终的系统,就会发现和自己预想的想法有很大的出入。所以这里的交付是个相对的感念,实际是指持续交付。所以敏捷开发在这类项目中是非常合适的工程学方法。

2.3文档的管理

对于微型项目,几乎一个目录就可以保存所有的文件,这样做的方法也是为了便于备份和转移。我常用的目录结构如下:


从图上可以看出,这一个目录包含了所有的信息,以下详细分析:

1, Database。数据库目录。如果系统有不同的多种数据库,可以在该目录下根据数据库类型建立子目录,比如说SqlServerAccess等。然后根据版本建立下一层子目录。需要注意的时,有的数据库,比如SqlServer 2000。会锁定数据库文件,这样在备份或者转移项目的时候就需要先停止数据库服务。

2, Design。主要是保存PageDesgin或者UIDesign

3, Document。这个目录比较重要,保存的时所有的文档。下面按照“日期+文档名称”的规则为每一个文档建立子目录。注意,这个目录下的文档是正式提交的文档。同时,一个文档可能提交过N个版本。

4, Member。重要目录。用于保存项目所有成员的文档。类似于版本控制器。每个成员按名称建立自己的子目录,再在自己的目录下按照“日期+该工作名称”的方法建立目录。目录下保存该项工作所有资料。包括文字、图片等。这样每个成员的工作记录都有据可查。

5,        Publish。项目发布的目录。按照“时间+版本”的方式发布,我们的目标就是尽早的发布!注意发布中应该含有所有相关信息,包括程序(安装程序)、数据库脚本、帮助文档,甚至是刻录光盘的Autorun.Inf

6,        Ref。引用目录,里面放的是项目引用的第三方类库和相关的帮助文档等。

7,        Solution。重要目录。这就是我们的解决方案所在的地方了!一般是按照版本建立解决访问。

8,        Source。参考资料。可以是文档,图片,也可以是别人的产品,开源项目等。只要是对项目有参考价值的,都应该被捕捉。

9,        Team。团队的公用文件夹。存放公用的信息,比如说成员的联系方式等。

10,    Template。模版。一般指文档模版,即dot文件。目的是为了保证项目的文档都有一致、良好的格式。这点在对企业单位,特别是国有企业的项目中尤其重要。混乱的格式会给人不可靠的感觉,领导对此尤为敏感。

11,    Tools。项目所用到的工具软件。比如说代码生成器等。

12,    TryProject。每个项目都可能涉及到一些我们不太了解的技术,这就需要我们做一些尝试,这些尝试也应该保存下来,作为参考。我们可以建立一些TryProject进行实验。

以上就是我管理文档的方法。从文档的管理方法其实可以反映出很多项目的情况。一个良好的项目应该有良好的条理性。,具体展示出来的效果如图所示:


需要说明的是,这个图所展示出来的只是一个
Demo。也是我为这篇文章所建立的。所有非常的小。真正的项目文件夹有几个G大小是很正常的。

2.4版本控制

任何项目都需要有版本控制,这是无可厚非的。版本控制就是个大型的Undo/Redo。保证你随时可以吃后悔药。

版本控制的概念不应该仅仅只是捕捉代码。所有和项目相关的数据都应该在被捕捉的范围内。这些数据通常包括:文档、设计、数据库(及脚本),发布过的二进制包。采集的资料等。这也是现在的版本控制软件发展的方向。

对于文档、设计等,其实前面的文档管理方法就是一种版本的控制方法。

对于代码,这个级别上的项目VSS无疑是最合适的选择。不管有没有第二个程序员,代码的版本控制都是有益无害的。

2.5其它方面

1, 数据库

数据库如果在团队项目中,一般是架设在专门的服务器上的,这样大家都可以根据同一个版本进行开发。不过数据库的修改就要比较谨慎。同时要建立好数据库备份计划。

如果能够分离数据层,或者采用ORM等框架,支持数据库类型的转换,那么采用Access进行开发,部属的时候采用Sql也是一个不错的选择,这样备份和转移的时候依然可以一个Copy搞定。

2, 备份

由于文件都在一个目录中,所以备份文档就是把整个项目目录Copy以下,不过有的时候最好清理一下TestResults(单元测试结果)文件夹,再压缩一下Solution文件夹。如果使用了VSS,还要记得备份VSS的数据库。

 

以上的方法不一定是最好的,只是我在做项目的过程中总结的一些适合自身的技巧。希望对大家有帮助。也希望起到抛砖引玉的作用。