<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>蔡晓东的博客</title>
	<atom:link href="http://www.caixiaodong.com/feed" rel="self" type="application/rss+xml" />
	<link>http://www.caixiaodong.com</link>
	<description>为什么要改版呢？</description>
	<lastBuildDate>Sat, 27 Aug 2011 14:17:15 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>国内第一本项目管理的实践书籍——《IT项目管理那些事儿》</title>
		<link>http://www.caixiaodong.com/archives/196.html</link>
		<comments>http://www.caixiaodong.com/archives/196.html#comments</comments>
		<pubDate>Sat, 27 Aug 2011 14:17:15 +0000</pubDate>
		<dc:creator>蔡晓东</dc:creator>
				<category><![CDATA[软件工程]]></category>

		<guid isPermaLink="false">http://www.caixiaodong.com/?p=196</guid>
		<description><![CDATA[

CSDN创始人蒋涛写序，中国过程与系统改进协会秘书长王钧、中国计算机学会秘书长杜子德研究员、盛拓传媒CTO廖志强、神州数码VP潘冬博士等人推荐。

ISBN：9787121140716
2011年8月下旬上市
定价：59.00元


项目管理的实践，有的轻松活泼、有的痛苦辛酸，可就是真实的项目经理生涯。没有永远的鲜花，没有永远的泪水，只有日复一日的坚持，和项目成功时的喜悦。让你体会项目经理人的挫折，分析他们努力的轨迹，分享他们的悲欢，这就是咱们IT项目经理人自己的故事！
本书四大卖点：
1、 作者阵容空前强大
作者团队来自于不同的行业、不同的企业背景、不同的工作职位，从经验丰富的一线项目经理、项目总监到技术总监、PMO总监、CTO。

作者均为PMBAR社区专家：@标志为新浪微薄ID
@不胜人生一场醉PMBAR、@蔡晓东_、老谷@冯国馨PMBAR、@开启尘封的记忆、@传说中的王鹏举、@richard李明、RobertZee史昀、@张权先生、@恺墨、老倪、nancy刘玲
2、  叙事风格的项目管理书籍
与其它项目管理书籍不同，本书采用的是叙事的风格，通过分享项目经理人自身的实践和经验的案例，诸如一个个精彩绝伦的项目实施案例，组织级项目管理的实施过程，项目经理的成长和团队成员的培养历程，从而和读者达到共鸣并跟随作者叙事的脉动，以从中得以进一步的思索和升华。简而言之，通过感受项目经理人的喜怒哀乐，经验教训，达到“它山之石可以攻玉”的目的。
3、  PMBAR社区支持和项目管理群
本书作者团队来自于PMBAR社区，PMBAR项目研发管理实践社区聚合业内从事和关注项目与研发管理的专家及朋友，提供理论研究、实践分享和咨询培训指导。同时MSN项目管理群已经凝聚了几百位从事项目管理的PM、项目总监、技术总监和CTO，进行不定期线上线下的项目管理分享。
4、 广泛关注构建畅销动力：本书从创作过程中就吸引了大量有志于成为项目经理的、已经成为项目经理的，甚至企业管理者的IT人士的关注，知名的IT作者、相关论坛的顶贴支持、QQ群的广泛热议。知名作者、小说式的讲解、魅丽作品、全面营销的支持，构建起畅销动力！
京东商城
http://book.360buy.com/10804899.html
当当网
http://product.dangdang.com/product.aspx?product_id=22483332
卓越亚马逊
http://www.amazon.cn/IT%E9%A1%B9%E7%9B%AE%E7%AE%A1%E7%90%86%E9%82%A3%E4%BA%9B%E4%BA%8B%E5%84%BF-%E7%8E%8B%E4%BF%9D%E5%BC%BA/dp/B005FY3U2G
China-pub网
http://product.china-pub.com/198482&#38;ref=browse
电子工业出版社
http://www.phei.com.cn/bookshop/bookinfo.asp?bookcode=TP140710&#38;booktype=main

本书作者的博客地址： 
PMBAR社区
http://www.pmbar.net
不胜人生一场醉的博客
http://blog.csdn.net/baoqiangwang
谷雨霖的博客
http://space.itpub.net/3433/
刘羚的博客
http://liuling.csai.cn
蔡晓东的博客
http://www.caixiaodong.com/
史昀的博客
http://robertzee.wordpress.com/
]]></description>
		<wfw:commentRss>http://www.caixiaodong.com/archives/196.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>密码保护：17岁的问题</title>
		<link>http://www.caixiaodong.com/archives/193.html</link>
		<comments>http://www.caixiaodong.com/archives/193.html#comments</comments>
		<pubDate>Mon, 08 Nov 2010 16:09:55 +0000</pubDate>
		<dc:creator>蔡晓东</dc:creator>
				<category><![CDATA[静夜沉思]]></category>

		<guid isPermaLink="false">http://www.caixiaodong.com/?p=193</guid>
		<description><![CDATA[无法提供任何摘要。这是一篇受保护的文章。]]></description>
		<wfw:commentRss>http://www.caixiaodong.com/archives/193.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>软件开发项目管理系列课件</title>
		<link>http://www.caixiaodong.com/archives/189.html</link>
		<comments>http://www.caixiaodong.com/archives/189.html#comments</comments>
		<pubDate>Thu, 21 Oct 2010 13:49:51 +0000</pubDate>
		<dc:creator>蔡晓东</dc:creator>
				<category><![CDATA[软件工程]]></category>

		<guid isPermaLink="false">http://www.caixiaodong.com/?p=189</guid>
		<description><![CDATA[软件开发项目管理系列课件
]]></description>
		<wfw:commentRss>http://www.caixiaodong.com/archives/189.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>打造属于自己的项目管理方法论</title>
		<link>http://www.caixiaodong.com/archives/187.html</link>
		<comments>http://www.caixiaodong.com/archives/187.html#comments</comments>
		<pubDate>Tue, 04 May 2010 01:02:40 +0000</pubDate>
		<dc:creator>蔡晓东</dc:creator>
				<category><![CDATA[软件工程]]></category>
		<category><![CDATA[项目管理]]></category>

		<guid isPermaLink="false">http://www.caixiaodong.com/archives/187.html</guid>
		<description><![CDATA[在项目管理群里，有朋友感叹不是科班出身，只有丰富的实践经验，却无完整的理论体系。我对他说，错！实践经验远远比理论宝贵。有心学理论，花一些时间啃几本书就可以了；而实践经验，却不是每个人都有机会获得的。

幸运的是，我们身处一个高速成长的公司。大多数有能力、有意愿成为项目经理的人员，都有机会获得这个职位。然而，作为项目经理，却不是每个人都懂得珍惜这个职位，为自己获得尽可能多的能力提升。多数项目经理完全凭借经验从事管理。

在一个项目中付出的越多，收获的经验也越多。这当然是一种可行的成长方式。但是，不同项目组之间的管理水平差距却如此之大，某个项目组几年前就已经做到的重要管理实践，在另一个项目组，却几乎完全没有进行。如果有足够的时间，相信每个项目经理都能理解这个实践的重要性。更好的做法，是积极学习和利用其他人的项目管理经验。全球最优秀的项目经理的经验汇集，就体现在《项目管理知识体系指南》（PMBOK）中。项目管理理论来源于项目经理优秀实践的总结，并进行标准化表述及抽象，再用于指导广大项目经理的实践。

第一次看PMBOK，通篇都是过程（Process）的描述，感觉非常枯燥无趣，不知所云。但几个项目做下来，越来越体会到PMBOK的精要。特别有意思的是，公认项目管理做的比较差的项目组，逐个比对9个过程域，发现相符的很少；而公认项目管理做的比较好的项目组，至少有一半的过程域是基本做到了，尽管项目经理同样没有读过PMBOK。

那么，下一个问题就是，如果让项目管理较差的项目组参照9个过程域逐个改进，它的项目管理水平会不会提高，甚至表现出整体绩效提高呢？这个问题就需要细细思量了，而且刚刚说过最宝贵的“经验”就派上了用场。我们可以把一个以往的项目在脑袋里回放一遍，逐个比对9个过程域中的某些方法是必要和有益的，而哪些对于我们的项目却不适用。或许是PMBOK的方法过于复杂，或许是我们的项目规模太小，各种原因都有可能导致某些方法不适合我们，这没有关系，选择我们适用的，在下一个项目中检验。之后，对于PMBOK的方法，我们还会一些优化的想法，这并不是说PMBOK错了，它是适合所有项目的理论，而并不是最适合我们项目的。三个步骤：（1）项目管理实践（2）对比理论框架评估某些实践可以适用理论（3）在实践中检验项目管理理论的适用性，并优化理论使之更适用于我们的实践。之后的成果，不是简单的实践经验，也不是单纯的项目管理理论，而是独特的项目管理方法论，是你的项目管理方法论！


这种经过反复锤炼出的方法论，即有良好的理论框架支持，又能最适用于我们所经常面对的业务背景和项目场景。这个方法论，将伴随着整个项目管理职业生涯，不断成熟优化。当项目面临复杂的场景、项目团队面临极大困难的时候，项目经理才能够保持一份坚定和冷静，把必胜的信任传递给每一个项目成员和干系人，并带领项目走向成功。

PS：项目管理方法论所涉及的范围很广，除了PMBOK，还有很多社区资源可以利用，和其他项目经理共同进步是一个很好的主意。在软件行业，与项目管理并重的还有软件工程过程知识，它对项目成败的影响也非常显著，这里不再展开讨论。
]]></description>
		<wfw:commentRss>http://www.caixiaodong.com/archives/187.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>如何使用mail@yourname.com格式的邮箱</title>
		<link>http://www.caixiaodong.com/archives/186.html</link>
		<comments>http://www.caixiaodong.com/archives/186.html#comments</comments>
		<pubDate>Tue, 06 Apr 2010 05:13:17 +0000</pubDate>
		<dc:creator>蔡晓东</dc:creator>
				<category><![CDATA[软件工程]]></category>

		<guid isPermaLink="false">http://www.caixiaodong.com/archives/186.html</guid>
		<description><![CDATA[知道我邮箱的朋友们越来越多，有的朋友觉得很酷，可是却不为所动。其实创建一个自己姓名的邮箱还是非常有必要的。其一，这是一个真正的私有邮箱，个人永远拥有它的所有权，不会因为一些无良服务商或众所周知的原因突然不可用；其二，邮箱容易记忆是非常重要的；其三，作为一个IT业的专业人士，偶尔写写博客，可以随意发表一些专业的独立意见，而不需要迁就编辑的喜好。
首先，应该先注册一个个人姓名的域名。当然首先.com域名，价格便宜，质量又好。如果姓名是3个字的，基本上都还怎么被注册。注册服务商建议godaddy.com，支持支付宝付款，每年50元人民币左右。
有了域名之后，接下来是选择邮局。我选择的是gmail企业邮局，不过也有人发现国内发信到gmail很慢（我没有发现），后来我建议她把使用QQ企业邮局。这个就是个人域名邮箱的好处了，自己设置一下就好，没必要逐个通知说，我的gmail邮箱不用了，改成用QQ邮箱了。
邮局确定了以后，DNS将MX记录解析到邮局就可以了。具体看邮局的说明。如果需要帮助也可以找我，前提是我有空的时候。
另外，有了域名，再花上100元/年，弄个php空间写博客是个好主意。我的空间稍贵一点，200元/年，但支持10个主域，还没有用完呢。
]]></description>
		<wfw:commentRss>http://www.caixiaodong.com/archives/186.html/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>软件工程过程与简单迭代式软件过程</title>
		<link>http://www.caixiaodong.com/archives/182.html</link>
		<comments>http://www.caixiaodong.com/archives/182.html#comments</comments>
		<pubDate>Thu, 18 Mar 2010 08:18:25 +0000</pubDate>
		<dc:creator>蔡晓东</dc:creator>
				<category><![CDATA[软件工程]]></category>

		<guid isPermaLink="false">http://www.caixiaodong.com/?p=182</guid>
		<description><![CDATA[文档格式为PDF。文档内容是PPT。大小约 约700K。
软件工程过程与简单迭代式过程.rar
]]></description>
		<wfw:commentRss>http://www.caixiaodong.com/archives/182.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>PPT</title>
		<link>http://www.caixiaodong.com/archives/179.html</link>
		<comments>http://www.caixiaodong.com/archives/179.html#comments</comments>
		<pubDate>Thu, 18 Mar 2010 06:49:24 +0000</pubDate>
		<dc:creator>蔡晓东</dc:creator>
				<category><![CDATA[软件工程]]></category>

		<guid isPermaLink="false">http://www.caixiaodong.com/?p=179</guid>
		<description><![CDATA[发布一个PPT资源，供需要的朋友们参考使用。原来也是从某网站下载的，可是不记得出处了。
PPT模板下载 约23兆
]]></description>
		<wfw:commentRss>http://www.caixiaodong.com/archives/179.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>老谷的项目管理群09.12.29的主题，电信增值业务项目管理经验交流</title>
		<link>http://www.caixiaodong.com/archives/176.html</link>
		<comments>http://www.caixiaodong.com/archives/176.html#comments</comments>
		<pubDate>Wed, 06 Jan 2010 00:13:55 +0000</pubDate>
		<dc:creator>蔡晓东</dc:creator>
				<category><![CDATA[软件工程]]></category>

		<guid isPermaLink="false">http://www.caixiaodong.com/?p=176</guid>
		<description><![CDATA[主讲：蔡晓东-技术主管
记录人员：一点红
蔡晓东-技术主管-it-福州 说 (12:26):
 给来的早的各位预报一下内容：
 这是一个很长的故事：
 0、缘起
 1、项目组织结构
 2、人员培训及开发的启动
 3、风险管理
 4、需求管理
 5、团队文化
 6、割接前后
蔡晓东-技术主管-it-福州 说 (12:31):
 今天由我和大家分享电信增值业务系统的项目管理经验。
蔡晓东-技术主管-it-福州 说 (12:31):
 0、缘起
 我刚到公司不久，就接到一个电信增值业务系统的需求
 领导问我说，我们公司能做吗？
 如果我的回答是不能，那么这个事情的结果，很可能就是由另外一家公司的产品进驻，上线后移交给我们公司。
 考虑利弊对比，而且根据我的经验和技能，还是比较有把握的。当然，我不愿意跳槽到一家新公司后，接手其他公司的产品，而不是自主开发。
 所以我跟领导所，我们能做。
 ……
 过了一些日子，领导问我，怎么项目没有什么进展？
 我说，人呢？她让我把需要的人数和安排告诉她。
 之后，回了个消息给我：“还需要加10个人？”
 我问“很多吗”？
 从那时候开始，我就意识到这个项目今后将面临的种种困难。一切只是一个开始。
 我们的公司太缺乏这种大项目的经验，完全没有应对这个项目的思想准备，在很多情况下，只能靠自己了。
 好在我的领导还是非常善于接受意见的，后来她详细了解了我在另一家公司参与的类似项目情况、投入人数、时间等，也尽可能补充了一些人员进来，在数量上基本达到了我的要求。
 1、项目组织结构
蔡晓东-技术主管-it-福州 说 (12:39):
 我们公司以前很少有自主开发的大项目，因此，组织结构是按照人员投入最大化的方式，弱矩阵方式。
 一个项目来了，在开发组中找个人负责，然后需求组、自动业务组、维护组都有相应人员配合；考核归各自组长。
蔡晓东-技术主管-it-福州 说 (12:41):
 再加上我们公司的股东背景原因，项目成员不太善于接受项目的意思，有时跑到客户的立场去了。例如，在出现分歧时，维护组的人员就说要对电信公司运维部门负责。
 需求人员也经常站在客户角度提需求，发挥想象力，而不顾项目的实际。
蔡晓东-技术主管-it-福州 说 (12:42):
 最大的问题，在于领导的意识，比较害怕冲突，而在弱矩阵情况下，冲突是在所难免的。
hz_wm-上海 说 (12:42):
 站在客户角度提需求，也是有道理的。
蔡晓东-技术主管-it-福州 说 (12:42):
 我在一段时间内，也向这种组织结构妥协。
蔡晓东-技术主管-it-福州 说 (12:43):
 直到一次电信公司的老总带队到我们公司考察，实际上是来质询项目进度及其他相关问题。
蔡晓东-技术主管-it-福州 说 (12:44):
 这带着两个影响：其一，我决定改造组织结构，消除矩阵，建成项目型组织；其二，领导认识到只有给我充分授权，才能对我问责。
蔡晓东-技术主管-it-福州 [...]]]></description>
		<wfw:commentRss>http://www.caixiaodong.com/archives/176.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>功能点分析法的思考</title>
		<link>http://www.caixiaodong.com/archives/167.html</link>
		<comments>http://www.caixiaodong.com/archives/167.html#comments</comments>
		<pubDate>Tue, 24 Nov 2009 12:24:44 +0000</pubDate>
		<dc:creator>蔡晓东</dc:creator>
				<category><![CDATA[软件工程]]></category>
		<category><![CDATA[估算]]></category>
		<category><![CDATA[功能点]]></category>
		<category><![CDATA[功能点分析法]]></category>
		<category><![CDATA[项目计划]]></category>

		<guid isPermaLink="false">http://www.caixiaodong.com/?p=167</guid>
		<description><![CDATA[在编制项目计划时，必须先对软件规模有个整体估计，然后再分配到各阶段、各类活动、各个明细任务中中，如果每个明细任务都可以在预期时间内完成，那么计划也就能如期完成，并且人力资源成本也被严格控制了。因此，在编制计划时，对项目整体上的规模估计非常重要。
根据互联网上的资料以及我的观察，国内主流的估算方法分为三类：主观估计法、代码行法及功能点分析法。Delphi法是主观估计的一种，只是因为有多个人员的参与并进行多轮估计，会使主观估计的结果趋于客观。scrum敏捷方法中，也存在类似的多人主观估计，通过“敏捷扑克”多人同时出牌，是一个很好的实践。
代码行法主要有以下几个问题：其一，不同编程语言的开发效率不等，一些工具自动生成了一些代码行，这样，实现相同的功能，所需代码行及时间可能大相径庭。其二，我国软件业的职业教育水平参差不齐，为了实现相同功能，不同编码人员采取的算法逻辑各不相同，最终输出的代码行数差距很大。其三，对于在现有代码基础上增加新功能的情况，可能新增代码只占少部分，更多的是修改原有代码，而被修改的代码行与工作量是否存在线性关系着实可疑。
假设为了实现一个功能模块X，程序员A写了1000行代码，花了2个星期；类似的功能模块Y，程序员B写了2000行代码，他需要花费4个星期吗？如果他们的工作经验近似，那么程序员B应该同样花费2个星期的时间。程序员B在实现每个功能点时，很少考虑复用，而是不断复制粘贴自己的代码，再进行修改，很快就完成了2000行代码，实现了模块功能。程序员A，则基本不复制粘贴代码，而是修改原有函数，通过函数复用来实现。（PS：一个真实的案例，某位同学在1个月时间内完成了6万行代码，并受到表彰。）
功能点分析法在理论模型上更适合软件开发的实际情况。在上面的例子中，通过估算模块X与模块Y所包含的功能点数，判断模块规模，再分发工作任务。不论最终输出的代码是1000行还是2000行，只要功能点数相同，则工作量相同，应在相同的工期内完成。
功能点分为数据功能与交易功能两大类。数据功能包括内部逻辑文件（ILF）与外部接口文件（EIF）两类；交易功能包括外部输入（EI）、外部输出（EO）、外部查询（EQ）三类。功能点分析法通过计数ILF、EIF、EI、EO、EQ的数量及复杂性，折算为对应功能点数，再根据每功能点的生产率数据，估算所需要的工作量。功能点分析法利用软件工作量与需求功能的线性关系估算工作量，这种关系不受开发人员编程风格（喜欢拷贝还是函数复用）、是否为系统升级改进等因素影响，较代码行法更为稳定可信。
谋求寻找工作量与需求功能之间的关系，这个想法并不非常新颖，“拍脑袋法”一般也不是毫无根据，更多的是根据需求功能的复杂与否、数量多寡来估计。功能点分析法的精髓在于对功能点的抽象，以较小的估算时间投入，达到在初期估算规模的目的。大中型系统的需求经常有变更，甚至在概要设计后，都有一定需求变更。在初期，需求更难以准确捕捉。因此，功能点分析法关注于容易在早期观察的两个层面：数据与应用边界。
内部逻辑文件（ILF）是一组用户可以识别的、存在内部关联的数据或控制信息。外部接口文件（EIF）是一组用户可以识别的、在本应用被引用的数据或控制信息。因为“用户可以识别”这一特性，决定了ILF、EIF在早期就可以发现。根据ILF与EIF相关的数据元素类型（DET）和记录元素类型（RET），确定ILF、EIF的复杂性，并估算其功能点数。
外部输入（EI）、外部输出（EO）、外部查询（EQ）关注的则是应用边界，即以从应用边界外向系统发送数据为目的的，是EI，反之则是EO或EQ。系统向应用边界外发送数据或者从应用边界外向系统发送数据，都是交易功能。在系统开发需求阶段，交易功能一般发现的不完整。但当需求规格说明书初步完成时，一般所有交易功能都能被发现。尽管在开发过程中，需求的描述将更将清晰，可能还会新增部分功能，但新增功能的同时可能会删除一部分功能。交易功能的功能点数总体规模还相对稳定。（假设还未开发）
在完成了数据功能、交易功能的功能点估算后，再应用调整因子进行调整，功能点估算法似乎已经非常完美了。但实际上，实际应用功能点估算法的案例并不占很大比例。功能点分析法在现阶段推广使用，也还有一些局限：
一、将需求功能点分解为数据功能与交易功能2个层面，分别统计功能点再累加，这种方法对于规模与风险适中的项目比较适合，对于极端情况则不太适用。例如，对于一个100人日以下的项目，开发代码时可以不遵循数据功能与交易功能分别实现的做法，直接在界面层面实现数据操作，一次实现了2个层面的功能点。这样，尽管“质量”不高，但实际上这样的项目，经常并不要求非常高的质量。因此，我们可以发现，小项目使用功能点分析法计算出来的工作量往往偏大。对于内部逻辑非常复杂的情况，用数据功能与交易功能2个层面来抽象，可能也不能涵盖其内部蕴含的复杂性（目前手头还缺乏数据实证）。
二、人日数与功能点之间的生产率缺乏历史数据。生产率受很多因素影响：行业特点、员工技能、质量要求等。即便在同一家公司，完成一个功能点的人日数也很难达到稳定。一般的，小项目的质量要求较低，完成一个功能点就比较快；互联网应用界面质量要求高，完成一个功能点较慢；大项目除了质量要求因素以外，为了消解技术风险，以全生命周期衡量的生产率也会较低。
要在一个实体中真正应用功能点分析法，还存在很多困难。
]]></description>
		<wfw:commentRss>http://www.caixiaodong.com/archives/167.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>主流软件工程与项目管理观点</title>
		<link>http://www.caixiaodong.com/archives/163.html</link>
		<comments>http://www.caixiaodong.com/archives/163.html#comments</comments>
		<pubDate>Sun, 22 Nov 2009 07:09:10 +0000</pubDate>
		<dc:creator>蔡晓东</dc:creator>
				<category><![CDATA[软件工程]]></category>
		<category><![CDATA[PMBOK]]></category>
		<category><![CDATA[SWEBOK]]></category>
		<category><![CDATA[管理过程]]></category>
		<category><![CDATA[软件过程]]></category>

		<guid isPermaLink="false">http://www.caixiaodong.com/?p=163</guid>
		<description><![CDATA[经过多年的发展，软件业已成为一个日趋成熟的工程学科。IEEE计算机学会主持建立了《软件工程知识体系指南》（SWEBOK），系统阐述了软件工程职业的核心知识体系。其中“软件工程”指的是应用系统化、学科化、定量的方法，来开发、运行和维护软件；即将“工程”应用到软件；以及对上述各种方法的研究。
SWEBOK识别出10个知识领域，即：软件需求、软件设计、软件构造、软件测试、软件维护、软件配置管理、软件工程管理、软件工程过程、软件工程工具和方法、软件质量。对其中每个知识领域，进一步分解为知识子域。例如软件需求知识域，分解为软件需求基础、需求过程、需求获取、需求分析、需求规格说明、需求确认、需求度量。
SWEBOK的大多数知识领域，对应于法约尔所描述的“技术职能”。粗放的软件开发技术，被分解为软件需求、软件构造（编码实现）、软件测试等多种技术，并进行工作分工，由不同的软件工程师分别承担。我们知道，适当的专业分工有利于提高效率及质量。另一方面，专业化分工有利于软件工程师个人技能的提升。例如，对于负责需求的软件工程师，可以专注于学习需求获取、需求分析、需求规格说明、需求确认等需求子域的知识，并通过工作不断累积经验，成长为需求专家。
软件工程管理定义为应用管理活动——计划、协调、度量、监控、控制和报表——以保证软件的开发和维护是系统的、有纪律的和量化的。软件工程管理的知识子域为：启动和范围定义、软件项目计划、软件项目实施、评审和评价、关闭及软件工程度量。前5个知识域与项目管理知识体系联系紧密，可以视为项目管理知识在软件工程项目中的应用。软件工程度量知识子域则是管理过程的基础之一，有度量信息的管理可以改善软件工业效率和质量的不可预测性。也正是因为软件度量，才使软件业成为一个工程学科。
项目管理知识体系指南（PMBOK）中详细描述了项目管理知识。PMBOK并为软件项目设计，所描述的各个知识领域适用于所有项目。正由于这个原因，对于大多数软件项目经理来说，这些知识并不怎么适用。但由于PMI及培训机构的力推，拥有PMP认证对于中国项目经理来说相当有意义，因此重视PMBOK而忽视SWEBOK就很自然了。
根据PMBOK的定义，过程是为完成预定的产品、成果或服务而执行的一系列行动和活动。每个过程都有各自的输入、工具和技术，以及相应输出。项目过程由项目团队实施，一般可以分为两大类：项目管理过程和产品导向过程。其中项目管理过程具有一般性，由PMBOK描述；而产品导向过程则因应用领域而不同，例如，对于软件产品，应当参照SWEBOK。
项目管理过程分为5类过程组，即：启动过程组、规划过程组、执行过程组、监控过程组、收尾过程组。每个过程组包含若干管理过程。各个过程组不是孤立的，而是重叠及相互作用的。对应于5个过程组，项目管理的相关知识领域有：项目整合管理、项目范围管理、项目时间管理、项目成本管理、项目质量管理、项目人力资源管理、项目沟通管理、项目风险管理、项目采购管理9个知识领域。
作为事实上的标准，PMBOK涵盖了几乎所有项目管理相关的知识领域和技能，提供了项目经理从事项目管理工作的终极指南。然而，对于大多数软件项目经理来说，PMBOK提供的知识过多过泛，很难作为实际工作的参考。举例来说，每个项目经理都知道沟通很重要。PMBOK更是把沟通管理作为一个独立知识领域来强调，并分解为：识别干系人、规划沟通、发布信息、管理干系人期望、报告绩效5个知识子域。在实际项目中，特别是小项目，沟通管理应当是简单的，而且受到企业环境及外部环境的强烈约束。对于整个项目管理来说，我们也不太可能严格遵循“过程”。过于关注管理过程，反而对导致管理成本过高而损失效率。

SWEBOK与PMBOK分别描述了主流软件工程知识与项目管理知识。这些知识不能简单应用在我们的软件工程上，但已经构成了深远的影响。软件工程师接受各自关注领域的软件工程知识，项目经理获得了PMP、IPMP认证，形成了我们工作环境中的主流软件工程及项目管理观点。在面对工作中一些分歧的时候，一些人员将引用权威的说法，以证明自己的观点；但当真正进行实际工作时，又将权威观点束之高阁。这一点并没有导致非议，因为我们的高层管理者并不真正相信软件工程和项目管理。
他们相信的还是“中学为体，西学为用”。

注释：本系列文章使用“软件工程师”概念与SWEBOK保持一致；即软件工程师不但包括典型的软件设计和编码人员，也涵盖其他从事软件工程的专业人员。
]]></description>
		<wfw:commentRss>http://www.caixiaodong.com/archives/163.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

