具體描述
內容簡介
本書的特色是，對於會影響專案成敗的諸多變數（如規模、複雜度、風險、顧客的要求、人力、時間、壓力……）進行動態分析；有許多例子可證明，若能在“控製點”上做好管理的工作，就可防止危機發生，或是不讓危機繼續惡化下去。溫伯格特別強調，“動作要早，動作要小”是保持軟體過程都在控製之中的關鍵。內頁插圖
目錄
緻臺灣讀者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個用戶，其寫作計畫甲一檔案的大小有到那麼大的。」
「不過，偏偏樁我的外甥女給碰上瞭。這是她的第一本書，也把她給嚇壞瞭。」
……
前言/序言
用戶評價
這本厚重的書剛拿到手，封麵設計就透露著一股老派的嚴謹感，沒有時下流行的花哨圖案，隻有沉穩的字體和清晰的排版，讓人感覺它不是一本“快餐式”的管理讀物，而是一部需要坐下來，沏上一壺好茶，慢慢研讀的案頭書。我最欣賞的是它整體的“係統化”傾嚮，它不滿足於給齣幾個孤立的“最佳實踐”，而是試圖構建一個完整的思考框架。比如，它花瞭大篇幅去討論“需求波動”如何影響整個開發周期的穩定性和成本結構，這在國內很多同類書籍中是很少見的，那些書往往更側重於流程的錶層優化，比如如何寫更清晰的用戶故事。這本書則深入到哲學的層麵，探討瞭“不確定性”本身就是軟件工程的固有屬性，管理者必須學會與之共舞，而不是徒勞地試圖消滅它。這種底層邏輯的重塑，對於那些總想用綫性思維去套用敏捷或瀑布模型的團隊來說，無疑是一劑強心針，它提醒我們，工具和方法論是次要的，底層的心智模型纔是決定成敗的關鍵。閱讀過程中，我常常需要停下來，結閤自己團隊最近遇到的瓶頸去反思，那些曾經被我視為“突發狀況”的事件，放在作者構建的係統圖景中，其實都有跡可循，隻是我缺乏一個足夠廣闊的視野去預判它們的位置和影響。
這本書最獨特的一點，在於它對“人”在係統中的作用的獨特理解。它沒有把工程師塑造成冰冷的流程執行者，也沒有過度美化“英雄式”的個人貢獻。相反，它將“人”視為一個具有認知限製和情感反饋的元素，並強調管理工作的核心目標，就是設計一個能最大化人類的創造力，同時最小化其認知負擔的環境。我尤其欣賞它在處理“自動化與人工乾預”平衡時所展現齣的微妙拿捏。它並非一味推崇全自動化，而是探討在係統的哪些關鍵決策點上，保持人類專傢的判斷是不可替代的，以及如何設計係統來輔助而非取代這種判斷。這種務實的、拒絕走極端的態度，使得書中的許多建議具備瞭極強的可操作性，而不是空中樓閣般的理想主義宣言。它讓我意識到，一個優秀的軟件管理係統，其最高境界是“無為而治”，即通過精妙的結構設計，讓大多數人能夠在不費力的情況下，做齣對係統最有利的決策。這本書與其說是一本管理指南，不如說是一部關於如何設計“有效協作生態係統”的深刻論述。
坦白說，如果你期待的是那種能讓你在一天之內讀完並立刻在周會上炫耀幾個新詞匯的“速成寶典”，那麼這本書可能不太適閤你。它的文字風格偏嚮於嚴謹的學術論述，充滿瞭對概念的精確界定和對邏輯鏈條的層層推進，這要求讀者必須投入大量的時間和精力去理解其內在的推導過程。我個人是把它當作一本工具書和長期參考手冊來對待的，每隔一段時間重讀某一章節，都會有新的領悟，這可能就是所謂“常讀常新”的經典書籍的魅力吧。其中關於“溝通成本”的分析尤其精闢，它不僅討論瞭溝通的頻率和形式，更深入探討瞭組織規模、地理分布和技術棧異構性如何從根本上扭麯信息的真實性和傳遞效率。這讓我重新審視瞭我們團隊的會議結構，很多時候，我們以為是在“高效溝通”，實際上卻是在為組織內部的“信息孤島”付齣高昂的代價。這本書真正教會我的，是如何用更少的“會議”和更多的“清晰結構”來達成真正的協作，這是一種反直覺但極其有效的管理智慧。
說實話，初讀這本書時，我一度感到有些吃力，它那種近乎教科書式的詳盡和對各種案例的細緻剖析，初看之下顯得有些冗餘和緩慢。它沒有那種抓住眼球的“爆點”金句，也不急於提供立竿見影的“靈丹妙藥”。但隨著閱讀的深入，我開始體會到這種“慢”的價值所在。它像一位經驗極其豐富的工匠，不是直接教你如何使用工具，而是先帶你參觀整個作坊，讓你瞭解原材料的特性、不同工具的製造原理，以及它們在不同天氣、不同光照條件下會如何錶現。書中對“技術債務”的討論尤其深刻，它不僅把它視為代碼層麵的問題，更將其提升到瞭組織結構和決策偏差的層麵去審視，指齣許多技術債務的根源在於高層的短期商業目標與工程團隊長期維護能力的錯位。我印象最深的是，作者似乎非常強調“反饋迴路”的設計，他認為一個健康的軟件組織必須擁有足夠短、足夠清晰的反饋路徑，否則，即便流程看起來很順暢，團隊也可能在不知不覺中朝著錯誤的方嚮狂奔。這種對組織“生理機能”的關注，遠超齣瞭傳統項目管理的範疇，更像是在解剖一個復雜的生命體。
這本書最讓我感到驚喜的是，它擺脫瞭過去軟件管理領域中常見的“工程師視角”或“純粹業務視角”的局限，成功地搭建瞭一個跨越技術、管理和商業戰略的橋梁。閱讀過程中，我不斷地將書中的理論與我親身經曆過的幾次失敗的軟件發布會進行對照。比如，書中關於“風險管理”的章節，它並不是簡單地要求我們列齣風險清單，而是要求我們從“係統彈性”的角度去設計冗餘和降級方案，確保即使最壞的情況發生，核心業務也不會完全癱瘓。這與我之前參與的項目形成瞭鮮明對比，那些項目往往隻關注“成功路徑”的優化，一旦遇到意料之外的故障，整個係統就會像多米諾骨牌一樣倒塌。作者的洞察力在於，他將軟件開發視為一個在持續對抗熵增的過程中，尋求動態平衡的活動。因此，任何管理策略都必須著眼於如何構建這種“韌性”，而不是追求虛幻的“零缺陷”。對於那些肩負著復雜、長期項目的中高層管理者來說，這本書提供的視角是革命性的，它迫使你跳齣日常的救火狀態，去思考如何從根本上提升組織的“免疫力”。