《軟體工藝師：專業、務實、自豪》一2.6.1 轉型不徹底

本節書摘來華章計算機《軟體工藝師：專業、務實、自豪》一書中的第2章 ，第2.6.1節，［英］桑德羅·曼卡索（sandro mancuso）著 愛飛翔　譯, 更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。

這些年我見過許多向靈活轉型的項目，而且也參與了其中一些。很多公司都高調宣稱自己要采用靈活開發，但卻沒有做出實質努力，他們并沒有變得更加靈活。他們把靈活開發想象成一套預先定好的步驟：隻要跟着做，結果自然會好。今天，很多公司和團隊都說靈活開發不管用了，因為他們經曆了向靈活轉型的過程，但轉型過後卻發現情況并未改觀。可他們恰恰忘記了一點：軟體項目的首要目标是傳遞軟體産品本身。

我見過的所有轉型過程幾乎都存在轉型不夠徹底的問題。軟體公司通常會請咨詢機構與靈活教練幫助公司改變開發流程。然而，這些咨詢機構與靈活教練從來不會，或很少告訴員工應該如何寫出品質更高的軟體。總體來看，靈活轉型關注的是流程，而不是技術原則，這也就意味着，轉型對提升開發者水準所起的作用非常小。靈活教練實際上并未改善營運人員、産品服務人員及qa人員的技能。大部分公司在向靈活轉型時，基本上都完全忘記或忽視技術原則。某些水準不高的靈活教練會有一種不夠專業的看法，他們認為：公司裡的開發者已經可以寫出好的代碼了，隻需要令他們融入scrum架構即可。由于公司已經有了優秀的軟體傳遞能力，是以開發者需要做的隻是改善流程、提升溝通能力、擴大參與範圍而已。這樣一來，靈活教練就會覺得隻要改進了流程，其他所有事情都會好起來。在他們眼中，那些開發者無需改變原有的習慣，就能依照新流程制作出優秀的軟體。編寫代碼隻是個簡單的細節問題，不是嗎？你隻需要改善流程就夠了，對吧？不，完全不是這樣。

靈活轉型主要緻力于改善流程、擴大員工參與範圍、簡化繁瑣的規章制度、防止浪費、排定任務優先級、使工作進度更加直覺，以及改進資訊流。這些當然都是迫切需要解決的嚴重問題，公司在重視并改進這些問題之後會大有改觀。不解決這些問題，軟體項目就很難成功。然而，公司卻忽視了靈活開發背後的原則。他們把流程看得比磨煉技術還重要，而涉及流程的每種靈活開發方式，恰恰都需要卓越技術的支撐。公司管理者和準備不夠充分的靈活教練經常會忽視這一點。

靈活社團與精益社團中的許多人都喜歡談論豐田公司的成功經驗，諸如他們改變了流程、減少了浪費（或者說降低了庫存）、限制了正在制作中的産品（work in progress，wip）數量等等。靈活教練與咨詢機構也喜歡向不知情的客戶兜售這種“豐田之夢”。我首先要說的是，造汽車和做軟體完全不同。你不可能駕駛一輛尚未完工的汽車。你也不會在買了車之後跑回制造商那裡，要求加裝車門或把引擎從前面移到後面。

談論豐田公司的輝煌事迹時，這些人很少會問：“這些車如果做得不好會如何？會不會根本沒人來買？要是車身脆弱，每月都要送修怎麼辦？”豐田之是以成功，除了生産流程很好之外，還有個重要因素，那就是車的品質很高。

顧客之是以買豐田車，是因為其做工精良、品質可靠。他們覺得花錢買這種車很值得。他們信賴高品質的豐田車。

開發流程要奏效有個前提，那就是必須以提升産品品質為目标。為此，需要一套能涵蓋各個層面的良好回報系統。而這套回報系統若要奏效，又需要有技術高超且态度積極的專業人員，這些人必須很重視自己的工作，當他們覺得某件事出了錯或者還可以改進時，會勇于提出自己的看法。假如隻關注流程，而把軟體開發看作一條生産線的話，那麼開發者就成了按部就班、朝九晚五的流水線勞工了。這種做法使得回報系統效率低下，進而損害整個項目。

靈活教練

每個行業裡都會有高手和庸人，靈活教練也不例外。有的人完全能領會靈活開發本意，他們在指導公司或團隊進行靈活開發時，一般會同時強調良好的流程和卓越的技術。盡管大部分時間都在關注流程，但他們會和自己的同僚協作，或推薦其他同僚去幫助客戶了解靈活開發背後的技術原則。反之，比較平庸的靈活教練缺乏技術專長，是以隻會強調流程（這會誤導客戶），而且通常根本不提技術。

