會員日
目前位置: > > > >
溫伯格的軟體管理學:擁抱變革(第4卷)
left
right
  • 庫存 = 6
  • 放入購物車放入購物車
    直接結帳直接結帳
  • 放入下次購買清單放入下次購買清單
本書適用活動

內容簡介

專案為何會落後一年?……因為每次落後一天。——《人月神話》 要有高品質的軟體,就要有高品質的管理。——《溫伯格的軟體管理學》 《溫伯格的軟體管理學》一套四冊,主題分別是: 一、 系統化思考(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.竄改程式、正確地啟動專案、正確地維持專案、適當地終止專案、保護資訊資產、技術移轉的法則、以及六個附錄幫助複習本系列所運用到的觀念模型。 組織需要成長,個人也需要不斷學習,以因應變化,為未來做好準備。本書將幫助您成為傑出的軟體工程經理人,並有能力帶領整個組織進行轉型。也讓您的組織能夠邁向永續學習、持續改善。 【第4卷《溫伯格的軟體管理學:擁抱變革》專業好評】 ◎「溫伯格是一位真正原創性的思想家,他提到的會影響到軟體開發的組織因素,常令我有「原來如此!」的頓悟……這本書是談如何創造出一個環境,使得前三卷所提到的軟體工程文化得以落實。溫伯格談軟體開發的管理,最吸引人之處是他能夠涵蓋各種領域的智慧,包括家族治療理論、人格類型研究、以及他數十年的軟體開發顧問經驗。——Warren Keuffel, Software Development ◎「第四卷提供給讀者,打造高品質的軟體工程組織的藥方……溫伯格指出,要交付高品質的軟體產品及服務,有些工具很重要,但是他正確地建議了更廣泛的技術,包括正式與非正式的組織關係、技術審查與規畫方法、標準、評量方式,與技術基礎設施例如網絡、硬體與軟體工具。」——H. Remus, Computing Reviews 【第3卷《溫伯格的軟體管理學:關照全局的管理作為》專業好評】 ◎「如果你以前是程式設計高手、現在卻為管理問題而苦惱的話,你會發現溫伯格是一位良師,他以本身二十多年的經驗協助程式設計師、團隊領導人和經理人,讓他們在本身專業的心理層面與社交層面獲得成長。這本書可能會讓你對自己目前靠著反射動作所做的一些決定,再做一番深思。光是這一點就讓這本書值得一讀。——Tom Adams, IEEE Software ◎「如果你在意你複雜的開發專案能否準時完成並具有高品質水準,而且不會讓整個團隊因此心力交瘁,那麼你非買溫伯格這本書不可。你不但自己要看,也要買給你的團隊成員看,從經理人開始做起……我強力推薦這本書。」——Ron Jeffries, ATMUSER ◎《溫伯格的軟體管理學:關照全局的管理作為(第3卷)》與創造高品質的軟體有關,而且這本書不是要你使用方法論、CASE工具、JAD或其他有效做法,而是教你應用與優良管理相關的人際基本技巧來創造高品質的軟體。……儘管電腦界人士向來以溝通技巧太差聞名,我們寧可讀ISDN的溝通協定,也不想看有關人力資源管理的書。」——Peter de Jager, CIO Canada ◎「第3卷的主要概念是,除了正確的思考(第1卷:系統化思考)和觀察應該觀察的事(第2卷:第一級評量)之外,你必須能夠把自己的構想和觀察付諸行動。」——GMW, Dorset House Quarterly, Vol. IV, No. 2

目錄

◎致台灣讀者 傑拉爾德‧溫伯格 Preface to the Chinese Editions
◎〔導讀〕從技術到管理,失落的環節 曾昭屏 
◎〔推薦序〕期望改變又不想受傷害的軟工思維 王克明
◎致謝
◎前言

第一部 讓變革真正能夠發生的模型
◎1一些常見的變革模型
‧1.1 擴散模型
‧1.2 地板有洞模型
‧1.3 牛頓模型
‧1.4 學習曲線模型
‧1.5 心得與建議
‧1.6 摘要
‧1.7 練習
◎2 薩提爾變革模型
‧2.1模型綜述
‧2.2第1階段:近期現狀階段
‧2.3第2階段:混亂階段
‧2.4第3階段:整合與實踐階段
‧2.5第4階段:「新現狀」階段
‧2.6心得與建議
‧2.7摘要
‧2.8練習
◎3對變革的反應
‧3.1抉擇點
‧3.2運用麥理曼的時區理論來決定變革介入時機
‧3.3資訊流動的方式
‧3.4統合變革
‧3.5防範未然型組織中的變革
‧3.6心得與建議
‧3.7摘要
‧3.8練習

第二部 防範未然型組織中的變革才能
◎4變革才能
‧4.1個人對變革的反應
‧4.2個案研究:變更座位安排
‧4.3個案研究:程式碼修補
‧4.4個案研究:知道什麼事該丟下不管
‧4.5心得與建議
‧4.6摘要
‧4.7練習
◎5大部分事情維持不變
‧5.1你在維持甚麼?
‧5.2揭露使用中的理論
‧5.3變質
‧5.4設計維護債務
‧5.5變革才能債務
‧5.6破壞變革才能
‧5.7經理人的簡單規則
‧5.8 心得與建議
‧5.9 摘要
‧5.10練習
◎6練習成為變革能手
‧6.1去上班
‧6.2做一項小改變
‧6.3什麼都不改變
‧6.4改變關係
‧6.5成為觸媒
‧6.6完全在場
‧6.7完全不在場
‧6.8應用加法原則
‧6.9安排「大旅行」(Grand Tour)
‧6.10以史為鑑
‧6.11將理論化為實務
‧6.12自我發展

第三部 替未來的組織做規畫
◎7統合規畫第一部分:資訊
‧7.1從統合規畫開始
‧7.2資訊收集
‧7.3技巧
‧7.4心得與建議
‧7.5摘要
‧7.6練習
◎8統合規畫第二部分:系統思考
‧8.1解決問題
‧8.2成長與規模
‧8.3風險與報酬
‧8.4信賴
‧8.5移除掉完全靜止不動
‧8.6心得與建議
‧8.7摘要
‧8.8練習
◎9戰術性變革規畫
‧9.1何謂戰術性變革規畫?
‧9.2開放式的變革規畫
‧9.3以倒推方式做規畫
‧9.4挑選實際可行的新目標
‧9.5從頭到尾言行一致
‧9.6挑選與測試目標
‧9.7甚麼會妨礙達成目標?
‧9.8面臨不可預測性時的規畫模型
‧9.9回饋計畫
‧9.10心得與建議
‧9.11摘要
‧9.12練習
◎10以軟體工程師的思維做規畫
‧10.1工程控制的含意
‧10.2工程管理行動的基本圖
‧10.3控制的階層
‧10.4心得與建議
‧10.5摘要
‧10.6練習

第四部 應該改變什麼
◎11穩定軟體工程的構成要件
‧11.1為甚麼軟體沒什麼不同
‧11.2為甚麼軟體成本如此高昂
‧11.3何處可找到改進空間
‧11.4為甚麼軟體專案會失敗
‧11.5資訊失敗
‧11.6找出資訊失敗的解決方案
‧11.7行動失敗
‧11.8心得與建議
‧11.9摘要
‧11.10練習
◎12流程原則
‧12.1百萬富翁測驗
‧12.2穩定性原則
‧12.3明顯性原則
‧12.4可評量性原則
‧12.5產品原則
‧12.6心得與建議
‧12.7摘要
‧12.8練習
◎13文化與流程
‧13.1文化/流程原則
‧13.2文化與流程互動的例子
‧13.3流程的三種含義
‧13.4是什麼創造了文化?
‧13.5心得與建議
‧13.6摘要
‧13.7練習
◎14改善流程
‧14.1三種流程改善層次
‧14.2一個流程改善案例
‧14.3讓看不見的變成可見
‧14.4預防未來再發生
‧14.5學到的教訓
‧14.6但是我們公司不一樣
‧14.7但是那代價太高
‧14.8心得與建議
‧14.9摘要
‧14.10練習
◎15需求原則與流程
‧15.1固定需求的假設
‧15.2軟體品質第零法則
‧15.3需求的流程模型
‧15.4孿生流程
‧15.5需求的向上流動
‧15.6管理階層對需求流程的態度
‧15.7心得與建議
‧15.8摘要
‧15.9練習
◎16改善需求流程
‧16.1衡量需求的真正成本與價值
‧16.2獲得對需求投入的控制
‧16.3獲得對需求產出的控制
‧16.4獲得對需求流程本身的控制
‧16.5 心得與建議
‧16.6 摘要
‧16.7 練習
◎17正確地啟動專案
‧17.1專案的先決條件
‧17.2想要的結果
‧17.3指導方針
‧17.4資源
‧17.5責任歸屬
‧17.6 後果
‧17.7心得與建議
‧17.8摘要
‧17.9練習
◎18正確地維持專案
‧18.1瀑布模型
‧18.2級聯模型
‧18.3疊代強化
‧18.4可再利用的程式碼
‧18.5原型設計
‧18.6重新規畫
‧18.7心得與建議
‧18.8摘要
‧18.9練習
◎19適當地終止專案
‧19.1測試
‧19.2測試vs.竄改程式
‧19.3如何知道專案何時步入失敗
‧19.4使專案重生
‧19.5心得與建議
‧19.6摘要
‧19.7練習
◎20以更小規模更快速建造
‧20.1更小的意思是甚麼?
‧20.2縮減規格的範圍
‧20.3消除最糟糕的部分
‧20.4盡早拿掉
‧20.5管理遲來的需求
‧20.6心得與建議
‧20.7摘要
‧20.8練習
◎21保護資訊資產
‧21.1程式碼庫
‧21.2資料字典
‧21.3標準
‧21.4設計
‧21.5測試庫及其歷史
‧21.6其他文件
‧21.7增進資產保護
‧21.8心得與建議
‧21.9摘要
‧21.10練習
◎22管理設計
‧22.1設計創新的生命週期
‧22.2設計的動態學
‧22.3艾德蒙.希拉瑞學派
‧22.4法蘭克.洛伊.萊特症候群
‧22.5泰德.威廉斯理論
‧22.6太多廚師
‧22.7哎呀!
‧22.8心得與建議
‧22.9摘要
‧22.10練習
◎23引進技術
‧23.1調查工具文化
‧23.2技術與文化
‧23.3技術移轉定律
‧23.4從危機到鎮靜的型態管制
‧23.5技術移轉十誡
‧23.6第十一條戒律
‧23.7 心得與建議
‧23.8 摘要
‧23.9 練習

第五部 結語
◎附錄A:效應圖
◎附錄B:薩提爾人際互動模型
◎附錄C:軟體工程文化模式
◎附錄D:控制模型
◎附錄E:觀察者的三種立場
◎附錄F:MBTI與氣質 模型

序跋

前言


  此刻我們並不知道,這些「軟體流程改善」的結果是否為典型的結果。我們認為詮釋這些結果最好的方式,就是將這些結果當作是指標,看看它在受到支持的環境下,會有什麼事情發生。❶── J. Herbsleb等人

  這本書要談的是,如何創造一個有利於軟體工程進行的環境。在這樣的環境裏,你的組織將可實現軟體工程協會(SEI)和其他流程改善機構的一些客戶所宣稱的,在品質與生產力方面獲得令人印象深刻的進展。

  本書是《溫伯格的軟體管理學》系列的第四本。前三本書告訴我們必須做些什麼,而這本書是說明如何創造出實踐必要的變革所需之環境。如果你尚未讀過其他三本,閱讀這本書應該會促使你回去讀那三本。你可以用任何順序來閱讀,但這本書應該留到最後才讀,即使那可能是你第二次讀它了。❷

  由於沒有從一開始就創造出一個有利於軟體工程的環境,結果軟體工程的歷史在實現品質與生產力的進展上,大多數是以失敗收場。為了改善糟糕的情況,很多經理人將錢花在CASE工具、CAST(電腦輔助軟體測試)工具、CAD工具、方法論、外包、訓練、應用套裝軟體等方面,但是他們極少一開始就把力氣花在改善、或換掉那些造成這種後果的經理人。

  我們這一行一直是個「尚未成功」的產業,而且除非我們能破除對於「特效藥」的迷思,真正去處理關於經理人的問題,不然我們將永遠是個未成功的產業。這種迷思有一部分是來自於只是將每項工作當作更高階工作之踏腳石的那些經理人。海軍上將瑞克瓦(Hyman Rickover)在談到這類經理人或工作者所犯的錯誤時說:

  「當一個人從事某項工作時(任何工作都一樣),他必須認為他『擁有』那項工作,而他的所做所為,就好像他會永遠一直從事那項工作一樣。他必須負責盡職地關照他的工作,就好像看待自己的事業或自己的錢一樣……有太多人將整個的工作生涯花在尋找下一份工作上。當一個人覺得他擁有現在的工作,也依照這樣的態度來做事,那他根本不需要擔心他的下一份工作。」❸

  身為經理人,我們承認有成長的需要,無論是人或組織都需要成長。請不要沮喪,因為我已經看過數百位經理人成功地成長,我知道我們辦得到。一旦經理人開始成長,我看過他們能成功地進行本書所介紹的許多美妙的軟體工程活動,相信你也做得到。

  這些活動是什麼?《溫伯格的軟體管理學》系列的前三卷談到,想要在軟體工程的管理工作上獲致高品質的成果,你需要具備以下三種基本能力:

  1.     具有了解複雜情況的能力,以便你能為專案做好事前的規畫,從而進行觀察並採取行動,使專案能依計畫進行,或適時修正原計畫。

  2.     具有觀察事態如何發展的能力,並且有能力從你所採取的因應行動是否有效,來判斷你觀察的方向是否正確。

   3. 在複雜的人際關係中,即使你會感到迷惘、憤怒、或是非常害怕,甚至害怕到想要一走了之並躲起來,但你仍然有能力採取合宜的行動。

  第四卷要處理組織變革的問題,並告訴我們如何運用前三卷所提到的工具來進行管理,將原本的組織改造成不僅現在能了解和實踐優良的軟體工程觀念,而且未來也能了解和實踐這些觀念。我們將這種組織稱作「防範未然型」(Anticipating)的組織。

  所有的組織都會改變,但是「防範未然型」組織讓組織變革成為一種明確的、普遍性的功能。與前一階段的「把穩方向型」(模式3)的文化相比,「防範未然型」的文化具有四個特性:

  1.     「防範未然型」文化具有有效的模型,以協助人們在理智與情感上了解組織與個人的改變。

  2.     組織裏的員工(不僅是經理人)有相當高的比例是擁有技能的變革能手(change artist),他們獲得組織實務上的支持,而能夠使變革之輪平順運轉。

  3.     「防範未然型」文化習慣前瞻未來,並為組織變革做好規畫。在變革能手的協助下,這種文化知道如何堅持到底地執行計畫。

  4.     「防範未然型」文化讓有計畫的變革立足於健全軟體工程實務的穩定基礎上,使評量和預測得以進行。

  本書的內容分成四部,分別涵蓋「防範未然型」組織的這四個特性,並說明如何讓組織具備這些特性。

  軟體作家與研究者Capers Jones告訴我們,專案越大,失敗的機率也越高。❹他的觀察適用於軟體專案,但是,要改變你所在的組織的品質文化,其工作份量比起您的組織曾做過的任何軟體專案都要大得多。那正是為什麼我將「組織變革」這個主題單獨寫一本書的原因,也是為什麼它是系列中最後一冊的原因。因為若要獲得成功,你必須從前三冊開始所有的練習。

  為了帶領組織文化的變革,你必須變成一位傑出的軟體工程經理人,而光是閱讀這四卷書是不夠的。這四卷書中大多數的章節都有建議延伸閱讀,而你應該遵循這些建議進行。此外,大多數章節的結尾都有「練習」這一節,讓你在學習的最高潮時檢驗學習的效果。

  談完所有這些之後,你可能發現至少要閱讀四十本書(不是要你立刻讀完!),而這四本書僅僅是個導引,你還需要花幾千個小時練習你所學到的。然而,相較於你為了要成為傑出的軟體工程師,已讀過多少書練習了多少小時,這個負擔似乎還算合理。如果你能這樣努力下去,你必定能達成你的新目標,也就是至少成為一位傑出的軟體工程經理人,能帶領整個組織進行轉型。

  祝你一路順風!

延伸內容

期望改變又不想受傷害的軟工思維


◎文/王克明

  《溫伯格的軟體管理學》這一系列共出版了四冊,每一冊看來都很厚,好像閱讀起來也吃力,但其實如果能抓出作者的假設點,就能掌握出閱讀的目標與方向。若是問我這四冊各用一個字詞來表達主題,那就是:整體、觀察、溝通、實踐。這四項因子,也正是軟體專案開發成功與否的主要關鍵。

  我們並無法完全移植其他成熟產業(如建築、硬體製造業)的成功經驗到軟體這個領域來,原因就在於「變動(Change)」這個最根本的因素。因為變,所以無法事前規劃精密的藍圖再據此施工;也更因為善變,軟體專案無法採用代工業的IPO(Input-Process-Output)亦即瀑布式(waterfall)的管理模式。

  不是要抑制變動,而是要能順應變化;對軟體專案唯一需要保持的信念,就是要不斷做出改變。

  當面對軟體專案多變複雜的特質,第一步就是要能掌握住整體,這也是溫伯格在第一冊《系統化思考》開宗明義所提及,我們所需要的正是「正確的思考」,也就是系統化的思考,因為唯有如此,我們才能「明白自己在做什麼」。系統化思考就是一種架構觀(architecture view),而架構並非單指IT系統如三層式(3-tier),我寧願稱呼這為實作面的分層結構框架。

  誰需要對軟體專案有全貌認知的系統化思考?個人以為兩種角色是必要的:專案經理(project manager, PM)與架構師(architect)。這兩種角色都是在做調和的工作,專案經理調和的是人,架構師調和的是技術。

  人包括了客戶、利益關係人(stakeholder)、團隊開發人員等各類角色。PM講究的是領導統御的能力,而非去精通某種管理工具、技術、方法論等,那些都是次要的。「人」才是PM首要解決的課題,如此才有機會在成本、時程、系統開發規模等找出適切的平衡點。至於品質,那則是架構師的責任了。架構師也是在做調和,只是他調和的是技術,而技術不單是指實作面,也涵蓋了需求分析、結構設計等其他兩個面向,個人擔任軟體顧問多年來的經驗,最常碰到的問題就是這三種面向的不一致與衝突。

  這邊就舉我擔任軟體架構顧問多年來的實務經驗談,簡述關於調和需求、結構、實作三個構面的觀念。

  實作技術人員常指望需求不要頻繁變動,但請記得,需求必然就是會變動,所以我常指導技術人員要具備的心態就是預期所交付的需求都是錯的──但這樣也能開發下去。似乎很神奇?其實需求分析就是抓住參與者(actor)使用系統背後所隱含的意圖,每一個意圖可以視為是一個功能性的目標框架,而後所有相關該功能的細節,包括欄位明細、企業邏輯等,就可以在該目標框架內透過循環(iteration)、漸進(increment)的開發模式,逐步琢磨出精確的細節。

  一開始建立功能目標框架,並可順暢地轉移到實作階段,同樣也是建立程式碼的骨架(skeleton),而細節就是被封裝(encapsulate)在框架之內。請記得,封裝可是軟體設計的第一原則,但普遍軟體開發人員均不自知,幾乎都以資料導向的思維開發系統,如此過早揭露出太多雜質不確定的細節,當然就難以開發維護了。

  再則,共用性的結構設計反而可以延遲開發,待個別功能逐一的實現,再來才去挖掘出這些功能的共用性需求。所以,應付短線時程的專案首重是需求的實現,而當爾後上線系統能提升其再利用性價值,再來才去談及結構面的重整,也就是重構(re-factoring)的功夫了。當然,即使是短線重視個別功能實現的專案,也必須要事先規劃並建立可被延展的框架才能應付重構,例如MVC(mode-view-control)樣式的設計,這些就是較深入技術面的議題了。

  (PS:為何不一開始就專注在共用性的結構設計上?因為那會耗費相當多的開發成本與時程,而這往往都是短線專案最缺乏的。再則,事前的結構設計需要有相當的軟實力功夫,這類人才其實鳳毛鱗角。)

  系統化思考就是在做調和的工作,包括人與技術面等議題。調和的過程中,必然會衍生出諸多的問題──包括技能、技術與溝通(甚至還有政治)等風險,而風險當然及早揭露、及早解決才好。第二冊《第一級評量》談及的就是如何觀察、發現問題的本質,並進而找出解決方案;而第三冊《關照全局的管理作為》則單對溝通議題,進而討論性格分析並找出因應的管理措施(很有意思,軟體工程也需涉獵到心理學這個領域)。

  專案管理者經常喜好找尋工具、方法論來抑制或預防開發過程中所發生的上述問題,但往往導入這些高度儀式化的工具與方法並沒有實際解決問題,反而衍生了更多的問題。問題是不斷在過程當中發生的,所以並沒有固定的方法或工具可以事先預防解決,反而應該要懂得從過程當中觀察再觀察,發現問題的核心,思索應對的策略,動態找出方法來實際解決。

  溫伯格就曾在書中一針見血地提到:專案經理經常對發生的狀況視而不見,甚至已經是麻木不仁了。為何如此?人們總害怕揭露問題反而會損及自己的權益,甚至會造成更多的問題發生。如何解決?整體性的系統思考、學習型的組織、密切的溝通互動,盡量拋開成見與政治面(這點最難)利害關係,才能有機會鼓勵專案開發過程中懂得觀察與發現問題,並進而協同找出應對的解決方案。

  相較於技術衍生的問題,開發過程有更多更需克服的問題是源自於溝通的議題上,所以溫伯格在第三冊專書介紹以「人」為本的職場管理學,甚而還探究性格分析的心理層面。專案管理者需要了解團隊成員的人格類型與心理狀況,甚至更需要的是如何自我覺察,了解自己與他人,改善人際關係,才能轉化為「關照全局」的學習型組織。

  個人是覺得,軟體人員最好真的要先認清自己適合擔任何種角色。這也可以透過PDP統計學的動物性格分析來了解自己與他人的性格傾向。共分為五種:有魄力威權的老虎、活潑愛表現的孔雀、注重細節的貓頭鷹、任勞任怨的無尾熊,以及具多重性格、視環境而轉換的變色龍。舉例來說,就個人多年來的觀察心得,與客戶往來溝通或做需求訪談等需要人際關係的工作,由孔雀性格的人來擔任最適合;寫程式碼,喜愛與技術為伍者由貓頭鷹或無尾熊性格的人來做,產能會最高;領導統御如專案經理的工作,當然就是老虎性格最適切了;至於變色龍性格,嗯,最適合擔任顧問或者軟體架構師了。(這裏僅是簡單的列舉,當然現實上多數人的性格更是複雜錯綜。)

  了解管理者應具備的素養,包括系統性的思考、敏銳的觀察力、關照全局的溝通能力,當然就要在現實的環境中來實踐之,而這也是最後這一本《擁抱變革》所論及的主題──預期軟體專案變動的常態,並進而建構能因應變革的組織,確實有效改善軟體工程的環境。

  沒有絕對的方法可以有效應付變動,但卻有一致性的原則:將變動侷限在可控制的範圍之內。所以溫伯格特別強調了其中的要訣:「動作要早,動作要小,是保持軟體過程都在控制之中的關鍵。」。另外在《顧問成功的祕密》一書中,他也強調了變革應該是:「既可以改變,又不用受傷害。」

  這很有意思,管理者想要改善環境,提升軟體工程的品質,可能有兩種方式:一為革命(revolution),一為革新(evolution)。革命是要抱著不成功便成仁的決心,成效雖快,但也很容易失敗更會受傷害;而革新是採漸進的做法,一次只改一點點,有了一些成效後再往前推進,雖然緩慢但也比較不會受傷害。

  綜合許多軟體大家的成功實務經驗,包括溫伯格本人,建議的做法會比較傾向是革新的漸進式做法。

  所以,現今主流的開發方法論,包括UP(unified process)、Agile、Scrum等,雖然各自實踐的方法不一樣,但對應變動的核心本質卻都是一致的──採用快速循環漸進(iteration & increment, I&I)的開發模式。

  I&I的做法對一個功能單位的實現,至少會切分兩個以上的循環(iteration),第一個循環先建立出包括程式碼的骨架,並確實打通技術關節;第二個循環則著重在於對精細度的要求,包括如資料欄位、企業邏輯(business logic)的正確性,以及對於例外事件的處理(exception handling)。每一次的循環係以「週」為開發單位,在1~2個星期內涵蓋了需求分析、結構設計、程式碼實作(乃至於測試)。如此循環漸增,早一些取得回饋(feedback),早一點揭露風險,如此才有機會應付軟體專案的變動,並且比較不容易受傷害。

  組織要能順應I&I的做法,必然需要經過某種程度的變革,才能讓軟體團隊可以忍受模糊與不確定性。透過本書提供的實踐方法,讓傑出的管理者可以帶領組織預期改變,並進而擁抱改變。「兵無常勢,水無常形,能因敵之變化而致勝者,謂之神。」期待管理者可以成為本書所稱謂的「變革能手(change artist)」。

本文作者王克明(Kenming Wang):
●    現職:HSDc軟體架構師(Software Architect)、資深講師、顧問。
●    曾任:系統工程師、Oracle DBA、IT部門副理、講師、顧問、軟體架構師。《iThome》、《北京程序員》等平面雜誌專欄作者。
●    精通軟體設計本質、物件導向觀念、UML、RUP/XP、軟體架構規劃與設計等。
●    多年來極為豐富之教學經驗,擅長傳授軟體設計本質給學員。
●    Novell CNI/CNI, Microsoft MCSE, Oracle DBA, Java SCJP, UML OCUP等多張專業認證執照。
●    熱愛閱讀,享受學習,擅長觀察與思考,同時亦為圍棋業餘五段棋癡。

作者資料

傑拉爾德.溫伯格(Gerald M. Weinberg)

是美國軟體工程界最著名的人士之一。曾任職於IBM、Ethnotech、水星計畫(美國第一個載人太空計畫),並曾任教於多所大學。他更是傑出的軟體專業作家和軟體管理思想家,因對技術問題與人性問題所提出的創新思考法而為世人所推崇。1997年,溫伯格因其在軟體領域的傑出貢獻,入選為美國計算機博物館的「計算機名人堂」(Computer Hall of Fame)成員。他也榮獲J.-D. Warnier獎項中的「資訊科學類卓越獎」,此獎每年一度頒發給在資訊科學領域對理論與實際應用有傑出貢獻的人士。 溫伯格共寫了30幾本書,包括《顧問成功的祕密》、《你想通了嗎?》、《領導者,該想什麼?》、《從需求到設計》、一共四冊的《溫伯格的軟體管理學》(以上由經濟新潮社出版)、《程式設計的心理學》等等,這些著作主要涵蓋兩個主題:人與技術的結合;人的思維模式、思維習慣與解決問題的方法。 在西方國家,溫伯格擁有大量的忠實讀者。溫伯格現為Weinberg and Weinberg顧問公司的負責人,他的網站是http://www.geraldmweinberg.com

基本資料

作者:傑拉爾德.溫伯格(Gerald M. Weinberg) 譯者:何霖 出版社:經濟新潮社 書系:經營管理 出版日期:2012-05-21 ISBN:9789866031137 城邦書號:QB1091 規格:平裝 / 單色 / 704頁 / 17cm×23cm
注意事項
  • 若有任何購書問題,請參考 FAQ