导航↓ 相册|收藏博客|加入友情链接|给博主留言
我要啦免费统计阅读使人充实,会谈使人敏捷,写作与笔记使人精确。史鉴使人明智;诗歌使人巧慧;数学使人精细;博物使人深沉;伦理之学使人庄重;逻辑与修辞使人善辩。-培根
黑猫大队长
2018-1-15 21:46

™™™
2017-10-18 10:12
™™™
2017-10-18 10:11
™™™
2017-10-18 9:52
Z浪迹天涯
2017-10-16 1:3
sunnyrl
2017-9-13 12:2
pangdan2007
2017-7-10 19:54
  • 创建:2007/2/23
  • 文章:973
  • 评论:5127
  • 访问:966491
  •  

2007-7-17 13:15 | PMP考前习题总结(2)

项目选择(市场/运营/客户/技术/法律)
项目管理团队识别干系人,项目经理负责干系人管理
项目生命周期定义在每个阶段将做的技术工作
高层管理在完成一个生命周期阶段后定期审查
矩阵组织冲突的根源是权限不明确
组织规划考虑(组织界面/技术界面/人际关系界面)

整体变更活动不包含推荐预防措施,质量审计也不审这个
项目计划需要得到客户的正式认可和接受
有效变更控制系统不包括报告的标准或格式
变更第一步是要提交变更请求,执行前必须得到批准和签字
分析影响,评估和寻找可选方案是很重要的
整体管理在项目管理每阶段结束时进行
归档工作已经完成是项目收尾完成的依据,但从卖方角度则是付款已经支付
项目收尾最组织过程资产更新不包含班子成员的重新安排
项目收尾的归档中不用包含每个成员的绩效评估

项目范围应该定期进行检查和审查
工作分解结构词汇表和工作授权系统可以控制镀金
项目范围通过计划评定,产品范围通过产品要求评定
项目范围说明书不用包括干系人分析

又是外部依赖又是强制依赖时候选择外部依赖
GERT图形评审技术是活动排序的方法
关键路径估算先控制成本,再保证进度灵活
项目进度报告是沟通的要素
项目进度表在早期的作用是确定项目成本
类别估算是专家估算,类别估算是自上而下估算,精度比参数估算差

计划编制后得到定局估算(-5%到10%)
收益成本比中的收益是payback或benefit而不是profit
利润和资本是影响资本回报的要素
类别估算提供对管理层预期的理解?
发起人为项目提供合同定义?
支付给承包商的修理费是免责付款

