自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+

  • 博客(27)
  • 收藏
  • 关注

原创 项目计划和任务分配的外科手术队模式-On The Road

最近开始阅读《人月神话》,读到“外科手术队”章节,我就明白了这本书能如此受青睐的原因。人月理论是不能应用于项目计划的,人数和时间并不是成简单的反比:人数的增加,则意味着不同思维的增加和交流的增加,当这一切默默的纠缠在一起后,项目就渐渐沉入沼泽。传统的项目计划和任务分配方式,是将一个系统分为多个子系统,将每一个子系统的设计和编码分配给其中的一个或者几个programer。这种模式下我看到的现

2007-09-07 09:44:00 1029

原创 焦油坑与激情-蝈蝈俊.net

这是蝈蝈俊.net最近的一篇博客。先来听我说几个真实的故事:     上周面试了一个开发人员,这个人所有的面试题都答出来了。各方面我们需要的知识也掌握了,但是在初试中,这个人就被我们三个面试官一并否决了。 原因很简单,这个面试者提供的答案都是能解决问题,但几乎都是效率最差的方案;另外,从一些面试题中,可以看出这人很多时候,把开发工作当成一个应付差事的工作来做,而不是作为自己的兴趣来做。缺乏

2007-09-05 17:45:00 964

原创 项目计划-不仅仅指项目进度-Adams Wang

项目计划的重要性相信每个人都了然于胸。Brooks在“祸起萧墙(Hatching a Catastrophe)”一文中提及了项目计划/跟踪。另外,在其他的许多章节中,阐述了计划文档化的重要性。这里,项目计划不仅仅指的是项目进度,采用Microsoft Project所画出的仅仅是项目的进度。在具体的实践中,项目计划可以从以下若干方面考虑:项目描述:包括项目定义、名称、背景、目标与范围、交付

2007-09-05 17:22:00 996

原创 迭代开发-Adams Wang

Brooks在“20年后的人月神话(The Mythical Man-Month after 20 Years)”明确提出了迭代开发的概念“增量开发模型更佳——渐进地精化”。这种开发方法对项目产生的激励作用是不可估量的,作者在北卡罗来纳大学时,“我常常会被屏幕上第一幅图案、第一个可运行的系统对团队士气产生的鼓舞效果而感到震惊。”而在C++的现实项目中,在极大的压力下,当第一个可执行的原型出现在开发

2007-08-31 14:22:00 953

原创 面向变更的开发-Adams Wang

“稳定状态的生产思想特别不适合项目工作。我们倾向于忘记这一点:项目的全部目的就是让自己死亡。项目生命中的唯一稳定状态是死后僵硬……”(Peopeware);“软件开发是减少混乱度(减少熵)的过程,所以它本身是处于亚稳态的。软件维护是提高混乱度(增加熵)的过程,即使是最熟练的软件维护工作,也只是放缓了系统退化到非稳态的进程。”——“未雨绸缪(Plan to Throw One Away)”软

2007-08-31 14:19:00 835

原创 《人月神话》(32周年中文纪念版)免费试读

《人月神话》(32周年中文纪念版)免费试读第1章 焦油坑  编程系统产品 职业的乐趣 职业的苦恼 第3章 外科手术队伍  问题 Mills的建议 如何运作 团队的扩建 第7章 为什么巴比伦塔会失败  巴比伦塔的管理教训 大

2007-08-31 14:08:00 1252

原创 Fred Books图集

 点击看大图 1965年和System/360机器合影 1978年的Fred Brooks

2007-08-30 09:25:00 1019

原创 软件开发中的交流问题-Adams Wang

Brooks在“贵族专制、民主政治和系统设计(Aristocracy, Democracy, and System Design)”一章中,一针见血地指出了成功软件具有高度的概念一致性。“结构师难道不是新贵?……至于贵族专制统治的问题,必须回答 “是”或者“否”。就必须只能存在少数的结构师而言,答案是肯定的……”,《人月》中的体系结构更加类似于现在的需求概念,而非现在所意义的体系结构。不过,在具体

