死亡之旅

出版时间：2005-5-1  出版社：电子工业出版社  作者：EDWARD YOURDON,周浩宇  页数：216  字数：175000  译者：周浩宇  
Tag标签：无  

内容概要

本书涵盖了整个项目生命周期，以浅显易懂的语言和生动的事例对死亡之旅项目的起因给出了崭新的理由，深刻分析了这种现象的本质，并系统地讨论了项目参与者所面临的所有关键问题：政治、人员、过程、项目管理，以及工具，为我们提供了行之有效的方法和指南。本书不但有助于快速识别死亡之旅项目，而且能够大大提高自己从中生还的概率。     无论是开发人员、项目领导、直线商务经理还是CxO，都可以在本书中找到现实而适用的解决方案。

作者简介

爱德华·尤登不但被公认为软件领域最有影响力的人士之一，而且还被选入计算机名人堂，与Charles Babbage，Seymour Gray，James Martin，Grace Hopper和Bill Gates并列其中。作为国际知名的咨询师，他撰写和合著了超过25本专著，其中包括“Byte Wars”、“Managing High—Inte

书籍目录

第1章 绪论　1.1 死亡之旅的定义　1.2 死亡之旅项目的分类　1.3 为何会出现死亡之旅项目　　1.3.1 政治，政治，还是政治　　1.3.2 市场人员、高级管理人员、缺乏经验的项目经理等所做出的幼稚承诺　　1.3.3 年轻人幼稚的乐观主义：“我们周末能完成它！”　　1.3.4 新公司的创业精神　　1.3.5 海军陆战队精神：真正的程序员无需睡眠　　1.3.6 市场全球化导致的残酷竞争　　1.3.7 新技术出现引发的激烈竞争　　1.3.8 不可预期的政府法令导致的巨大压力 　　1.3.9 出乎意料的危机 　1.4 人们为何会参加死亡之旅项目 　　1.4.1 虽然风险很高，但回报也很高 　　1.4.2 珠峰综合症 　　1.4.3 年轻人的天真和乐观 　　1.4.4 不做就要失业 　　1.4.5 未来获得提升的必要条件 　　1.4.6 不做就要面临破产或其他不幸 　　1.4.7 一个突破旧条条框框的机会 　　1.4.8 报复 　1.5 结论 　注释 第2章 政治 　2.1 确定项目所涉及的政治“玩家” 　　2.1.1 业主 　　2.1.2 客户 　　2.1.3 股东 　　2.1.4 干系人 　　2.1.5 支持者 　2.2 确定项目的基本类型 　2.3 项目参与者的承诺程度 　2.4 导致政治争执的关键问题 　2.5 结论 　注释 第3章 谈判 　3.1 理智的谈判 　3.2 识别可接受的折中 　3.3 谈判游戏 　3.4 谈判策略 　3.5 谈判失败后应该做什么 　注释 　参考书目 第4章 死亡之旅项目中的人员 　4.1 雇用和人员配备问题 　4.2 忠诚、承诺、激励和奖赏 　　4.2.1 奖励项目团队成员 　　4.2.2 加班问题 　4.3 沟通的重要性 　4.4 团队建设问题 　4.5 死亡之旅项目的工作场所条件 　4.6 结论 　注释 　参考书目 第5章 死亡之旅过程 　5.1 “triage”的概念 　5.2 需求管理的重要性 　5.3 SEI、ISO 9000、正式过程与非正式过程 　5.4 “足够好”的软件　5.5 最佳实践和最差实践 　5.6 当死亡之旅遭遇XP 　5.7 结论 　注释 　参考书目 第6章 动态的过程 　6.1 软件开发过程模型 　　6.1.1 思维模型 　　6.1.2 电子表格模型 　　6.1.3 静态vs. 动态模型 　　6.1.4 可视化模型 　　6.1.5 示例：TAREK ABDEL-HAMID的软件过程模型 　6.2 结论　注释 　参考书目 第7章 关键链进度排定和限制理论 　7.1 介绍 　7.2 什么样的组织行为是紊乱的 　7.3 我们如何才能改变紊乱的组织行为 　7.4 理智世界中的行为 　7.5 关键链进度排定 　7.6 结论 　注释 　参考书目 第8章 时间管理 　8.1 企业文化对时间管理的影响 　8.2 股东争执所浪费的时间 　8.3 帮助项目团队更好地利用时间 　注释 第9章 管理和控制项目进展 　9.1 “天天做”概念 　9.2 风险管理 　9.3 对进展监控的额外建议：里程碑评审 　注释 　参考书目 第10章 工具和技术 　10.1 最小工具集 　10.2 工具和过程 　10.3 选择新工具的风险 　10.4 结论 　注释 　参考书目 第11章 模拟器和“军事演习” 　11.1 介绍 　11.2 “军事演习”的概念 　11.3 结论 　注释 　参考书目