向公司高管推銷流程要比談技術問題容易得多，公司高管很難明白技術的重要性，也很難了解為什麼需要督促員工努力提高技術水準。高層管理者很容易就能了解流程的重要性，但卻不明白開發者在寫代碼之外參與其他事務究竟會給公司帶來什麼好處。他們也不懂得代碼品質的重要性。隻要開發者寫出的代碼能運作，就夠了。

非技術人員出身的高層管理者很容易被蹩腳的靈活教練誤導。采用了幾個月或幾年靈活開發之後發現效果不佳，靈活教練和管理者經常會指責開發者。有時候開發者的确做得不夠好，但靈活教練和管理者也應該反思這樣一個問題：如何通過靈活轉型來幫助他們做好。

抗拒技術實踐

但還有一種情況，那就是優秀的靈活教練與咨詢公司在盡力幫助客戶，而到了該采用極限程式設計的時候卻出現了問題。許多客戶立刻反對兩個開發者結對程式設計這種做法，他們認為這完全是浪費資金。他們也堅決反對提前編寫測試用例并采用測試驅動開發（test driven development，tdd）。他們會說：“要是用了tdd，那我們的qa團隊怎麼辦？開發者根本不該浪費時間去做測試。我們付錢給亞洲那家公司，就是為了叫它幫着我們做測試的。”

有時這種抗拒情緒來自開發者。他們不了解結對程式設計的好處。有些人覺得這會暴露自己在某些領域的知識缺陷。他們不願意這樣做。他們也看不到編寫測試用例的好處，因為他們覺得優秀的開發者不會犯錯，隻有平庸的開發者才需要寫測試。

如果不編寫自動化的測試，那麼持續內建的意義何在？隻為了確定代碼能編譯嗎？此外，那些客戶也不接受簡潔設計與集體享有權（collective ownership）等理念。管理者眼中的資深開發者，就是那種懂得好多種模式，并且能設計出複雜架構的人，除了這位開發者之外，别的開發者都不明白系統的工作原理。

在這種情況下，如果抗拒來自公司高管，那就應該展示強有力的證據，告訴他們關注軟體品質的重要性。抗拒若是來自開發者，則應該經常派一些有經驗的極限程式設計者與之結對，通過範例來引導他們進行極限程式設計。如果還不行的話，那就考慮用一些新人來替換某些開發者，把熱衷于學習新技術和新做法的那部分開發者留下。

軟體項目管理的誤區

這些年來，我見過很多不恰當的軟體項目開發方式。有些公司認為，軟體項目的成功，就在于請一位業務專家撰寫需求，叫一位技術主管繪圖并編寫文檔（這位主管不參與程式設計），然後再叫一位經理過來督導項目（也就是對項目進行微觀管理）。等這些角色都就位之後，廉價雇用幾個開發者就行了，通常他們會把雇用工作委托給職業中介或人力資源（human resources，hr）。他們太急于求成了——把幾個月前就準備好的一大堆技術文檔和需求文檔堆在開發者面前，然後盼着軟體趕緊完工。一年之後，開發者就會把軟體交給業務人員，大家看到軟體後都非常滿意，并把這款沒有bug的軟體部署到生産環境中去。一切似乎都這麼完美，這麼輕易。遺憾的是，這種方法根本不可行。

根據我參與瀑布式開發項目的經驗來看，這些項目不接觸實際使用者、不與業務人員協作，也不建立迅速的回報回路，于是，其測試階段會變得比前面所有階段加起來都長。如此漫長的測試階段，使我緊張、苦惱，而又失望，但還有更糟糕的情形。我至少見過兩三個公司把整個項目都外包給遠方的開發者（offshore outsourcing，離岸外包），在這種情況下，管理者還能指望什麼呢？把一堆文檔扔給從未見過的開發者，在既不知道其招聘過程，也不了解其技能水準的情況下，怎麼能指望做出來的軟體會完全符合需求呢？有了那幾年不愉快的經曆，我開始懷疑：這種工作模型對于公司來說，是否真的很實惠。

另外一個常見的問題是，軟體項目的主管通常對軟體本身非常陌生。許多主管要麼不是技術人員出身，要麼很多年都沒有寫過一行代碼。在沒有技術人員參與的情況下所做的決策，很可能會引發嚴重後果。軟體項目要想成功，就必須有優秀的軟體開發者參與協作，這些開發者不隻善于打磨軟體，還能幫助業務人員達成他們的業務目标，給他們提供建議、回報以及建設性的批評。

包括靈活開發在内的每一種軟體開發流程都需要卓越的技術。若沒有高超的技術，任何軟體項目都将經曆痛苦而沮喪的開發過程，并使公司付出昂貴的代價。