665
《軟件工藝師：專業、務實、自豪》一2.6.1 轉型不徹底
本節書摘來異步社區《軟件工藝師：專業、務實、自豪》一書中的第2章 ，第2.6.1節，［英］桑德羅·曼卡索（Sandro Mancuso）著 愛飛翔 譯, 更多章節內容可以訪問雲棲社區“異步社區”公眾號查看。
2.6.1 轉型不徹底
這些年我見過許多向敏捷轉型的項目，而且也參與了其中一些。很多公司都高調宣稱自己要采用敏捷開發，但卻沒有做出實質努力，他們並沒有變得更加敏捷。他們把敏捷開發想象成一套預先定好的步驟：隻要跟著做，結果自然會好。今天，很多公司和團隊都說敏捷開發不管用了，因為他們經曆了向敏捷轉型的過程，但轉型過後卻發現情況並未改觀。可他們恰恰忘記了一點：軟件項目的首要目標是交付軟件產品本身。
我見過的所有轉型過程幾乎都存在轉型不夠徹底的問題。軟件公司通常會請谘詢機構與敏捷教練幫助公司改變開發流程。然而，這些谘詢機構與敏捷教練從來不會，或很少告訴員工應該如何寫出質量更高的軟件。總體來看，敏捷轉型關注的是流程，而不是技術原則，這也就意味著，轉型對提升開發者水平所起的作用非常小。敏捷教練實際上並未改善運營人員、產品服務人員及QA人員的技能。大部分公司在向敏捷轉型時，基本上都完全忘記或忽視技術原則。某些水平不高的敏捷教練會有一種不夠專業的看法，他們認為：公司裏的開發者已經可以寫出好的代碼了，隻需要令他們融入Scrum框架即可。由於公司已經有了優秀的軟件交付能力，所以開發者需要做的隻是改善流程、提升溝通能力、擴大參與範圍而已。這樣一來，敏捷教練就會覺得隻要改進了流程，其他所有事情都會好起來。在他們眼中，那些開發者無需改變原有的習慣，就能依照新流程製作出優秀的軟件。編寫代碼隻是個簡單的細節問題，不是嗎？你隻需要改善流程就夠了，對吧？不，完全不是這樣。
敏捷轉型主要致力於改善流程、擴大員工參與範圍、簡化繁瑣的規章製度、防止浪費、排定任務優先級、使工作進度更加直觀，以及改進信息流。這些當然都是迫切需要解決的嚴重問題，公司在重視並改進這些問題之後會大有改觀。不解決這些問題，軟件項目就很難成功。然而，公司卻忽視了敏捷開發背後的原則。他們把流程看得比磨煉技術還重要，而涉及流程的每種敏捷開發方式，恰恰都需要卓越技術的支撐。公司管理者和準備不夠充分的敏捷教練經常會忽視這一點。
敏捷社團與精益社團中的許多人都喜歡談論豐田公司的成功經驗，諸如他們改變了流程、減少了浪費（或者說降低了庫存）、限製了正在製作中的產品（Work In Progress，WIP）數量等等。敏捷教練與谘詢機構也喜歡向不知情的客戶兜售這種“豐田之夢”。我首先要說的是，造汽車和做軟件完全不同。你不可能駕駛一輛尚未完工的汽車。你也不會在買了車之後跑回製造商那裏，要求加裝車門或把引擎從前麵移到後麵。
談論豐田公司的輝煌事跡時，這些人很少會問：“這些車如果做得不好會如何？會不會根本沒人來買？要是車身脆弱，每月都要送修怎麼辦？”豐田之所以成功，除了生產流程很好之外，還有個重要因素，那就是車的質量很高。
顧客之所以買豐田車，是因為其做工精良、質量可靠。他們覺得花錢買這種車很值得。他們信賴高質量的豐田車。
開發流程要奏效有個前提，那就是必須以提升產品質量為目標。為此，需要一套能涵蓋各個層麵的良好反饋係統。而這套反饋係統若要奏效，又需要有技術高超且態度積極的專業人員，這些人必須很重視自己的工作，當他們覺得某件事出了錯或者還可以改進時，會勇於提出自己的看法。假如隻關注流程，而把軟件開發看作一條生產線的話，那麼開發者就成了按部就班、朝九晚五的流水線工人了。這種做法使得反饋係統效率低下，進而損害整個項目。
敏捷教練
每個行業裏都會有高手和庸人，敏捷教練也不例外。有的人完全能領會敏捷開發本意，他們在指導公司或團隊進行敏捷開發時，一般會同時強調良好的流程和卓越的技術。盡管大部分時間都在關注流程，但他們會和自己的同事協作，或推薦其他同事去幫助客戶理解敏捷開發背後的技術原則。反之，比較平庸的敏捷教練缺乏技術專長，所以隻會強調流程（這會誤導客戶），而且通常根本不提技術。
向公司高管推銷流程要比談技術問題容易得多，公司高管很難明白技術的重要性，也很難理解為什麼需要督促員工努力提高技術水平。高層管理者很容易就能理解流程的重要性，但卻不明白開發者在寫代碼之外參與其他事務究竟會給公司帶來什麼好處。他們也不懂得代碼質量的重要性。隻要開發者寫出的代碼能運行，就夠了。
非技術人員出身的高層管理者很容易被蹩腳的敏捷教練誤導。采用了幾個月或幾年敏捷開發之後發現效果不佳，敏捷教練和管理者經常會指責開發者。有時候開發者的確做得不夠好，但敏捷教練和管理者也應該反思這樣一個問題：如何通過敏捷轉型來幫助他們做好。
抗拒技術實踐
但還有一種情況，那就是優秀的敏捷教練與谘詢公司在盡力幫助客戶，而到了該采用極限編程的時候卻出現了問題。許多客戶立刻反對兩個開發者結對編程這種做法，他們認為這完全是浪費資金。他們也堅決反對提前編寫測試用例並采用測試驅動開發（Test Driven Development，TDD）。他們會說：“要是用了TDD，那我們的QA團隊怎麼辦？開發者根本不該浪費時間去做測試。我們付錢給亞洲那家公司，就是為了叫它幫著我們做測試的。”
有時這種抗拒情緒來自開發者。他們不理解結對編程的好處。有些人覺得這會暴露自己在某些領域的知識缺陷。他們不願意這樣做。他們也看不到編寫測試用例的好處，因為他們覺得優秀的開發者不會犯錯，隻有平庸的開發者才需要寫測試。
如果不編寫自動化的測試，那麼持續集成的意義何在？隻為了確保代碼能編譯嗎？此外，那些客戶也不接受簡潔設計與集體享有權（collective ownership）等理念。管理者眼中的資深開發者，就是那種懂得好多種模式，並且能設計出複雜架構的人，除了這位開發者之外，別的開發者都不明白係統的工作原理。
在這種情況下，如果抗拒來自公司高管，那就應該展示強有力的證據，告訴他們關注軟件質量的重要性。抗拒若是來自開發者，則應該經常派一些有經驗的極限編程者與之結對，通過範例來引導他們進行極限編程。如果還不行的話，那就考慮用一些新人來替換某些開發者，把熱衷於學習新技術和新做法的那部分開發者留下。
軟件項目管理的誤區
這些年來，我見過很多不恰當的軟件項目開發方式。有些公司認為，軟件項目的成功，就在於請一位業務專家撰寫需求，叫一位技術主管繪圖並編寫文檔（這位主管不參與編程），然後再叫一位經理過來督導項目（也就是對項目進行微觀管理）。等這些角色都就位之後，廉價雇用幾個開發者就行了，通常他們會把雇用工作委托給職業中介或人力資源（Human Resources，HR）。他們太急於求成了——把幾個月前就準備好的一大堆技術文檔和需求文檔堆在開發者麵前，然後盼著軟件趕緊完工。一年之後，開發者就會把軟件交給業務人員，大家看到軟件後都非常滿意，並把這款沒有bug的軟件部署到生產環境中去。一切似乎都這麼完美，這麼輕易。遺憾的是，這種方法根本不可行。
根據我參與瀑布式開發項目的經驗來看，這些項目不接觸實際用戶、不與業務人員協作，也不建立迅速的反饋回路，於是，其測試階段會變得比前麵所有階段加起來都長。如此漫長的測試階段，使我緊張、苦惱，而又失望，但還有更糟糕的情形。我至少見過兩三個公司把整個項目都外包給遠方的開發者（offshore outsourcing，離岸外包），在這種情況下，管理者還能指望什麼呢？把一堆文檔扔給從未見過的開發者，在既不知道其招聘過程，也不了解其技能水平的情況下，怎麼能指望做出來的軟件會完全符合需求呢？有了那幾年不愉快的經曆，我開始懷疑：這種工作模型對於公司來說，是否真的很實惠。
另外一個常見的問題是，軟件項目的主管通常對軟件本身非常陌生。許多主管要麼不是技術人員出身，要麼很多年都沒有寫過一行代碼。在沒有技術人員參與的情況下所做的決策，很可能會引發嚴重後果。軟件項目要想成功，就必須有優秀的軟件開發者參與協作，這些開發者不隻善於打磨軟件，還能幫助業務人員達成他們的業務目標，給他們提供建議、反饋以及建設性的批評。
包括敏捷開發在內的每一種軟件開發流程都需要卓越的技術。若沒有高超的技術，任何軟件項目都將經曆痛苦而沮喪的開發過程，並使公司付出昂貴的代價。
最後更新：2017-06-22 14:32:01