Tom Demarco 软件工程领域权威，软件团队管理圣经《人件》作者，IEEE会士，1986年Warnier奖得主，1999年Stevens奖得主，大西洋系统行会负责人。曾任职贝尔实验室，是结构化分析与设计的创始人。
    Peter Hruschka 嵌入式实时系统设计和分析专家，用于系统架构文档的ARC42模板开发者，大西洋系统行会负责人。
    Tim Lister 软件团队管理圣经《人件》作者，风险管理理论的狂热爱好者。大西洋系统行会负责人。
    译者简介：
    金明，Thought Works高级咨询师，Info Q资深编辑，SCJP，系统分析师。在企业应用开发领域拥有多年项目开发经验，专注于敏捷原则与方法的理论实践和指导咨询。是敏捷和精益方法与思想的坚定追随者。目前主要关注于大型企业的敏捷咨询、Java／EE、Scala、REST、Web Service以及HTML5。多次在软件开发者社区的活动中发表演讲。译著有《软件开发沉思录——Thought Works文集》、《卓有成效的程序员》等。同时在《程序员》和Info Q上发表过多篇论文。

    《项目百态：深入理解软件项目行为模式》介绍了软件项目行为的86个模式，基本上概括了软件项目生命周期的方方面面，揭示了软件项目最常遇到的困境，反省了行业内种种不良习惯和做法。六位作者均来自一个开发咨询的管理团队Atlantic Systems Guild，长期以来为众多软件公司的经理人提供专业的咨询服务。他们浓缩了成百上千个项目管理的案例，通过《项目百态：深入理解软件项目行为模式》中一个个模式展现出来。每个模式都以生动形象的插图开始，另外还加上一些趣闻和真实事件。 《项目百态：深入理解软件项目行为模式》适合所有软件项目的管理者阅读，也适合有志于成为软件管理者的人参考。

    “只要参与过一两个软件项目，就一定会对书中介绍的情景深有感触，也必然会从中得到经验教训。” 
    ——Joel Spolsky，《软件随想录》作者 

    “作者以十足的幽默感和深刻的洞察力写就此书。本书清楚地讲述了项目因何而失败，有何补救措施，并以非常友善和令人乐于接受的方式提出了切实可行的建议。” 
    ——Warren McFarland，哈佛商学院教授 

    “对于任何一位曾经在组织里面从事过项目工作的人来说，86个项目模式熟悉得令人心惊。幸运的是，其中有一些模式是良性的，应该给予鼓励。然而悲哀的是，剩下的绝大多数模式不仅仅令人心灰意冷，而且它们对生产率、质量和项目团队士气的破坏程度令人瞠目结舌。” 
    ——Ed Yourdon，《死亡之旅》作者 

    “这本《项目百态》就是关于项目管理的实话集……读这样一本书，你会笑，更多的时候你会摇头苦笑，甚至如芒在背。” 
    ——熊节，ThoughtWorks中国公司首席咨询师，《重构》译者

    在组建项目的时候，目标就是更改某些系统、某部分工作、产品或者服务的状态。这一点是很明显的。
    然而，一旦项目开始，期望每个人或者每群人都准确地知道理想的未来状态会是什么样子，这是不现实的。
    例如，在项目的起始时刻，构建者期望用户完整、精准地列举所有的需求，这是不现实的。类似地，消费者也几乎不能期望构建者在分析完条件之前，就可以理解需求。在不理解需求的情况下，改变的努力几乎总是折戟沉沙。
    问题通常在于利害相干人不明白他们必须向其他人学习。在消费者与构建者之间必须互相教学。每一方都必须教导对方，并向对方学习。
    让我们更具体一些来看。需求收集者需要研究消费者的工作，才能确切地指出有效的产品或者服务。然而，有三个障碍也许会阻碍消费者把他们的知识传递给构建者。首先，消费者可能太熟稔于他们的工作，以为一切都是不言而喻的——他们未能提到细节（他们以为构建者已经知道了）。其次，消费者并不一定具备良好的沟通技巧，可能对主动提供有助于构建者的信息变得不耐烦。最后，消费者可能在确认或预料他们未来的需求方面存在困难。在我们看到实物之前就清楚我们想要什么东西，这是非常困难的（甚至是不可能的）。
    想一想漫步于书店的经历，你可能会突然发现自己对某一主题的某本书很感兴趣，而你先前却从未考虑过这个主题。或许你并不经常浏览书丛，那么想象一下在你最喜欢的购物类别里面发现一款令人激动的商品——也许是一件时髦的电子器件或者梦幻般的女士内衣。（读者请基于自己的性别进行选择。）简单地说，在知道某些东西是否符合自己的需要和目标之前，我们很可能要先观看或者体验一下。
    所以，如果构建者必须向消费者交付如同书籍、电子器件或者女士内衣一样令人愉悦的产品或者服务——而预先又不知道产品或者服务的特征，就必须有双向教学的过程。不幸的是，有一些障碍往往会阻碍消费者和构建者进行有意义的学习：已签署的规格书、误导性的解决方案、关闭的学习之门以及通用语言的缺失。我们将在后面讨论这些。
    有些组织坚持在任何开发活动开始之前都要签署需求规格书。规格书通常由主要的消费者签署。由于主要的消费者将对规格书全权负责，他自然而然会去强行指定。这使得需求收集者的角色退化成抄录员，阻碍了本应基于早期原型和探索性模型进行发现与学习的过程。
    互相教学也可能会因为误导性的解决方案而受到阻碍。有些利害相干人把自己摆在知自己之所欲、而且该欲求终归会满足的位置上面。在这样的情形下，他们想要的就是对于当前问题的直接的解决方案。但是，那些解决方案很少能够解决大量更大的需求——那些关乎工作条件、承担工作的组织、组织之外利害相干人的需求。在这样的情形下，每个人都需要理解问题本身，做到了这一点，解决方案迟早会出现的。
    学习最好是及早开始。随着项目进展，想法开始定型，期望更加不容易改变，曾经谈论的解决方案越来越富于预见性。对于构建者和消费者，打破这一切并就他们想要的产品或者服务学习新的东西就变得越来越困难。一旦错过早期的机会，需求提供者和需求收集者的传统角色就变得更加根深蒂固，创新就变得难上加难。
    ……