2007-08-29 10:04:00 919

原创 小型的C++项目团队组建-Adams Wang

 “人月神话(The Mythical Man-Month)”提出了这样的论断,(盲目地)“向进度落后的项目中增加人手,只会使进度更加落后。”这中间还涉及到如何组建你的开发团队,或者面向一个软件开发任务时,如何规划开发计划、划分任务项、分配资源。紧接着,在“外科手术队伍(The Surgical Team)”中,Brooks提出了用外科医生+副手来组织团队,保证设计思路的完整性。其中,还提到了采用

2007-08-29 09:57:00 1219

原创 微软Exchange团队刷新人月神话记录

Vista喧嚣背后的真相在微软WinHEC大会上,比尔•盖茨给合作伙伴颁发了产品试用金碟。2007三大商务引擎面向全球商业用户发布。   一再跳票的Vista带给用户的将会是什么?是吊足的胃口和不断的抱怨,还是让人耳目一新的兴奋和疯狂?耗时五载、动用6000名工程师、花费200亿美元,倚借Vista微软能否重现Windows 95时期的辉煌?一向被病毒和黑客格外青睐的Windows以及微软公司

2007-08-09 11:41:00 1207

原创 焦油坑-项目失败的表现-zwavelet

焦油坑一章一开始提出项目失败的表现:“表面上看起来好像没有任何一个单独的问题会导致困难,每个问题都能获得解决,但是当他们相互纠缠和积累在一起的时候,团队的行动就会变得越来越慢。”对于问题的我们很难看到本质,不过,如果我们想解决问题,就必须试图先去了解问题。那么,这个问题在接下来的对 “编程系统产品” 的介绍,体现出来的,是人们对这个问题认识的不足和误解,并且,对此作了工作量的的确定,程序到

2007-08-09 11:25:00 892

原创 程式設計師都是樂觀的傢伙-forlady

看到小女子介紹人月神話這本書,請不要以為是羅曼史小說或者傳奇故事。它是一本二十年前出的、講三十年前軟體專案管理問題與經驗的書,原名是The Mythical Man-Month。其中的很多事例,現在仍存在,其中很多經驗,現在拿來用都還來得及。這次的版本為20週年紀念版。首先作者提出了一件常常發生的事情,這也是一個朋友身上發生的故事:『程式設計師都是樂觀的傢伙。』而且我發現越年輕越樂觀,但是

2007-08-06 10:40:00 796

原创 程序员要有勇气不妥协,坚持自己预估的时间-forlady

曾經接過急迫且大型的網站建置專案,但是進行上卻還算順利,這是由於系統工程師十分有經驗,在分工、次序與掌控上,都做了很好的安排。但在最近的一個朋友的經驗中,卻是遇到網站的機制改版,在時程與資源運用上卻不斷延遲,還好是內部機制,不用對客戶交代,否則所蒙受的將不是只有金錢上的損失。我們知道時程延遲,但原因在哪裡?為何會發生?人月,是我們預估和排定時程用的,但是作者提出一個前提:『使用人月必須

2007-08-06 10:38:00 857

原创 软件开发中的审美疲劳-surstar

软件的开发的过程是一个反复的过程,对自己的界面时时刻刻的面对,一种很简单而豪无意思的说法是:换一个角度来看的产品,也许有一些人可以做到,但是他们真的做到吗,这和一个人美术细胞有关,一个修养有关,我认为要做到:吹毛求疵,在《人月神话》里,作者这样说到,程序员是一个天生就有追求完美的天性,这也是在锻炼过程中生成的!(大意),我认为 对自己的产品吹毛求疵是可以做到的,现在你打开一个你自己软件,观看自己的

2007-08-06 10:29:00 889

原创 月加班时间达到300个小时-baryonlee

