Quality software management.Volume 4,Anticipating change
副标题：无
作 者：杰拉尔德·温伯格(Gerald M. Weinberg)著;何霖译
分类号：
ISBN：9789866031137
微信扫一扫,移动浏览光盘
简介
專案為何會落後一年？……因為每次落後一天。－《人月神話》
要有高品質的軟體，就要有高品質的管理。－《溫伯格的軟體管理學》
《溫伯格的軟體管理學》一套四冊，主題分別是：
一、 系統化思考（Systems Thinking）、
二、 第一級評量（First-Order Measurement）、
三、 關照全局的管理作為（Congruent Action）、
四、 擁抱變革（Anticipating Change）。
本書是這個系列的第四本，要談的主題是：如何創造一個有利於軟體工程進行的環境。前三本書已談過為了創造高品質的軟體，如何進行高品質的管理；而這本書是說明如何創造出實踐必要的變革所需之環境，在這種環境下，專案的品質與生產力都會有大幅的進步。
變革聽起來很偉大，其實就是改變，無論是組織引進一項新工具、改善流程、或是來了一個新主管，或是在個人層次的改善，都是一種變革。為了能夠成功變革，個人和組織都必須學習，能夠成長。
然而軟體這個行業，由於一直以來未能創造出一個有利於軟體工程的環境，使得軟體產業在實踐品質與生產力方面，大多數都以失敗收場。為了改善糟糕的情況，大多數的經理人將錢花在工具、方法論、外包、訓練、套裝應用軟體上，而沒有用心去改善、或撤換掉那些造成這種後果的始作俑者－－經理人。
在本系列的前三卷已談到，想要在軟體工程的管理上獲得高品質的成果，需要具備以下三種能力：
1. 具有了解複雜情況的能力，讓你能夠為專案做好事前的規畫，從而進行觀察並採取行動，使專案能依計畫進行，或適時修正原計畫。（第1卷）
2. 具有觀察事態如何發展的能力，並且有能力從你所採取的因應行動是否有效，來判斷你觀察的方向是否正確。（第2卷）
3. 在複雜的人際關係中，即使你會感到迷惘、憤怒、或是非常害怕，甚至害怕到想要一走了之並躲起來，但你仍然有能力採取合宜的行動。（第3卷）
本書所談的組織變革，就是要讓經理人運用前三卷的觀念和工具來進行管理，讓你的組織不僅現在能了解和實踐優良的軟體工程觀念，未來也可以。這樣的組織稱為「防範未然型」（Anticipating）的組織，它讓組織變革成為一種明確的、普遍性的功能。
「防範未然型」的文化具有四個特性：
1. 它具有有效的模型，以協助人們在理智與情感上了解組織與個人的改變。
2. 組織裡的員工（不光是經理人）有相當高的比例是擁有技能的變革能手（change artist），他們獲得組織實務上的支持，能夠使變革順利進行。
3. 「防範未然型」組織總是前瞻未來，並且為變革做好規畫。在變革能手的協助下，這種文化知道如何堅持到底執行計畫。
4. 「防範未然型」文化讓有計畫的變革立足於健全軟體工程實務的基礎上，使評量和預測得以進行。
本書的主題包括：常見的變革模型、薩提爾變革模型、外來成分（foreign element）、變革才能（change artistry）、變革能手（change artist）、個人對於變革的反應、設計債務、維護債務、統合規畫（meta-planning）、戰術性變革規畫、變革專案vs.軟體專案、流程原則與模型、為什麼專案會失敗、流程的三種含義、流程改善的三種層次、需求流程與管理、測試vs.竄改程式、正確地啟動專案、正確地維持專案、適當地終止專案、保護資訊資產、技術移轉的法則、以及六個附錄幫助複習本系列所運用到的觀念模型。
組織需要成長，個人也需要不斷學習，以因應變化，為未來做好準備。本書將幫助您成為傑出的軟體工程經理人，並有能力帶領整個組織進行轉型。也讓您的組織能夠邁向永續學習、持續改善。
目录
致台灣讀者 傑拉爾德．溫伯格 7
Preface to the Chinese Editions 10
〔導讀〕從技術到管理，失落的環節 曾昭屏 13
〔推薦序〕期望改變又不想受傷害的軟工思維 王克明 17
編輯說明 24
謝詞 35
前言 39
第一部 讓變革真正能夠發生的模型
1 一些常見的變革模型 45
1.1 擴散模型 46
1.2 地板有洞模型 48
1.3 牛頓模型 53
1.4 學習曲線模型 57
1.5 心得與建議 59
1.6 摘要 60
1.7 練習 62
2 薩提爾變革模型 65
2.1 模型綜述 65
2.2 第1階段：近期現狀階段 67
2.3 第2階段：混亂階段 72
2.4 第3階段：整合與實踐階段 74
2.5 第4階段：「新現狀」階段 77
2.6 心得與建議 79
2.7 摘要 82
2.8 練習 84
3 對變革的反應 87
3.1 抉擇點 88
3.2 運用麥理曼的時區理論來決定變革介入時機 94
3.3 資訊流動的方式 97
3.4 統合變革 100
3.5 防範未然型組織中的變革 102
3.6 心得與建議 104
3.7 摘要 106
3.8 練習 109
第二部 防範未然型組織中的變革才能
4 變革才能 115
4.1 個人對變革的反應 116
4.2 個案研究：變更座位安排 121
4.3 個案研究：程式碼修補 123
4.4 個案研究：知道什麼事該丟下不管 125
4.5 心得與建議 127
4.6 摘要 128
4.7 練習 131
5 大部分事情維持不變 133
5.1 你在維持什麼？ 134
5.2 揭露使用中的理論 138
5.3 變質 140
5.4 設計維護債務 141
5.5 變革才能債務 144
5.6 破壞變革才能 145
5.7 經理人的簡單規則 148
5.8 心得與建議 149
5.9 摘要 150
5.10 練習 153
6 練習成為變革能手 155
6.1 去上班 155
6.2 做一項小改變 157
6.3 什麼都不改變 160
6.4 改變關係 162
6.5 成為觸媒 165
6.6 完全在場 167
6.7 完全不在場 170
6.8 應用加法原則 172
6.9 安排「大旅行」（Grand Tour） 174
6.10 以史為鑑 176
6.11 將理論化為實務 178
6.12 自我發展 180
第三部 替未來的組織做規畫
7 統合規畫第一部分：資訊 183
7.1 從統合規畫開始 184
7.2 資訊蒐集 188
7.3 技巧 201
7.4 心得與建議 203
7.5 摘要 205
7.6 練習 207
8 統合規畫第二部分：系統思考 211
8.1 解決問題 212
8.2 成長與規模 215
8.3 風險與報酬 222
8.4 信賴 227
8.5 移除掉完全靜止不動 230
8.6 心得與建議 234
8.7 摘要 236
8.8 練習 240
9 戰術性變革規畫 243
9.1 何謂戰術性變革規畫？ 244
9.2 開放式的變革規畫 245
9.3 以倒推方式做規畫 247
9.4 挑選實際可行的新目標 250
9.5 從頭到尾言行一致 253
9.6 挑選與測試目標 255
9.7 什麼會妨礙達成目標？ 260
9.8 面臨不可預測性時的規畫模型 261
9.9 回饋計畫 268
9.10 心得與建議 270
9.11 摘要 271
9.12 練習 273
10 以軟體工程師的思維做規畫 275
10.1 工程控制的含意 276
10.2 工程管理行動的基本圖 285
10.3 控制的層級 286
10.4 心得與建議 292
10.5 摘要 295
10.6 練習 296
第四部 應該改變什麼
11 穩定軟體工程的構成要件 301
11.1 為什麼軟體沒什麼不同 302
11.2 為什麼軟體成本如此高昂 304
11.3 何處可找到改進空間 307
11.4 為什麼軟體專案會失敗 309
11.5 資訊失敗 310
11.6 找出資訊失敗的解決方案 314
11.7 行動失敗 317
11.8 心得與建議 319
11.9 摘要 320
11.10 練習 321
12 流程原則 323
12.1 百萬富翁測驗 324
12.2 穩定性原則 326
12.3 明顯性原則 330
12.4 可評量性原則 334
12.5 產品原則 337
12.6 心得與建議 340
12.7 摘要 341
12.8 練習 343
13 文化與流程 345
13.1 文化∕流程原則 346
13.2 文化與流程互動的例子 347
13.3 流程的三種含義 353
13.4 是什麼創造了文化？ 358
13.5 心得與建議 360
13.6 摘要 362
13.7 練習 364
14 改善流程 369
14.1 三種流程改善層次 370
14.2 一個流程改善案例 371
14.3 讓看不見的變成可見 376
14.4 預防未來再發生 377
14.5 學到的教訓 378
14.6 但是我們公司不一樣 379
14.7 但是那代價太高 382
14.8 心得與建議 385
14.9 摘要 386
14.10 練習 388
15 需求原則與流程 389
15.1 固定需求的假設 390
15.2 軟體品質第零法則 392
15.3 需求的流程模型 395
15.4 孿生流程 397
15.5 需求的向上流動 399
15.6 管理階層對需求流程的態度 401
15.7 心得與建議 403
15.8 摘要 404
15.9 練習 407
16 改善需求流程 409
16.1 衡量需求的真正成本與價值 410
16.2 獲得對需求投入的控制 414
16.3 獲得對需求產出的控制 421
16.4 獲得對需求流程本身的控制 425
16.5 心得與建議 429
16.6 摘要 431
16.7 練習 434
17 正確地啟動專案 437
17.1 專案的先決條件 438
17.2 想要的結果 442
17.3 指導方針 444
17.4 資源 446
17.5 責任歸屬 448
17.6 後果 451
17.7 心得與建議 455
17.8 摘要 458
17.9 練習 462
18 正確地維持專案 463
18.1 瀑布模型 464
18.2 級聯模型 466
18.3 疊代強化 468
18.4 可再利用的程式碼 469
18.5 原型設計 471
18.6 重新規畫 474
18.7 心得與建議 479
18.8 摘要 482
18.9 練習 486
19 適當地終止專案 487
19.1 測試 488
19.2 測試vs.竄改程式 492
19.3 如何知道專案何時步入失敗 499
19.4 使專案重生 504
19.5 心得與建議 506
19.6 摘要 509
19.7 練習 512
20 以更小規模更快速建造 515
20.1 更小的意思是什麼？ 516
20.2 縮減規格的範圍 519
20.3 消除最糟糕的部分 520
20.4 盡早拿掉 525
20.5 管理遲來的需求 528
20.6 心得與建議 533
20.7 摘要 535
20.8 練習 538
21 保護資訊資產 539
21.1 程式碼庫 542
21.2 資料字典 543
21.3 標準 546
21.4 設計 547
21.5 測試庫及其歷史 549
21.6 其他文件 551
21.7 增進資產保護 551
21.8 心得與建議 555
21.9 摘要 557
21.10 練習 560
22 管理設計 561
22.1 設計創新的生命週期 562
22.2 設計的動態學 564
22.3 艾德蒙．希拉瑞學派 570
22.4 法蘭克．洛伊．萊特症候群 571
22.5 泰德．威廉斯理論 573
22.6 太多廚師 577
22.7 哎呀！ 577
22.8 心得與建議 579
22.9 摘要 579
22.10 練習 583
23 引進技術 585
23.1 調查工具文化 586
23.2 技術與文化 588
23.3 技術移轉定律 593
23.4 從危機到鎮靜的型態管制 596
23.5 技術移轉十誡 600
23.6 第十一條戒律 606
23.7 心得與建議 607
23.8 摘要 609
23.9 練習 612
第五部 結語
附錄A 效應圖 619
附錄B 薩提爾人際互動模型 623
附錄C 軟體工程文化模式 625
附錄D 控制模型 633
附錄E 觀察者的三種立場 641
附錄F 梅布二氏人格類型指標與四種氣質 643
註解 651
法則、定律、與原理一覽表 673
人名索引 679
名詞索引 683
Preface to the Chinese Editions 10
〔導讀〕從技術到管理，失落的環節 曾昭屏 13
〔推薦序〕期望改變又不想受傷害的軟工思維 王克明 17
編輯說明 24
謝詞 35
前言 39
第一部 讓變革真正能夠發生的模型
1 一些常見的變革模型 45
1.1 擴散模型 46
1.2 地板有洞模型 48
1.3 牛頓模型 53
1.4 學習曲線模型 57
1.5 心得與建議 59
1.6 摘要 60
1.7 練習 62
2 薩提爾變革模型 65
2.1 模型綜述 65
2.2 第1階段：近期現狀階段 67
2.3 第2階段：混亂階段 72
2.4 第3階段：整合與實踐階段 74
2.5 第4階段：「新現狀」階段 77
2.6 心得與建議 79
2.7 摘要 82
2.8 練習 84
3 對變革的反應 87
3.1 抉擇點 88
3.2 運用麥理曼的時區理論來決定變革介入時機 94
3.3 資訊流動的方式 97
3.4 統合變革 100
3.5 防範未然型組織中的變革 102
3.6 心得與建議 104
3.7 摘要 106
3.8 練習 109
第二部 防範未然型組織中的變革才能
4 變革才能 115
4.1 個人對變革的反應 116
4.2 個案研究：變更座位安排 121
4.3 個案研究：程式碼修補 123
4.4 個案研究：知道什麼事該丟下不管 125
4.5 心得與建議 127
4.6 摘要 128
4.7 練習 131
5 大部分事情維持不變 133
5.1 你在維持什麼？ 134
5.2 揭露使用中的理論 138
5.3 變質 140
5.4 設計維護債務 141
5.5 變革才能債務 144
5.6 破壞變革才能 145
5.7 經理人的簡單規則 148
5.8 心得與建議 149
5.9 摘要 150
5.10 練習 153
6 練習成為變革能手 155
6.1 去上班 155
6.2 做一項小改變 157
6.3 什麼都不改變 160
6.4 改變關係 162
6.5 成為觸媒 165
6.6 完全在場 167
6.7 完全不在場 170
6.8 應用加法原則 172
6.9 安排「大旅行」（Grand Tour） 174
6.10 以史為鑑 176
6.11 將理論化為實務 178
6.12 自我發展 180
第三部 替未來的組織做規畫
7 統合規畫第一部分：資訊 183
7.1 從統合規畫開始 184
7.2 資訊蒐集 188
7.3 技巧 201
7.4 心得與建議 203
7.5 摘要 205
7.6 練習 207
8 統合規畫第二部分：系統思考 211
8.1 解決問題 212
8.2 成長與規模 215
8.3 風險與報酬 222
8.4 信賴 227
8.5 移除掉完全靜止不動 230
8.6 心得與建議 234
8.7 摘要 236
8.8 練習 240
9 戰術性變革規畫 243
9.1 何謂戰術性變革規畫？ 244
9.2 開放式的變革規畫 245
9.3 以倒推方式做規畫 247
9.4 挑選實際可行的新目標 250
9.5 從頭到尾言行一致 253
9.6 挑選與測試目標 255
9.7 什麼會妨礙達成目標？ 260
9.8 面臨不可預測性時的規畫模型 261
9.9 回饋計畫 268
9.10 心得與建議 270
9.11 摘要 271
9.12 練習 273
10 以軟體工程師的思維做規畫 275
10.1 工程控制的含意 276
10.2 工程管理行動的基本圖 285
10.3 控制的層級 286
10.4 心得與建議 292
10.5 摘要 295
10.6 練習 296
第四部 應該改變什麼
11 穩定軟體工程的構成要件 301
11.1 為什麼軟體沒什麼不同 302
11.2 為什麼軟體成本如此高昂 304
11.3 何處可找到改進空間 307
11.4 為什麼軟體專案會失敗 309
11.5 資訊失敗 310
11.6 找出資訊失敗的解決方案 314
11.7 行動失敗 317
11.8 心得與建議 319
11.9 摘要 320
11.10 練習 321
12 流程原則 323
12.1 百萬富翁測驗 324
12.2 穩定性原則 326
12.3 明顯性原則 330
12.4 可評量性原則 334
12.5 產品原則 337
12.6 心得與建議 340
12.7 摘要 341
12.8 練習 343
13 文化與流程 345
13.1 文化∕流程原則 346
13.2 文化與流程互動的例子 347
13.3 流程的三種含義 353
13.4 是什麼創造了文化？ 358
13.5 心得與建議 360
13.6 摘要 362
13.7 練習 364
14 改善流程 369
14.1 三種流程改善層次 370
14.2 一個流程改善案例 371
14.3 讓看不見的變成可見 376
14.4 預防未來再發生 377
14.5 學到的教訓 378
14.6 但是我們公司不一樣 379
14.7 但是那代價太高 382
14.8 心得與建議 385
14.9 摘要 386
14.10 練習 388
15 需求原則與流程 389
15.1 固定需求的假設 390
15.2 軟體品質第零法則 392
15.3 需求的流程模型 395
15.4 孿生流程 397
15.5 需求的向上流動 399
15.6 管理階層對需求流程的態度 401
15.7 心得與建議 403
15.8 摘要 404
15.9 練習 407
16 改善需求流程 409
16.1 衡量需求的真正成本與價值 410
16.2 獲得對需求投入的控制 414
16.3 獲得對需求產出的控制 421
16.4 獲得對需求流程本身的控制 425
16.5 心得與建議 429
16.6 摘要 431
16.7 練習 434
17 正確地啟動專案 437
17.1 專案的先決條件 438
17.2 想要的結果 442
17.3 指導方針 444
17.4 資源 446
17.5 責任歸屬 448
17.6 後果 451
17.7 心得與建議 455
17.8 摘要 458
17.9 練習 462
18 正確地維持專案 463
18.1 瀑布模型 464
18.2 級聯模型 466
18.3 疊代強化 468
18.4 可再利用的程式碼 469
18.5 原型設計 471
18.6 重新規畫 474
18.7 心得與建議 479
18.8 摘要 482
18.9 練習 486
19 適當地終止專案 487
19.1 測試 488
19.2 測試vs.竄改程式 492
19.3 如何知道專案何時步入失敗 499
19.4 使專案重生 504
19.5 心得與建議 506
19.6 摘要 509
19.7 練習 512
20 以更小規模更快速建造 515
20.1 更小的意思是什麼？ 516
20.2 縮減規格的範圍 519
20.3 消除最糟糕的部分 520
20.4 盡早拿掉 525
20.5 管理遲來的需求 528
20.6 心得與建議 533
20.7 摘要 535
20.8 練習 538
21 保護資訊資產 539
21.1 程式碼庫 542
21.2 資料字典 543
21.3 標準 546
21.4 設計 547
21.5 測試庫及其歷史 549
21.6 其他文件 551
21.7 增進資產保護 551
21.8 心得與建議 555
21.9 摘要 557
21.10 練習 560
22 管理設計 561
22.1 設計創新的生命週期 562
22.2 設計的動態學 564
22.3 艾德蒙．希拉瑞學派 570
22.4 法蘭克．洛伊．萊特症候群 571
22.5 泰德．威廉斯理論 573
22.6 太多廚師 577
22.7 哎呀！ 577
22.8 心得與建議 579
22.9 摘要 579
22.10 練習 583
23 引進技術 585
23.1 調查工具文化 586
23.2 技術與文化 588
23.3 技術移轉定律 593
23.4 從危機到鎮靜的型態管制 596
23.5 技術移轉十誡 600
23.6 第十一條戒律 606
23.7 心得與建議 607
23.8 摘要 609
23.9 練習 612
第五部 結語
附錄A 效應圖 619
附錄B 薩提爾人際互動模型 623
附錄C 軟體工程文化模式 625
附錄D 控制模型 633
附錄E 觀察者的三種立場 641
附錄F 梅布二氏人格類型指標與四種氣質 643
註解 651
法則、定律、與原理一覽表 673
人名索引 679
名詞索引 683
Quality software management.Volume 4,Anticipating change
- 名称
- 类型
- 大小
光盘服务联系方式: 020-38250260 客服QQ：4006604884
云图客服：
用户发送的提问，这种方式就需要有位在线客服来回答用户的问题，这种 就属于对话式的,问题是这种提问是否需要用户登录才能提问
Video Player
×
Audio Player
×
pdf Player
×
