《軟體工藝師：專業、務實、自豪》一2.6 因轉型不佳而表現出的問題

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

許多靈活項目正源源不斷地産出低劣代碼。

幾年之間，許多公司和團隊都加入了邁向靈活開發的轉型行列。有些公司已經改頭換面了。雖說有的公司仍然要坐在會議室裡開一個小時會，但原先某些坐着開會的公司，現在已經改為開站會（stand-up meeting）了。燃盡圖（burn-down chart）、疊代計劃表（iteration backlog）、發行計劃表（release backlog），都成了新的項目管理工具。使用者用例變成了使用者故事。項目經理也成了scrum主管（scrum master）。事實卻是，對這些公司來說，靈活兩個字隻不過是貼在舊工作方式上的新标簽罷了。不過，有些變化還是比較明顯的。看看轉型之前與轉型之後的工作照，你就會發現一些大的差別。現在的辦公室是開放式的，員工之間的隔間（cubicle）沒有了，好幾個人圍着一台電腦工作，到處都是白闆。某些公司甚至整個牆面都是白闆，上面布滿了各色記事貼。這就是很多公司對靈活的了解。白闆上記事貼的數量成了衡量靈活程度的名額。他們以為記事貼越多，就說明公司越靈活。有的公司還采用各種顔色和尺寸的記事貼來表示不同僚項，他們把這種公司視作非常成熟的靈活公司。每個人都在來回挪移那些彩色紙片（有些紙片移動地相當慢，有些稍快一點，還有的根本就不動），并感到相當充實和自在。隻要老闆同意，每位團隊成員都可以做自己想做的事，直到有一天，也許是幾個月過後，也許是一年過後，沉浸在記事貼牆面中的團隊和公司會突然醒悟過來，發現有一大堆令人頭疼的困難正擺在他們面前，這就是向靈活轉型不佳所産生的不良反應（agile hangover）。

他們發現轉型完畢之後，仍然不能迅速傳遞足夠好的軟體。實際上，很多公司和團隊依然沒能解決那些轉型前就已經有的問題。他們仍然需要花很長時間來部署軟體産品。仍然積累了很多尚未解決的技術問題（technical debt，也稱技術債務），一開始就采用靈活來開發的項目竟然也是這樣。開發者沒有積極地運用靈活開發方式。公司裡仍然需要專門的品質控制（quality assurance，qa）團隊。許多公司甚至在每輪疊代過後，還有一段可能持續數天或數周的測試期。修改這樣的應用程式仍然十分困難。代碼庫一團糟，耽誤了工作進度。bug清單也沒有比運用靈活開發方式之前更短。他們還是會寫出那種沒人看得懂也沒人敢去修改的程式來。他們排除故障的主要方式，依然是調試程式并分析日志（log）。有些程式寫出來才幾年，管理者就不打算再用它了，因為那些程式既難于修改，又阻礙業務發展。

新的應用程式雖然采用靈活開發方式建構，卻與轉型前的程式一樣糟糕，依然設計得很差，依然非常複雜，而且依然有很多bug。要發展業務，就需要迅速地應對變化，而這些程式和它們的開發團隊卻做得不夠，沒能“擁抱變化”。開發者的工作流程确實比原來好了，他們之間也确實開始頻繁交流了，然而他們所做的技術工作實際上和從前并沒有什麼差別。老問題依然擺在那裡：技術水準停滞不前、士氣低落、積極性不高、技術問題堆積成山、技術專長不夠突出、發行流程不夠可靠、系統不夠穩定、bug發現不夠及時、測試不夠可靠、測試開銷太大、“開發——調試——部署”周期不夠高效、産品建構時間太長、對需求了解得不夠透徹等等。看到這種情況之後，公司很詫異：到底哪出了問題？當初我們要的可不是這種效果啊！公司當初之是以要改變整個流程并采用靈活開發，主要就是想通過軟體獲得更高的投資回報。