具体描述
内容简介
本書的特色是，對於會影響專案成敗的諸多變數（如規模、複雜度、風險、顧客的要求、人力、時間、壓力……）進行動態分析；有許多例子可證明，若能在“控制點”上做好管理的工作，就可防止危機發生，或是不讓危機繼續惡化下去。溫伯格特別強調，“動作要早，動作要小”是保持軟體過程都在控制之中的關鍵。内页插图
目录
致臺灣讀者Prefacc to the Chinese Editions
〔導讀〕從技術到管理，失落的環節
前言
第一部 品質的模式
1 何謂品質？品質的重要性何在？
1.1 軟體品質打開的故事
1.2 品質的相對性
1.3 品質足在某人心曰中的價值
1.4 Precision Cribbage牌戲
1.5 要改善牕質九何如此閑難
1.6 軟體文化與次文化
1.7 心得與建議
1.8 摘要
1.9 練習
2 軟體次文化
2.1 克勞斯此的想法應用於軟體業
2.2 軟體次文化的六種模式
2.3 模式0：渾然不知型
2.4 模式1：變化無常型
2.5 模式2：照章行事型
2.6 模式3：把穩方向型
2.7 模式4：防範木然型
2.8 模式5：全面關照型
2.9 心得與建議
2.10 摘要
2.11 練習
3 怎樣才能改變模式？
3.1 思維模式的政變
3.2 利用模型以選出較佳的模式
3.3 讓模式能夠接納新資訊
3.4 心得與建議
3.5 摘要
3.6 練習
第二部 管理的模式
4 管理用的控制模式
4.1 射擊移動的標靶
4.2 榘成y（的控制模型
4.3 模式與模式的控制論模型
4.4 工程化的管理
4.5 從計算機科學到軟體工程
4.6 心得與建議
4.7 摘要
4.8 練習
5 讓管理模型變得透明
5.1 為什麼事情會不照計畫進行？
5.2 線性模型從其謬誤之處
5.3 效應圃
5.4 從輸出結果逆向得出效應圖
5.5 非線性才是事態惡化的上因
5.6 心得與建議
5.7 摘要
5.8 練習
6 反皚效應
6.1 小矮胖癥候群
6.2 失控、棊增、與癱瘓
6.3 動作要早，動作要小
6.4 負向反鱸——為什麼完全沒有癱瘓發生
6.5 心得與建議
6.6 摘要
6.7 練習
……
17 如何處理停擺的壓力
18 我們努力得來的成就
註解
法則、定律、與原理一覽表
索引
精彩书摘
何謂品質？品質的重要性何在？
軟體行業中人對於消除「模稜兩可的用詞」可說是不遺餘力，作家亦復如此。不過，有時作家會故意把用詞弄得摸棱兩可，就像本書的書名。「高品質軟體管理」（Quality Software Managemcnt）的意思可以是「高品質欹體的管理」，也可以是「軟體業的高品質管理」，因為我認為這兩者是無法分割的。兩者的意思都若重於「高品質」一詞，因此我們若想在合理的範圍內保持用詞的模稜兩可，首先我們必須將這個經常受到誤解的術語之真正涵義弄清楚。
1.1 與軟體品質有關的故事我的妹妹有個女兒名叫泰拉，她是她們家中唯一步找後塵，以作家為業的。她寫的是有開醫藥史方面頗具趣味件的書籍’而我對她所寫每一本書的進展都很關心，就像那是我自己的書一樣。為了要提拔自家人的這份私心，當她第一本書（美國大眾傳播媒體上的疾病）．完成後，竟然發現一大堆嚴重的打字錯誤和整段的文字遺漏，這讓我感到非常難以忍受（參看圖1-1）。讓我更不能忍受的是，那些錯誤都是因她所使用的文字處理軟體——Cozy Write（輕鬆寫）——中的一個bug所造成，而該軟體足由我的一個客戶Mini Cozy（迷你輕鬆）軟體公司所發行。
泰拉請我在下一次拜訪Mini Cozy公司時，能夠和該公司討論一下這個問鱷。我找到Cozy Write的專案經理’他承認該產品中存在此一錯誤。
「這個bug很難碰得到，」他說。
「我可不這麼認為，」我反駁道「在我外甥女的書中，我可以找出25個例子。」
「可是這類錯誤要在寫作計晝的規模有一本書這麼大的文件上才會發生。我們的產品有超過10萬個用戶，當中可能不出10個用戶，其寫作計畫甲一檔案的大小有到那麼大的。」
「不過，偏偏樁我的外甥女給碰上了。這是她的第一本書，也把她給嚇壞了。」
……
前言/序言
用户评价
坦白说，如果你期待的是那种能让你在一天之内读完并立刻在周会上炫耀几个新词汇的“速成宝典”，那么这本书可能不太适合你。它的文字风格偏向于严谨的学术论述，充满了对概念的精确界定和对逻辑链条的层层推进，这要求读者必须投入大量的时间和精力去理解其内在的推导过程。我个人是把它当作一本工具书和长期参考手册来对待的，每隔一段时间重读某一章节，都会有新的领悟，这可能就是所谓“常读常新”的经典书籍的魅力吧。其中关于“沟通成本”的分析尤其精辟，它不仅讨论了沟通的频率和形式，更深入探讨了组织规模、地理分布和技术栈异构性如何从根本上扭曲信息的真实性和传递效率。这让我重新审视了我们团队的会议结构，很多时候，我们以为是在“高效沟通”，实际上却是在为组织内部的“信息孤岛”付出高昂的代价。这本书真正教会我的，是如何用更少的“会议”和更多的“清晰结构”来达成真正的协作，这是一种反直觉但极其有效的管理智慧。
这本书最让我感到惊喜的是，它摆脱了过去软件管理领域中常见的“工程师视角”或“纯粹业务视角”的局限，成功地搭建了一个跨越技术、管理和商业战略的桥梁。阅读过程中，我不断地将书中的理论与我亲身经历过的几次失败的软件发布会进行对照。比如，书中关于“风险管理”的章节，它并不是简单地要求我们列出风险清单，而是要求我们从“系统弹性”的角度去设计冗余和降级方案，确保即使最坏的情况发生，核心业务也不会完全瘫痪。这与我之前参与的项目形成了鲜明对比，那些项目往往只关注“成功路径”的优化，一旦遇到意料之外的故障，整个系统就会像多米诺骨牌一样倒塌。作者的洞察力在于，他将软件开发视为一个在持续对抗熵增的过程中，寻求动态平衡的活动。因此，任何管理策略都必须着眼于如何构建这种“韧性”，而不是追求虚幻的“零缺陷”。对于那些肩负着复杂、长期项目的中高层管理者来说，这本书提供的视角是革命性的，它迫使你跳出日常的救火状态，去思考如何从根本上提升组织的“免疫力”。
说实话，初读这本书时，我一度感到有些吃力，它那种近乎教科书式的详尽和对各种案例的细致剖析，初看之下显得有些冗余和缓慢。它没有那种抓住眼球的“爆点”金句，也不急于提供立竿见影的“灵丹妙药”。但随着阅读的深入，我开始体会到这种“慢”的价值所在。它像一位经验极其丰富的工匠，不是直接教你如何使用工具，而是先带你参观整个作坊，让你了解原材料的特性、不同工具的制造原理，以及它们在不同天气、不同光照条件下会如何表现。书中对“技术债务”的讨论尤其深刻，它不仅把它视为代码层面的问题，更将其提升到了组织结构和决策偏差的层面去审视，指出许多技术债务的根源在于高层的短期商业目标与工程团队长期维护能力的错位。我印象最深的是，作者似乎非常强调“反馈回路”的设计，他认为一个健康的软件组织必须拥有足够短、足够清晰的反馈路径，否则，即便流程看起来很顺畅，团队也可能在不知不觉中朝着错误的方向狂奔。这种对组织“生理机能”的关注，远超出了传统项目管理的范畴，更像是在解剖一个复杂的生命体。
这本书最独特的一点，在于它对“人”在系统中的作用的独特理解。它没有把工程师塑造成冰冷的流程执行者，也没有过度美化“英雄式”的个人贡献。相反，它将“人”视为一个具有认知限制和情感反馈的元素，并强调管理工作的核心目标，就是设计一个能最大化人类的创造力，同时最小化其认知负担的环境。我尤其欣赏它在处理“自动化与人工干预”平衡时所展现出的微妙拿捏。它并非一味推崇全自动化，而是探讨在系统的哪些关键决策点上，保持人类专家的判断是不可替代的，以及如何设计系统来辅助而非取代这种判断。这种务实的、拒绝走极端的态度，使得书中的许多建议具备了极强的可操作性，而不是空中楼阁般的理想主义宣言。它让我意识到，一个优秀的软件管理系统，其最高境界是“无为而治”，即通过精妙的结构设计，让大多数人能够在不费力的情况下，做出对系统最有利的决策。这本书与其说是一本管理指南，不如说是一部关于如何设计“有效协作生态系统”的深刻论述。
这本厚重的书刚拿到手，封面设计就透露着一股老派的严谨感，没有时下流行的花哨图案，只有沉稳的字体和清晰的排版，让人感觉它不是一本“快餐式”的管理读物，而是一部需要坐下来，沏上一壶好茶，慢慢研读的案头书。我最欣赏的是它整体的“系统化”倾向，它不满足于给出几个孤立的“最佳实践”，而是试图构建一个完整的思考框架。比如，它花了大篇幅去讨论“需求波动”如何影响整个开发周期的稳定性和成本结构，这在国内很多同类书籍中是很少见的，那些书往往更侧重于流程的表层优化，比如如何写更清晰的用户故事。这本书则深入到哲学的层面，探讨了“不确定性”本身就是软件工程的固有属性，管理者必须学会与之共舞，而不是徒劳地试图消灭它。这种底层逻辑的重塑，对于那些总想用线性思维去套用敏捷或瀑布模型的团队来说，无疑是一剂强心针，它提醒我们，工具和方法论是次要的，底层的心智模型才是决定成败的关键。阅读过程中，我常常需要停下来，结合自己团队最近遇到的瓶颈去反思，那些曾经被我视为“突发状况”的事件，放在作者构建的系统图景中，其实都有迹可循，只是我缺乏一个足够广阔的视野去预判它们的位置和影响。