上一个项目已经结束1个多月了,新的项目一直没有下来。最近的一个月,yan一直在设计他的workflow。workflow的思想是去年他们做open cube的时候学到的。那个系统最终还是成为了他们的噩梦。一周只回家一次,月加班时间达到300个小时,持续半年以上。最后的结果还是放弃。完全是《人月神话》里描写的泥潭。一个近百人组成的team就像一个困兽掉进了沼泽地,经常半夜2,3点钟开会,还一个人不缺

2007-08-03 11:58:00 888

原创 亲历产品概念完整性

我这几天很烦!一是因为现在做的项目处于测试阶段,由于一些原因,导致现在发现了很多关于模块交互方面的问题。现在将这些模块“组装”成一个像样的系统,这些问题必须解决,而且目前只能自己与其它开发人员商量解决!这个项目在设计的时候有七个人参与,应该是开发部所有的开发人员包括在内。当时先是讨论整个框架的设计,然后将各个模块的设计分下来,一人完成一两个,再接着开会讨论,讨论来讨论去,讨论的差不多了,也

2007-08-02 18:44:00 1323

原创 什么是软件开发的核心问题?-jlinux

软件开发的核心问题? 我自己的回答是人. 这里面包括很多, 人, team, 公司等等, 从一个人到一群人, 不管是开发软件的人也好, 使用软件的人也好,都是由人为主体的. 而其他不敢是工具也好,还是方法也好, 不都是人在操作和使用吗. 这正是《人件》中所阐述的思想,我们以后会另开一个线索讨论《人件》中所关注的问题。国外资深的开发人员都读过《人月神话》和《人件》这两本书。国内的开发人员却不

2007-08-02 18:29:00 918

原创 什么是软件开发的核心问题?-dlee

按照软件工程鼻祖,《人月神话》作者 Brooks 在“没有银弹——软件工程中的根本和次要问题”一章中阐述的思想,软件开发的核心问题就是如何从概念上对一个复杂的业务系统进行建模。这个建模是含义广泛的,不仅仅包括对象建模,还包括数据建模、算法建模等等一系列的内容。总而言之是要先找到解决复杂问题的突破口(先要搞明白需要做什么,然后再考虑如何做)。至于采用什么表示方法(简单文本、UML 图、E-R 图)、

2007-08-02 17:11:00 1224

原创 概念完整性非常重要-camer

看了《人月神话》,体会到一点:概念完整性非常重要,扩展开来说,pmbok中项目管理体系已经是一个经过验证的管理概念,要做好项目必须要关注项目中的各方面特性,就算你不关注,它们事实也存在。所以我认为一个成熟的项目管理人员,必须在头脑中首先有这样一个完整的项目管理概念,但是在小公司中,由于条件的不充分,可以弱化那些优先级不太高的子概念(比如hr),但是这仅仅是弱化,不是不存在,在一定时候,你必须关注,

2007-08-01 10:01:00 905

原创 保持设计的概念完整-巫丹

保持设计的概念完整。无论对小软件还是大软件,都必须由一个设计师主导,最多两个人讨论来共同完成软件的整体设计。作为一个软件,一个系统,必须有一个清晰明确的概念模型,大家都在这个框架下工作,所有的创新发展都必须与基本的概念相吻合。具体的实现人员可以细化概念,但只有总设计者才有否定与发展基本概念的权力。需要注意的一点是,即使是总设计师一直是同一个人,他脑海中所认为理所当然的规则或者概念,很可能由于没有明

2007-08-01 09:35:00 675

原创 进度落后与增加人力-巫丹

进度落后与增加人力。记得当年看《C++编程思想》,Bruce说“十个妇女不能在一个月内生下小孩”(大意),于我心有戚戚焉。而本书作者Brooks得出的结论是对我是震撼性的:“向进度落后的项目中增加人手,只会使进度更加落后”。以前,增加人手基本是挽救进度落后项目的主要办法。这个办法行不通的话,难道只有“加班”一条路了?但长期加班是对个人的摧残,我更愿意利用业余时间去看书,例如看这本“人月神话”。

