作者：微软MVP 胡百敬 来源：胡百敬(Byron_Hu)

多年顾问经验告诉我，IT 产业应以「人」为本，经费、设备、软件都是其次。但缺乏有力的数据、广泛而深入的理论分析左证，难有什么说服力。读到 Peopleware 一书后，觉得这是每个 IT 从业人员都应阅读的一本书。它清楚解释了靠脑力工作的产业特殊性，大量制造的一致化在此并不适用。两位作者透过亲身经历的小故事，以风趣但尖锐的笔调，直指普遍存在对知识工作者的管理弊病。从适于大脑工作的环境，到群体间的政治，在细微处体贴人心，引领出乐在工作的团队。

现今，大部分对于脑力密集产业所持有的管理概念多习自工业革命后的大量制造，只会紧紧控制众多劳力的「身体时间」，未能激发「脑力时间」。但从事知识工作，应在项目规划时，尝试评估所需的「有效脑力时间」，而非粗糙的劳力时间--「人/月」，这种只要人在就有产出的生产模式，不适用于脑力工作。

多数管理者视提升脑力素质的费用为支出，而非投资，导致不珍惜已经养成的团队成员，任意裁撤或驱使其离职，以降低成本。但罔顾再在新人身上重复支出的养成费用，低估未进入状况的大脑对团队之杀伤力。

脑力工作是在彰显人的价值，强调「个体」的特殊、无可取代性，而管理者需培养出团队文化，身处其中的荣誉，促进敬业乐群的气氛。其依凭的不是职位所赋予的权威，而是出自内心的关怀、同理、信任和尊重。当个人的价值与工作、团队相契合时，对养成员工所花之费用才是投资。当然，有棱角的个体与企业自然契合是运气，上位者需要允许；甚至鼓励共有特质的强化，让成员乐于融入其中而淡化调适习性的难过。

为成员的切身着想，尝试替他解决不利于思考的问题。书中特别强调营造工作环境，例如纾解压力的空间配置，隔绝噪音，适于团队交流的办公室隔间…等。由于进入专注思考的神驰(flow)状态不易，需要持续 15 分钟以上才能进入，但随便一个电话铃声，老板呼喊，同事聊天，都会将神驰状态破坏殆尽。此起彼落的状况，常让大脑一整天无法有质量地运作。作者提出了有门、有窗、有权力自由布置的脑力工作办公室。但他也知道在成本压力下，大多近乎神话，因此提出了大量退而求其次的方式。

我们大都同意现今企业的竞争力来自于创意，尤其 IT 团队需要有高效率、质量与可实践的创意，促成个人凝结成团队，让团队欣欣向荣。这需要的是激励、触媒，而不是高压和制式。要找出个人愿意融入团队的方式，有完成项目的荣誉与自我成就感，让人欢娱才有创新，才会发挥脑力，而非仅为了薪水让身体绑死 8 个小时，但脑子仅做僵化的反射。

创意来自于个人，但团队可以激发创意，并让创意产生力量。在新的世代我们需追求的是个人、团队、部门到企业的全面成功，不应该为了任一环而牺牲其它环节，否则成功都不会持久。若管理者掐紧的是同仁出现在眼前的工作时数，计较省了多少培育或激励士气的费用，只想准时完工却不了解质量，让工作气氛是莫可奈何听命行事，则不用奢想创意。同时，奠基于知识的创意才有可能实现，而组织学习决定知识深度，组织学习同时受限于是否有能力把人留住。

作者于书中一再歌咏团队，期待营造集体的智慧。强调知识团队需要的是触媒、凝胶，尽量降低统治和强迫，鼓励变化和允许犯错，以塑造利于自主、创新的环境。虽本书初次出版距今近30 年，但仍畅销热卖。与人月神话(The Mythical Man-Month作者Frederick P. Brooks, Jr.)并称 IT 项目管理的经典。透过时间锤炼，证明基本人性并没有多大的变化，这益发凸显了本书的价值。

