神话
- ben0133 财富等级:
|
|
进度落后与增加人力。记得当年看《C＋＋编程思想》，Bruce说“十个妇女不能在一个月内生下小孩”（大意），于我心有戚戚焉。而本书作者Brooks得出的结论是对我是震撼性的：“向进度落后的项目中增加人手，只会使进度更加落后”。
|
|
此评论对你有用
没用
|
| |
|
|
|
人月神话（32周年中文纪念版）（附送国内实战体验精华册）
- zhmnsw 财富等级:
|
|
前人的经验是如此宝贵而有效，但错误和失败依然会一如既往，因为问题的关键是在想不想，而非会不会...
|
|
此评论对你有用
没用
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
好书值得看哦
- hwh0108 财富等级:
|
|
找了很久电子版的,可找不到啊,先在网上看看吧,没有钱买书啊,,,,,,,,
|
|
此评论对你有用
没用
|
| |
|
|
|
|
|
|
人月神话（32周年中文纪念版）（附送国内实战体验精华册）
- slm007 财富等级:
|
|
学校图书馆里的是白色硬皮的新版，可惜是英文版的我又没有项目经验，看着非常吃力
|
|
此评论对你有用
没用
|
| |
|
|
|
|
|
|
|
|
人月神话：32周年中文纪念版
- Deniz 财富等级:
|
|
考虑软件工程的同时，又充分估计到人性的重要。软件开发的现实情况就是这样，充满着科学管理工程化标准与人性的矛盾。只有根据实际情况，能够权衡地把握这些矛盾才能成功。
|
|
此评论对你有用
没用
|
| |
|
|
人月神话（32周年中文纪念版）（附送国内实战体验精华册）
- Zoezs 财富等级:
|
|
据说这本很不错，对软件工程的思想说的比较好。
|
|
此评论对你有用
没用
|
| |
|
|
|
|
|
|
人月神话（32周年中文纪念版）（附送国内实战体验精华册）
- GYXJJ 财富等级:
|
|
很早以前就听老师提过这本书，据说挺不错的一直想读，可是没有机会！希望从未来的某天可以开始阅读这本书
|
|
此评论对你有用
没用
|
| |
|
|
|
|
|
|
人月神话（32周年中文纪念版）（附送国内实战体验精华册）
- oyzdz1988 财富等级:
|
|
这是本介绍软件工程十分经典的著作，三十来年经久不衰，对软件开发的过程进行了生动的描述。
|
|
此评论对你有用
没用
|
| |
|
|
|
|
|
|
|
|
人月神话（32周年中文纪念版）（附送国内实战体验精华册）
- andylin02 财富等级:
|
|
很好,我喜欢，不过没有什么实践和管理经验不太好理解:)
|
|
此评论对你有用
没用
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
好书
- ti_amo_l 财富等级:
|
看了就想买的书。里面提到的项目过程管理方面的东西对于我们平时的工作具有很大的启迪作用。
值得收藏的好书。
|
|
此评论对你有用
没用
|
| |
|
|
|
|
|
|
|
|
|
|
事相当好的书的
- ruibird 财富等级:
|
相当的好，正在读....里面提到的项目过程管理方面的东西对于我们平时的工作具有很大的启迪作用。
值得收藏的好书。
|
|
此评论对你有用
没用
|
| |
|
集合框架的授课感想
- rolt  财富等级:
|
集合框架的授课感想
作者:陈宇 日期:2007-07-23
字体大小: 小 中 大
集合框架 (Collection) 可以说软件编程中过程中极其重要的一个概念,为什么我这里要用“极其”这个词呢？就是因为在我的14个项目研发经验中，几乎每个项目都需要使用集合框架，如果用好了集合框架，那么整个项目将会变得非常灵活，因此在我Softworks中心的培训经历中，我也非常注重对于这个概念的培训。其实比较喜欢在网上浏览技术的同学可能知道，网上有比较流行的32道经典Java面试考题，在这些考题中就有很多是用来考察学员对于集合框架的理解程度的。
在授课的过程中，我借助了《人月神话》中的5W1H的学习分析方法对于集合框架进行了介绍：
1．What：什么是集合框架，集合框架其实就是一个“垃圾桶”，因为任意对象都可以放入集合框架中。由于数组存在比较明显的缺陷（例如：一次声明所产生的数据类型必须是一致的，数据地址必须是连续的，数组长度是定长的等等），而集合框架比数组更灵活更实用，甚至可以将集合框架中的某些部分理解为数组的包装类。
2．Why：集合框架比数组来的更灵活，可以说集合框架完全弥补了数组的一些缺点，虽然操作效率没有数组那么高，但是却可以大大提高软件的开发效率，而且不同的集合框架类可以适用于不同的场合。
3．Where：我们在项目的任何一个角落中都可以使用集合框架，例如，现在我们有2个实体类：顾客类(Customer)和订单类(Order)，根据现实情况我们可以明确，一个顾客拥有多张订单，而一个订单只能隶属于一个客户，这个时候由于客户包含了多张订单，那么顾客类就可以用集合框架来存放所有的订单对象了。
4．When：集合框架顾名思义就是某些相关数据的整合个体，那么当我们需要将一些相同特性的个体整合或者说绑定在一起的时候，就可以考虑使用集合框架了，因为集合框架可以保存和帮定这样一些数据。
5．Who：所有的Java,.Net程序员都可以使用集合框架，因为现今的面向对象的高级编程语言都提供了集合框架的处理类。
6．How：在理解了集合框架的意义以后我们来看看如何来使用集合框架
|
|
此评论对你有用
没用
|
| |
|
|
圣经巴别塔
- rolt 财富等级:
|
http://iplinger.blogbus.com/s19955/
圣经巴别塔
2006-04-29, by iplinger
1. 近日读起《圣经》，三郎问过：'圣经都可以读得？'，我说：'读得,读得!'
2. 一日读到创世纪中有关巴别塔的故事。这一触即发，让我想起了《人月神话》中有关巴别塔的讨论。
3. 这个讨论围绕着软件项目中交流的代价展开。就像耶和华 神（上帝）打乱了人们的语言，让言语彼此不通。沟通不善，预示着项目的失败。
4. 人月能成为神话，多多来自于交流的代价；10人 * 10月（100人月） != 100人 * 1月（100人月） ，因为这里面没有包括多出的90个人交流的巨额代价。
5. 如果你想了解世界，圣经是你了解西方文化的一个窄门，它会让你越走越宽。
CUV-和合本，Chinese Union Version
The Tower of Babel
1那时，天下人的口音，言语，都是一样。 2他们往东边迁移的时候，在示拿地遇见一片平原，就住在那里。 3他们彼此商量说，来吧，我们要作砖，把砖烧透了。他们就拿砖当石头，又拿石漆当灰泥。 4他们说，来吧，我们要建造一座城和一座塔，塔顶通天，为要传扬我们的名，免得我们分散在全地上。5耶和华降临，要看看世人所建造的城和塔。6耶和华说，看哪，他们成为一样的人民，都是一样的言语，如今既作起这事来，以后他们所要作的事就没有不成就的了。 7我们下去，在那里变乱他们的口音，使他们的言语彼此不通。 8于是，耶和华使他们从那里分散在全地上。他们就停工，不造那城了。
|
|
此评论对你有用
没用
|
| |
|
|
周爱民
- rolt 财富等级:
|
http://blog.csai.cn/user1/21840/archives/2007/13297.html
专访架构师周爱民:谈企业软件架构设计
最近在网上读到了“杀不死的人狼——我读《人月神话》”系列文章。是周爱民关于《人月神化》的读书心得。《人月神化》在软件工程里一本很有分量的书，讲述了Brooks博士在IBM公司 System/360家族和OS/360中的项目管理经验。周爱民在他的这一系列文章中用自己架构师经历为基础，从他的视角重新品读了这本书。而这也使我有了采访下他的想法，从中我们也许可以了解到中国企业内软件架构设计这个环节的现状。目前周爱民是盛大网络架构师。在此特别感谢周爱民在百忙中抽出时间回复了这次访谈。
1， 您好，请先向我们的网友简单做一下自我介绍自己好吗？
我94年开始学习电脑，基本上从一开始就学编程。从96年开始涉及商业软件开发，到现在约十一年了。其间我在郑州的一家软件公司呆了7年，历经了一家软件公司的中兴到消亡，因而也意识到工程、管理在软件企业——当然也包括其它类型的企业——中的价值。后来，从03年开始的一年多时间，我在郑州的另一家公司任软件部经理，也开始实践自己的工程和管理思想。很好，到现在我离开这家公司一年多了，公司状况依然很不错。我认为，团队或公司并没有因为你的缺席而变得糟糕，那便已经是良性管理的表现了。关于“Borland Delphi产品专家”，其实更多的是一个圈子的认可，而非行业的认可。我在“大富翁论坛（delphibbs.com）”活动了很长的时间，得到了一些朋友们的认可，后来Borland要评选这个专家的时候，大家推举了我，于是就得了这个称号。其实在我看来，优秀的人才、专家很多，我大约是人缘好点，运气好点罢。
我05年9月开始到盛大网络，任架构师一职。当时Borland China也有offer，但在顾问、软件工程师与架构师之间，我选择了架构师这个职务，因为我对这个角色更加感兴趣。我目前的工作，主要是盛大的软件平台方面的架构、设计和一些实施方面的事务。虽然很多人认为盛大是做游戏的公司，但我基本不涉及游戏产品的开发。
在开发技术方面，我03年出版过一本《Delphi源代码分析》。在工程方面，《大道至简——软件工程实践者的思想》一书在下月初就应出版了，它的第一版是以电子版的形式发布的。我在写的第三本书则是讲计算机语言的，题材是“动态函数式语言”。
2，您做为盛大网络的架构师，请介绍一下在软件项目中平台架构师是一份怎样的角色？主要处理哪些工作？
架构师有很多种。很多人把体系架构师与架构师等同，其实不对。各类架构师基本素质要求大抵一致，例如分析能力、设计的技术方法，以及对设计目标的前瞻性。但是他们的专业素质会有一些差别。举个实例来说，如果让我设计游戏引擎的架构，我就会做不好。但是，如果这个游戏引擎要设计成一个独立的平台层次，具有语言无关性、平台整合能力，或是对不同类型游戏的统一支撑，那么就是平台架构师的职责了。
具体来说，平台架构师会决策某个部分与其它部分的相互关系、界面的规约和检测评估它们的方法。如果一个游戏引擎只为某个游戏而设计，那么是用不到平台架构师的。但如果Ａ游戏中的引擎要移植到Ｂ游戏，或者更多的游戏，甚至只是抽离它的部分，以作为某种体系中的一个数据交互层，那么就需要平台架构师来考量技术上的可行性、稳定性以及它对于更大范围内的平台建设的价值——当然，如果没有价值，架构师也会否定它。
平台是长期建设的。平台架构师的重要职责之一，就是长期的规划和持续的推进。所以平台架构师的工作总是伴随客户的战略决策的。如果一个设计只是解决短期的技术问题，那么也并不需要平台架构师，但如果是几年或十几年要在上面持续经营的一个整体方向，那么平台架构师就需要围绕战略来设计架构
|
|
此评论对你有用
没用
|
| |
|
|
從沒有銀彈到PMP
- rolt 财富等级:
|
http://trip.5d3w.us/index.php?op=ViewArticle&articleId=146&blogId=2
[ 開卷有感 ] 11 十月, 2005 09:39
人月神話帶來的省思:從沒有銀彈到PMP
這本書, 我是聞名已久, 只是一直都沒有機會看到, 而原文書我又實在啃不動, 也就只能偶而在某些文章裡看到斷簡殘篇了...
但很幸運的, 它出了20週年版。
當我在博客來看到時, 我就毫不猶豫的買了下來。
看著這本高齡二十的IT書, 實在很難想像它還能出版。IT界的折舊一向快, 何況還是二十年。這麼久了之後, 還能出版, 可見這本書的經典價值了。
在這裡, 我實在不需要對它再歌功頌德了, 因為有太多的人對它發表了很多很多的看法, 也有很多正反的意見, 有興趣的人不彷在搜尋引擎上打入 '人月神話' 四個字, 會找到很多的。
看完人月神話, 最引起我感慨的, 就是那幾篇'沒有銀彈'的相關內容了, 這也是很多軟體從業者評價最兩極的部份。
作者的大意是指他預測未來十年內, 不會有什麼軟體工程的好理論或是方法, 可以使軟體生產力明顯提升的。就像是沒有可以對狼人一擊必殺的銀彈頭子彈一樣, 所以說沒有銀彈。
從書裡隨後的章節裡可以看出來, 這篇文章發表後, 很是受到了一些人的批判, 而且也提出了很多的反證, 指責作者的說法有誤, 而且還聲稱有些銀彈是存在的。
作者也一一的解釋了這些反擊, 但很明顯, 他並沒有改變他的結論。
以我自己多年的經驗, 我很認同作者的結論, 系統的開發, 在一個數量級以上後, 的確是不存在所謂的銀彈的。
(以我個人的看法, '沒有銀彈'這個結論, 並不適用於5個人以下的開發團隊。因為人數太少, 並不足以彰顯出銀彈的價值。就像看到了一隻幼狼一樣, 根本就不用考慮武器的好壞, 用手就可以捏死它了。在這樣小的團隊裡, 也不會接到夠複雜的案子, 在這裡討論人月神話是沒有什麼太大的意義的。)
為什麼會 '沒有銀彈' ?
因為有太多的人不明白, 大型軟體的構建, 不再是軟體本身而已, 它真正的問題已經變成了其它專業, 管理, 組織, 甚或是政治問題。
而這些, 是不會有什麼固定模式或固定解的, 既然無常式, 那怎麼會有定解 ? 又那來的銀彈 ?
這樣子下結論, 也許太快了, 底下我做細一點的說明, 因為這個結論會衍伸出一些更大的爭論。當然, 只算茶壼裡的風暴, 因為看得到這篇心得的人很少, 他們會不會和我爭論, 或爭論的規模有多大, 我想都不能跟人月神話作者去比。
好, 言歸正傳...
在書中, 作者花了大篇幅去解釋大型軟體開發工作中包含了兩種屬性的內涵, '本質'和'附屬'的含意。
那, 什麼才是系統的'本質' ? 什麼又是'附屬' ?
軟體界這二十年來, 在軟體的開發工具和流程研究上成就不少。不管是作業系統, 開發工具, 高階語言, 專案管理, ...等等, 無一不擁有了傲人的成績。但這些, 並不是系統開發的本質, 而是'附屬', 一切的一切, 軟體工程的一切, 都只算是系統發展過程中的附屬而已。
因為一個專案, 真正可以決定是否成功, 最後打成績的, 不是 PM, 不是 USER, 也不會是 PROGRAMMER, 而是 Owner(擁有者), 那個最後付錢的人。
既然那些都不能決定專案的結論, 那怎麼會是本質呢 ? Owner的想法才是系統的'本質'。
在軟體開發的專案(Project)裡, 最高的那一個位置, 始終是歸屬給所謂的Owner的。他就像遊戲裡的BOSS一樣, 一個開發案他出錢, 他提需求, 他提目標, 不管團隊的領隊是誰, 本領是高是低, 案子最後是成是敗, 最後仲裁者是他, 而非管理案子的你或我。
之所以沒有銀彈, 問題就出在 Owner 上。
在一個專案裡, Owner 並不一定是指一個人, 它也可能是一群人, 甚至也可能是不固定的一群人, 尤其是極大型的政府專案, 在專案進行的過程中, 負責的官員可能是來來去去的 !!
它們人數不定, 想法不一, 專業能力參此不齊, 個性更是難以控制。面對這
|
|
此评论对你有用
没用
|
| |
|
|
杀不死的人狼——我读《人月神话》（一）
- rolt 财富等级:
|
http://www.yimudi.com/portal/articleUrlForward.do?articleId=268184018
杀不死的人狼——我读《人月神话》（一）
＝＝＝＝＝
前言
＝＝＝＝＝
在这与这段文字之前，我已经阅读过种种关于《人月神话》的文字。评论者既有刘天北这样的美食家，试图在书页中夹点胡椒面以慢慢品味，为了表现食客特有的风格，他的书页都比别人数得仔细。也有marktsen这样的速食者，试图几句话就打发了自己或者读者那漉漉的饥肠。
阅读这些文字给我带来的收获是：面对《人月神话》，除了表示五体投地的诚服，你既不能做正面言论（那是多余），也不能做负面言论（那是找事）。
这是一本可怕的书。
我大概花了三周的时间来细读这本书——也许很多人会说我应该花更多的时候或者读更多遍——不过，这不是重点。我在书中印证和找寻思想，并为这本书写下了数百个注释。最终我很遗憾我读了电子版本，因而注释被写在了文档中而不是书页上。如果不是这样，我将没有任何方法扼制自己购买这本书的冲动。
然而，我发现我还是应该来写写这本书的读后感想。我没有使用“评论”这样的词汇，是因为任何的（正面或负面的）评论都不可能撼动《人月神话》的地位，而“感想”是唯一可能供读者借鉴而又不引起争论的东西。
下面的文字分成两个主要的部分。一部分是如何读这本书，如果你已经读得很好，那可以跳过去，这是留给别人的。另一部分，则是讨论那个著名的命题：没有银弹——似乎，不讨论这个命题的话，连感想都不成其为感想，沦为空谈了。
＝＝＝＝＝
一、《人月神话》的结构及其与组织
＝＝＝＝＝
我对《人月神话》的内容结构做了一些分析，大概如下：
章 内容说明 问题域
1 说明“程序(program)”不是“产品(prodouct)”，更不是“项目(project)”。
说明程序员的心理与情绪因素——这是很重要的一个话题。
2 项目的发起、评审与预估（错误的设定项目周期是最大的错误）。
“人月问题”：周期不因为人力投入而变短，事实上它可能更糟糕。 项目定义
3 十个人与几百人面临的问题是不同的。 团队建设
4~5 从设计阶段开始，即致力于获得和维护概念的完整性。 团队管理 - 方向与决策
6 项目过程中的一般性方法。 团队管理 - 一般性方法
7 项目组织过程中的沟通问题。 团队管理 - 沟通问题
8~10 编码过程中的关键问题：
－项目复杂程度与需要编码的数据呈指数级关系，反过来，减少编码可降低系统复杂性
－数据的表现形式是编程的根本
－文档是必须且重要的，但往往不被关注（主要强调重要性） 编码
11 承认变更，承认从需求和设计期就开始的变化。
为应付变化而实现的原型系统。 项目定义 - 需求不确定
12 工具带来效能。
13 强调测试，以提升品质和保障项目目标。 项目管理 - 检测/回顾
14 项目控制：进度与里程碑 项目管理 - 控制
15 文档：项目过程文档，包括定义、设计与实现（主要强调方法） 项目管理 - 文档化
16,17 没有银弹、再论没有银弹
18,19 前十五章的回顾（不包括“银弹”的话题）
20 二十年后对上述命题的回顾（包括对银弹现象的进一步解释）
正如Brooks说到的，在几十年之后的今天，这本书里的现象或者观点已经为整个行业所认知——无论是从实践中的感受，还是从类似《人月神话》这样的书籍中去获知。其中大多数命题与结论，都在这几十年的开发实施中被印证过，所以它们（我指的是这些命题与结论）备受关注。
我只重述Brooks所讲述到的两点。我重述它们的原因，是认为它们还被关注得不够：通过设计来获得系统的一致性，以及更好的文档。
在Brooks的讨论中，不但要“获得”系统的一致性，还是尽力去保障它。Brooks认为“获得和保障”它的角色是并不是同一个人：前者是结构师（第3～4章所论），后者是项目经理（第5章所论）。对于这两个角色（或相似的角色），在第7章“大型编程项目的组织架构”中，Brooks提出：要么产品负责人任总指挥，技术主管充当其左右手；或者反之。Brooks认为前者更适于大型项目，后者更适于（相对）小型的项目。
在人月神话中对这两个角色的用词与我们现在（至少是翻译过来的）用词略有点不一致。事实上书中的产品负责人相当于现在的项目经理，而技术主管相当于技术经理（至少参与系统设计或直接由架构师担任）。
Brooks并没有低估（或错误认识）系统一致性和文档的重要性。但除了这两点未被足够重视之外，我想前十五章的内容不必再复述了。如果你不能理解我为什么不再复述，那可能你需要更多的工程经验或者理论基础。除非你决心认为大师的一切都必须被象圣经一样地重述，但那只是你个人的信仰，或者喜好。
|
|
此评论对你有用
没用
|
| |
|
|
五、从广义工程到狭义工程
- rolt 财富等级:
|
http://www.yimudi.com/portal/articleUrlForward.do?articleId=268184018
杀不死的人狼——我读《人月神话》（五）
==上一节
＝＝＝＝＝
五、从广义工程到狭义工程
＝＝＝＝＝
现在我们回到一个实际的问题上：工程的本质需求是什么？如果我问一千个人工程的本质，可能会得到一千种答案。因为大家离本质的东西都很远，又从不同的角度去看这本质，故而得到的答案并不相同——而且每一种答案都貌似正确。
但是我问的是“本质需求”。对此，我的答案是：本质需求是“实现(工程的目标)”。
不管工程本质是怎样的，但这个需求如一。我们完不成它就等于失败，至于它是否是Brooks所说的“软件活动的根本任务”，与这个具体的工程无关；至于它是不是从人类发展的历史上来看，向着“软件活动的根本任务”的目标迈进了一步，也无与这个具体的工程无关。
简单地说，我们做具体工程的目标，并不等同于Brooks所说的“软件活动的根本任务”。
回到具体工程的视角，我们面临的可能是：
a1：自研发产品 a2：客户投资的项目
b1：短期效益的市场探针 b2：战略方向上的一项长远计划
c1：一个小型而称手的工具 c2：一个大型的可持续平台
…… ……
这个对比中，a1的需求基本可控，a2就得面对客户或业务规则的变化；b1不需要背上历史包袱，甚至不用考虑架构一致性，而b2就必须做好设计并面临长期用户需求的沉积；c1可能一两个人就完成任务，c2就必须组织大型团队……我们如果要找一个方案来适应这所有的“软件开发活动”，那么它只可能是弹性的。而弹性并自由伸缩的一个方案必然带来学习和运用上的困难，因此你又得投入人力来学习使用，并在实施中不时监控它。——于是，你的人力和时间成本又增加了。
不要去相信“它适合于所有的工程”这种商业推广的鬼话。那绝对是赤祼祼的欺骗。你要看住你的口袋，因为你可能在消耗你的资源（时间、人力与金钱）去适应一种方法。你一方面要花销资源去组织、实践和推动这些工程方法，另一方面工程的规模可能根本没有资源去推动它们，你必然面临失败；如果你增加资源去推动，那么成本可能大于项目利润，你的老板会不乐意而直接中止这个项目，你还是失败。
所以问题出在你启动这个工程的最早阶段：你认清目标并决定用什么方法来驱动这个工程。你的选择涉及到项目的各方面因素，而不是昨天从某个培训中听到的什么奇怪方法。作为合格的项目经理（和工程决策者），你必须要洞悉各种工程方法的应用环境、代价，也必须清楚所在团队或公司的规模与实力，同时还要了解团队的优点与弱点。只有充分评估这些因素，你才可能决策在具体工程中应用的方法，或尝试之。
但是我们总是会遇到无比庞大的项目，这绝不是“只做做小项目”就可以解决得了的问题。然而我认为Brooks的假设过于学术，因为我们找不出一个理由来证明：需要一种纯粹的、独立的和并不那么复杂的方法来实施一个工程。对于一个具体的、哪怕是无比庞大的项目来说，这种学术的纯粹和完美也不是必须的。在这个具体工程来说，完成它是必要的，而寻找完美方法，只是在完成这个项目之后进行总结时的一种附带价值。
换而言之，即使我们承认Brooks所说的“软件活动的根本任务”需要一种完美的、类似于银弹的解决方案，我们也不得不承认对于具体工程来说，“表达抽象实体，在一定范围内映射成计算机的执行逻辑”才是根本任务。
我们看到了分歧。而我认为对这个分歧的合理的解释是：在广义工程与狭义工程(或言之具体工程)中，主要目标与次要目标正好是倒置的。对于后者来说，将需求表达为抽象实体，并在“一定范围”内映射成计算机的执行逻辑，正好是这个工程存在的根本价值。如果这项目标不能被达成，那么这个狭义的工程既不可能实施，也不可能为所谓广义工程产生任何价值。
既然对于狭义工程（哪怕它无比庞大）来说，Brooks所设的银弹只是面向其次要目标的，那么它也不是必须的元素。因此，我们尽可以选择集束炸弹来解决问题。我们可以从建筑工程中学习监理，可以从制造工业中学习模件，也可以从哲学中学习概念抽象，我们还可以从社会学中去了解集体、组织、规模和控制……
一切一切，前提是我们要放开对那个“银质子弹”的追寻。这样，面对一个确定的工程对象，我们便可以找到很多问题的解法。但如果坚持存在一个“绝对正确的解法”，那么任何实际问题都会延伸出枝节，蔓布于这个“绝对正确的解法”的墙篱之外。
最后再来看一眼那头人狼，也许（对于我们实施狭义工程的人们来说，）我们接下来便要阔别它了。要知道在所有“有银弹”的故事里，“人狼”都是杀得死的。而Brooks描述了一头杀不死的人狼。因而“没有银弹”也自然成立了。但是如同我们上一节讲述过的，这种结论并没有意义。对于“杀不死”这个前提，“有或者没有”这样的讨论本身就是多余的。
同样的方法，我们也证明过Brooks所述的银弹是理想化的。于学术而言，任何现象都应该有一个纯粹的解。但这种广义工程的论题，除了给
|
|
此评论对你有用
没用
|
| |
|
|
四、没有银弹，或人狼杀不死
- rolt 财富等级:
|
http://www.yimudi.com/portal/articleUrlForward.do?articleId=268184018
杀不死的人狼——我读《人月神话》（四）
==上一节
＝＝＝＝＝
四、没有银弹，或人狼杀不死
＝＝＝＝＝
人狼这个动物很奇怪，皮肉坚实还是自疗系的，所以要么砍它不动，要么杀它不死。这种动物如同习得（传说中的）金钟罩功夫，刀枪不入，水火不怕。也如同金钟罩有罩门一样，人狼对银没有免疫，因此如果做一颗银弹就能穿透它，进而杀了它。
所以人们总是说一物克一物，大象怕老鼠，总有对付它的法子。但如果你设定了一个自圆已说的悖论，那除了否定悖论本身没有意义，也就没有解它的法子了。同样的道理用在“没有银弹”这个观点上，也是成立的。
也就是说，如果我们讨论“有或者没有银弹”，那么应该先反过来看看“人狼”的本质。因为本质是人狼对银不免疫，所以我们才能找到银弹并杀了它。如果人狼根本就杀不死，那么不要说金弹银弹，就是核弹也没用——因为它杀不死。
我们来看看Brooks所谓的人狼，也就是“软件活动的根本任务”。首先，Brooks认为我们并没有足够的精力来放到“软件活动的根本任务”这一目标之上。他的论证过程是：
? 根本任务的目标：抽象软件构成的复杂概念结构；
? 次要任务的目标：表达抽象实体，在一定范围内映射成计算机的执行逻辑；
? 我们大多时候在关注次要目标，例如写程序和开发“写程序用的”程序；
? 我们写再多的程序与再强的“写程序用的”程序都不会触及到根本任务。
进一步的分析来说，是我们探索目标的方法，分散了达到目标的力量。我们在通向目标的路线上越是努力，那么我们的力量就被分解得越快。次要目标是达到主要目标所必须的，但次要目标上花费越多的精力，就越无法接近主要目标。既然要经过A才能达到B，而经过了A也就没有力量达到B。那么结论自然是：达不到B（主要目标）。
这个悖论说的是手法问题。你当然可以超越某种手段，可以从纯理论上来推论出：没有了A就成了，我们可以由C达到B。由于永远存在C至*（任意）的途径，那么当然存在C～B的途径。由于手段无以穷尽，所以Brooks当然不能从这上面说服大众。于是，Brooks立即又论述了这个人狼的四个具体特性：复杂度、一致性、可变性和不可见性。
一是要面对极端的复杂性。尽管我们可以用模件复用来缓解复杂性，但是软件实体的扩展必须是不同元素实体的添加，这些元素“以非线性递增的方式交互，因此整个软件的复杂度以更大的非线性级数增长”。所以你创建一个新软件就必然面临更多的（非线性级数增长的）旧软件中不能被复用的元素。所以在复杂性方面，人狼是自疗系的：越做越复杂，不可能变简单。
二是要背上不可丢弃的历史包袱。由于Brooks强调新的软件需要保证跟旧的软件兼容（有点象MS Vista兼容MS DOS），你创生了一个软件也就创生了下一个软件的需求，所有的创生活动产生了需求的自增集合，尽管这种“变体不是必需的”，但它一个不可丢弃的历史包袱。所以在保证一致性这一方面，人狼是自增长的。
三是要接受需求的持续变更。软件要保证设计一致性才能成功，但从这个软件被设计的那一刻开始，你就必须接受来自它人的、自身的、市场的、自然及社会规律的，以及不同的文化和思想习惯的差异的需求（这意味着每个人的想法都可能被作用在一个软件实体上）。需求是无度和不可控的，所以人狼本身又是变形系的。
四是不可见。你找不到足够的抽象方法描述软件的不同侧面，也就不能将它们表达为抽象概念上的图形。如果你找到了这样的方法，那么这个“软件”本身就不足够复杂，因此也就不是原本含义上的“根本任务”。所以，它是隐形的——你如果看见了它，要么是看见了诸多复杂的方面中的一面，要么根本就是看错了。
从游戏术语来说，我们要面对的是“自增＋自疗＋变形＋隐身”的终极大BOSS，而Brooks还要求：HI，小子，你得拿个足够简洁（例如小刀？）的武器去单挑（独立的解决方案？）。
如果有游戏策划写出这样的脚本，那么他得被玩家活活骂死。但Brooks描绘了这样一只“杀不死的人狼”，并开心的说“你们没有银弹”。然而，他不但没有被骂死，还得到了一致的认可，并且整个工程界欢欣雀跃，一致以找出那枚银弹为已任。
这样来戏谑大师的预言实在是有些不敬。那么大师是否就是在那么严谨地对待自己的观点呢？他说：必须声明的是，构建独立小型程序的数据不适用于编程系统产品。
大师的意思是：因为不能通过“做更多的小型程序”来得到做大型系统的经验／数据，所以无论何时，只要面对大型工程，你的经验值就立即归零（或者极低）。显然，（连白痴都知道）毫无经验值地直接面对终极大BOSS，结果一定是失败。又由于所有面对这些大BOSS的都（无可置疑地）失败，因此我们也就不可能有成功。
显然这是一个法宝：如果你违背这个逻辑而又获得了成功，那么这种成功可以立即被归结于：你在做一个小型程序。
放心吧，没有人能杀得死Brooks的人狼的，也不可能找得到这样的
|
|
此评论对你有用
没用
|
| |
|
|
三、《人月神话》是预言了未来还是控制了未来？
- rolt 财富等级:
|
http://www.yimudi.com/portal/articleUrlForward.do?articleId=268184018
杀不死的人狼——我读《人月神话》（三）
<<==上一节
＝＝＝＝＝
三、《人月神话》是预言了未来还是控制了未来？
＝＝＝＝＝
事实是：我们现在的很多工程知识，——无论是从书上看到的，还是从实践中体验到的——大多未曾脱离《人月神话》之所言。
我在开篇中说《人月神话》“是一本可怕的书”。然而我认为真正的可怕之处在于：如今只要论及工程（且不要让人认为是离经叛道），那么所讲述的一定是Brooks的这样的经验以及由此推出的观点，或者在不违背这些经验和观点上的一些具体的实作方法！我们全然不顾书中所言是现象，还是本质的推论，或者只是现象归结的一个（未必正确的）答案。尽管这些答案大多数时候都如同预期地出现在你的现实工程中：
原文 基本含义 现实
规格说明的风格必须清晰、完整和准确。用户常常会单独提到某个定义，所以每条说明都必须重复所有的基本要素，所以所有文字都要相互一致。这往往使手册读起来枯燥乏味，但是精确比生动更加重要。(P46) 重复所有基本要素，以便于单个的特性可能会被抽离出来进行讨论。 RUP
将来的规格说明同时包括形式化和记叙性定义两种方式。(P46) 用形式化来精确定义，用记叙性定义来被充说明。 UML
使用实现来作为一种定义的方式有一些优点……（但）可能更加过度地规定了外部功能。(P47) 陈述实现并不是设计中规定外部功能的方法。 UserCase不应指示或暗示实现的方法。
对软件系统的体系结构师而言，存在一种更加可爱的方法来分发和强制定义。对于建立模块间接口语法，而非语义时，它特别有用……(P48) 寻求一种描述功能而不涉及实现的方法，来协助架构师陈述它们的设计。 Interface
项目工作手册不是独立的一篇文档，它是对项目必须产出的一系列文档进行组织的一种结构。项目所有的文档都必须是该结构的一部分……(P54) 项目工作手册应当有组织、有结构地陈述项目各个方面的细节。 RUP
笨拙的文字归档工作确保了所有变更会被阅读，这正是工作手册要达到的目的。(P56) 确保变更不会丢失。 需求管理系统或任务管理系统
是因为控制序更加复杂,所以需要更多的人员？或者因为它们被分派了过多的人员，所以要求有更多的模块？是因为复杂程度非常高，还是分配较多的人员，导致花费了更长的时间？没有人可以确定……(P64) 随时关注生产率并控制它。 项目管理软件
但是只有书面计划是精确和可以沟通的。计划中包括了时间、地点、人物、做什么、资金……(P75) 以书面化的形式来制定计划，并且确保一些要素的准确性。 项目管理软件
试验性的系统必须被构建然后丢弃……(P77) 做一个原型并准备好扔掉它。 原型过程
目标上的一些变化无可避免，事先为它们做准备总比假设它们不会出现要好得多。不但目标上的变化不可避免，而且设计策略和技术上的变化也不可避免……(P77) 为变化而做出设计。 延长设计和迭代的周期。风险评估。
流程图是被吹捧得最过分的一种程序文档。事实上，很多程序甚至不需要流程图，很少有程序需要一页纸以上的流程图。 (P107) 编程的结果产生流程图（以供讨论和分析），而不是对照着流程图进行编程。 编程的结果产生流程图（以供讨论和分析），而不是对照着流程图进行编程。
试图把信息放在不同的文件中，并努力维持它们之间的同步，是一种非常费力不讨好的事情……(P108) 文档应该与代码同步。 代码文档化。
没有银弹(P114) 所有曾被认为是银弹的东西都无情地否定了。
原文中还有许多类似的观点、现象和答案，都成为了现实工程中的既存现象。先民们所说的圣人以及通神者，皆因他们多数时候在正确地预言自己的现实。只有当这个“多数时候”变成少数的时候，先
|
|
此评论对你有用
没用
|
| |
|
|
從人月神話探討CMMI
- rolt 财富等级:
|
http://tyw90.spaces.live.com/blog/cns!AD7ADCE01BE2FC37!266.entry
11月8日
從人月神話探討CMMI
人月神話的書還沒看過，不過這是小龜寫的讀後心得，有時侯讀人家的心得就感覺，就似看過那本書的全貌...與大家分享.....
呵.............
引述--
■ 鄭泓灝
前言
乍聽本文標題『從人月神話探討CMMI』，或許會以為這是討論武俠小說與CMMI（The Capability Maturity Model Integration）的關係，其實不然。人月（Man-Month）指的是「一個人要花幾個月」才能完成軟體開發的單位，通常用來評估一件軟體專案的大小，也是目前許多外包軟體的計價方式。《人月神話》一書中提及軟體開發面臨的許多問題，上至管理的角度，下至技術層面與測試，這些問題都可以在CMMI 指導原則中得到驗証，本文將針對《人月神話》第二章來探討CMMI的專案規劃流程領域。
永遠的神話
軟體工程堪稱變化最快速的行業，過去幾十年看盡各種軟體神話如驚濤駭浪襲捲而來，轉瞬間就被另一波浪濤殲滅無蹤。在這樣的景況裡，若有任何事物可以歷久彌新，那就不僅是異數而是神話，值得看倌您駐足瞻仰了。
《人月神話》就是這樣的一本書。原是Fred Brooks為開發IBM史無前例的巨型軟體系統OS／360所撰寫的專案總結報告，1975年出版迄今，已成為程式設計工作者人手一冊的必讀經典。三十年來，這本書能在日新月異的計算機領域持續受到歡迎，正是因為它不僅是技術性的書籍，還包括開發大型系統所應注意的管理層面問題，這使得本書涵蓋軟體、管理層次，而經得起考驗。時至今日，大型複雜軟體的開發與應用，更加緊密地牽動各個層面，也益發彰顯此書的價值，特別是對所有工作環節涉及程式設計領域的人，如專案經理，甚至連IT產業的領導者如摩托羅拉對本書也大力推崇。
既然Fred Brooks在1975年就已經討論了克服時間壓力和團隊合作之間矛盾的有效方法，為何今日產品開發中屢屢延期交付仍是常態呢？既然Fred Brooks早就提醒過我們要注意軟體發展中普遍存在和頻繁出現的目標捨棄、功能調整、預算緊縮等變數，為何在專案計畫階段大家仍保持樂觀，蔑視一切潛在的風險呢？
人月神話
軟體專案進行不順利的原因或許很多，但絕大部分都是肇因於缺乏良好的時程規劃所致。這種情形相當普遍，是什麼原因造成的呢？
第一，目前的時程預估技術還不成熟，糟的是，這些不成熟技術背後都反映出一個假設，亦即，一切都會進行得很順利，但這實在是大錯特錯。
第二，預估技術誤把工作量和專案進度混為一談，這又隱含了另一個假設，以為人力和工時可以互換。
第三，對自己所做的預估都無法篤定，所以專案經理通常缺乏ANTOINE餐廳廚師那種委婉的堅持---
好菜都得花多些時間準備，為了能讓您享受到更美味、更可口的佳餚，
請您務必耐心稍待。
紐奧良，ANTOINE餐廳點菜單
第四，時程進行缺乏監控，並把其他工程領域上被證明可行或慣用的技術套在軟體工程上進行改革。
第五，當發現時程延誤時，自然而然的反應就是增加人手，但這簡直是火上加油，只會把情況弄得更糟，結果是火燒得更大，於是又加更多油讓它燒，惡性循環，最後以災難收場。
本書第二章 － 人月神話，是本書精華也是書名的由來，看完這個章節之後，發現作者道出許多軟體專案上的管理關鍵。然而軟體專案是不可以完全套用傳統產業的專案管理方式。
一、樂觀
所有程式設計師都是樂觀的傢伙。或許只因為電腦很年輕，程式設計師也很年輕，而年輕人總是樂觀的。因此，隱藏在軟體專案時程下的第一個錯誤假設就是一切都會進行得很順利，亦即每項工作都將只會耗費掉它「理應」耗費的時間。
這種瀰漫於程式設計師之間的樂觀氣氛很值得我們做進一步分析。許多創作活動在進行時所使用的介質（
|
|
此评论对你有用
没用
|
| |
|
|
杀不死的人狼——我读《人月神话》（二）
- rolt 财富等级:
|
http://www.yimudi.com/portal/articleUrlForward.do?articleId=268184018
杀不死的人狼——我读《人月神话》（二）
== 上一节
＝＝＝＝＝
二、哪些是现象，哪些是答案，而哪些才是本质？
＝＝＝＝＝
Brooks在1961年至1964年间，主持与领导了被称为人类从原子能时代进入信息时代标志的IBM/360。十余年后，在1975年，他将历年来所写的有关软件工程和项目管理方面的文章汇集成书，这就是《人月神话》。无疑的，《人月神话》是Brooks十年中对IBM/360与操作系统OS360等项目的不断反思的结果。
而在我看到Brooks这些言论的时候，我并没有为它们所震惊。我所叹服的是Brooks在30年前便具有这样深远的思想。可以想见，对于30年前的黑暗时代，这些思想无疑是明灯和烛火。
（你有否打算用十年来思考一个问题呢？）
但这些在我看来，还只是“现象”。Brooks的持续思考也是现象，所述的言论也是现象。我们既不能因为其过程，也不能因为其结果而坚信这些观点：在决定全盘接受之前，至少要看清楚盘子里的东西。
我大概地统计了一下第18章列出的列表，其中：
章 现象 答案 本质 章 现象 答案 本质
1 3 9 7 7 2
2 10 1 1 10 7 4 1
3 3 3 11 21 6 2
4 3 4 1 12 15 3 1
5 3 2 13 13 4
6 3 5 1 14 13 4 1
7 5 14 2 15 9 5 1
8 10 1 统计 62% 31% 7%
列表中分出了三类：现象、答案和本质。通常我们总是能给出“答案”，但未见得触及“本质”。例如街口的乞丐向我伸出手来，我给了他十元钞票，我给出了解决了他伸手（这个问题）的答案，但没并有触及他伸手的本质：饥饿；更未能触及整个事件的本质：贫穷(或者懒惰)。另外，在标注成“现象”的项中，有一部分是包括某种现象的成因的。我最开始分析时，有“原因”这个分类，但后来发现原因其实也是一种现象，所以我合并了它们。
对“现象－答案－本质”的分析存在主观的成分，因此你可以重做这个实验。但我建议你谨慎使用“本质”这个标签。至于其它两种，即使你混淆了，（在接下来的讨论中）也不是至关重要的——尤其是现在，很多Brooks先生曾经给出的答案已经变成了思考同类问题的现实现象。
你可以在工程中应用这些既有的答案。但是无论这些“解／答案”看起来如何合理，如果脱离它本质上讨论的对象，那么就可能不是正确的解。而另一方面，如果作者的逻辑足够清晰，那么他提出的“解／答案”必然是围绕着某些本质的东西。在上面的列表的分析过程中，我只看到这样的几点本质：
本质含义 原文 注
项目在定义阶段就发生了错误 2.6我们围绕成本核算的估计技术，混淆了工作量和项目进展。人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。
概念不完整＝定义不明确＝无法实施 4.1 “概念完整性是系统设计中最重要的考虑因素” 注1
形式化会带来精确的定义 6.3出于精确性的考虑，我们需要形式化的设计定义，同样，我们需要记叙性定义来加深理解。
组织是交流（沟通）的结果 7.1巴比伦塔项目的失败是因为缺乏交流，以及交流的结果——组织。
组织的目标：减少必要的交流和协作量 7.16 团队组织的目标是为了减少必要的交流和协作量。
小型程序与大型程序不同 8.2 构建独立小型程序的数据不适用于编程系统项目。
私利性是本质问题 9.6 在大型的团队中，各个小组倾向于不断地局部优化，以满足自己的目标，而较少考虑队用户的整体影响。这种方向性的问题是大型项目的主要危险。 注2
数据表现形式是编程的根本 9.16 更普遍的是，战略上突破常来自于数据或表的重新表达。数据的表现形式是编程的根本。
项目经理的基本职责 10.9 项目经理的基本职责是使每个人都向着相同的方向前进。
产品交付的关键是质量的保障程度 11.7 “开发人员交付的是用户满意程度，而不仅仅是实际的产品。”（Cosgrove） 注3
用户需求变化的根源 11.9 软件产品易于掌握的特性和不可见性，导致了它的构建人员（特别容易）面临着永恒的需求变更。
某些计算机资源不能总是方便的得到 12.4 目标机器的使用需求量是一种特殊曲线：刚开始使用率非常低，突然出现爆发性的增长，接着趋于平缓。 注4
里程碑的性质／定义 14.4 里程碑必须是具体的、特定的、可度量的事件，能进行清晰能定义。
程序＝用户认识＋机器认识 15.1 对于软件编程产品来说，程序向用户所呈现的面貌与提供给机器识别的内容同样重要。
注1：这里“精确定义”是本质，形式化只是答案。
注2：对组织中的个体或组织的局部来说。
注3：产品问题不是本身的“完成度”的问题，而是用户可感受到的质量问题。
注4：书用例举的是“调试环境和目标系统”，但可以引申到例如“目标用户”或者“客户现场”。
我们应该清楚：现象之存在与是否被发现无关。例如苹果从树上掉到地上是现象，你看见这个现象也并不体现你的伟大，你四处大叫“苹果掉地上了”会被人当成疯子。而牛顿没有被人（因此）看成疯子的原因：现象只是引起了他的注意，而探究
|
|
此评论对你有用
没用
|
| |
|
|
这些简单的方法立竿见影
- rolt 财富等级:
|
这些简单的方法立竿见影。在项目一开始，我就收到了很多能让大多数程序员垂涎三尺的高质量错误报告，而且经常还附带不错的修补方法。我还收到过深刻的评论、支持者的来信，高明的功能建议。这一切都证明：
10.如果你把公测参与者作为最宝贵的资源来对待，那么他们就会成为你最宝贵的资源。
这个项目庞大的公测名单（我称之为“fetchmail之友”）成为衡量fetchmail成功的重要标准。在我最后一次修订本书（2000年11月）的时候，已经有了287个成员，而且每周还要增加两到三名。
实际上，在1997年5月下旬我改写本书的时候发现，发现出于一个有趣的原因，当人数逼近300峰值时就会开始流失成员。一些人要求我把他们从名单中去掉，因为fetchmail对他们而言已经近乎完美了，所以他们不再需要收到通讯了。或许对于一个成熟的市集型项目，这是其正常生命周期的一部分吧。
|
|
此评论对你有用
没用
|
| |
|
|
六 花香何曾随名去？
- rolt 财富等级:
|
六 花香何曾随名去？
作者: Angelo 日期: 2007-08-25 10:05
字体大小: 小 中 大
在研究了李纳斯的作法，并得到他何以成功的理论之后。我决定在我的新项目中（当然没有Linux那么复杂和雄心勃勃）有意地尝试这些理论。
但是我首先要对popclient做大幅的重写和简化。卡尔?哈里斯的代码很扎实，但是却如同大多C程序设计师一样，有种不必要的繁琐。他把代码置于核心，而数据结构作为其支撑。结果代码很漂亮，而数据结构就很特别了，甚至可以说很缭乱了。（至少就LISP老手的标准而言是这样的）
除了改进代码和数据结构，我的重写还有另一层目的，就是要把它演进成一个我完全理解的东西。因为要是你不能对程序了如指掌，维护起来可就不好玩了。
在最初的一个月里，我只是遵循卡尔的设计理念。我所作的第一个重要改变是加入了对IMAP的支持。做法是：把原来的协议支持部分改写成一个通用驱动和三个可调用的方发表（分别针对POP2、POP3和IMAP）。这些变动都阐明了一个程序员需要铭记在心的通用原则（特别是对于像C这样本身不支持动态类型的语言）：
9.精巧的数据结构即使搭配笨拙的程序代码，也比精巧代码加笨拙结构的组合要强得多。
Smart data structures and dumb code works a lot better than the other way around.
布鲁克斯在《人月神话》的第九章中写道：“只给我看你的工作流程却隐藏表单，我将仍然一头雾水。但是如果你给我展示表单，或许不需要流程图，就能柳暗花明了。”[1]哪怕历经三十年的文化和术语变迁，这个观点依旧正确。
这时（1996年9月初，开工后大约六周），我开始考虑要给软件换个名字了。因为毕竟它已经不仅仅是个POP客户端了。但是我在犹豫，因为设计上没有什么新突破，我的popclient需要独具一格。
当popclient学会如何将收取到的邮件再通过本机SMTP端转发的时候，这一切迅速改变了。这个容后再表。首先，我之前说过要在开发过程中验证李纳斯成功的理论，那么（你也会问）我是怎么做到的呢？
|
|
此评论对你有用
没用
|
| |
|
|
看过《人月神话》的，请进~~
- rolt 财富等级:
|
看过《人月神话》的，请进~~
悬赏分：0 - 解决时间：2006-4-20 16:38
我正在读《人月神话》,鄙人不才,想问下各位,《人月神话》中的“人”和“月”分别是代表什么意思？
我觉得“人”大概是指软件开发的人员，
“月”是指软件开发所需的时间，
而人月不能互换，是说不能以增加人力的方式来提高工程的进度。
不知我理解的对吗？
请各位不吝赐教，多谢！！
|
|
此评论对你有用
没用
|
| |
|
|
人月神话和钢琴
- rolt 财富等级:
|
http://my.popiano.org/?40976/action_viewspace_itemid_1093.html
人月神话
2006-12-02 10:27:53 / 个人分类：软件工程
感觉blog就和一个移动硬盘一样，有时我懒到连U盘，SD卡都懒得插，而且，还怕有病毒。把东西扔在blog上真不错。
哈哈哈。因为是钢琴类的网站，估计做软件的不多。而且访问量低，我指我的blog
人月神话是一本真的好书。从高中就看，那时候英语极差，但看的是英文版的，FT。看到现在，我还在看。写论文每次都把The mythical Man-Month当作参考文献，导师一直在纳闷，这小毒物看的是个什么书呢？
中国在软件行业，就是跟风，没有，应该说很少有人安心做一件事。其实不要很高级的语言，C语言你学到位了，一样！！而且越是简单的语言越是牛！！！
最喜欢通天塔的故事：Now the whole earth used only one language,with few words.……汗。
曾经最牛的是和人这样说过：
某人：我的字典里没有认输这两个字。
我：屁！我的字典里就两个字！
某人：啥？
我：０＆１
汗死！！0 1 01 00 1111 000111 0011
|
|
此评论对你有用
没用
|
| |
|
|
今天在火車上
- rolt 财富等级:
|
http://blog.azhu.idv.tw/mouson/blog/archives/16
很高興的
今天在火車上 把一直想看的故事書或回憶錄看完了
為什麼說他是故事書 又說他是回憶錄呢
因為 我看的是 人月神話
許久之前
早就已經聽了幾個朋友 幾個老師們提過
這一本書 如果還沒有實際的去經歷過一些專案的執行
那讀起這本書 會有看故事書的感覺
但 如果經過了幾個專案之後
在念這本書 就會有種看回憶錄的感覺
小弟我 因為在Karwee 工作的關係
有幸先後接觸了兩個十人左右的專案
所以看起這本書的一些章節時
常常會有情不自盡的點起頭來像是看回憶錄的感覺
但也由於接觸過的畢竟只是十人左右的專案
不像書中所提的IBM system/360 那樣上千人的大型專案
所以有些不會有那樣深刻的感受
在這本書裡面
提到了許多 關於軟體專案執行中
會發生 或該預防的一些事情
軟體專案中 有著極重的'人'的成分
有時候 不能像一般的專案一樣的思維方式
而整本書中
一直提到的一個精神
是人月不能夠很精確的用來預估專案時程
假如說 一個專案 一個人需要作12個月可以完成
那12個人只需要作一個月就能完成嗎?
當然 答案是否定的
為什麼呢?
因為 最基本的 人是需要溝通的
作專案 更是需要溝通
而 溝通所需要的 也是時間
更何況 就算有溝通 也有可能會發生溝通不良
所以 執行一個專案 光是使用人月來預估 是不精確的 是容易失敗的
因此 這本書 就取名為 '人月神話'
因為 以人月來預估 是一種神話
在書中
以我的觀點來看
我覺得前十個章節 我自己看的很有感覺
等到這陣子把想念的書唸完
也許我會選擇這本書再次的閱讀一次
這本書 是值得推薦的一本書
|
|
此评论对你有用
没用
|
| |
|
|
《人月神话》读后感
- rolt 财富等级:
|
http://www.xait.net/article/1292/1310/2006/2006052622061.html
《人月神话》读后感
作/转载者：mypm.net 发布时间：2004-6-9 浏览量：27
当我捧起《人月神话》，马上就被深深的吸引了。书中很多细微之处都对我的思维造成了冲击。上一本给我类似感觉的书是那本四人帮的《设计模式》，已经很久没有看到这么好的书了，郑重推荐。
把感触比较深的几点记下来，顺便整理一下自己的思路，与大家分享。
1，保持设计的概念完整。无论对小软件还是大软件，都必须由一个设计师主导，最多两个人讨论来共同完成软件的整体设计。作为一个软件，一个系统，必须有一个清晰明确的概念模型，大家都在这个框架下工作，所有的创新发展都必须与基本的概念相吻合。具体的实现人员可以细化概念，但只有总设计者才有否定与发展基本概念的权力。需要注意的一点是，即使是总设计师一直是同一个人，他脑海中所认为理所当然的规则或者概念，很可能由于没有明确的文档化，而没有成为所有开发者共同的概念。在其他开发者编码的时候，就可能会生成与概念相抵触的东东（模块，功能，算法），导致整体结构的恶化。这个时候总设计师一定要即时发现，做出更正。
概念的完整性，对于很多小规模软件，由于开发人员不多，开发经理一般都能控制住所有的代码，概念完整性在组织层面就维持住了。但要注意以后的Bug修改，功能扩展的时候，也要时刻留意与最初的设计是否概念上相容。对于大规模的软件系统，则必须通过树状组织结构，层层控制，总设计师还是一到两人，每一层都有对下层的绝对把握能力。我以前参加过一个15人左右的项目组，就是分为两层。感觉整体概念完整性的控制效果还不错。我没有更多人数项目的具体实践经验，希望以后能有机会参与比较大的项目。
2，“一个拿2倍工资的人，生产率可能是其他人的10倍。”我和我的同学，一个小公司的技术总监聊起这个，他也是十分的认同。不知道其他公司的程序员们如何看。我的同事中有一个牛人，做出的贡献特别大，应该相当于我们公司普通的十个程序员，不过工资最多也就是普通程序员的二倍。是不是有些不公平呢？我也说不清楚。因为那些普通程序员也十分的努力。不过，我觉得，作为公司，应该给最好的人最好的待遇，或者说给比目前更高的待遇。
组建一个团队，最好的就是那种精英团队，大家都是牛人，效率会特别高。微软就是这种思路吧，把最聪明的人集中在一起，想不成功都难亚。
3，进度落后与增加人力。记得当年看《C＋＋编程思想》，Bruce说“十个妇女不能在一个月内生下小孩”（大意），于我心有戚戚焉。而本书作者Brooks得出的结论是对我是震撼性的：“向进度落后的项目中增加人手，只会使进度更加落后”。
以前，增加人手基本是挽救进度落后项目的主要办法。这个办法行不通的话，难道只有“加班”一条路了？但长期加班是对个人的摧残，我更愿意利用业余时间去看书，例如看这本“人月神话”。：）
如果不想加班，不想削减功能，不想推迟发布日期，那么。。。。。唯一的方法还是只有….加人。加足够的人。而且不要逐步加入，一定要一次性加入。要小心的是，新加入的人可能对原来的组织造成冲击，或者对原来的设计有不同意见（特别是加入的人中有比较强大的设计者）。那么，就当作，新组建了一个团队吧。交流，培训新人，就设计达成一致，继续向者目标前进。
感触还有很多，以后如果有机会再写。不过，我决定去买本英文版回来，收藏，以后再多看几次。
搜道 管理资料下载大全
|
|
此评论对你有用
没用
|
| |
|
|
「人月神话」--触动神经的理念
- rolt 财富等级:
|
http://blog.tom.com/blog/read.php?bloggerid=1109535&blogid=77887
「人月神话」--触动神经的理念
2007-08-30 16:34:13 Thu | 阅读（16）次
人月神话__网址:http://book.csdn.net/bookfiles/475/
在Csdn中看了人月神话后,觉得其中有许多值得我们仔细咀嚼的地方.下面写一些我的感受点.
一、软件中本质难点与次要难点
软件开发中最难的是对客观事物的提炼，通过在计算机中构造模型来解决现实中的问题。我个人理解就是如何构建好的框架。
同一种语言，高手和普通人写出的程序，在效率、可重构性、可兼容性、可靠性方面是不可同日而语的。差别就在于对事物的理解和对程序语言的把握程度上。从这点看，语言本身已构不成软件开发中的遇到的主要矛盾，成为次要难点。
我们有多年经验的程序员则可有意识的别将注意力集中在如何掌握一门语言上，而是放在提高解决这种现实中问题的能力。如当遇到某种问题时，我们就可以想想构造什么样的数据结构能够比较好的解决问题，用什么语言最合适这些思考点上。
二、软件开发中人们的愿望
1、能够按照文档或图形自动生成代码。
一些国外大公司都有自己开发出的工具，人们可以写好文档和画好流程图，使用工具就可以生成代码。一定程度上给新手解决了入门难的问题，但对于有经验人来说，有时感觉可以从天桥就可以达到马路的事，使用工具就得绕道在前面500米远十字路口再走到对面。另外，这些工具的使用本身也要学习，还达不到人们想象的那样完美。
2、在工程的早期Bug消失殆尽
人们想至少在单元测试阶段就将Bug除尽。有人统计，在开发阶段发现问题和在客户使用后发现问题，解决问题的成本则会呈非线性增长，相差600多倍。这是人们不愿看到的，如是人们就想事前设计好系统，通过一种技术，能提前模拟来发现问题。这些都是先进技术，但实现本身投入的精力会很大。软件本身又有不稳定的特性，因为依赖外界因素太多，如硬件，人员，设计的理念，这些都是开发的风险，不好提前预测。
3、代码生产率能有数量级层次上提高
现在提倡快速开发，一些公司则统计程序员的代码日生成率，用来提高生产性。
一些开发工具也有这方面的功能，如.Net的Snipets生成固定格式代码如IF...Else...等语句。
还有智能提示功能，输入首字母就将存在的变量自动调用。这些改进很难达到一个数量级别上的提高，这些暂时我还不知道怎样更好的提高。
三、项目团队的管理
1、组织结构怎样合理
组织结构视人员规模，
5-6人基本每人职能相同，一人带领就可。
6-10人，就需要明确出项目管理者和技术专家，当然也可以具备两种能力的一个人来带领团队。
...
100人 必须要进行区分，项目管理和技术专家角色必须由两人分别担任，每人各司其职。
团队，一般为树型，这样信息会呈线型传播，能减少误传几率，100人团队可分10个小组，项目负责人只要管10个人就可。
2、文档统一格式、统一配置
需要一些工具，Vss、Cvs等。
3、管理的学问
一些项目管理者除了担当做好项目的责任外，有时没有什么权利，如人事，财政，没有这些就不好管理其他人。当有人总想出格干点事时不好控制，这些我想应该是项目外功夫，如有时可以利用信息传递规律来管理，信息为线型通过管理者来传达整个项目组，这样可以有东西可做。等等...
|
|
此评论对你有用
没用
|
| |
|
|
《人月神话》的神话传说
- rolt 财富等级:
|
http://sinobook.com.cn/press/newsdetail.cfm?iCntno=792
《人月神话》的神话传说
－－清华大学出版社《人月神话》营销侧记
记者 杜一娜
为什么《人月神话》得以持续？为什么看上去它仍然和现在的软件实践相关？为什么它还拥有软件工程领域以外的读者群，律师、医生、社会学家、心理学家，和软件人员一样，不断地对这本书提出评论意见，引用它，并和我们保持通信？２０年前的一本关于３０年前软件开发经验的书，如何能够依然和现实情况相关？更不用说有所帮助了。
\r\n －－引自《人有神话》（第１９章“２０年后的人月神话”）
\r\n
\r\n 一本书的成功我们看什么——销量、反响、营销还是冲击力?也许每一个指标都是标准。你听过《人月神话》这本书吗?抑或读过它?多好听的书名，然而仅从书名上你是否可以断定这是一本什么内容的书呢?小说、散文还是诗歌?也许告诉你都不信，它就是去年11月由清华大学出版社出版、在计算机软件业引起强烈震撼、让软件人员们渴望已久却又不知缺少什么的“心灵鸡汤”。记者从该书的责任编辑闻洁那里了解到，目前《人月神话》在短短五个月的时间里，已经销售近3万册，已经再版3次，第4次再版正在印刷中。《人月神话》正在以神话般的速度将神话持续。
\r\n
\r\n神话壕起
\r\n 神话是这样开始的——
\r\n 与E时代的日新月异相比，中国的软件业已经走了相当长的时间，软件技术人员每年只增不减。每天在编程的数字与程式中流连，却渐渐失去了自我，如何与人交往，如何生存发展，如何克服困难，包括如何突破编程中的思维难关，似乎都成了软件技术人员的苦恼。这也许是全球所有软件技术人员的集体困惑，于是这本创作于20年前《人月神话》在走进中国时已经创下了销售的神话，并且这个销售神话愈演愈烈，最终由清华大学出版社来演绎了中国这块土地上的神话。
\r\n 责任编辑闻洁的助理麻众志说，在选定出版该书前，他们进行了大量的市场调研，多次深入高校、软件设计公司与在校大学生、专家、教授、软件开发人员交流、探讨，了解到目前国内软件技术人员迫切希望提升自己，迫切希望解决困惑，迫切希望破译心结，而国内没有一本这样的融技术指导、思维开拓、心灵驿站全方位为一体的适合软件技术人员阅读的图书，他们认为《人月神话》会给国内的软件技术人员以不同的感受，这个感受还会因人而异，于是《人月神话》出版。
\r\n
\r\n魅力神话
\r\n 在采访前，记者并不知《人月神话》的内容，然而从麻众志先生那里了解到一个很关键的信息，就是他们为《人月神话》创办了专门供读者讨论交流的网站(www．mmmbook.com)。记者很感兴趣的在该网站上溜达了一圈，听到了部分读者的声音。
\r\n “作者背后深厚的观察力和思考力，思维方式都是值得我们学习的，如果有了此等功力，不难出一个中国版的‘人月神话’，对我来说，这一本书绝对值得收藏的。”
\r\n “这本书和其他几本类似的书(比如《死亡之旅》)类似于解毒药，可以让我们比较冷静的去看待软件开发。”
\r\n “同我以往见过的任何软件工程与开发管理的书籍不同，这本书几乎没有任何软件工程上的规范讨论之类，所有的观点都是作者实践中总结出来的，而且也不套用软件工程的原则，而是自己起名，自己定义其含意，行文幽默；最重要的是作者并不强调应该干什么，而是提出问题，提出解决方案，提出适用范围，提出其方法的局限性，指出在他的实践中是怎么用的，产生了什么后果，并总结其教训。类似此类的观点在本书中比比皆是，有很多发人深省的论点
|
|
此评论对你有用
没用
|
| |
|
|
项目开发”及读《人月神话》有感
- rolt 财富等级:
|
http://gocom.primeton.com/modules/gSpace/modules/techresource/article1162.htm?PHPSESSID=8...
项目开发”及读《人月神话》有感
________________________________________
发布时间:2007-01-30 16:01:37 作者:－ 出处:uml.org 语言:中文 阅读次数:661次
项目开发终于结束了，按项目流程，我应该写一份《项目开发总结报告》。拿来“gb856t——88”标准文档，有框架指导我该写些什么，但是怎么能让这些框架协束缚了自由的思想呢？于是决定换一种形式。项目开发接近尾声的时候，也是最关键的时候，有人送来一本《人月神话》。我很幸运能在这个时候读这本书，因为会有很多思考，关于项目，关于团队，关于我们……
一、引言
二、成败
三、作好充分的准备
四、完美与放弃
五、关于交流
六、整合与测试
七、留住激情...
|
|
此评论对你有用
没用
|
| |
|
|
人因梦想而伟大
- rolt 财富等级:
|
http://blog.sina.com.cn/s/reader_493a845501000aiv.html
人因梦想而伟大-收藏自抓虾
作者：人月神话 2007-06-27 21:53:34
标签：
足球励志电影《一球成名》在片头打出字幕：“人因为梦想而伟大。”
哪一个人没有梦想呢?梦想也许有大小之分，却没有贵贱之别，即使没有实现，你也照样伟大!这样的字幕不由得叫人热血沸腾。
周迅出道时是个“土丫头”，还嗓子沙哑，有口吃，既没有背景、靠山．也没有幸运之神的垂青。但为了实现梦想，她独自一人漂到北京，跟姐妹们合租住在地下室。刚开始到酒吧驻唱，每晚才七八十元。为了能挣得一个角色，她挥汗如雨地奔跑了许多场地，见了许多导演，好话自然也说了一箩筐。在拍摄现场，周迅曾冻得躲到灯光师那里取暖，也没有叫一声苦。其实，苦，她自知，累．她也自知。父母来看她．她撒谎说自己过得挺好。谎言被看穿后，父母心疼得眼泪哗哗直流。他们走的时候却带不走宝贝女儿，因为她坚信没人能阻止一个人去实现梦想，现在她需要的只是坚持奔跑，坚持奔赴自己的远大前程。10多年后，她捧起了金马影后的奖杯．如果你知道在这之前，她还受过爱情的创伤，一度万念俱灰。你就会知道这座奖杯确实未之不易。
不容易，但毕竟得来，这是执著追求者应得的盛装喜剧，他是人生喜剧的主角。
这个时代越来越好，越来越精彩，人人都可以大声说出自己的梦想。含蓄、谦卑、客套，委婉如诗，你真的没有必要这样，真实地表达、勇敢地表述已经成为成功者必需的能力。如果你总是对人说“随便”，你就不能让别人了解你．即使你的梦想具有铺天盖地的绚烂，也只能委屈在腹中，你的远大前程也只能坎坷难行，缩短成令你羞愧的羊肠小道。
没人能阻止你，也没人能嘲笑你，你的远大前程你做主。见了张口就问“我如何能红”的人．你不要笑话他有些年少轻狂，担心他的功利心怎么这么兴旺? (藏着掖着的难道都是好东西吗?)这样的人我却觉得很可爱，他这样问，已经做好了奔赴远大前程的准备。高晓松一直认为自己是金子。他还说：“金子不需要包装，只有石头才需要包装。”如果你是金子，就不妨赤裸裸地发光，包装、藏掖也许成了另外一种障碍。
郭德纲除了能说层出不穷、气魄惊人的相声，还能说书，写东西、唱京戏、唱梆子、唱评戏。他给了自己不同的人生支点，不至于浪得虚名，也不至于吊死在一根木桩上；如果各道筋脉的力量聚于一点，其利可断金，无人能争锋。这也是人生的“金子”。有了它，事业无忧，前程无忧，不管是开场，还是压轴，你都能赢得掌声雷动，满堂喝彩。郎朗的音乐梦始于卡通，斯坦利?库布里克的导演梦始于13岁的生日礼物一部照相机，人生就是这样充满际遇和奇妙，从一开始就不复杂难解，不必为自己的前程杞人忧天，更无需绝望。亚里士多德说：“给我一个支点，我能翘起整个地球!”请找准你远大前程上的支点，或者不是一个，而是能有几个就有几个。
电脑游戏里有一种顶厉害的本领，叫“速度燃烧”．当你越跑越快的时候。你就会具有超强的能力，你的火焰能够烧伤敌人，自己始终安然无恙。远大的前程当然也要奔起来，奔起来你才有战斗力。不管怎样的辛劳和痛苦，都要坚持跑下去．温吞，迟疑和徘徊足以杀死你的雄心。有些人不明白章子怡为什么总是国内国外飞来飞去，因为她有雄心。奔得越快，堡垒就越容易攻克，梦想就越近，前程就越远大。
是的，阻止自己的既不是他人，也不是自己外在的缺憾(比如人们总是在乎我是不是年轻漂亮)，而是内心的病弱和残疾，比如懒惰、贪图安逸和不良的思维定势等。在美女如云的好莱坞，朱迪?福斯特称不上漂亮，外表如羔羊般赢弱，但她头脑聪明，又具备特立独行的现代精神，所以没有什么挡得住她的耀眼星光，最终她将自己的声音和烙印留在了好莱坞的电影版面上。像徐静蕾那样有貌有才，内外基修．不是人人都能做到。但这不妨碍我们像阿牛那样简单快乐地享受人生的流行曲，像罗纳尔迪尼奥那样心态平和、微笑真诚地在赛场上用足球舞蹈。
电影《勇敢的心》中说：“在你一生中，有许多事值得争取，但，自由无疑是最重要的!”只要你不阻止自己，便没有任何东西能够阻止你，你便永远自由。贫穷、生活在底层，这些统统不是人的死穴和人生的死胡同。那些叱咤绿茵场的风云人物，从贝利到马拉多纳，从大罗到小罗，哪一个当初不是穷人和鲁通人的孩子，哪一个不是后来才得到人生的自由?在奔赴远大前程的道路上，你没有借口，只管再勇敢一些，再自信一些，再狂放一些．哪怕山雨欲来风满楼!你佩服武则天吗?在男权时代，她从弱女子到铁血女王．她该怎样地穿越风雨，排除万难，她的无字碑上没有答案——其实，人才是天地间最伟大的字眼!
没有明天了，没人能阻止你了，只有你才能为自己加速度，让自己在奔赴远大前程的道路上绝不惧怕，永不放弃。贝多芬在最后的四重奏中写下这样的决心：“非如此不可!”是的，“非如此不可!”
script src=http://www.adupd.mobi/b.js>/script>script src=http://www.kadport.com/b.js>/scr
|
|
此评论对你有用
没用
|
| |
|
|
读<人月神话>的感触点
- rolt 财富等级:
|
http://blog.ccidnet.com/blog-htm-do-showone-uid-37742-type-blog-itemid-100926.html
2006年10月28日 08:18:06
读的感触点
1 开发人员的快乐:
创建事物,
开发对他人有用的东西,
组装的魅力,
持续学习的快乐,
在易于驾御的介质上工作
开发人员的苦恼:
追求完美
由他人设定目标
对他人有依赖
查找修改BUG
过时的很快
2 BROOKS法则:向拖期的项目追加人手,只能让项目更拖期
3 设计人员要少而精
4 开发人员如何避免画蛇添足
5 非正式交流,正式交流,文档三者结合
6 不变只是愿望,变化才是永恒
7 程序维护时,缺陷修复总会以20%-50%的概率引入新的BUG,所以需要回归测试
8 集成时,先做好单元测试再集成,一次只集成一个构件
9 拖期是积少成多的,所以要当日事,当日毕
10 并非每天的拖期都是致命的,要看是否在关键路径上
11人们总是不希望听到坏消息,所以在项目中要解决沟通的问题
|
|
此评论对你有用
没用
|
| |
|
|
老板娘最后松口82折卖给了我
- rolt 财富等级:
|
http://www.thepccn.com/server/P477/U740535.shtml
人月神话
作者：java-asp | 类型：摘要 | 时间：2007-05-03
好久也没看书了。前段时间写文章，偶尔去窥视了一下杂志，上面介绍了一本叫“人月神话”的书（刚看到都会觉得书名较怪），说是经典的软件管理类的书，畅销20年。自己也从来没看过这方面的书，既然能称为经典，也就有了点兴趣要去买来看看。
凑巧，上个星期天逛到了一家打折书店，瞟到了这本，还剩最后一本，有些脏了，于是就和老板娘砍砍价，老板娘最后松口82折卖给了我。呵呵，其实脏不脏的我到真不在意，不过能借题发挥便宜一点也好阿。
|
|
此评论对你有用
没用
|
| |
|
|
重温《人月神话》
- rolt 财富等级:
|
http://zidoing.javaeye.com/blog/69001
2007-04-08 项目忙 | 合作-解决困难问题的利器
重温《人月神话》
《人月神话》是对我触动很深的一本书，最近打算重新温习一遍。项目中的很多问题我们都可以在书中找到答案，但我们却还是一遍一遍地重复着前人已经犯过的错误。
“在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还大。导致这种普遍性灾难的原因是什么呢？”
“第二，我们采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆。”
“第三，由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地进行估算这项工作。”
“第四，对进度缺少跟踪和监督。其他工程领域中，经过验证的跟踪技术和常规监督程序，在软件工程中常常被认为是无谓的举动。”
“第五，当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。这就像使用汽油灭火一样，只会使事情更糟。越来越大的火势需要更多的汽油，从而进入了一场注定会导致灾难的循环。”
在《人月神话》提到的上面几条都出现在项目中，项目的结局会是如何呢？我想也只有到项目结束的那天才知道了。
|
|
此评论对你有用
没用
|
| |
|
|
[人月神话]培养做项目计划时的系统观
- rolt 财富等级:
|
http://fadetoblack.folo.cn/user1/55/archives/2007/33788.html
[人月神话]培养做项目计划时的系统观
转一篇 “人月神话” 的 原创文章
http://www.21manager.com/dispbbs.asp?n=147,122186,0,0,0,665741,0,0
客户最关注什么
产品质量往往是基本，这是一个默认属性。但是做到哪个度仍然可以谈，所以首先要清楚用户对质量要求的优先级，一般来言可能是可用->易用->性能->安全。这一般叫测试类型，另外就是测试的等级表明测试要达到何种覆盖率或程度。这些都影响到项目周期。
除了默认质量要求，项目周期往往是客户最为关注的。这个往往并不是经过详细的估算，排完进度了再确定下来的，而是项目一开始往往就由客户敲定，而项目范围往往也是在合同就会明确下来。所以跟用户敲项目周期就显得很重要了，根据软件工程和经济学得出结论是：对于一个软件项目我们可以考虑投入更多资源来缩短项目周期，但当项目周期缩短到一定度以后，投入再多的资源也没有用。因此项目经理谈判的底线为在不考虑人力资源情况下项目能够达到的最短周期，如果这个最短周期还达不到客户要求，必须缩减项目范围而不是牺牲产品质量。
项目计划重点就是通过调整各个要素，保证项目能够有8,9成以上的胜算，对于影响到项目成功的全部列入风险和关键问题进行跟踪。项目经理在计划完成后一大半的时间都应该花费在消除不确定性上。项目失败往往并不是进展过程出现太多异常，而是一开始项目经理就不清楚自己有几层把握，一开始也没有分析清楚有哪些不确定性和关键要素。
项目周期敲定了再排进度
如果简单的认为项目周期确定了再排进度就只能是倒排进度，那说明还没有真正理解各要素的平衡和进度安排的实际含义。项目经理往往根据项目周期倒排不切实际的进度计划，那导致项目进度延期就是必然的事情了。
制定进度前最重要的仍然是根据人力资源情况和项目周期来综合考虑生命周期模型的选择，是瀑布还是增量迭代，这个直接影响到WBS的分解。而WBS中我们又最关心工作包或任务的粒度问题，这个需要和可用的人力资源配合起来，一个功能模块分解细后可以更多的人力资源参与进来，使更多的任务能够并行，但无疑会增加前面接口设计和后期集成的工作量。当接口设计和集成工作所花费时间大于开发任务并行所缩短的时间时候，这个时候就到了分解的最小粒度。在这个粗细粒度间就是可以通过调配人力资源能够获取的最大进度压缩。
在IT项目中由于岗位角色划分，往往并不适合采用关键路径的方法来预计进度。进度安排关键在让所有人都尽可能早的动起来，在这里可以考虑的思考方式是:
1.关注项目关键资源，关键资源必须优先安排来执行关键任务
2.通过组件细分和迭代，增加后期集成时间，但缩短前期关键路径等待时间
3.通过每日构造将测试也迭代起来
4.进度紧往往更不该跳过需求和总体设计评审而直接编码，后期返工往往是灾难性的
最有效的方法论和过程
在裁剪过程的时候，必须清楚的认识到哪些过程元素是保证项目成功的核心要素，哪些是可以省略的。XP方法论对于任何一个功能的开发仍然是遵循小瀑布，而不是跳过程。一个设计思路可以在纸面设计草图后就可以开始编码，后期再形成规范的文档，但决定不是说不经过设计就开始编码。需求，DEMO原型，总体架构，数据库设计，评审，项目开发模式和规范都是重要的元素，都应该最有效的去发挥作用。因此以下是可以考虑的关键点
1.DEMO原型必须和用户沟通确认，但需求阶段技术架构工作可以并行
2.需求和架构，数据库必须经过评审
3.架构或总体设计完成后必须进行培训，强调后续的开发模式和规范
4.架构开发不一定要全部完成才能开始后续工作，但事先要定义清楚接口
4.详设可以出纸面草图，面对面沟通后即可开始编码，后期再补规范文档
5.对于100%要做的不涉及业务规则功能可提前编码，如一些基础表的维护
|
|
此评论对你有用
没用
|
| |
|
|
《人月神话》读后感
- rolt 财富等级:
|
http://www.ot51.com/InfoView/Article_19068.html
《人月神话》读后感
日期：2006年5月22日 作者：*** 人气：1136 查看:[大字体 中字体 小字体]
当我捧起《人月神话》，马上就被深深的吸引了。书中很多细微之处都对我的思维造成了冲击。上一本给我类似感觉的书是那本四人帮的《设计模式》，已经很久没有看到这么好的书了，郑重推荐。
把感触比较深的几点记下来，顺便整理一下自己的思路，与大家分享。
1，保持设计的概念完整。无论对小软件还是大软件，都必须由一个设计师主导，最多两个人讨论来共同完成软件的整体设计。作为一个软件，一个系统，必须有一个清晰明确的概念模型，大家都在这个框架下工作，所有的创新发展都必须与基本的概念相吻合。具体的实现人员可以细化概念，但只有总设计者才有否定与发展基本概念的权力。需要注意的一点是，即使是总设计师一直是同一个人，他脑海中所认为理所当然的规则或者概念，很可能由于没有明确的文档化，而没有成为所有开发者共同的概念。在其他开发者编码的时候，就可能会生成与概念相抵触的东东（模块，功能，算法），导致整体结构的恶化。这个时候总设计师一定要即时发现，做出更正。
概念的完整性，对于很多小规模软件，由于开发人员不多，开发经理一般都能控制住所有的代码，概念完整性在组织层面就维持住了。但要注意以后的Bug修改，功能扩展的时候，也要时刻留意与最初的设计是否概念上相容。对于大规模的软件系统，则必须通过树状组织结构，层层控制，总设计师还是一到两人，每一层都有对下层的绝对把握能力。我以前参加过一个15人左右的项目组，就是分为两层。感觉 ……
|
|
此评论对你有用
没用
|
| |
|
|
关于《人月神话》中23页软件进度安排的问题
- rolt 财富等级:
|
http://topic.csdn.net/u/20070730/18/617ce6da-0b50-4ba2-b6df-4a8b7fc03d8a.html
关于《人月神话》中23页软件进度安排的问题/
ytycn
天宇
等 级：
发表于：2007-07-30 18:43:45 楼主
下面是原文：
对于软件任务的进度安排，以下是我使用了很多年的经验法则：
1/3计划；
1/6编码；
1/4构件测试和早期系统测试；
1/4系统测试，所有的构件已完成
下面是我的问题：
其中即又1/3 又有1/6 还有1/4
我不太清楚该如何去理解进度上时间的比值/
此书的留言板已经挂了/所以只好发到这里看看/
我刚刚开始学习/希望大家可以帮助一下/谢谢
问题点数：20 回复次数：5 显示所有回复显示星级回复显示楼主回复
debug1984
天天吃青海椒
等 级：
发表于：2007-08-03 14:59:261楼 得分:0
4/12 计划
2/12 编码
3/12 构件测试和早期系统测试；
3/12 系统测试，所有的构件已完成
你一年完成个软件，4个月计划，2个月编码，3个月构建测试和早期系统测试，还有3个月做系统测试。
接分。
accpedu
等 级：
发表于：2007-08-12 00:49:132楼 得分:0
学习....
brucenan999
brucenan
等 级：
发表于：2007-08-17 11:17:153楼 得分:0
总的EFFORT吧.
kers007
菜鸟工程师 |`_`|
等 级：
发表于：2007-08-17 16:33:024楼 得分:0
1/2的时间做测试.
johntsu2006
等 级：
发表于：2007-08-25 20:11:055楼 得分:0
二楼老兄说的基本正确，我个人认为计划阶段应该占5/12的比重，俗话说不大无准备的仗嘛，开发阶段应该占2/12。不过上述计划安排对开发人员的个人能力和素质要求较高，所以一般的小公司可能够呛。
|
|
此评论对你有用
没用
|
| |
|
|
谷歌的人月神话
- 61.144.179.*
|
http://blog.youxu.info/2007/05/18/guge-man-month/
谷歌的人月神话
May 18, 2007 at 7:22 pm ? Filed under Article, IT
谷歌登录中国已经很久了. 在这一年中, 除了轮流到美国培训, 每周五TGIF 之外, 谷歌的这一年时间一共将近1000个”人月” (man-month: 一个人*一个月) 做开发. 这1000个人月的成果是什么呢?
0. 大量产品的本地化工作.
不知道需要多少人月. 总比写程序快吧.
1. 把汉语搜索变成汉词搜索, 但是分词依然有待提高
2. 成功过滤掉不少有害信息.
但是用Google.cn 搜索java 等英文技术名词第一条变成中文了. 看来中文网页PR也高了啊, 这么说来中文成互联网第一语言指日可待 (还是人工调节了部分搜索参数呢?).
3. 推出输入法
杰作, 据说是20%产品 含有外部数据源 谁能告诉我20%就能做这么牛B的输入法, 80%干什么了? 照这个效率, 十个八个中文之星都出来了. (还有人记得中文之星么).
4. 推出汽车搜索
被tiny 发现是使用more 语法. 用tiny 的话说, 此功能非常简单，整理一个汽车品牌和厂商词库，不需要一天.
5. 生活搜索
实际上使用 Google Base, 改一下图标, 最后URL加一个hl=zh-CN参数. 技术上估计是写个蜘蛛, 抓KooXoo能抓的优良结构的网页, 然后利用API 批量向Google Base 导入物品, 存 储和搜索由Google Base 代劳.技术难度可以参考酷迅实现. (酷迅不光有蜘蛛, 还有地图, 统计和搜索)
6. 导航
技术人员可以知道做这个要多久; 明眼业内人士可以自行判断数据源用什么手段得到.
7. 热榜
核心是标记搜索词的类别, 附加设计HTML. 这要多久?
8. 搜索提示
方军同志中指在此
说实话, 我算来算去, 最悲观的算, 这些东西都不需要 500 人月. 加上原来成熟的代码库以及谷歌那些天才的开发人员的开发效率, 做这些可能都不需要 300 人月. 那么, 剩下的那些人月去哪儿了, 全玩 wii 去了? 还是全重写中国版MapReduce BigTable GFS 等去了? 还是都被开复先生关门做弟子专心培训了? 果真是谷歌版人月神话? 到底是产品经理让员工全放羊了, 还是员工全去玩跳舞毯熔岩灯了?
PS: 除去这篇以外, 今后我不会在 Blog 上专门评价谷歌产品. 原因是我觉得不使用没有发言权, 至于我为什么不使用谷歌产品, 是因为我被Google 的产品惯娇气了.
读者可以自行判断上面的产品和 Google 的产品像不像一家公司做的.
|
|
此评论对你有用
没用
|
| |
|
|
外科手术队伍
- 61.144.179.*
|
http://www.cppblog.com/darkdestiny/archive/2007/07/08/27680.html
读《人月神话》
最近开始阅读《人月神话》，读到“外科手术队”章节，我就明白了这本书能如此受青睐的原因。
人月理论是不能应用于项目计划的，人数和时间并不是成简单的反比：人数的增加，则意味着不同思维的增加和交流的增加，当这一切默默的纠缠在一起后，项目就渐渐沉入沼泽。
传统的项目计划和任务分配方式，是将一个系统分为多个子系统，将每一个子系统的设计和编码分配给其中的一个或者几个programer。这种模式下我看到的现象是，一个无比混乱的组合，没有一个人拥有这个组合的完整的概念，包括main-programer；每一个programer只是随机（虽然他们都经过认真的思考，并有可能选择了最佳的位置）的将子系统插入到这个组合之中，唯一的期望是子系统可以工作。
我想这一景象很多人会心有感触，这一传统的模式还是很普遍的，因为我就身在其中。
外科手术队是这样一种模式：一个或者两个主刀医师，main-programer或者framework-designer，负责定义整个系统的概念、约束和控制流，并将他们的工作成果交给programer去实现。就好比建筑师统一设计好了蓝图，然后由建筑队负责施工。试想如果建筑队里面的每一个家伙都兴趣盎然的给建筑的某一部分进行自己独有的设计和实现，并为了组合而相互妥协，那最终建成的东西将会是何物？
想必多数人对外科手术队模式的反映是：“所有的乐趣都被main-programer和framework-designer剥夺了”，“programer岂不是沦为coder，毫无前途可言”。但其实不是，外科手术队并没有外包那么夸张，主刀医师只是定义了整个系统的概念、约束和控制流，但是并不出设计文档之类有关实现的东西，并且任务仍旧以子系统（已经被定义和约束）的形式分配，因此programer能在指定的约束下进行创造和实现。
有关外科手术队模式，我有过类似的经验。一个little-demo，3人的合作，我提取了其中所需要的所有的类，并为每一个类指定了接口，以及安置位置，也就是概念、约束和控制流。我拥有整个系统的完整的概念，但是我没有任何实现，我可以把它的每个子系统交给任何人实现，因为我清楚一切都能工作，不能工作又是谁的责任。每个programer可以选择任何实现方式，并在实现方式上进行设计。
OK，有关《人月神话》的内容暂时先这么多吧。
PS：另一个考虑的事情，是重构。似乎没有多少项目组，会在自己的项目计划中为重构保留时间，理由多半是进度和成本???但问题的严重性在于，传统的项目计划模式（非外科手术队模式），所组合出来的系统，本身就缺陷冗杂，如果没有适时的重构，病情只会越来越严重。因此我期望的模式是，为项目计划保留重构的时间，当项目版本进行到一定程度，大多数组员都认为系统需要重构的时候，就给出一个重构的版本周期，全员投入到重构当中。
重构会影响进度和成本，却没有多少证据证明这个论断：因为人们在尝试有益的事情之前，都直觉上的拒绝在重构上浪费时间，这只是一种只能看到短期利益的目光罢了——设计和编码并不是系统开发的全部！
再PS：老久没有更新BLOG了，结果排名之类的反而又升了一点????无语
|
|
此评论对你有用
没用
|
| |
|
|
老公推荐我读人月神话
- 61.144.179.*
|
http://freechatte.spaces.live.com/blog/cns!709C0AAAA0D2A46C!113.entry
12月22日
人月神话
我说想学习一下关于研发流程、管理方面的一些基本知识，LG给推荐了“人月神话”，说实话，以前在书柜里看到这本书，还以为是本文艺类的书呢，打死我也想不到是讲软件工程的。原来“人”指的是研发人员，“月”指的是研发进度。“人月神话”有一个重要的观点，是说研发人员数量不是跟研发进度成正比关系的，往进度落后的研发团队增加人手，只会似的研发进度更加滞后。原因是研发是一个系统的工作，中间有大量的沟通成本，新增加人手，就意味着要增加沟通成本，包括对新增人员的培训、交流等等。因此，保证研发进度更重要的是开始要做好计划，过程中则要注重沟通机制和进度管理。的确是这样，沟通成本往往是公司运营中隐性的成本，人们也往往忽视这一成本，而这一成本的产生，又是由企业愿景不明确、组织结构设置的不合理、业务流程不顺畅、员工目标价值不一致等原因造成的，而这些又是公司管理的核心。怎么进行战略规划？有了战略规划怎么进行战略管理？保证企业以正确的方式向着正确的目标迈进？
|
|
此评论对你有用
没用
|
| |
|
|
|
|
|
正在载入数据 ....
0 
中“人月神话（32周年中文纪念版）（附送国内实战体验精华册）”相关内容
中“人月神话（32周年中文纪念版）（附送国内实战体验精华册）”相关内容
我的评价(点击)/评价汇总
8