2007-08-01 09:29:00 786

原创 我的人月代码产量分析-*o*

编写代码也已经数年了. 说到编写代码的能力, 只怕也不会有一大堆人超越我. 但是, 领导终究是领导, 始终会有没有学过管理或者尝试以流水线理论来主导软件开发的领导. 而且, 在国内, 这样的领导并不少见. 这些领导的共同只处在于: 目标产品是定下期限要完成的, 所有的东西是可以以人手定量的, 而人员配备"按照正常情况足够满足开发进度". 在这一前提下, 形形色色的变种会出现.有些是不能明确说出

2007-08-01 09:21:00 908

原创 关于首席程序员、副手、管理员的分工-wuguangyao(小武)

关于首席程序员、副手、管理员的分工,我的看法:首先,我们都承认,人月神话中关于这一段的描述是正确的,也就是说这种工作方式是科学的。其次,在我们这个公司是肯定不可能这样去做的。第三,除了那些作坊式的开发团队,由于他们本身可能只有一两个人,或者两三个人,否则,我怀疑是否有哪个公司的开发团队或者开发小组真正采用了这种工作方式,似乎大家都是在遵循这书中所说的错误的开发方式,(用一大堆人来解决问

2007-07-31 09:48:00 815

原创 关于首席程序员、副手、管理员的分工-cenwangsky (屹康)

《人月神话》书中对首席程序员、副手、管理员定义如下:首席程序员。他亲自定义功能和性能技术说明书,设计程序,编制源代码,测试以及书写技术文档。他使用例如PL/I的结构化编程语言,拥有对计算机系统的访问能力;该计算机系统不仅仅能进行测试,还存储程序的各种版本,以允许简单的文件更新,并对他的文档提供文本编辑能力。首席程序员需要极高的天分、十年的经验和应用数学、业务数据处理或其他方面的大量系统和应用知

2007-07-31 09:45:00 840

原创 分工导致了对于效率的盲目追求-Zhangmin

分工使得每个程序员只关注于自己的工作领域,没有时间也没有精力去关心系统的其他部分,这样就带来了系统开发中的本位主义,更严重的是,系统中存在的错误被详细的分工掩盖了起来,最后往往等到系统测试时才发现错误,这时修改系统已经太晚了,只好在上面进行修补,最后整个系统变得如同泥潭一般,让项目组不能自拔,究其原因,往往是因为分工导致了互不了解,最后大家彼此的工作被相互抵消了,工作的越努力,给其他部分带来的麻烦

2007-07-31 09:40:00 1141 1

原创 关于我们的思考--“项目开发”及读《人月神话》有感-kaka

项目开发终于结束了,按项目流程,我应该写一份《项目开发总结报告》。拿来“GB856T——88”标准文档,有框架指导我该写些什么,但是怎么能让这些框架协束缚了自由的思想呢?于是决定换一种形式。项目开发接近尾声的时候,也是最关键的时候,有人送来一本《人月神话》。我很幸运能在这个时候读这本书,因为会有很多思考,关于项目,关于团队,关于我们…………完美与放弃在《人月神话》中有一段被截取,称

2007-07-30 17:26:00 670

原创 又见人月神话-开篇

得知消息,《人月神话》(影印注释版)和《人月神话》(25周年中文纪念版)将陆续在8、9月出版了。已经很久没有关注她了。印象中,《人月神话》还是我进入IT出版行业运作的第一本书。想一想,第一次出版离现在已经有几年了吧。几年了?翻开翻译版的版权页,惊讶的发现,已经5年了!5年了!我从一个行业跳入了另一个行业,又从一个编辑转变成了一个销售,做营销、做产品、做运营,然后到现在的角色,一个我自己拿一

2007-07-30 16:54:00 1115

空空如也

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除