980
《軟件工藝師：專業、務實、自豪》一2.6 因轉型不佳而表現出的問題
本節書摘來異步社區《軟件工藝師：專業、務實、自豪》一書中的第2章 ，第2.6節，［英］桑德羅·曼卡索（Sandro Mancuso）著 愛飛翔 譯, 更多章節內容可以訪問雲棲社區“異步社區”公眾號查看。
2.6 因轉型不佳而表現出的問題
許多敏捷項目正源源不斷地產出低劣代碼。
幾年之間，許多公司和團隊都加入了邁向敏捷開發的轉型行列。有些公司已經改頭換麵了。雖說有的公司仍然要坐在會議室裏開一個小時會，但原先某些坐著開會的公司，現在已經改為開站會（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發現不夠及時、測試不夠可靠、測試開銷太大、“開發——調試——部署”周期不夠高效、產品構建時間太長、對需求理解得不夠透徹等等。看到這種情況之後，公司很詫異：到底哪出了問題？當初我們要的可不是這種效果啊！公司當初之所以要改變整個流程並采用敏捷開發，主要就是想通過軟件獲得更高的投資回報。
最後更新：2017-06-22 14:02:23