用户评论 (总计7条)

•   　　這首先是一本教讀者審時度勢的書。對於一個死亡之旅的項目，如何去判定？看項目發起人，項目發起的背後真正原因。遭遇這樣的項目時，是戰還是離？“具體情況具體分析”，看你的上司是誰，是一個什麽樣的人，這是一什麽樣的項目，神風特攻隊？自殺還是醜陋的？還是？
  　　決定留下來，一定要明確真正的目標和真正的需求，要與干系人談判、溝通、發佈這個目標。這個目標會遭到很多人和因素的干擾，項目經理就要排除這種干擾。需求是可以分類的，變化的、動態的，要捕捉它。
  　　死亡之旅的目標是在有限的資源（時間、人力、技術、資源）下，完成可用的交付，而不是過程。任何不能促使這個目標實現的活動、技術，都是不值得採用的。
  　　團隊的形成是有規律的，是一個動態的，追求的是“動態平衡”。團隊的產出率有其上限，“人月神化”是不存在的。
•   　　在软件工程的图书中，《死亡之旅》是本相当奇特的书。它并没有讲一个软件工程方法，而是在讲一种软件工程实施中的现象。
  　　
  　　“死亡之旅”（Death March或者译为“死亡行军”）项目是这样一种现象：在软件开发中，软件要素的制约与软件目标存在一倍及以上的差距。这些要素可能包括人才、时间等方面。如果你接到了一个需要一个5人团队半年时间才能完成的项目，却被要求三个月完成。这个时候，你的团队就在死亡行军了。在这本书中，作者对死亡之旅现象产生的原因、环境以及身处死亡之旅项目中的人的种种遭遇、困难、行为都有介绍。
  　　
  　　
  　　为什么会产生这种死亡之旅项目？
  　　
  　　这个话题就足够讨论很长时间，书中也讨论了很多可能的原因。结合我个人的项目经历，我认为现实环境中最容易出现的原因是管理层的盲目自大，还有一线开发者没有话语权。从某种层面来说，这两种原因通常都会同时出现。管理层永远都是容易盲目乐观的，特别是进行内部管理时。由于身处高位，他们都通常更容易获得来自中层管理者的过多乐观汇报。如果管理者自认为曾经从事过基层技术工作，那就更容易自认为对技术了如指掌，一切都尽在掌握。“找你们几个低效的程序员来搞只是因为老子没时间”。实际上项目的复杂度总是比从外面看上去更高的。一个简单的原因是一个系统需要应付所有可能的输入，甚至异常情况。而外观上人们只能看到简单的关键路径。对于习惯了在线付款的你根本看不到支付系统在背后为多少种信用卡异常编写了代码，因为你可能一辈子也遇不上数据库异常回滚。所以，一个技术出身的领导者更容易作出愚蠢的决定，确信那些明显脱离实际的项目资源评估。因为他们像其他高管一样乐观，却比其他高管更自信，所以，很多“悲剧”就上演了。
  　　
  　　对于书中提到的其他客观因素，我倒不太认为会很严重得引发死亡之旅项目。企业的竞争压力确实在增加，但如果意识到这是个死亡之旅项目，理智的高管也不太可能做出决定，因为这很有可能导致投资损失，并且耽误那些本可以争取到的市场机会。当然，如果由于政治原因做出决定，除了自认倒霉没有任何话好说。
  　　
  　　
  　　如果不幸遇到死亡之旅项目，作为项目经理或者一线研发工程师，你还有什么可选择吗？
  　　
  　　走为上计。我认为书中提出这个方案是很严肃的。出现这种很不理智的决定本身已经说明了整个组织存在着过于草率或者不够客观的决策，存在着很大的风险。如果确实出现了这样的问题，一走了之没什么不好，只是很多时候我们走不了。
  　　
  　　挺过难关。这是最常见的一个选择。一般情况下，作为下属，无奈得忍受上级决定已经成为习惯。你可以有一些可选择的方案来减少困难。例如对一些项目的不重要因素降低要求；想办法激励团队或提供更高待遇。（换几个更有效率的工程师？申请独立的工作环境？提高团队伙食？）在死亡之旅的路上，除了路途中的艰难，还有可怕的终点审判。要学会通过一些方式让管理层更好地接受这个结局，也是挺过死亡之旅的关键因素。
  　　
  　　还有第三种选择吗？也许有，但是幸运的人毕竟是少数。软件开发是一个有伸缩性的工作，核心的制约是开发人员的工作效率。如果有办法通过所有可能的方式提升开发效率，甚至在总体上提升一倍，那么你就真正赢得了死亡之旅的全程！有哪些因素可以考虑？
  　　
  　　 减少开发人员的无关工作（填写毫无意义的工作报告；减少开发人员被邮件和电话打断的机会）
  　　
  　　 在制度和团队风格上打消成员的内心障碍（例如“反正要加班，不如白天少干点”）
  　　
  　　 切实得激励团队成员，让大家忘掉项目的不明朗前景
  　　
  　　 识别项目障碍并小心引入工具
  　　
  　　真的会有将团队生产力提高一倍的可能吗？是有的，但机会不多。团队的改进空间有限，在巨大的压力下又不能付出过多的学习成本，所以希望不大。同时，加班和工具对提升团队产出的影响也不可能达到如此大的比例（想想老生常谈的“没有银弹”）。
  　　
  　　所以想摆脱死亡之旅项目真正的希望还是要靠更了解软件工程规律的管理层和决策体系，更有说服力的评估方法和敢于指出问题的组织氛围。
  　　
  　　同步发表在我的博客 http://hi.baidu.com/thinkradar/item/84a588936fe0771f336eeb5b