SPC中了解特殊原因和随机原因差异很重要(如控制图七点原则)
质量属性是具体特征,产品据此进行设计和试验
质量保证是管活动和过程,质量控制是管可交付成果
边际分析(收入增量=改进的成本……
编辑 | 阅读全文(1560) | 回复(0),人月&神话 发表于 2007-7-17 13:15

2007-7-17 13:15 | 软件开发项目要素

1.天赋和技能

才能是天赋和后天技能的结合.软件开发需要开发者不断的学习和积累,提高自身知识技能。更需要有一种先天的职业洞察力和对软件开发职业的敏锐度。软件开发中自我学习能力很重要,但学习能力强弱则体现到个体的悟性。这种天赋和悟性有助你充分的发挥你的潜力和开发技能。疯子不都是天才,但他们都很执著和狂热,开发者需要时刻保持着这份狂热。

2.沟通和协作

软件开发是一种高层次的脑力劳动,需要实现现实事物到抽象事物的转换。软件开发的过程就是开发者不断认识现实,不断寻找解决方案,不断创建解决方案的过程。沟通已经不再局限在完成当前工作的交流和协作,更多的是开发者间思维和思想的交流。对于新组建的团队或新老员工间沟通会异常艰苦或复杂,而对于配合多年的开发者间的沟通往往仅仅是一个眼神和手势。开发团队只有真正建立了自己的团队语言,才能够真正感受到沟通的愉悦。
建立大量文档的方式不适应已经建立团队语言的配合默契的团队,文档也很难体现出开发者对某个开发工作的深层次理解和经验的分享。沟通是双向的经验,心得和开发者间情感的交流,而不是像文档一样单项的信息传递。

3.团队和发展

团队建设和发展对提高整体项目绩效是至关重要的。在团队中开发者相互学习和共同成长。信任和友善对团队共同发展的重要因素,当你要和他人共同来完成一个目标的时候,你必须高度信任你的搭档而并肩战斗。在这个过程中你虚心接受他人的经验和意见,同时又无私的分享自己的知识和经验。

4.学习和创新

当你觉得你的工作完全是一种毫无疑义的体力劳动的时候,你应该考虑你的工作是否应该由系统来自动完成了。天才在面对着一些毫无意义的重复劳动时候都是懒人。他知道他们的时间宝贵,应该用来去探索未知的世界和寻求突破。软件开发的每个过程和阶段都体现着创新,体现着模式的匹配,解决方案选择和全新的解决方案,创新的过程就是我们知识积累得到……
编辑 | 阅读全文(1186) | 回复(0),人月&神话 发表于 2007-7-17 13:15
波士顿矩阵

波士顿矩阵是由美国大型商业咨询公司——波士顿咨询集团(Boston Consulting Group)首创的一种规划企业产品组合的方法。问题的关键在于要解决如何使企业的产品品种及其结构适合市场需求的变化,只有这样企业的生产才有意义。同时,如何将企业有限的资源有效地分配到合理的产品结构中去,以保证企业收益,是企业在激烈竞争中能否取胜的关键。
波士顿矩阵认为一般决定产品结构的基本因素有二个:即市场引力与企业实力。对于市场引力,销售增长率是决定企业产品结构是否合理的外在因素。对于企业实力,市场占有率是决定企业产品结构的内在要素.销售增长率与市场占有率既相互影响,又互为条件:市场引力大,销售增长率高,可以显示产品发展的良好前景,企业也具备相应的适应能力,实力较强;如果仅有市场引力大,而没有相应的高销售增长率,则说明企业尚无足够实力,则该种产品也无法顺利发展。相反,企业实力强,而市场引力小的产品也预示了该产品的市场前景不佳。
通过以上两个因素相互作用,会出现四种不同性质的产品类型,形成不同的产品发展前景:


明星产品(stars):它是指处于高增长率、高市场占有率象限内的产品群,这类产品可能成为企业的现金牛产品,需要加大投资以支持其迅速发展。

现金牛产品(cash cow):它是指处于低增长率、高市场占有率象限内的产品群,已进入成熟期。其财务特点是销售量大,产品利润率高、负债比率低,可以为企业提供资金,而且由于增长率低,也无需增大投资。

问号产品(question marks):它是处于高增长率、低市场占有率象限内的产品群。前者说明市场机会大,前景好,而后者则说明……
编辑 | 阅读全文(8113) | 回复(0),人月&神话 发表于 2007-7-17 13:15
转载自:http://www.a.com.cn/News/Infos/200607/11384416475.shtml

管理的主要目的应该是使雇主实现最大限度的富裕,同时也使每个雇员实现最大限度的富裕,管理要满足双方的利益要求,而不能仅仅是雇主获利的工具。工业心理学的研究是科学管理的必然趋势,管理中人的心理因素日益受到重视。近年来,由于竞争全球化,企业结构重组、人员精减、不断变革等全球大环境的影响,心理契约的内涵在不断发展变化,管理领域对心理契约的研究又出现一个新的高潮。

心理契约的意思是说,在任一组织中,每一成员与该组织的各种管理者之间及其他人之间,总是有一套非成文的期望在起作用。这些期望可以是对经济内容的要求,但心理契约的本质是对无形的心理内容的期望。

心理契约是组织和个人双方彼此对对方应付出什么同时又应得到什么的一种主观心理约定,约定的核心成分是双方隐含的非正式的相互责任。员工是抱着一定的动机加入组织的,希望借助于组织来满足自己物质的和精神的多层次需要;组织对人力资源的招聘、培训也是有特定目的的,力图最好地利用组织的人力资源来实现组织的目标。个人和组织间的社会交换关系无法把双方相互责任的界定完全体现在书面的雇佣合同中,但在每一个员工的内心深处,对自己该为组织付出什么、付出多少,组织应该给自己回报什么、回报多少等都有明确的认识。

为更好地解释、分析个人与组织之间的交互关系,心理契约这一术语在60年代初由组织心理学家阿吉里斯首先引入到管理领域,强调在员工与组织的相互关系中,除正式雇佣契约规定的内容外,还存在着隐含的、非正式的、未公开说明的相互期望,它们同样是决定员工态度和行为的重要因素。

心理契约是隐含的,内容因人而异,但它却是影响组织行为的重要因素,可以减少雇佣双方的不安全感,规范员工的行为,形成对组织的归属感和忠诚感。……
编辑 | 阅读全文(1050) | 回复(0),人月&神话 发表于 2007-7-17 13:15

2007-7-17 13:15 | 再看关键链进度计划

注:本文内容来自对高德拉特《关键链》一书的学习和总结

任务工期假设

如果前后依赖的AB两个任务,A任务的工期为10天,B任务的工期为5天。当A任务实际只需要6天完成时候,B任务仍然会在11天才开始进行。这个一方面原因是提前完工的小组或个人并不会报告实情,另一方面由于预知了A任务在10天完成,小组或个人或将任务分配到10天内分阶段完成,多余的时间会处理每天遇到的其它任务

结论
1.一个步骤的延误会全部转嫁给下一步骤,而提前完工赚得时间往往被消耗。
2.顺序步骤中的每个步骤的延迟会累积,而提前完工赚得的时间并不能累积。 

路径汇聚风险

在项目进度安排的网络图中,在路径聚合点往往具备了最大的风险。如果说现在有A,B,C三个同时进行的项目任务,要三个任务都完成了才能进行D任务,则ABC三个任务任一个延迟都将导致D任务的延迟。如果A,B,C三个任务的按时完工概率都为50%,那这个时候的D任务的按时完工概率只有50%*50%*50%=13%左右。

结论
1.在进度网络图中的路径汇聚点具有最大的进度风险
2.如果安全时间不放在并行序列的最末端,它对减小汇聚风险没有丝毫作用

风险概率

我们以一个简单的三点估算老考查任务完成的概率问题。对于一项任务最可能完成时间是12天,最乐观估计时间是6天,最悲观估计时间是24天。这个时候的均值为13,标准差为3,由于悲观估计时间大,该概率分布已经不是一个典型的正态分布,而是一个有了长右尾的分布如下图。在这个图中可以看到为了增加项目完工概率的30%,需要付出成倍的安全时间投入。在项目中提前完工往往并不会受到额外的奖赏,但延迟交付却会受到层层指责,因此项目估算采用的是最右边的安全值而不是富有调整的中间值。
……
编辑 | 阅读全文(1026) | 回复(1),人月&神话 发表于 2007-7-17 13:15
转载自:http://www.kaifulee.com/modules/tinyd0/index.php?id=205

工作的人,按资历的深浅,大致可以分为三种阶段:进入社会不久的新鲜人、中层干部与高层主管。
在这三个阶段工作的人,可以比拟为三种动物。

刚进入社会不久的新鲜人,像是一只鸟———刚刚孵化,开始学习飞翔的小鸟。小鸟面对广阔的天地,好处是机会无穷,无限的空间任其展翅。但是小鸟也要明确自己到底要如何成长。

小鸟的优势,就是还没有被环境、习惯、条件所局限或制约,因此各种新奇的尝试与可能,都在双翼之下。你可以选择成为家鸟,驻足别人屋檐下;你也可以选择成为林鸟,生活在茂密的森林里;你还可以选择成为候鸟,随季节的变化而周游各地。

但是,也要小心。太多新奇的选择,会让你眼花缭乱。或者,你选择成为一种与你的体力与本质都不适合的鸟。或者,你不停地变换自己生存的方式,最后忘了自己是一只什么样的鸟。或者,你选择方便的离人群很近的觅食方式,结果成为别人弹弓下的猎物。

工作了一段时间,成为公司或组织里的中坚干部之后,你成了一只骆驼。

这段时间,你大致已经在工作岗位上累积了足够的经验与能力,因此你的公司、你的上司愿意信任你,或者使用你,一再把沉重的工作负担交付下来,让你承担。生活中,你大致已经成了家,或者已经为人父、为人母,有你的家庭责任要尽。这时候的骆驼,已经不像小鸟那样可以任意飞翔,甚至,即使有变动的机会出现,你也已经不敢轻易尝试。

骆驼只能在茫茫的沙漠中行走。上司,像是沙漠中头顶的烈日;属下,像是脚下滚烫的沙子。两相煎熬,你只能忍辱负重地行走,默默地行走。

骆驼的优势,在于平稳,看起来几乎没有任何风险。你职位上的工作,大多已经驾轻就熟。不但熟,还是全公司里最熟的——新进的属下,没有你了解;比你资深的上司,可……
编辑 | 阅读全文(805) | 回复(0),人月&神话 发表于 2007-7-17 13:15
每天我们都在遇到层出不穷的问题,也在解决着各种各样的问题。有简单的问题,也有复杂的问题;有简单的解决方法,也有复杂的解决方法。简单的问题可以复杂化,复杂的问题也可以简单化,那应该如何看待问题本身和问题的应对:

1.简单的问题复杂化

小故事往往蕴含大道路,有些问题往往是表象简单而内涵复杂。对于这类问题必须要能够透过问题现象看本质,不是头痛医头,脚痛医脚而是应该挖掘导致问题的本质因素,标本兼治。有些问题是问题本身简单,但如果没有处理好往往导致深远的影响,对这类问题更应该谨慎对待,注重细节。

问题本身简单并不意味着问题导致的影响简单,问题本身的简单也不意味着导致问题的根源简单。

2.简单的的问题简单化

越有经验的人越容易犯一些常人难犯的低级错误。一招被蛇咬,十年怕井绳,当你在某些问题上吃过大亏或者花费了很大的经历解决了某类问题后,常常形成了这类问题都很复杂的思维定势,而这思维定势老使我们从复杂的角度来思考问题,在问题的某一个点上钻的很深,但对问题的面却认识的不够。这种思维模式是最容易导致我们简单的问题复杂化的。

多从常人的思考角度来思考,多考虑问题的面而不是点,多考虑解决问题的可行性而不是解决方法的最优,简单的方法往往是最有效的。

3.复杂的问题简单化

问题都是由无数的子问题和问题分支构成的。问题的复杂并不意味着问题分支的复杂。对于复杂的问题应该逐步分解,各个击破。每个子问题的解决方法往往都有章可循或非常简单,关键的是我们能够搞清楚问题的定义,对问题进行有效的分解,简单的方法汇聚起来就能够解决复杂的问题。

4.复杂的问题复杂化

当问题涉及到的子问题和问题分支相互影响和关联的时候,整个问题的解决过程就是一个系统工程了。我们必须从系统的角度来综合考虑和分析各个子问题和因素的相关影响和作用,考虑他们之间……
编辑 | 阅读全文(1118) | 回复(0),人月&神话 发表于 2007-7-17 13:15
软件开发的管理和流程是我曾经花很多时间思考、学习的课题。Steve所批判的Extreme Programming我也曾经研究过,并(曾经)对里面的很多思想比较认可,只是因为配对编程的代价实在太高,所以从来没有真正应用过。市场上那么多的软件工程、软件开发管理的书籍,但似乎都没有能够解决大多数软件项目开发会失败的现实。如果有什么方法真正有效,那么以微软的实力和见识,怎么也不会让Windows Vista一拖再拖到现在无法发布吧。

Steve的另一篇blog “(Not) Managing Software Developers”让我从另一个角度去思考软件开发的管理。 Steve用非常风趣的语言大大挖苦了一番想成为项目经理的人。根据他的第22条军规,最想成为项目经理的人往往是最不适合的人。他也大大批判了多数公司倚重项目经理给以项目经理比程序员更好待遇的体系——我相信几乎所有国内的软件企业都是属于他所批判的类型——这种体系下,一个好的程序员要么离开;要么忍气吞声;要么变成一个项目经理。在最后一种情况下,公司失去了一个好的程序员而获得了一个糟糕的项目经理。

Steve认为,给项目经理以巨大控制权并指挥程序员的做法是从传统的非高科技企业学来的,而这事实上意味着软件企业变得非高科技,沦为一个传统企业——只等着有一天一个真正的创新者把它取代。

Google的伟大不仅在于技术上的创新,更在于它在企业文化和管理方法的创新。Steve打了一个很好的比方,传统的管理是“推动”式管理,而Google则是一种“润滑油”式管理。可以说的话题很多,而且每个话题都可以深入展开,我尝试着简单做一个总结吧:

不要指望通过项目管理解决程序员能力不足的问题

这是我自己加入的观点。这也是针对国内的现状而提出的,即很多程序员没有达到基本程序员的水平。如果一个项目的预……
编辑 | 阅读全文(1004) | 回复(0),人月&神话 发表于 2007-7-17 13:15
问题界定清楚问题就解决了一半,在面对现实世界得出错误的问题定义的时候,问题的解决方法正确性已经不重要,即使是正确的解决方法也无法帮助你解决问题.

在问题定义清楚后我们会去寻找问题的解决方法.我们原来可能遇到过类似的问题,这个时候的解决方法和步骤可能直接出自你原来的经验积累.你用你原来的经验进行模式匹配解决了问题,但是场景和时间都在变化,你用老方法解决了新问题,可能仅仅解决了问题的表象,也可能你的解决方法本身就不是很好的方法.

在问题定义清楚后,你现有的模式和知识积累无法解决问题.按照传统的方法,我们需要对问题进行仔细分析后提出解决问题的方案和构想,然后一步步的去论证其可行性,当发觉走不通或不可行的时候回及时回头,当某个分支需要我们去学习新的工具和技术的时候,我们会不断的去学习,进行归纳和总结.在最后,我们的积累已经不是简单的解决问题的成果,而是在解决问题过程中对工具技术的学习,对解决过程的总结,在解决过程中走了弯路形成的经验教训的反思.这些过程的积累将有助于我们解决层出不穷的新问题.

问题本身的价值不在于结果而在于解决问题的过程积累.新问题可以用老模式去匹配,老问题可以用新方法去解决.

随着搜索引擎的出现,极大的提高我们解决问题的速度和效率,其带来的好处是显而易见的.但过度依赖搜索引擎的害处却需要我们每个人警惕和重视.虽然现在有高度人工智能的搜索引擎还没有出现,但我们现在已经有过度依赖搜索的现象,如果人工智能的搜索引擎出来后,我们常人是否还需要积极思考,又如何去体会思维过程的乐趣?

1.关键字很难准确描述清楚问题的定义
要将一个问题描述清楚可能设计到问题的发生环境,发生操作动作,时间和相关人员等很多要素,但在搜索中我们选择的关键字往往很难涵盖到问题的所有内容,这样我们搜索出来的答案虽然是正确的,但却往往无法解决问题真正的问……
编辑 | 阅读全文(933) | 回复(0),人月&神话 发表于 2007-7-17 13:15
软件度量是软件过程改进的一个重要方面,度量的目的是过程改进,但最终目的仍然是软件企业的成本收益上.如果最终的度量和改进没有体现到企业的赢利上,那就不能将度量和改进发挥了作用.
将度量用于绩效考核是不推荐的做法,但当度量不和绩效考核挂钩的时候更需要从人性化的角度去推动度量和改进.和绩效考核挂钩造成的后果就是为了指标而指标,为了度量而度量,具体指标和度量数据能够发挥哪些作用,如何指导改进和企业赢利并不会有太多人关心.软件工程和CMMI推荐了一套集成化的度量分析模型,我们讲给模型仍然不能充分体现客户驱动和价值驱动的概念.如果真正体现绩效,似乎从平衡计分卡角度来规划软件度量的指标更有实际的指导意义(待后续思考).
对于度量,首先要解决为什么需要度量的问题,做任何事情都是需求驱动的,没有源动力驱动做一件事情就体现不出价值.而驱动度量的源动力归根到底仍然是以最小的成本生产高质量的软件,为企业创造价值.这个驱动力是一个长期的驱动力而不时局限在现在,对于软件过程改进更是体现在对企业中期和长期价值的贡献.
不可否则人的经验或专家的判断比一些数据更有用.但这些经验必须要能够固化下来形成过程或方法论,才能形成企业的过程资产,长久的为企业服务.如何来证明某种方法或经验是否有效?我们可以设定指标,开始收集和分析数据,根据数据做出决策和判断.所以大家都清楚可以通过度量来知道某种方法是否有效,但如何保证你设置的度量指标本身,你收集的数据是否真正有效才是度量的关键问题.
要使度量真正有效必须要解决两方面的问题,一个是度量指标的设计是否合理?一个是如何保证你收集的数据是真实可靠?这两者缺一不可,如果这两点都做好了,你的度量过程就做好了.度量过程做好了才谈得上我们利用这些数据去做分析和决策,以持续改进工作软件开发过程.《实用软件度量》一书在如何进行有效度量中还谈到必须将度量过程做为软件工程的支持过……
编辑 | 阅读全文(1241) | 回复(1),人月&神话 发表于 2007-7-17 13:15

2007-7-17 13:15 | 感受工作的乐趣

自己做IT行业多年,平时也经常有人问我做哪一行,回答IT的话范围又太广了,回答项目管理别人也不清楚是指什么。所以我一般回答编程序和写软件的时候居多。

每当我回答写程序的时候,有羡慕的人认为这是高智商的劳动,也有不屑一顾的认为编代码是低级劳动的。所以问题又回答了工作本身上,工作是没有高低贵贱之分的,关键是你是否喜欢你的工作?是否能够从工作中感受到乐趣和快乐?你做的工作是为自己的,不是显示来给别人看的,只有你的工作为别人,为国家创造了价值,为了自己寻找到了乐趣,那对你来讲就是最好的工作。别人是否理解你的工作早已不重要,道不同不相为谋,很多时候无需解释。

如果你自己都不欣赏你开发出来的软件,如果你不是一个月不写程序就觉得手痒的话,那你还算不上真正的程序员,也体会不到程序开发的真正乐趣所在。软件开发项目虽然根据生命周期模型对角色进行了细分,但每一个岗位和角色都是重要的,都需要成员去独立的思考和解决问题,当你开发出来的软件产品能够真正去解决别人的问题,提高企业效率的时候,程序员的价值也得到了体现。

干一行爱一行,作软件开发需要的就是一种执着和不断学习的心态,当你能够去感受工作给你带来的乐趣时候,工作本身就变得轻松了。你才能更多的去发挥自己的潜力和才能,体现自己的价值,如果你是编码牛人,你一样可能拿很高的薪水而不是一定要去做什么管理类的工作。
编辑 | 阅读全文(1024) | 回复(0),人月&神话 发表于 2007-7-17 13:15
原文:http://www.doyouhike.net/forum/233418,0,0,1.html

深圳之最——中山公园

每年百公里的出发点——中山公园有三个深圳之最:

深圳历史最为悠久的公园:始建于一九二五年,由中华民国宝安县县长、香港绅士胡钰先生为纪念孙中山而建。当时面积仅有1.3万平方米。如今面积49万平方米。

深圳最早的重点文物保护单位:一九八三年十月,深圳建市的第四个年头,中山公园就被列为第一批重点文物保护单位,园内有距今613年的古城墙——明洪武二十七年(一三九四年)修建的南头城北城墙遗址;

全国最大的孙中山头像:中山公园的孙中山大型石雕头像用重达88吨的花岗岩雕刻而成,是目前全国最大的孙中山头像。雕像背面刻有中山先生的手迹:“吾志所向,一往无前,愈挫愈奋,再接再励,因能鼓动风潮造成时势。民国七年十二月三十日孙文”。

深圳之源—南头古城

54年前——1953年,宝安县委机关迁至深圳镇。自此以后,1000多年里一直是深圳地区政治和经济中心的南头日渐衰落。

1676年前——公元331年,东晋在深圳南头设置了东官郡,管辖范围包括今天的深圳市、东莞市、中山市、珠海市及香港地区。所辖6县之首的宝安县意为“得宝而安”。这是深圳地区历史上最早建立的国家行政机构。

南头红花园出土的东汉人面砖像,这应该是深圳先祖最早艺术形象,一双圆睁了1700年的双眼,见证……
编辑 | 阅读全文(1529) | 回复(0),人月&神话 发表于 2007-7-17 13:15

2007-7-17 13:14 | PMP考试通过了

成绩还算不错,但比预想的稍微差一点。还需努力!

Dear ***,
    
Congratulations on obtaining the PMP credential.

Our goal is that you receive your Certificate package within 8 weeks of your exam. To assist us in this effort please visit our website at https://www.pmi.org/certapp/ and validate that your preferred mailing address is correct and complete within 24 hours after receipt of this email.

As a confirmation that you passed your exam, you may download and print your SCORe report from the above link.  You also will be able to view the important policies and procedures necessary to maintain your credential contained within the CCR Handbook.

Sincerely,

PMI Certification Program Department
编辑 | 阅读全文(1024) | 回复(0),人月&神话 发表于 2007-7-17 13:14
如果一个 200人的项目中,有 25 个最能干和最有开发经验的项目经理,那么开除剩下的 175 名程序员,让项目经理来编程开发。-《人月神话》P17

25人的优秀开发团队整体业绩肯定优于200人团队,但25人开发进度往往是无法满足实际的进度要求的,所以往往是投入成倍的人力资源来争取20-30%的进度收益,软件技术层出不穷,超过1年的开发计划估计都不会有太多人感兴趣.

软件开发团队的主次定位和角色分析依然重要,Mills建议的外科手术队伍目的仍然是提高软件开发的效率和生产率,或者说在效率和进度之间更好的权衡.这种手术队伍高度强调了外科医生和副手在开发团队中的重要作用,整个软件系统的高层设计和构想,系统分解都应该由副手辅助外科医生确定,以保证整个软件系统高度的概念一致性.手术队伍中的编辑,测试,秘书,语言专家等都是辅助角色,目的是为了使外科医生和副手真正的专注,只有专注和不受干扰效率才能得到改善.所有的辅助角色不是没有技能要求,他们仍然需要和整个队伍默契配合,外科医生手一伸你就知道需要递剪刀而不是药棉.辅助角色的专业化分工是高效的关键,它使成员之间采用非常简单的交流模式成为可能.

软件团队中的高层设计必须要集中到1-2人手里,以维护概念一致性.高度集中的外科医生方案不一定是最佳方案,但一般却是可行的方案.每个人都选择的最好五官拼在一起绝对形成不了一张漂亮的脸.所以即使外科医生有错了,也需要是同一种类型的错误,而不是五花八门的错误难以弥补.

对于一个新软件产品的开发,系统分析和设计是关键的内容,它反映了一系列连贯的设计思路,宁可省略一些不规则的特性和改进,也不提倡独立和无法整合的系统,哪怕它们其实包含着许多很好的设计。因此在系统设计中概念完整性是必须重点考虑的因素,为了保持一致性需要系统设计高度统一,并集……
编辑 | 阅读全文(981) | 回复(0),人月&神话 发表于 2007-7-17 13:14
对于软件产品,软件规模的增加会导致其复杂度呈现指数倍的增加,也会导致工作量的指数倍增加。对于单纯的规模/生产率的参数模型是没有考虑这种指数关系.

COCOMOII成本估算模型考虑了该问题是可以借鉴的。软件产品规模较小的系统投入再多的人是没有意义的,团队人数增加沟通渠道指数倍增加,同时为了让大家都有事可做将导致组件划分和角色的分工越来越细,导致为了人而扭曲原来运转良好的开发过程,而不是真正根据软件开发需求来确定人力资源。

虽然不是线性的,但软件产品规模和软件团队最佳人数上应该有个对应关系以获得最好的收益和价值。有时进度处于高优先级时候,在项目初期需要投入更多的人员,但往往比最佳值投入的更多的人员往往只能获取到20-30%甚至更少的进度收益(收益递减规则).

用人月来衡量软件产品的规模是一种欺骗性的神话,它暗示着人员数量和时间是可以相互替换的。但往往2个人开发一年的项目是无法在10个人开发两个月的情况下完成的。但书中仅仅强调了由于人员增加带来的沟通渠道和沟通时间的增加,并没有强调软件开发受到软件生命周期模型的约束,即使是敏捷方法论如果用户需求或软件需求都不清楚,是无法展开设计开发工作的。软件开发生命周期模型确定了软件开发项目是由不同种类的任务或活动,组成的具有相互依赖的约束的网络图。软件项目的进度受到资源和关键路径等多重约束,增加资源往往会导致重新绘制网络图和重排进度计划。

系统测试时间应该占整个项目周期时间的1/4左右,不为项目安排足够的系统测试时间简直是一项灾难。在快速软件开发中的一个要素就是每日构建和冒烟测试,每日构建的成功实施可以降低后续系统测试时间和项目风险。另外随着软件规模的增加,除开发工作量指数增加外,测试复杂度也呈现指数增加。

估算不准确往往是导致进度计划偏差较大的原因,估算方法有很多包括功能点,参数估算,但很多时候估算……
编辑 | 阅读全文(1673) | 回复(0),人月&神话 发表于 2007-7-17 13:14
(共 973 条) 1 2 ... 50 51 52 53 54 ... 64 65 翻页至

仅列出标题