项目管理简介
问:近年来,您在大力倡导软件研发项目管理方面做了很多工作。首先,请您介绍一下软件项目管理的由来,您认为实施软件研发项目管理的意义何在呢?
答:软件研发项目管理最早源自于70年代中期。当时美国国防部曾立题专门研究软件项目做不好的原因,发现70%的项目是因为管理不善引起的,而并不是因为技术实力不够,进而得出一个结论,即管理是影响软件研发项目全局的因素,而技术只影响局部。这个结论非常重要。到了90年代中期,软件研发项目管理不善的问题仍然存在。据美国软件工程实施现状的调查,软件研发的情况仍然很难预测,大约只有10%的项目能够在预定的费用和进度下交付。在商用软件产业中,这一现象尤为严重。1995年,美国共取消了810亿美元的软件项目,其中31%的项目未做完就取消了,53%的软件项目进度通常要延长一半的时间,通常只有9%的软件项目能够及时交付并且费用也不超支。软件项目失败的主要原因有: 需求定义不明确; 缺乏一个好的软件研发过程; 没有一个统一领导的产品研发小组; 子合同管理不严格; 没有经常注意改善软件过程; 对软件构架很不重视; 软件界面定义不善且缺乏合适的控制; 软件升级暴露了硬件的缺点; 关心创新而不关心费用和风险; 军用标准太少且不够完善等等。在关系到软件项目成功与否的众多因素中,软件度量、工作量估计、项目规划、进展控制、需求变化和风险管理等都是与项目管理直接相关的因素。由此可见,软件研发项目管理的意义至关重要。
软件项目管理和其他项目管理相比有其特殊性。首先,软件是知识产品,进度和质量都难以度量,生产效率也难以保证。其次,软件系统的复杂程度也是超乎人想象的。例如,宇宙飞船的软件系统源程序代码多达2000万行,如果按过去的生产效率一个人一年只能写1万行代码的话,那么需要2000万人年的工作量,这是非常惊人的。正因为软件如此复杂和难以度量,软件研发项目管理的发展还很不成熟。
问:如您所说,软件是十分复杂且难以度量,因此对软件研发项目进行管理必须依据一定的标准。国内软件行业以前倡导的标准是iso9000系列,而您却在很多场合大力倡导cmm,即能力成熟度模型(capability maturity model)。请问这两种标准的区别何在?为什么您主张软件研发项目管理一定要依循cmm标准呢?
答:iso9000是国际标准化组织提出的系列标准,其中iso9003是专门为软件行业定制的。而cmm则是美国卡纳基梅隆大学软件工程研究所(cmu/sei)提出的软件研发项目管理的一系列方法。iso9000和cmm的共同点是二者都强调了软件产品的质量。所不同的是,iso9000强调的是衡量的准则,例如应该做什么、什么算好、什么算不好,却没有告诉软件开发人员如何达到好的目标,如何避免差错。cmm则提供了一整套较为完善的软件研发项目管理的方法。美国先后在这上面投资了5亿多美元,做了很多实践工作来改进软件研发项目管理,而且其内容还在不断地改进,cmm 1.1版本推出后,现在又开始推出了cmm 2.0。iso9000系列标准涵盖面广,即包括其他行业也一直没有什么改进。在软件行业方面,它实际上是由英国学院派一批没有做过复杂巨系统的人制定出来的标准,如果认为,只要通过iso9000认证,就可改善软件生产,并用它来引导国内软件行业的发展,这无疑是种误导,我认为应该倡导美国的cmm系列。我在1999年宣扬这个观点时,当时有些人还觉得这个观点有些偏颇,但现在,越来越多的人已经同意这种观点。最近,北京市软件行业协会在中关村电脑节期间也开始倡导依循cmm来进行软件研发项目的管理。相信国内对这方面的重视程度还会进一步加强。
问:cmm的具体内涵是什么?是否实施了cmm后,软件研发项目的质量就能够有所保障了呢?
答:根据软件生产的历史与现状,cmm框架可用5个不断进化的层次来表达:其中初始层是混沌的过程,可重复层是经过训练的软件过程,定义层是标准一致的软件过程,管理层是可预测的软件过程,优化层是能持续改善的软件过程。任何单位所实施的软件过程,都可能在某一方面比较成熟,在另一方面不够成熟,但总体上必然属于这5个层次中的某一个层次。在某个层次内部,也有成熟程度的区别。在一个较低层次的上沿,很可能与一个较高层次的下沿非常接近,此时由这个较低层次向该较高层次进化也就比较容易。反之,在一个较低层次的下沿向较高层次进化,就比较困难。在cmm框架的不同层次中,需要解决带有不同层次特征的软件过程问题。因此,一个软件开发单位首先需要了解自己处于哪一个层次,然后才能够对症下药地针对该层次的特殊要求解决相关问题,这样才能收到事半功倍的软件过程改善效果。任何软件开发单位在致力于软件过程改善时,只能由所处的层次向紧邻的上一层次进化,即软件过程的进化是渐进的,而不能是跳跃的。而且在由某一成熟层次向上一更成熟层次进化时,在原有层次中的那些已经具备的能力还应该得到保持与发扬。
cmm家族包括cmm集成产品集、sa-cmm(软件获取能力成熟度模型)、se-cmm(系统工程能力成熟度模型)和ideal模型。其中cmm集成产品集为工业界和政府部门提供了一系列集成产品,以支持软件过程和产品改善;sa-cmm用于单位获取和采购基于软件的应用系统的软件过程,美国国防部、陆军、海军和一些商用单位都已采用了sa-cmm对他们的获取能力进行评估;se-cmm是描述了一个单位为保证实现一个好的系统工程的主要元素;而ideal模型则是一个单位用于启动、规划和实现过程改善措施蓝图的模型,概括了建立一个成功的过程改善项目的必要步骤,其中i代表initiating(启动)、d代表diagnosing(诊断)、e代表establishing(建造)、a代表acting(措施)、l代表learning(学习)。
美国曾在1995年做过软件产业成熟程度的调查,发现在美国的软件产业中,cmm成熟度等级为初始级的竟占70%,其特征是软件开发过程不能预测,风险度高; 为可重复级的占15%, 其特征是软件开发过程需小心谨慎方能避免失败; 为定义级的所占比例小于10%,其特征是软件开发过程相当稳定, 进展顺利且可以预测; 为管理级的所占比例小于5%,特征是软件过程预测准确、值得信赖;为优化级的所占比例小于1%,其特征是软件过程能持续改善。美国的情况尚且如此,国内在这方面的起步则更加缓慢一些。目前,据我所知,国内只有清华大学鼎新公司的cmm成熟度等级能够达到可重复级。尽管cmm已经是一套发展相当成熟的方法,但国内要想完全地掌握并大范围地付诸实践,对绝大多数软件企业来说,可能还需要3~5年的时间。
需要注意的是,并不是实施了cmm后,软件研发项目的质量就能够有所保障了。cmm不是万能的,它的成功与否,与组织内部有关人员的积极参与和创造性活动密不可分,而且cmm并未提供有关子过程实现域所需要的具体知识和技能。因此,psp(personal software process,个体软件过程)应运而生。psp也是由美国卡纳基梅隆大学软件工程研究所开发出来的,它的推出在软件工程界引起了极大的轰动,可以说是由定向软件工程走向定量软件工程的一个标志。psp为基于个体和小型群组软件过程的优化提供了具体而有效的途径,例如如何制订计划,如何控制质量,如何与其他人相互协作等等。在软件设计阶段,psp的着眼点在于软件缺陷的预防,其具体办法是强化设计结束准则,而不是设计方法的选择。根据对参加培训的104位软件人员的统计数据表明,在应用了psp后,软件中总的差错减少了58.0%,在测试阶段发现的差错减少了71.9%,生产效率提高了20.8%。psp的研究结果还表明,绝大多数软件缺陷是由于对问题的错误理解或简单的失误所造成的,只有很少一部分是由于技术问题而产生的。而且根据多年来的软件工程统计数据表明,如果在设计阶段注入一个差错,则这个差错在编码阶段引发了3~5个新的缺陷,要修复这些缺陷所花的费用要比修复这个设计缺陷所花的费用多一个数量级。因此,psp保障软件产品质量的一个重要途径是提高设计质量。
然而,实践证明,仅有psp还是不够的,因此,cmm/sei又在此基础上又发展出了tsp(team software process,群组软件过程)的方法。tsp指导项目组中的成员如何有效地规划和管理所面临的项目开发任务,并且告诉管理人员如何指导软件开发队伍。始终以最佳状态来完成工作。tsp实施集体管理与自己管理自己相结合的原则,最终目的在于指导开发人员如何在最少的时间内,以预定的费用生产出高质量的软件产品,所采用的方法是对群组开发过程的定义、度量和改进。实施tsp的先决条件有3条:首先,需要有高层主管和各级经理的支持,以取得必要的资源;其次,项目组开发人员需要经过psp的培训并有按tsp工作的愿望和热情;第三,整个开发单位在总体上应处于cmm二级以上,开发小组的规模以3~20人为宜。在实施tsp的过程中,首先要有明确的目标,开发人员要努力完成已经接受的委托任务。在每一阶段开始,要做好工作计划。如果发现未能按期按质完成计划,应立即分析原因,以判定问题是由于工作内容不合适或工作计划不实际所引起,还是由于资源不足或主观努力不够所引起。开发小组一方面应随时追踪项目进展状态并进行定期汇报,另一方面应经常评审自己是否按psp的原理工作。开发小组成员应按自己管理自己的原则管理软件过程,如发现过程不合适,应及时改进,以保证用高质量的过程来产生高质量的软件。项目开发小组则按集体管理的原则进行管理,全体成员都要参加和关心小组的规划、进展的追踪和决策的制定等项工作。
总而言之,单纯实施cmm,永远不能真正做到能力成熟度的升级,只有将实施cmm与实施psp和tsp有机地结合起来,才能发挥最大的效力。
问:在软件研发项目管理方面,您觉得国内还存在哪些不足?在实施软件过程改善方面,需要注意哪些问题呢?
答:目前国内对软件研发项目管理存在的最大问题是认识不足。管理实际上是一把手工程,需要高层管理人员的足够重视。据国外有些大公司的介绍,他们在软件研发项目管理方面的投资一般占软件研发费用的10%左右。做软件项目管理是要花钱的,需要投入一定的人力物力,这些都需要得到高层管理人员的支持。软件过程的重大修改必须由高层管理部门启动,这是软件过程改善能够进行到底的关键。此外,软件过程的改善还有待于全体有关人员的积极参与,否则不仅他本人将失去从软件过程改善中获得提高的机会,甚至还会成为过程改善的阻力。在进行软件项目管理的过程中,需要注意以下几点: 首先,软件过程改善不仅需要有明确的目标,而且需要对当前过程有很好的了解,就好比当查阅地图确定行进方向时,不仅行进的目标要明确,还需要知道现在自己所处的位置。其次,需要认识到软件过程改善是一个持续改善的过程,需要不断地学习,需要知识的积累,特别是当主客观环境(例如客户需求和主要开发人员)发生变化时,需要对过程进行修改,以适应变化了的情况。最后,软件过程改善不仅需要参与人员的自觉努力,还需要定期补充各项必要的资源。过程改善需要有关领导的规划、参与人员的忘我工作和管理人员的精心安排,但是如果没有必要的资金投入,整个软件过程改善工作就会缺乏物质基础。
除了要认识到过程改善工作是一把手工程这个关键因素外,还应认识到软件过程成熟度的升级本身就是一个过程,且有一个生命周期。因此,过程改善工作必然具有一切过程所具有的固有特征,即需要循序渐进,不能一蹴而就;需要持续改善,不能停滞不前;需要联系实际,不能照本宣科;需要适应变革,不能凝固不变。我认为,将cmm/psp/tsp引入软件企业最有效的途径首先要对单位主管和主要开发人员进行系统的培训。卡纳基梅隆大学软件工程研究所曾尝试让软件工程师通过自学的方式来进行,但实际上,只有不到20%的人能够坚持到底。另外一个有效的途径是自顶向下的课程培训,即从高层主管依次普及到下面的工程师。
现在国内软件产业的发展可以说已经具有一定规模了,但除了北大方正、东大阿尔派、用友等大企业外,做软件工程项目更多的是一些规模在数十人左右的中小企业。也许有人会问,像他们这样一些人力物力资源匮乏的企业,又如何来进行软件研发项目的管理呢?其实,我建议这些中小企业可以以cmm为框架,先从psp做起,然后在此基础上逐渐过渡到tsp,以保证cmm/psp/tsp确实在企业中生根开花。我相信只要坚持改善软件工程的管理,并在实践中总结适合自身的经验,一定能取得很好的效果。
项目管理相关软件
禅道项目管理软件(ZenTaoPMS)是一款国产的,基于LGPL协议,开源免费的项目管理软件,它集产品管理、项目管理、测试管理于一体,同时还包含了事务管理、组织管理等诸多功能,是中小型企业项目管理的首选。官方网站:www.zentao.cn
禅道项目管理软件使用PHP + MySQL开发,基于自主的PHP开发框架──ZenTaoPHP而成。第三方开发者或者企业可以非常方便的开发插件或者进行定制。
禅道在手,项目无忧!
Zen是“禅”的意思,Tao是“道”的意思。ZenTao合意为禅与道。这个名称是我在读《编程之禅》和《编程之道》的时候受到启发,决定采用这个比较有中国味道的名字。
说到这个问题,要从BugFree谈起。自从04年发布BugFree以来到2007年,BugFree陆续发布了五六个版本,在Bug管理方面基本上已经完备。但这个时候产生了一些新的问题。很多网友拿着BugFree进行改动,改造为其他的管理系统。还经常有网友问,BugFree可以不可以加入项目管理的功能。我也一直在思考这些问题。后来我加入了阿里巴巴,在中国雅虎‘、阿里妈妈、淘宝三年的工作经历中,参加了大大小小的项目。也深为项目管理所困惑。于是就产生了做一个工具来解决项目管理的问题。
由于种种原因,我这个愿望在阿里巴巴并没有实现。说来也是一件幸事,这样我可以把它开源来发布。从今年初我就开始着手考虑这套管理软件的设计。整整花了半年的时间在考虑。7月份从阿里巴巴辞职之后,我开始有有了相对比较多的一点时间来进行这套系统的开发。同时也非常感谢现在的这家单位,为我开发禅道项目管理软件提供了大力的支持。
很多朋友会问,已经有很多的开源项目管理软件或者系统了,为什么还要自己做一个呢?主要原因是我认为现在的开源项目管理软件对这个问题解决的并不好,比如缺乏需求管理,bug管理等功能。而且很多开源的项目管理软件使用起来也不方便。
市场上也有很多商业的软件,但收费都不菲,而且也未必见得好用。
现在也有很多在线的项目管理服务,比如国外的basecamp,国内的易度,忙吧等。但我的观点,这些在线的项目管理软件功能有限,缺乏定制,访问速度无法保证,而且缺乏保密。
1. 集成了产品管理、项目管理、测试管理、人员管理、发布管理、事务管理等功能于一体。你只需要一个软件就可以完成项目管理的最核心的任务。
2. 开源免费,降低企业部署的成本。
3. 功能注重实效,使用方便,没有太多复杂的概念。我设计的理念是一个没有做过项目管理的人经过10分钟的培训可以使用它进行项目管理。:)
4. 基于PHP+MySQL开发,企业自主改动方便。并且基于ZenTaoPHP框架,为第三方开发者的加入打下了坚实的基础。
5. 主要理念基于scrum,同时结合了PMP里面的很多概念。
6. 支持多公司,多项目,多产品,多团队的开发。
7. 灵活的权限设置。
8. 支持产品与项目之间的矩阵关系。
禅道项目管理软件目前正在紧密开发中,已经发布了几个alpha版本。但这几个版本的功能还仅仅是冰山一角。我们计划在今年年底的时候推出beta版本,明年第一季度的时候推出第一个stable的版本。
禅道项目管理软件需要您的帮助,无论您是开发人员,抑或是项目经理,或者是产品经理,还是测试人员,又或者是开源爱好者,您都可以在禅道项目管理软件找到参与的地方。我们会以非常open的心态打造一个禅道项目管理软件的社区。我相信,禅道社区的成功,才是禅道项目管理软件的成功。
添加日期:2010-02-24 10:53 作者:王春生 来源:本站原创 阅读 61
大家好,我很高兴的向大家宣布,windows平台下面集成apache, mysql, php, zentaoPMS的运行环境终于完成了。欢迎大家下载使用。
http://zentaoms.googlecode.com/files/ZenTaoPMS.0.5.beta.exe
2.1 下载之后,运行zentaopms_0.5_beta.exe,然后指定解压缩的目录。推荐将其解压缩到c:\。如果是其他的目录,注意,目录中不要看含有中文,也不要含有空格。
2.2 以解压缩到c:\为例,进入c:\zentao,里面有一个start.exe文件。双击运行。
2.3 软件会有一个提示,然后缩放到桌面的右下角,为一个蓝色的图标。
2.4 左键单击该图标,然后选择第一个菜单,start uniserver。
2.5 然后通过浏览器访问 http://localhost/zentao/ 管理用户:admin,密码 123456
三、关于该运行环境
3.1 该运行环境是基于uniserver制作的,感谢uniserver团队开发的如此优雅的amp环境。:)
3.2 该exe文件其实是通过7zip压缩的自解压缩文件。也可以使用7z解开。
3.3 uniserver提供了非常翔实的帮助和功能,我也在研究中。如果有问题,大家可以先仔细看看它的帮助文档。:)
3.4 mysql的管理员账号是root,密码是root。
Apache2中网站的配置
安装目录\usr\local\apache2\conf\httpd.conf
#############################################
### Uniform Server - Apache Configuration ###
#############################################
#
# This is a neat and pre-configured setting of Apache 2 for the
# Uniform Server.
#
#############################################
### Apache Server Configuration - Notes ###
#############################################
#
# Based upon the NCSA server configuration files originally by Rob McCool.
#
# This is the main Apache server configuration file. It contains the
# configuration directives that give the server its instructions.
# See <URL:http://httpd.apache.org/docs/2.2> for detailed information.
# In particular, see
# <URL:http://httpd.apache.org/docs/2.2/mod/directives.html>
# for a discussion of each configuration directive.
#
# Do NOT simply read the instructions in here without understanding
# what they do. They're here only as hints or reminders. If you are unsure
# consult the online docs. You have been warned.
#
# The configuration directives are grouped into three basic sections:
# 1. Directives that control the operation of the Apache server process as a
# whole (the 'global environment').
# 2. Directives that define the parameters of the 'main' or 'default' server,
# which responds to requests that aren't handled by a virtual host.
# These directives also provide default values for the settings
# of all virtual hosts.
# 3. Settings for virtual hosts, which allow Web requests to be sent to
# different IP addresses or hostnames and have them handled by the
# same Apache server process.
#
# Configuration and logfile names: If the filenames you specify for many
# of the server's control files begin with "/" (or "drive:/" for Win32), the
# server will use that explicit path. If the filenames do *not* begin
# with "/", the value of ServerRoot is prepended -- so "logs/foo.log"
# with ServerRoot set to "C:/Program Files/Apache Software Foundation/Apache2.2" will be interpreted by the
# server as "C:/Program Files/Apache Software Foundation/Apache2.2/logs/foo.log".
#
# NOTE: Where filenames are specified, you must use forward slashes
# instead of backslashes (e.g., "c:/apache" instead of "c:\apache").
# If a drive letter is omitted, the drive on which Apache.exe is located
# will be used by default. It is recommended that you always supply
# an explicit drive letter in absolute paths to avoid confusion.
### Section 1: Global Environment
#
# The directives in this section affect the overall operation of Apache,
# such as the number of concurrent requests it can handle or where it
# can find its configuration files.
#
# ServerRoot: The top of the directory tree under which the server's
# configuration, error, and log files are kept.
#
# Do not add a slash at the end of the directory path. If you point
# ServerRoot at a non-local disk, be sure to point the LockFile directive
# at a local disk. If you wish to share the same ServerRoot for multiple
# httpd daemons, you will need to change at least LockFile and PidFile.
#
ServerRoot "D:/zentao/usr/local/apache2"
# ScoreBoardFile: File used to store internal server process information.
# If unspecified (the default), the scoreboard will be stored in an
# anonymous shared memory segment, and will be unavailable to third-party
# applications.
# If specified, ensure that no two invocations of Apache share the same
# scoreboard file. The scoreboard file MUST BE STORED ON A LOCAL DISK.
#ScoreBoardFile logs/apache_runtime_status
# PidFile: The file in which the server should record its process
# identification number when it starts.
PidFile logs/httpd.pid
# Timeout: The number of seconds before receives and sends time out.
Timeout 300
# KeepAlive: Whether or not to allow persistent connections (more than
# one request per connection). Set to "Off" to deactivate.
KeepAlive On
# MaxKeepAliveRequests: The maximum number of requests to allow
# during a persistent connection. Set to 0 to allow an unlimited amount.
# We recommend you leave this number high, for maximum performance.
MaxKeepAliveRequests 100
# KeepAliveTimeout: Number of seconds to wait for the next request from the
# same client on the same connection.
KeepAliveTimeout 15
##
## Server-Pool Size Regulation (MPM specific)
##
# WinNT MPM