若你从事的是知识工作，以脑力为主，不管是何种职位都适合本书。最好是组成读书会，让团队成员藉由讨论此书而形塑内部文化。尤其推荐 Agile 软件开发的拥护者研读此书，因为它说明了为何 Agile 比 CMMI 贴近人性。

书籍内容

本书以 34 篇短文集结而成，主要分为五个主题探讨：
第一部分讨论对「人」的「管理」

本章中揭示许多引领人性的基本，强调：「管理者的工作并不是叫人去工作，而是创造让人想去工作的情境」。其促成：自我期许 -> 卓越质量 -> 成就自我的良性循环让人向往。

作者阐释承袭自制造业的管理哲学用在脑力密集产业的误谬，说明标准化做汉堡、卖汉堡的管理模式只会打击士气，把人看成生产在线的零件，随时可以谈个价钱替换新品。看重以物理动力驱动物质，追逐市场吹嘘有如神兵利器的新技术，僵化施行削减成本，最大化劳力的管理，淡化人之为人的核心价值，终导致缺乏来自「心」的动力，让项目冰冷进行，其产出的成品因缺乏人性而平淡，甚至充满着无心与无奈所埋下的错误。

在诸多小故事中，节录我最深刻感受的部分：
这才是管理
某个下雪天，我拖着病体，组装一套供用户简报之用的破烂系统，莎朗进来发现我在操控台前勉强支撑，她便离开了。几分钟后，端着一锅汤回来，为我倒了一杯，我的精神为之一振。我问她要做的管理工作那么多，怎么会有空做这种事，她向我展露她的招牌微笑，说：「汤姆，这就是管理」。
 
第二部分讨论适于人工作的「环境」

此部分强调的是：避免让脑力工作者处在难以聚精会神的工作环境中。管理者需提升的是正常工作时间的「质」，而非延长工作时间的「量」。在延长的时间中工作，只会让人妥协，放弃理想与质量，并因劳累，涣散而埋下更多错误，诸此种种都将增加更多的工作量。

由于大部分 IT 部门难有营收，因此管理者都执着于省钱。导致团队成员多在嘈杂、拥挤、空气不佳的场所工作，让人难以专注。作者为此疾呼：「改善工作场所是最有助于提升生产力的手段…一个安静、宽敞、隐私的工作环境，是否有助于你现有的员工把工作做得更好，或是帮助你去吸引和留住更好的人才？」
而什么是比较合乎人性，不会遏止创意的工作环境呢？作者引证心理与建筑学，提出了许多有趣的建议。最终，或许需要思考本书引用的考据：「程序设计师之间存在 10 比 1 的生产力差异…同样，软件公司间也存在着 10 比 1 的生产力差异」，而你期待的团队生产力为何？
 
第三部分讨论找「对」人并留住他

本部分开宗明义点出：「就任何工作的最终成果而言，由”谁”来做总比”如何”去作的影响还要大」。笔者有同样的经验，十几年下来，我不怕问题，只怕处理问题的人。是化险为夷还是乱七八糟，就看谁在做。

作者道出成功的重点公式：
    * 找到适任的人
    * 让他们快乐到不想走
    * 放手让他们发挥

管理者需要将才，而非奴才，他的资源是团队，而非职位。有自信的管理者不要求表面的一致，而是鼓励差异化，让团体内各个头角峥嵘。若管理者要靠规范，藉服从来赢得自信，只会空洞地批判，如说人不专业、不合规矩、服装不整等，他只适合管机器或当纠察队。

在此部分，作者视人如宝，从如何挖掘、雕琢、持有到让其释放光芒都有精辟论述，其所针砭的观念如离职率、永续、方法论、文件、高科技…等，再再都需要我们重新检视对该议题的态度，什么是真正的需要而非盲从。
 
第四部分讨论培育团队

现今的 IT 问题日益庞大复杂，要靠优异的团队而非个人，而贯穿这整本书的就是营造好团队，让好的群我关系，同时成就企业、团队与个人。作者在这一部分举了好团队的实例，破坏团队的管理方式，型塑团队的小技巧，乃至于管理者的心胸。