•   　　最近很流行美国大学的哲学课程，死亡啦，幸福啦，在书店乍一看到，还以为是这一类的书呢。《死亡之旅》并不是讲那些终极问题的，而是把它落实到具体的生活中，就是那些令人抓狂的项目及其管理上。
  　　
  　　软件开发项目是越来越多了，“死亡之旅”类型的项目也愈发的多起来了。死亡之旅的项目有诸多细分的类型，也有不同的原因所导致。有的是管理层的一意孤行，有的是年轻工程师团队的自掘坟墓，有的是突如其来的危机导致，有的则是灭亡前的最后一搏。
  　　
  　　总体来说，对于理性的个人而言，此类“死亡”项目还是“避之则吉”。但是，最后参与其中的，又都各有各的理由。离职的成本太高，要出一口恶气，妄图一战成名，或者是光荣的最后一搏。其实有着众多的理由让人参与其中。
  　　
  　　那么一旦踏上了旅程，那就全力想着，怎么能活下来。《死亡之旅》这是很好的求生指南，特别对项目经理而言。
  　　
  　　政治上的沟通自然要顺畅，还要找到靠山，不然要啥没啥，和等死没啥区别。
  　　
  　　各种谈判自然力所能及的去讨价还价，总要死的不是那么难看才好。
  　　
  　　挑选成员，必然是要能同心协力的，共赴黄泉的。不然有人脚底抹油，必然有人死无全尸。所谓不怕神一样的对手，就怕猪一样的队友。
  　　
  　　在开发的过程中，有些工具要好好采用，例如XP，最佳实践，但是务必要有趁手的家伙。有些工具看上去锃亮，拾起来却不顺手，最后让人拿西瓜刀给切了。
  　　
  　　关键任务的安排和良好的时间管理在“死亡之旅”中更显重要。争分夺秒，运筹帷幄，才可能绝处逢生。
  　　
  　　当我刚刚开始阅读此书的时候，我以为是教大家如何识别死亡之旅，并且脚底抹油的。读到后来才明白，原来是让我们迎难而上的。在这不靠谱的世界里，忽悠是多么的重要。但是在忽悠的同时也有有真材实料，否则只能忽悠致死了。