模式1 玩的就是心跳 
模式2 快，赶上 
模式3 死鱼 
模式4 欢乐的鼓掌会议 
模式5 保姆型项目经理 
模式6 牵涉性疼痛 
模式7 明日复明日 
模式8 眼神交流 
模式9 情绪戒指管理 
模式10 忠实信徒 
模式11 出租灵魂 
模式12 系统开发旅鼠周期 
模式13 清空“板凳” 
模式14 面对面 
模式15 我给了你凿子，可你为什么不是米开朗基罗 
模式16 主面板 
模式17 无休止的集体会议 
模式18 幼犬和老狗 
模式19 影评人 
模式20 单一问责 
插曲 项目秘密 
模式21 苏式风格 
模式22 自然权力 
模式23 万籁俱寂的办公室 
模式24 白线 
模式25 沉默即同意 
模式26 稻草人 
模式27 伪造的紧急性 
模式28 时间清除了你的手牌 
模式29 lewis与clark 
模式30 短铅笔 
模式31 节奏 
模式32 加班预兆 
模式33 扑克之夜 
模式34 错误的质量关卡 
模式35 测试之前先测试 
模式36 苹果酒屋规则 
模式37 说，然后写下来 
模式38 项目中贪多求全 
模式39 巨神阿特拉斯 
模式40 所有人都穿着衣服是有原因的 
模式41 同事预审 
模式42 浮潜与水肺潜水 
模式43 一切都是该死的接口 
模式44 蓝色区域 
模式45 消息美化 
模式46 慢慢地道出事实 
模式47 残局游戏 
模式48 音乐制作人 
模式49 记者 
模式50 空椅子 
模式51 我的堂兄文尼 
模式52 特性汤 
模式53 数据质量 
模式54 本 
模式55 礼数小姐 
模式56 全神贯注 
模式57 “棒球不相信眼泪！” 
模式58 铁窗喋血 
模式59 按期交付，每回都不例外 
模式60 食物++ 
模式61 没人在意的交付物 
模式62 隐藏的美 
模式63 我不知道 
模式64 乌比冈湖儿童 
模式65 互相教学 
模式66 意气相投 
模式67 十字槽螺丝帽 
模式68 可预测的创新 
模式69 玛莉莲？明斯特 
插曲 剪辑掉的底片 
模式70 布朗运动 
模式71 大声地、清楚地 
模式72 安全阀 
模式73 巴别塔 
模式74 惊喜 
模式75 冰箱门 
模式76 明天会是晴空万里 
模式77 堆积 
模式78 变更时节 
模式79 造纸厂 
模式80 离岸荒唐事 
模式81 作战室 
模式82 什么味道 
模式83 不从教训中学习 
模式84 不成熟的想法神圣不可侵犯 
模式85 渗漏 
模式86 模板僵尸 
照片授权说明