经理人要经营的是团队的活力和热情。而团队的凝聚力可让心理得到满足，淡化金钱、地位、升迁的需求。其指标是离职率，其内涵是文化。文化需要管理者小心播种、孕育，营造气氛与散布机会。
 
第五部分讨论提升工作乐趣

愉悦地工作才能持久，持久的好脑力才能有好成果。作者为了增加 IT 工作的乐趣，提出寓教于乐的「建设性地制造少量混乱」，列表如下：
    * 先导专案
    * 竞赛
    * 脑力激荡
    * 紧张刺激的培训经验
    * 训练、旅游、会议、庆祝以及关闭

除了期盼或寻觅自己安身立命的好环境外，作者最后鼓励你成为自由人，让自我期许高过管理者对你的期许，同时挺身而出，唤醒大家对价值的再造。

本书另有第六部分，是两位作者在 20 年后，为新出的第二版所做之补强。提出破坏团队的因子、软件流程与 CMM 的省思、改变与进步、人力资本在项目进行中的配置、中阶管理层的组织学习……等值得玩味的议题。例如，作者提出：为了保证项目后期撰写大量程序代码与除错的人力够用，让初期就配置了过剩人力之问题。但如何解呢？这似乎需要你自己找解答。

这是一本满载幽默，妙趣横生的书。作者旁征博引，译笔行云流水。在会心微笑中读毕此书，深觉工作就该如此，也让我得以描绘 IT 人的桃花源。

本文系熊节为《Programming Ruby》第二版所作的推荐序。

根据我的观察，习惯于Java或者C#的程序员在初初接触Ruby时，最能打动他们的往往就是像本文标题这样的一句代码：原本熟悉的字符串或者整数突然摇身一变，有了很多新的行为，甚至让整个Ruby语言都似乎变了个样。尽管“改变标准库的行为”并不总是值得推荐的做法，但如果使用得当，你能够在Ruby的基础上创造出一种贴近项目需求、易写易读的方言——也有人把这些方言叫做“领域专用语言”（DSL，Domain Specific Language）。更多的程序员是因为Rails这个框架才开始对Ruby语言产生兴趣，而Rails在很大程度上正是一种针对Web应用开发的DSL。

能够创造DSL，这是Ruby语言最大的魅力之一。但仅仅这一点并不足以解释为何有那么多优秀的程序员如此盛赞Ruby语言，更不足以解释为何它会突然间红透半边天——毕竟，在元编程方面更具实力的LISP和Smalltalk并没有像如今的Ruby这样流行。作为一个Java程序员的Mike Clark给了我们一个有趣的比喻：推绳子——他说“读了仅仅几页 Programming Ruby之后，再使用Ruby之外的语言编程感觉就像是在‘推绳子’（push rope）。”把一根软绵绵的绳子往前推，那种有劲使不上的感觉，正是用惯Ruby之后再回到Java/C#时的真实感受。

灵活、优雅、巧妙、便利……这些溢美之辞我们已经听得太多了。但在我看来，Ruby最大的特点就一个字：快。这不仅意味着你能够很快地为自己的问题找到现成的解决办法，更意味着你能够直观地描述自己心中的想法，并且在改变想法时能够很快地调整你的程序。这种能力对于今天的软件开发者而言显得尤为重要，因为世界在飞快地改变，软件项目的需求在飞快地改变。对于今天的软件客户来说，尽快得到可以工作的软件、尽快反馈、尽快看到调整的效果，比一个完美但尚未实现的设计要有价值得多。而Ruby这种“快速实现想法”的能力，正是众多开发者对之青睐有加的根源所在。

Ruby能够帮你描述心中所想——这句话，在某种意义上，也意味着你需要熟悉Ruby的思考方式。尽管自称是面向对象的脚本语言，Ruby的精神仍然与函数式编程（functional programming）一脉相承。这种精神不仅体现在语法层面上，还体现在构建系统的思路上。Ruby社群很少会一开始就把要实现的目标想得清清楚楚、或是首先制定种种规范标准，相反，他们会充分利用Ruby的灵活与简洁、优雅与巧妙，从一个简单的、能够工作的软件开始，逐步增加更多的功能，并通过不断重构和优化让良好的设计逐渐浮现。