•   　　台词控：
  　　快乐在于能够长时间的为自己认为值得的事情努力工作，不管它是什么。一个人也许能够从照顾妻儿之中找到快乐，而另一个人则可能在打劫银行的犯罪行动中找到他，很可能还有人热衷于数年投身于没有明显成果的纯粹的研究工作之中。
  　　
  　　请注意每种情形的独特个性。任何两种情形都不会完全相同，而且你也没理由做此期望。每个人都必须为自己找到虽然需要付出艰苦努力却能令自己快乐的工作。反之，如果你在为自己寻求假期悠长而且能够及早退休的轻松工作，那么你就已经选错了职业。也许你应该去表演杂耍，甚至还可以投身政治。
  　　
  　　经过仔细分析之后，我找到了一个复杂的定理用以解释这种古怪的工作行为的存在：人们都是傻瓜。每个人都是傻瓜，我们的不同在于：我们会在不同的时间对不同的事物成为傻瓜。无论多聪明，你也会花费许多时间去做一个傻瓜。
  　　
  　　只要一起做事的人超过两个，政治就必然存在。
  　　
  　　幼稚经常与缺乏经验相连。
  　　
  　　“英雄们”的存在是人们的要求、需要和期望。如果只有他们才能挽救这个项目，他们就会确立自己在历史中的地位。
  　　
  　　自尊、完美和真诚是让神志清醒的人为何会同意参加这样一个“死亡之旅”。
  　　由于珠峰类型的死亡之旅项目而兴奋的不能自拔，那么你需要注意两件事。首先，你需要提防事先就注定失败的项目；第二件需要注意的是就是公司管理层口中大肆渲染的挑战很可能根本就不重要；连续问两到三遍“那又怎么样？”是一个不错的主意，将你拉回到现实世界。或者你不妨用非技术性的语言向自己的伴侣、“至关重要的另一半”、父母或向孩子解释项目，如果你能回答他们问的所有问题，而且最终不觉得愚蠢之极，那么你答可以意识清醒地加入这个项目。
  　　不要忘记政治是此时的一个关键因素，那些因死亡之旅项目的成功而最终赢得声誉的人并不一定就是项目的参与者。不仅如此，那个建议开始死亡之旅项目的经历很可能根本没有考虑过项目组成员是否能成功挺过项目，他们很可能只是把重组“危机”用做自己步步高升的垫脚石而已。
  　　
  　　愚蠢的定义就是一次次用同样的方式做同一件事，却期待会有不同的结果。
  　　
  　　项目就像是一场婚姻，开始时，我们通常天真而充满希望，但随着现实的慢慢介入，我们不得不重新调整对这种关系的期望。让人们开始一场婚姻的理由有很多，但它们往往没有逻辑关系。
  　　
  　　让项目中的每个成员都明白谁是关键玩家依旧非常重要。明白问题来自朋友还是来自敌人，以及他是否有可能具有政治含义将非常重要，不管你如何回答这个随意的问题，答案都很可能被带回到组织内部，而且其中的信息常常会被夸张、歪曲和隐藏。
  　　认为所有玩家信息也是项目的一部分，所以最好让每一个人（支持者、经理、开发者）都了解这些信息。一旦你把任何与项目相关的信息对开发者隐瞒不报，项目离失败就只有一步之遥了。
  　　
  　　联合应用开发（JAD）。项目经理应该努力从主要项目干系人处得到承诺：所有需要得到他们批准、同意、评审的问题，都必须在24小时内得到处理。
  　　
  　　一旦找出项目中的主要“玩家”，确定了项目类型，并且在项目经理所希望的承诺水平与成员实际所能提供的承诺水平间进行了沟通，就可以着手开始实际项目工作。
  　　
  　　准确评估每个项目团队成员的承诺水平：
  　　1、 在组员看来，哪些事情比项目更重要，以及哪些事情没有项目重要；
  　　2、 任何承诺声明都只能表明团队成员目前的感觉。
  　　
  　　人人都希望事情做得又快又好并且价格低廉。每个人都知道你可以达到以上三个目标中的任意两个。但问题是，你到底想要哪两个？
  　　
  　　虽然你很可能无法让他们改变项目的最后期限，但你却又可能在为项目配备比普通项目要求多得多的人员。
  　　
  　　任何首席指挥官都不应该去执行连自己都认为有缺陷的计划，它必须提出自己的理由并坚持对计划进行修改。拿破仑
  　　
  　　与年薪90000美元的资深程序员相比，20%的加薪对与年薪30000美元的初级程序员更有意义。
  　　
  　　几乎全部将系统需求划分为“必须做”、“应该做”和“可以做”三种类别。
  　　
  　　在死亡之旅项目中采用全新的陌生过程往往会导致灾难性后果，即便项目团队全体成员都一致同意此过程将会有助于项目也不例外。因为学习曲线、对过程细节不可避免的困惑和争论所带来的损失往往会超过它带来的益处。
  　　
  　　无论如何，在多数死亡之旅项目中，完美的可靠性、可维护性、可移植性并非必不可少，也并不实用，甚至可能毫无必要。
  　　
  　　我们怎样才能做出“足够好”呢？
  　　实用主义策略：在不明确的局面下进行定性分析和使用正面收益最大化的艺术。包括系统化思维、风险管理、经济学、决策理论、博弈论、控制理论和模糊逻辑。
  　　发展的策略：不但要考虑项目生命周期，而且要用发展的眼光看待人员、过程和各种资源。
  　　英雄的团队：团队中并不都是天才，而是要用技术熟练的普通人的有效合作。
  　　动态的基础设施：官僚体制和强权政治的对立面。在这种情况下，高级管理层会重视项目，重视市场，确定并解决项目之间的冲突，而且会在项目与组织的官僚体制发生冲突时给与项目强有力的支持。
  　　动态过程：过程能够在不断发展的写作环境中对工作提供支持。
  　　
  　　在短期里程碑之后立刻安排半天的小型审计：哪些方法确实有效？哪些方法大大有害？为了达到下一个里程碑，那些应该着重强调？哪些应该抛弃？这种自省不但非常有助于项目团队自身的改善，而且会为日后的死亡之旅项目团队提供参考。
  　　
  　　避免灾难往往比追求完美更为重要。
  　　不要为预想中的“未来”需求做设计，而应该为当前需求提供可能的最佳设计。
  　　
  　　“结队编程”重要主题：每个独立的开发任务都有两个软件工程师共同承担。这样做有两个好处。首先，在项目进行的过程中，如果其中一个开发人被传说中的啤酒卡车撞伤，结对编程可以提供宝贵的“保险”；其次，在开发人以疯狂的速度进行编码时，两对眼睛审查代码通常会更快、更节约成本。
  　　
  　　缺乏方法和标准也能把一个项目变成一场死亡之旅。
  　　
  　　天天做就是项目的心跳，通过它你才能确定自己确实还活着。
  　　
  　　
  　　
  　　
  　　
  　　
  　　学会静止，将你的注意力从你不喜欢的事物上移开，将注意力放到你希望体验的事物上。
  　　
  　　
•   非常在理，感同身受！也许是正在一个“死亡之旅”中蹒跚前行，直奔死亡而去的缘故吧。技术出身的高管更自信，也更愚蠢，的确如此啊。技而忧则仕，飘飘然，一点不记得自己当初在一线干活时的辛苦，只觉得自己牛的不一般，反而更看不起一线干活的，觉得比自己当年差太多了，在此种心态下做的决策，可想而知。
•   http://programmers.stackexchange.com/questions/70755/are-long-hours-and-no-benefits-the-norm-for-a-junior-programmer
  这里也有人推荐了这本书
•   [连续问两到三遍“那又怎么样？”是一个不错的主意，将你拉回到现实世界。或者你不妨用非技术性的语言向自己的伴侣、“至关重要的另一半”、父母或向孩子解释项目，如果你能回答他们问的所有问题，而且最终不觉得愚蠢之极，那么你答可以意识清醒地加入这个项目。]
  这段话很精彩