Andrew：首先，我們希望先來談談你的背景。你是怎麼瞭解到有關團隊的運作方式呢？
Mike：好。我想我是比較幸運，大概跟第一個程式設計師的工作有關吧。我的上司他沒當過程式設計師的經理，他不知道該怎麼辦，到了後來他讓我負責，雖然當時我自己也沒有多少經驗。但比起其他開發人員我的經驗是多了一點，當時只有四個人。不久我就成了團隊主管。就從那時起，我開始帶領各式各樣的軟體開發團隊，後來成為幾家公司的工程副總裁。從此我見識了不同種類的公司。
Jenny：透過這些經驗，你能不能告訴我們跟你一起工作過的那些較好的團隊俱有什麼特質？他們是否有相同之處？
Mike：一般說來，我所待過的優秀團隊，他們都能從清晰明確、振奮人心的目標中受益。他們有某種使命感，而且他們也真正的集中心力於此。當你有類似的目標，所有的其他廢話和政治鬥爭，就會被拋到一邊不予理會。
Andrew：你是否曾經覺得團隊裡只有你自己了解目標，其他團員卻不甚明白？你是如何讓所有人的目標都保持一致？
Mike：是這樣的，很多時候團隊並不能馬上了解專案的目標。這部分是專案經理的工作，在敏捷開發中，則是由產品負責人或Scrum 管理師來確保團隊能夠瞭解專案的目標。
回頭去看這個問題的重要性，我們很多人都曾經在以“賺一大筆錢”為目標的公司服務過。這可不是一個很高尚的目標。有一些團隊追求的目標本質上比這個東西更有價值，我要找的是這種團隊。
想賺一大筆錢並沒有錯，但是那並不能讓團隊上下一心，達成一些非凡的目標。沒錯，他們會努力工作，因為他們可以賺很多錢，但我要找的人，他們所能表現出來的工作效率，並非這類的物質獎勵所能激發出來。
我來舉一個例子。我服務過的一家醫療保健公司。事實上，那是第一家有護士電話服務、提供醫療建議的公司。現在這是一個很平常的事，但在20 世紀九十年代初可就很少見。
很多人之所以能在那家公司服務那麼久，因為他們覺得自己能夠改善人們的生活品質。這是一種很大的進步，你只要打電話給護士，不必去看病，馬上就能得到正確的醫療諮詢。
當時有一些典型的案例讓我們繼續維持這個電話服務。其中有一個常常會被提到的是一個年輕的母親，她的孩子生病了卻連絡不到醫生。她打電話來請教護士，然後心情才得到平靜，因為她知道該替她的孩子做些什麼事。
我們希望這個電話服務能夠非常具體的人性化。我們開始每天發出一封電子郵件，內容會提到前一天的每一通重要電話。有些電話的確是拯救了人們的生命。
我們開始把每天接到的電話經由電子郵件傳送給團隊成員，幫助他們了解團隊正在做的事情所產生的影響。我們還做其他類似的事情，盡量使團隊明白為什麼我們要做這個專案。
Andrew：這會對團隊的士氣產生巨大的影響，而且能使團隊融合成一體，不再只是一堆人在一起各自工作，我完全明白這個作用。但我想知道的是這對軟體的品質會產生影響嗎？因為它看起來有這個可能。
Mike：我想這是個很難回答的問題。你做過雙盲組研究嗎？你曾經對別人說：“你今天怎麼了，沒什麼精神？”或“你今天幹勁十足。”然後做對照研究，比較兩者之間所受的影響嗎？
一個具有明確、振奮人心的目標的團隊，和一個能夠寫出高品質軟體並經得起不斷測試的團隊，我相信兩者之間有直接關係。
我總是說做得越好的團隊走得越快。如果你能寫出高品質的程式碼，你就可以加快腳步，因為沒有一堆錯誤的程式碼會拖累你。
我曾經一起工作過的團隊只要他們有明確、振奮人心的目標作激勵，他們的進度就會很快。所以我可以推斷，他們還必須編寫出高品質的程式碼，才能夠做到這一點。
Andrew：快速地完成工作和完成高品質的工作，我真的很喜歡你認為這兩件事情之間有直接關係。
Jenny：實際上很多人對於這點非常難以理解，他們需要經過很長的時間，累積很多經驗才能明白兩者的關係。
我和Andrew 花費了很大的功夫，才把這個理念傳達給所有不同類型的人，因為如果談到先做一些投資，做前期的測試以便用來幫助人們編寫高品質的軟體，似乎就會遇到很多官僚作風的阻擾還要浪費許多額外的時間。
Andrew：很多程式設計師，還包括管理人員，除了編寫程式碼之外，他們總是不願意花費的時間做其他事情，比如弄清楚要開發什麼樣的軟體，應該如何開發這樣的軟體，並把這些要點記錄下來，其實這樣做反而能讓他們編寫出品質更好的程式碼，而且速度會比原來的方式更快。
Mike：我想有很大的部分是我們的溝通不良，沒有告訴大家建構這個應用程式或產品的所有目標。有時候並不需要編寫高品質的程式碼，這種情況下，我們必須要知道，也許快速完成就可以了。
我有一些客戶，他們為了廣告或行銷活動開發一個網站。比方說，我們要為一部即將上映的電影做一個網站，這個網站只會存在幾個月的時間。那麼程式碼就不必俱備像微軟Office那樣的高品質。如果我希望程式碼可以存活10年或更長的時間，那就需要作出投資，編寫更好的程式碼。
Jenny：你前面提到編寫高品質的程式碼會比品質不良的程式碼進度更快，如何對應你現在才說的話？
Mike：哦，那是因為回報是隨著時間的累積才能顯現。編寫高品質的程式碼是一種投資，如果我希望從只存在兩個月的網站回收對品質的投資，可能性很小。
如果應用程式將持續存在多年，我所做的投資就會非常有條不紊，非常小心地編寫程式碼，能夠回收投資的時間就會增長很多。
Andrew：讓我確定一下你的意思。你提到的“投資回收”是指日後的維護開銷更少吧？
這個觀點我同意。團隊需要擴充和維護程式碼的時間相對減少，也更省力，人們遇到錯誤的機會也降低了。但是你也可以容忍產品有更多的缺點存在，並交給使用者使用。如果它要使用數年，使用者將會發現很多缺陷，但是因為只要使用幾個星期或幾個月，所以他們將會容忍這些缺點的存在。你的意思是這樣嗎？
Mike：沒錯。聽起來你們好像有一點懷疑。讓我來證明一下。
想像一下你正在開發一些過去已經完成的應用程式。你很勤奮，對於品質和程式碼的感覺你是最用心的程式設計師。而且你也想開發出高品質的應用程式。它分為兩個部分：
應用程式本身，以及資料匯入常式，你會讓舊系統將資料跑過一次。
情況應該很明確，幾乎每個人處在這種情形下，都會為這個應用程式編寫高品質的程式碼，因為它要執行好幾年。資料匯入常式只需要執行一次。它就不需要像應用程式的其他部分那麼嚴格。
聽起來好像我贊成編寫出糟糕的程式碼，看來我說話必須注意這一點。我想要說的意思是：大多數團隊都不會有類似的討論，其實他們應該討論一下。而且應該讓專案的相關人士一起參加討論：“這個系統的規劃是執行多久？我們的目標是什麼？”我們都忽視了這樣重要的機會。
我會堅持這種想法，如果我們要開發的這個系統，它要執行10 年之久，那我保證它的程式碼品質一定高於使用一次的“資料匯入”常式。我當然要保證不會出錯，我會執行所有的測試，核對程式碼，並且執行一些範例資料，如果看起來還不錯，我的工作才算完成。
Andrew：你知道嗎？我覺得你是對的。我也覺得在專案開始開發時，人們應該訂出一個品質標準。事實上，以傳統品質管理的角度來看，這不正是驗收標準的重點嗎？還有目標的缺陷率？這些都是我們在教科書裡讀到的東西，可是它聽起來像是你說會在現實工作環境中遇見的問題。
Mike：我想這是我們應該討論，但通常卻很少談論到的話題。
想想專案會如何改變。我的意思是，我並不知道人們能不能永遠是這樣的誠實，但是想像一下，如果關鍵專案的相關人士進來說：“這裡是我的專案目標。我期望我職位能再往上爬升。希望這個專案能夠順利完成。而且品質要夠好，要在未來 6 至12 個月內完成，
才不會影響我職位的升遷。之後，我要去另外一個完全不同的部門，以後會發生什麼事和我沒有關係。”
當你聽到這些話，就會知道專案的相關人士的動機了。我也不必去諷刺他。這就是某類型的公司創造出來的動機，但是這也確實是某些人對於應用程式的一種看法，這也就是很多團隊為什麼會被迫編寫出低品質的程式碼，其實他們在大多數情況下都不願意這樣做。
Jenny：那麼，你要如何找出團隊的動機？一個團隊可能願意發行真正優秀的軟體，但如果品質差，會不會影響到團隊的士氣呢？如果團隊的目標大家都不一致，該怎麼辦？比如他們對於要發表什麼東西、為什麼要發表等等這些問題的認知不一樣，該怎麼辦？
Mike：我想舉出一個具體的例子，我去參觀過這家在波士頓的公司。並且跟副總裁見了面，他讓我去他們公司提供諮詢服務。我開始問他希望我幫助的是關於那方面的應用程式。
他們正在開發一個全新的系統，用來取代現有的工作流程系統。原來的系統大概是在2000-2002 年開發使用，其中有一些驚人的JavaScript 程式，今天我們稱之為Ajax 的程式碼，是由之前聘請的諮詢人員開發的。在當時就能開發出這種產品，那些人一定是天才。但是應用程式現在卻極其脆弱，因為它是在真正的Ajax 出現之前的類似Ajax 的程式碼。
我問副總裁為什麼要重新編寫系統，他說純粹為了獲得一個穩定的應用程式，這樣他的團隊不必再每年花很多時間去維護它，這是他唯一的目標。
然後，我就去跟團隊的團員見面。我並不是在尋找誤解或溝通上不順暢，我只是問了一些問題。我說：“你們為什麼要開發這個應用程式？這個專案的遠大目標是什麼？”結果得到的答案有：“我們需要更好的性能”“我們需要更快的處理能力，因為我們現在處理更多的文件。”其中一個答案是：“我們要換一個新的技術，因為我們的CTO 有一次在飛行途中的航空雜誌上看到了這個技術，他決定我們應該要改用新的技術。”
我跟五、六個開發人員交談過，沒有人能夠回答出正確的答案。沒有人的答案和副總裁想開發此專案的想法相同。他們作出的決定，將會導致應用程式產生同樣不易維護的問題。
該公司發行應用程式的方式很有趣，每三個月才向內部使用者發表一次。這很有趣，因為他們的規劃很簡單：“我們能否在6 月30 日之前完成？如果不能，那截止期限就改成9 月30 日。”
因此，老闆說：“嘿，我希望你們能在6 月30 日之前完成，如果不能的話，我也可以理解，因為我知道這個要求有點咄咄逼人。”團隊誤將老闆的話解讀為時程上的壓力，於是犧牲了品質，以達成6 月30 日完工的要求。
當我把這些告訴老闆，他大吃一驚。這是一個從開始就不與專案相關人士溝通的團隊，因此偏離了目標，做出完全錯誤的決策。
Andrew：這很有趣。聽你這麼一說，我幾乎可以聽到Jenny 上次提到之前她參加過的團隊，幾乎發生完全相同的事情。專案的目標很明確，跟截止期限也沒什麼關係。但是她對這個問題的想法和團隊完全不同。她花了不少時間才說服團隊不要在意截止期限，而要把重心放在品質上。Jenny 你還記得那個專案嗎？
Jenny：當然記得，解決問題的最好辦法就是明確的寫下專案的範圍，並確保每個人都能了解。不過你是對的，人們總是會非常重視發行日期，並確保所有工作都能符合預定的時間表。他們並沒有認真的去思考實際要達到的目標到底是什麼。
Andrew：我想這又回到了你一直提到的“明確、振奮人心的目標”。
Mike：沒錯。
Andrew：對於Jenny 提出的有關團隊的士氣和品質的問題，你有什麼看法？
Mike：你的意思是說，團隊的士氣會受到品質問題的影響嗎？我想你們想問的是這個問題。
Jenny：我想問的是，關於建構品質不良的團隊的士氣問題。我的意思是說如果你知道自己建構的東西，比方說品質低劣，這樣沒有事嗎？讓團隊省事而偷工減料，對他們會有什麼影響呢？
Mike：我想這個問題必須要小心的回答，因為有99％ 的時候，團隊認為他們被迫編寫糟糕的程式碼，實際上卻不是這樣。一般而言，這都是專案相關人士與開發人員之間對於專案目標的了解有差距所造成的結果。
剛才我強調過，大部分時間我們應該編寫更高品質的程式碼，但是為了做到這一點有時候就要認識到，並不是一個應用程式裡的所有程式碼都需要具有同樣的品質。
我想說明一下這個相互關係，我記得早期為不同的組織應徵人員時，發現剛畢業學生有些不尋常的地方。他們覺得分配給自己的每項工作都要做到最佳的水準，並且努力做到這一點，同時希望給我留下良好的印象。
我想了一下這個問題，後來察覺到這是他們學生時代保留下來的習慣。你們也上過大學，有五、六個教授是你的老師。不會有哪一位教授會說：“哦，好吧，我會給你高一點的分數，因為這個學期生物課不容易過，所以你只要放出B 級的作業，我就會給你一個 A。
學生的每天功課都是獨立的。所以我在給人們不同的任務時意識到這一點，有時候我必須說：“你必須盡力把這個工作做好。”不過其他時候──讓我們舉個其他工作為例，比如做一個廠商評估，我會說“我們要從我們的應用程式裡選擇一個日曆的小工具（widget）。有八個不錯的東西可以選擇。看來用哪一個都不會有問題。花二個小時去看看，選一個比較好的吧。”
我曾經遇到一個剛離開學校的新人，他們認為自己必須花20 小時來做這件事情，並作出絕對完美的決定。“我們永遠不會後悔這個決定！”他們會這樣想。在這個時候我只希望有一個好的結論就可以了，剩下的18 小時，我希望能用來做其他的工作。
這就是我想要在此說明的差異：並不是一切事情都要做到A 級的品質。大多數的情況下，我們根本沒有機會做到這一點。
這樣說會比較清楚嗎？我可不想讓人以為我容許糟糕程式碼的存在。我舉這個例子的意思是：有時候是可以這麼做的，但通常的情況下是不能這麼做。
Andrew：這麼說就有道理了。
Mike：我還是想對士氣的事情再多做一些評論。不過跟你們的問題有點不同，但我認為它才是真正的問題在這裡。我想告訴兩位我以前工作過的一個團隊。
當時我在公司裡管理一個非常大的專案，同時還進行著第二專案。這兩個專案的重要性並不相對等，但是都很重要。有一些人負責第二個專案，但是有一些非常奇怪的管理限制。
例如，他們被告知不允許在程式碼中做任何的錯誤處理。如果錯誤發生了，上司才不管你呢。應用程式可能當機。他卻一點也不在乎。這可真是奇怪到了極點。
在那之前我就聽說了一些這種不可思議的事情，但我自己的專案極為重要，十分的忙碌。
我根本沒有時間參與另外一個專案。只是聽說了有關它的一些消息。一連幾個的晚上，我睡不著，所以我乾脆一大早起床，就去了辦公室。專案的壓力很大，有一天我早上大約5 點左右，特別提早走進辦公室。那可是上午5 點大家都在睡夢中，當我進入辦公室，遇到的另外兩個開發人員，那是另外一個專案的兩個主要開發人員：Jeff 和Donna。
我說：“你們一大早在這裡幹什麼？”剛開始他們不想談，最後終於承認：“我們來添加一些錯誤處理的程式碼並做一些測試。上頭不讓我們在應用程式中做這些事情，但是我們的自尊心不容許自己做出那種東西，我們不能做出他要求的那種應用程式。”
那天早上5 點，我遇到了他們之後，和他們聊了一下。我是一個經理，他們是程式設計師。他們說：“能不能請你幫幫我們？跟我們老闆談談；弄清楚到底是怎麼回事。我們不能繼續這樣做下去。”這就有關士氣的問題了，他們因為老闆的堅持必須做出一個品質低劣的產品而感到自責。
所以我就去他們的老闆談談，我說：“這是怎麼回事？你為什麼不讓他們加入錯誤處理和做測試，並寫出高品質的產品？我同意他們，你這麼做是錯誤的。”我告訴他發生了什麼事。於是他說了實話。事情是這樣的。
這要回到當時的一種流行趨勢：用城市的名字為專案命名。微軟已經做了，所以很多公司也以城市的名字來做為專案的代號。我的專案名為Napa，是加州的一個城市。他們的專案被稱為Dodge City，就像是老西部的Dodge City。
老闆把這個專案命名為Dodge City，是因為他在環球影城看到的一些佈景，你可以在街上看到一些Dodge City 的招牌，可是只有表面而已，它呈現出建築物的外觀，後面什麼也沒有，沒有實質的內容，它不是真的城市。
這個老闆讓他們開發的應用程式，會在即將到來的貿易展覽會場上用來作為展示的樣品，以吸引人們申請續約，更新他們的舊版。因為人們會看到一個偉大的新版本即將發行。但是實際上，這個版本永遠不會發行。也永遠不會發行下一個新版本。他的目的其實是打算讓人們多花錢購買相關的產品，也就是我正在開發的那個產品。
這些開發人員在開發一個假的應用程式，一個虛假的泡沫軟體（vaporware），（這就是為什麼他們並不需要添加任何的錯誤處理程式碼），只要做成像Norton公司從20 世紀80 年代開始展示的那些漂亮的老模型就可以了。
這個團隊正在做一件不必要、不正當而且是自掘墳墓的事情。除了對你的客戶說謊產生的道德問題之外，這對團隊而言是件多麼糟糕的事情。
Andrew：他們一定非常沮喪，如果當初老闆把所有的細節都說清楚，先告訴團隊目標是什麼，他們可以先弄明白事情的來龍去脈，也許能做得更好，讓產品不必正常工作而看起來卻很真實。
人們在思考專案的時候，會認為專案的產品是要可以正常工作，如果不必這樣，那他們就可以做一些看起來很亮麗、耀眼的東西。老闆需要做的只是事前給團隊一些提示。
Mike：沒錯。老闆需要的就只是一個的完整的執行過程，以便在大型貿易展覽會場上展示。他不需要去展示一些錯誤的功能，他需要一些假資料，繞過那些錯誤的功能。他需要一個規劃過的展示過程，而且在會場上只需執行這個展示。
Andrew：我喜歡這個故事，它跟我們一直在談論的兩個理念緊密相連：一個是時間、品質、和士氣之間的關係，另外一個是如何瞭解願景、了解專案的主要目標，這些會對品質產生極大的影響。
我想這也是我們一直想跟你談話的原因之一，因為你花了很多時間談論實踐和程式設計師應該做些什麼才能讓程式碼變得更好，提高程式碼的品質。
比方說，你在某個現場，你不得不選擇一、二、三種實踐方式，它們可以對程式碼的品質和專案的規劃產生不同的重要作用。如果團隊陷入困境，不知道接下來該怎麼辦，你會告訴他們先做什麼？
Mike：第一個很容易的。我絕對會讓團隊做的首先就是使用持續整合的方法。我覺得這是最重要的事情。
我記得──這大概要回到1992 年。我曾經和一個團隊共事，他們正在開發當時最典型的C++ 應用程式，由於需要依靠一些外部依賴關係之類的東西，建構專案的時間開始延長。當時我們對於要如何經由網路建構伺服器之類的技術還不是很了解。由於種種原因，Novell 印表機佇列正好是我們一直在應用程式中使用的東西。
我知道這聽起來匪夷所思，但在當時它可是很神奇。事實上，我們真的建構了一個監控Novell 印表機佇列的伺服器。Novell 印表機佇列服務真是太好了。他們可以保留任何東西。我們把編譯的工作納入Novell 印表機佇列中，這樣我們有一個建構伺服器，它可以監控佇列，當發現有任何新的東西出現時，就會啟動編譯器自行編譯。
這是一個低級又簡陋的通訊方式。但是在那個應用程式中卻有很好的效果。我們只要把東西插入佇列中，建構程序就會自動執行。
我不知道當初為什麼我們從未想到用它來監控版本控制系統。大概七、八年之後我才見到另外一個團隊做了這件事。這徹底改變了我的想法。這是一個這麼奇妙的技術，當時我怎麼都沒想到。
因此我的第一個建議就是要持續整合。我認為這會使團隊受益匪淺。
Andrew：我喜歡把“持續整合”作為第一步的主意，因為團隊自己就可以完成這件事。
經理不會反對，因為任何經理只要對這個東西有了解，他一定會支持這個主意。而且看起來這是程式設計師應該做的工作。
Mike：沒錯，你說得很對。對於持續整合，人們不會提出反對意見。我覺得你的重點是說，也不必去跟經理說自己正在做持續整合的事，只要做就對了。
我並不打算誤導管理人員。我自己都做經理很多年了。可是還會碰見一些團員困惑的問我：“我該如何說服我的經理同意做持續整合呢？”其實你根本不必去說服他們。我的意思是，你難道編譯程式碼也要說服你的經理批准嗎？這是你工作的一部分，去做就對了。
關於推行持續整合，你的觀點是對的，人們不必去請求准許。也許要買一些硬體或設備，但是只要有一台舊的桌上型電腦，就可以開始做了。
我真心希望團隊要做的第二件事情，就是要達到一定程度的自動化測試。這和持續整合的第一個目標關係密切。應用程式持續不斷的建構是一回事；我們至少可以知道在編譯的層次上都能得到整合。但我確實希望同時能得到一些自動化的測試。這對很多團隊是一個很大的挑戰。
我不在乎他們的自動化測試水準能夠做到哪一個層次，不管是單元測試，還是使用像FitNesse 之類的工具進行我所謂的服務層次的測試，甚至就是多一點使用者介面的腳本測試。
當然，這些測試如何進行，我有自己的偏好，但最重要的是剛開始的第一步。通常，從一些高階的使用者介面開始測試是最容易的方法。必須將以前要用手工執行的回歸測試自動化，取得使用者介面層次的自動化，然後就可以開始添加入其他類型的自動化測試。
Andrew：你好像只解決了程式碼、建構版本和品質測試。但是關於制定計劃怎麼處理？
計劃同樣會對專案產生巨大的影響，但是要讓團隊或老闆能夠接受計劃的想法卻是不簡單，希望兩者同時接受更是出奇地困難。
Mike：我已經寫了一本有關制定計劃的書，因為總是聽到敏捷團隊四處奔波說：“我們是敏捷的人，我們不必制定計劃。”這是早期推廣敏捷的常見現象，一直持續到了2004年左右吧。
它一直困擾我，因為當時我已經在幾家公司擔任工程副總裁。如果我的團隊跑來向我報告說有一種沒見過的流程，然後說它有多麼的奇妙，“使用這種流程可以加快專案的速度，客戶更喜歡這種結果，而且它能提升品質。”還有一些敏捷所能帶來的其他美好的事物。但隨後他們說：“但是我們必須放棄所有的預測規劃。”
我一定會怒氣衝天，因為等於是拿著一個優秀但卻無法使用的流程在戲弄我。我不在乎有這個流程它有多麼的好，如果它不能容許某種程度的可預測性，我就無法使用它。從我在很多團隊裡完成過敏捷的經驗，我知道敏捷團隊可以制定計劃。所以我寫了那本書，目的就只是為了想嘗試消除這個錯誤思想：“我們是敏捷的人，我們不必制定計劃。”
現在很少再聽到關於這類的爭論了，所以我想我的書也發揮了一定的作用。不過最主要的還是時間的因素，團隊證明是可以制定計劃。有很多敏捷團隊都在規劃。這可能就是最大的影響：當人們看到其他團隊在做敏捷計劃，就不會說你不能做。
我當然要求團隊做計劃。但你最初的問題是，我希望團隊首先去做的幾件事情是什麼。通常的情況之下，第一件事情不是規劃。團隊首先要一起做好很多其他動作，然後才能談到規劃能力的問題，那是到了後來才有可能需要去擔心琢磨的事情。
Jenny：你說得很對。我們剛開始這次談話的時候，你提到：團隊如果不能瞭解目標，那會是個很大的問題，他們需要建立一個一致的目標。
我很好奇，你提到的所有的工具，都和執行專案和程式碼有關，並沒有說明如何了解專案的目標。你是否覺得團隊必須改善瞭解目標的能力？你可以推荐哪些相關務實的做法嗎？
Mike：關於改進規劃活動嗎？當然，沒問題。Jim Highsmith 在他的《Agile Project Management》（Addison-Wesley 出版）書裡記錄了一些。他談到讓團隊寫下所謂的“電梯簡報”（elevator statement）。這是個只有兩句話的說明，如果一個陌生人在電梯裡問你：“你最近在幹什麼？”你就可以把“電梯簡報”裡面的話講給他聽。
不過除了這些之外，我也做過其他事情，就像是你發表一件新產品，相關的雜誌將會寫一些評論，團隊希望雜誌會出現什麼樣的評論，那就讓他們以這些評論為目標。
我曾經幫一家做反間諜軟體的公司做過這樣的事情，他們的產品剛被一本雜誌評審為該領域排名第二的好產品，得了編輯推荐的亞軍。我們換個方向思考，如果這是年度排名第二的影片，那麼它的導演會非常的高興。他會賺很多錢。因為導演的電影拿下了該年度的亞軍，大家不會只看第一名的電影而不看第二名的電影。但是，排名第二的反間諜軟體產品呢？人們可能只會買第一的產品。
在這種利基市場裡排名第二對他們公司來說可不是件好事。所以他們認真的準備已經在進行中的內部開發流程變更。有一位名叫Erin 的ScrumMaster 和他們一起工作，我讓Erin要求團隊以雜誌的觀點寫了一篇評論。要等6 個月後下一期的雜誌出刊後才會看到新的評論，團隊希望雜誌出現什麼樣的評論，那就是他們的目標。
他們以雜誌的觀點寫了一篇評論，這就幫他們建立了一個清晰明確、振奮人心的目標，而且效果很好。我記得6 個月之後，雜誌發表評論的那一天。剛好是萬聖節，我在家裡。沒有去旅行也沒外出工作。我帶著小孩玩過了“不給糖，就搗蛋”的遊戲剛回家，大約在晚上10 點15 分左右，準備上床睡覺之前檢查了我的電子郵件，收到了一封Erin 的電子郵件，只有簡單的幾個字“我們贏了！”
一個星期後，我讀到了那期雜誌的真正評論，發現其中有些句子和團隊之前所寫的評論非常的接近：“發現的間諜比其他任何間諜軟體產品還多”“甚至刪除了其他產品無法找到的間諜軟體”。這些句子和團隊在半年前自己寫下的評論詞句非常的相似，他們把它當作產品的目標。
這就是證據，證明了團隊能夠和利益相關人士一起工作，只要弄清楚接下來的6 個月他們要發行的是什麼樣的軟體，然後將其實現，因為在他們的心中有明確而具體的目標。
讓團隊做類似的事情就會強化這個目標。這個目標就會在所有的團隊成員之間形成共享的願景。
Andrew：我還有一個問題想問。我和Jenny已經在全世界做了很多的演講和培訓，而且和軟體行業的許多人相互談論。我注意到一件事情，似乎總是有一小部分人，他們是高度熱心的敏捷傳教士。這個問題你也提到了一點，我在談論的這些人，他們認為敏捷是解決所有問題的最終答案。
我個人不相信所謂的銀彈能夠解決所有專案問題。但我相信很多敏捷團隊使用了一些非常好的務實做法，可以幫助很多敏捷或其他非敏捷的團隊，建構更好的軟體。你也已經提供了一些有關這些實踐的好例子。我也相信，每個人，包括我自己在內，要始終保持著一種開放的心態，而且也應該隨時留意尋找改善軟體的開發方法。
但是存在有少數的狂熱分子和傳教士，據我所知，他們宣稱只有一種真實的方式來建構軟體，而且世界上所有的人都應該改變他們做事的方式，即使他們目前的方法都沒問題。
我注意到你的做法並不是這樣。所以我想知道你是否注意到了我所說的那種狂熱行徑。你怎麼避免落入這種狂熱呢？或者你認為我的看法有問題？這種大聲喧嘩、排斥其他所有軟體開發方法的敏捷傳教法，人們應該落入其中嗎？我知道這是個意味深長的問題，但我想你明白我的意思。
Mike：我認為敏捷的狂熱恐怕不會對我們有什麼實質的幫助。敏捷方法是正確的做事方式。我確實是其擁護者。但是有兩件事情讓我不會成為一個狂熱的敏捷鼓吹者。
第一件事完全靠運氣，因為我一直都是以這樣的方式在建構軟體。我的職業生涯的第一件工作是在一家諮詢公司（那可不是一間小公司）──Andersen Consulting 的一個部門裡開發軟體，那個時候還稱之為“訴訟訊息服務”部。我們處理的是訴訟案件，工作中接觸到的專案都是為被起訴的人和公司提供服務。
我記得曾經為一些知名的訴訟案件工作。當你要為這種類型的專案工作時，可沒有一、二個月的時間讓你去完成它。律師會來跟你說：“我們需要一個程式解決這個問題，現在就要。”我們必須使用非常短的週期和週轉時間，才能處理這類的事情。
我很幸運，而且早在20 世紀 80 年代就已經學會了如何用那種方式建構軟體。我變得敏捷完全是靠運氣和環境所賜。該項工作的業務本質讓我做到這一點。
影響我的第二件事情，我認為是有親身經歷過物件導向的革命性演變過程。我以為敏捷是物件導向革命的第二波浪潮，敏捷是那個想法的延續。這也是為什麼很多偉大的OO（物件導向）思想家多年以前就開始了敏捷運動。他們只是繼續延伸了物件導向的工作方式而已。
我沒聽過有人這麼說：“我要趕去參加OO 設計會議。”他們只是說：“我去參加設計會議。”物件導向贏得勝利，沒有人會再談論OO，不會有人問：“這是一個結構化的設計會議或物件導向的設計會議？”物件導向獲得全勝，它們本來就該如此，在大多數情況下，團隊會進行物件導向開發。（我知道有些應用程式不使用OO，而且也不能使用OO。）
我想敏捷是同類型的東西。我很樂意“敏捷”這個名稱不見了，希望以後不必再談論敏捷軟體開發，我寧願只談論軟體開發。也許這個過程需要花上5 年或10 年的時間，但是到了最後我們都不會再談論到敏捷，它已經變成我們的工作方式。
有些專案或多或少適合使用敏捷，就像有些專案更適合用物件導向的方式來開發，我們不再需要標題是“敏捷”的書籍。我們不再需要敏捷軟體開發大會，只要軟體開發大會就夠了。
敏捷終將消失變成為一種概念，它將獲勝。它會成為我們日常的工作方式。（摘錄整理自本書第11章）
團隊之美──
資深團隊領導人物陳述發人深省並引以為鑑的經歷
Andrew Stellman＆Jennifer Greene／編著；鄭明輝／譯；碁峯資訊出版；售價：580元
《編者簡介》
Andrew Stellman＆Jennifer Green
Jennifer 和Andrew 在1998年開始合作，建構軟體和培訓軟體團隊。他們為所在的公司定義了軟體開發流程，之後共同完成了許多成功的專案。他們的專案一直專注於科學和公共衛生方面，並為Columbia University 公共衛生學院、Columbia University 商學院和National Academy of Sciences 等學校建構軟體。之後他們跨足商業的管理專案及軟體工程咨詢顧問。同時為商界和學術界提供培訓、專案管理、外包專案管理和專業服務。
《受訪者簡介》
Mike Cohn
Mike Cohn是Mountain Goat Software 公司的創始人，該公司提供流程和專案管理諮詢與培訓服務。他的著作包括《Agile Estimating and Planning》（敏捷估算與規劃）（Prentice Hall 出版社）、《User Stories Applied：For Agile Software Development 》（Addision-Wesley Professional 出版社） 以及《Succeeding with Agile》（Addison-Wesley 出版社）。Mike 擁有超過20 年的經驗，曾擔任多家公司的技術高級主管，這些公司包涵了草創企業一直到財富40 強公司。他還經常為雜誌撰文、在大會上做演講，同時也是Scrum 聯盟和敏捷聯盟的創始人之一。他的電子郵件地址是mike@mountaingoatsoftware.com。
熱門新聞
2024-04-22
2024-04-22
2024-04-22
2024-04-22
2024-04-22
2024-04-22