是以，跨进Ruby的世界，也许你首先需要学会的是这种“渐进式”的思维方式——不仅仅是编写软件，就连“学习Ruby语言”本身也是一样。你不需要读18本书或者参加半年培训来学会Ruby编程——另一方面即便你这么做了也未必就能学会，如果你没有使用Ruby来编写真正有用的程序的话。所以，如果你对Ruby产生了兴趣，稍微了解一下，然后就开始写吧：把编写shell脚本的首选语言从Perl改为Ruby，用Rake来构建你的项目，或者——像大多数人那样——用Rails来开发一个小网站。你会遇到无数的问题，解决这些问题的过程就是对你的技术进行重构的过程。

但你至少还需要通过某种途径来“稍微了解”Ruby语言，而且在遇到问题时也需要一本手册来帮你排疑解难。在你手上的这本《Programming Ruby》正是为此而生的一本书。书中的精彩内容无须我在这里赘述，你大可以自己去发掘。我唯一想要告诉你的是：如果你想要开采最瑰丽的“红宝石”宝藏，这本书就是你不可或缺的“镐头”。锻造这柄镐头的是两位大名鼎鼎的“实用主义程序员”Dave Thomas和Andy Hunt，这两位撰写过一系列C++/Java/.NET技术图书的开发者最终选择用Ruby on Rails来开发他们自己的网站（PragmaticProgrammer.com），这本身就已经证明了Ruby的价值，同时也让我们对这本书的实用性更有信心。

所以，你还在犹豫什么呢？既然已经拿起了这本书，既然已经对Ruby产生了兴趣，就不要再浪费时间了。翻开书，跟着这两位讲求实效的作者一道，现在就开始你的Ruby编程之旅吧。Ruby已经向你说过“hello”了，你将会如何回应它呢？

最后，和以往一样，祝你在Ruby的世界里，编程快乐！

---

作者介绍
熊节是ThoughtWorks公司的咨询师，曾参与《重构：改善既有代码的设计（中文版）》、《J2EE核心模式（原书第2版）》、《Contributing to Eclipse中文版》等图书的翻译。目前正在从事Ruby on Rails的项目，并致力于敏捷方法与思想的推广。

双方前锋紧紧地站在一起，裁判哨声响起，球被掷出，双方球员奋力拼搏，反复地冲刺，竭尽全力向自己的目标冲去。这是英式橄榄球中Scrum的场景。 然而这样的活动，却被Ken Schwaber和 Jeff Sutherland巧妙地借助隐喻的方式引入到敏捷项目管理中，仔细思索，却又如此的恰如其分。在橄榄球运动中，固然需要强健的体魄与迅捷的速度，但更 重要的却是组织、协作、交流，以及一位优秀的指挥官。虽然二者的方式不同，然而赢得比赛与成功交付产品的目标其实是完全一致的。

Scrum是一种灵活的软件管理过程，它可以帮助你驾驭迭代、递增的软件开发过程。Scrum方法最初实践于Easel公司，现已被数十家公司数百 个项目开发中应用，适用于需求难以预测的复杂商务应用产品的开发。作为一种项目管理方法，Scrum与其它方法颇有不同之处，规则与名称也自成一套体系。 在Scrum管理活动中，包含三种不同的角色：Scrum Master，Product Owner，Team。Scrum的每一次迭代被称为Sprint，意为“冲刺”，生动形象地展现了项目开发活动的迭代过程。Scrum将功能需求称之为 Product Backlog，它们通常是由Product Owner提出。Product Backlog会在Scrum Master主持的Sprint Planning Meeting中确定，并在确定了Sprint之后，形成Sprint Backlog。Scrum非常重视团队成员的交流，除了Sprint Planning Meeting之外，还要求召开Daily Scrum Meeting，以及Sprint Review Meeting与Sprint Retrospective Meeting。

