项目百态

深入理解软件项目行为模式

8.0286 评价豆瓣读书
阅读

作品简介

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

本书适合所有软件项目的管理者阅读,也适合有志于成为软件管理者的人参考。

这些组织里面的人不会从战略层次上思考问题,只是按照紧迫程度来完成工作。除非“忙乱指数”非常高,否则它通常都会被忽略——尽管它很有可能会带来显著的长期优势。人们会一直对其不闻不问,直到它突然(绝对出乎意料地)变得非常紧迫。“玩的就是心跳”分子相信最好的工作方式不是先谋而后动,而是竭力追赶时间。

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上发表过多篇论文。

作品目录

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

评论

载入中

热门划线

  1. 项目是为提供某项独特产品、服务或者成果所做的临时性努力。7 人
  2. 组织只有不再忙于处理突发事件才最有效率5 人
  3. 如果拭去隐喻带来的神秘性质,翻开思想和方法的装饰,直面软件领域与其他领域的根本差异,我们可以发现软件的核心特征在于其抽象性。软件开发由需求(问题域)到可执行的源代码(解决域),正是试图以一种抽象的形式捕捉或者展示另一种抽象。软件的抽象性导致了其他领域所不具备的两个重要特征。4 人
  4. 测试阶段之前测试的理由是它能使得后期测试更为有效,而且自始至终能够有效地减少在可避免错误上花费的修复时间。引入早期测试的组织发现后期可以安心地把精力放在测试产品的运作是否符合预期上面。很多组织无法做到这一点,因为它们对于“工作符合预期”的定义标准没有信心。如果需求本身就没有经过测试,需求又如何能被软件测试人员信任呢?早期测试的目的是给后来阶段的测试提供精准的标准以衡量解决方案。4 人
  5. 我们要解决的问题是什么?解决方案的要点是什么?每项要点由谁负责?首先需要完成的事情有什么?谁来完成它们?在什么时间之内完成?如果我们不清楚某一项个别的任务要花多长时间,谁来定义任务范围,以及何时才能完成?什么时候我们再聚一起,计划接下来的任务?3 人
  6. 绝对的服从可能是有害的,某些善意的无序反而是有益的。3 人
  7. 你们并不是没有优先级。你们的优先级策略是最后来的事情优先。2 人
  8. 布朗运动2 人
  9. 一个早期智人凝视着一样依稀很熟悉的东西,他的脑海中闪过一个想法:“嗨!又是那个东西!”这就是最原始的抽象。从那时起,一切都不同了。人类在地球上不再受自然羁绊。2 人
  10. 模式识别和抽象的区别在于它们捕获本质的方式。模式随着时间被吸取和提炼,保留在脑海的深处,很难用语言来表述,而多半是以直觉的方式传达给你的。2 人

喜欢这本书的人也喜欢