天天看點

《軟體工藝師:專業、務實、自豪》一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發現不夠及時、測試不夠可靠、測試開銷太大、“開發——調試——部署”周期不夠高效、産品建構時間太長、對需求了解得不夠透徹等等。看到這種情況之後,公司很詫異:到底哪出了問題?當初我們要的可不是這種效果啊!公司當初之是以要改變整個流程并采用靈活開發,主要就是想通過軟體獲得更高的投資回報。

繼續閱讀