虽然Scrum从名词的定义上来看，显得有几分离经叛道，但其本质仍然秉承了敏捷开发思想。重视成员的交流、功能需求的确定、迭代版本的交付、项目 风险以及产品质量的控制。Scrum提供了一种经验方法，它使得团队成员能够独立地、集中地在创造性的环境下工作。Scrum过程是敏捷的、自组织的，产 品的开发则是增量的迭代交付方式。

《SCRUM 敏捷项目管理》一书全面细致地介绍了Scrum方法。作为Scrum的创始人与倡导者，作者Ken Schwaber将自己多年以来实施Scrum方法的经验、体会、教训浓缩在这本仅有163页的薄薄小书中，真可谓是字字珠玑。全书只有9个篇章，却涵盖 了Scrum的方方面面，包括Scrum方法概述，Scrum角色的职责，如何从混沌中提炼Product Backlog以及如何划分Backlog的优先级，如何制定Scrum项目计划，跟踪项目计划的执行，以及如何在大规模项目中应用Scrum方法。书中 的附录A更是Scrum方法的精华，总结了实施Scrum方法必须遵循的基本原则。

全书并没有长篇大论的理论分析与描述，而是通过一个个真实典型的项目案例，逐步为我们展现了Scrum的适用场景与实施细则。以实践指导实践，是本 书最大的亮点，从而使得本书摆脱了通常所谓的项目管理书籍的那种沉闷与枯燥，以及空中楼阁般的不切实际。这得益于作者娓娓道来的深厚文字功底，更重要的是 作为敏捷联盟的创始人之一，作者深谙敏捷之道，能够目光敏锐地发现传统项目开发的瑕疵；而作为Scrum的倡导者，对于Scrum方法的实施早已达到游刃 有余的境界。因此，本书可以说是ken的厚积薄发之作。

Ken善于以案例启发读者。Scrum提供了一种经验方法指导团队成员独立、高效地完成项目开发，而本书则以项目实践指导读者从阅读中获取经验。全书的每一章几乎都提供了“Lesson Learned”小节，从而加深读者对Scrum方法的理解。

理解Scrum方法并不困难，最大的困难在于如何正确地在项目开发中应用Scrum方法。即使是富有经验的Scrum Master，在面对不同的场景，也需要做出不同的抉择。正如书中所述：“The ScrumMaster applies Scrum theory to projects with different types and degrees of complexity.”项目的类型不同，复杂度不同，则应用的Scrum方法就会有所区别。

以书中列举的Tree公司的项目为例，就需要成立XML Team，WebPub Team以及多个Journal Team。而在Journal Team中，Scrum Master并没有固执地按照Scrum原则安排7个成员，而是由9个成员组成，其中包括了兼职的XML成员与WebPub成员。

在MegaFund项目中，为了合理地分解任务与团队，在提炼Product Backlog时，则将非功能性需求的优先级提高到功能性需求之前。这样的调整，同样是根据项目的特点而定。

Scrum方法的优势在于它的设计自始至终具有很强的适应性。如何在自己的项目开发中准确地应用Scrum，让自己成为合格的 ScrumMaster，让团队的需求分析师或者客户成为合格的Product Owner，让自己的团队成为合格的Scrum Team，相信你从本书能够找到扣开Scrum之门的钥匙。本书无法使你在一夜之间就成为一名优秀的Scrum大师，但本书作者Ken Schwaber却可以给你高屋建瓴般的整体指导，使你迅速成长。毫无疑问，《SCRUM敏捷项目管理》已经给你指出了一条掌握Scrum项目管理的终南捷径了。

---

作者介绍
张逸具有多年的软件开发与设计经验，他是两届微软最有价值专家（MVP），著作/译作包括《软件设计精要与模式》、《WCF服务编程》。张逸熟悉C#，ASP.NET，WCF等技术，同时深谙面向对象领域的相关技术。目前，他主要从事 SOA企业信息解决方案的设计与研究，以及敏捷方法的推广与实践。张逸是捷道·敏捷堂的创始人。