敏捷與重構

敏捷軟體開發宣言是現正流行的開發精神。敏捷宣言雖然看起來有點抽象,其實背後有十二個原則

我們最優先的任務,
是透過及早並持續地交付有價值的軟體
來滿足客戶需求。

竭誠歡迎改變需求,甚至已處開發後期亦然。
敏捷流程掌控變更,以維護客戶的競爭優勢。

經常交付可用的軟體,
頻率可以從數週到數個月,
以較短時間間隔為佳。

前三點原則,相信老闆聽到都會非常開心。相信這些不只是老闆想要的,團隊也非常想要。

開發者也希望寫好的程式能馬上被使用,並也能常常推出讓使用者滿意的新功能,設計人員、企劃人員亦是如此。

只要先有共識,我們就可以繼續看下去:

業務人員與開發者
必須在專案全程中天天一起工作。

以積極的個人來建構專案,
給予他們所需的環境與支援,
並信任他們可以完成工作。

面對面的溝通
是傳遞資訊給開發團隊及團隊成員之間
效率最高且效果最佳的方法。

大家都希望能做到持續交付(Continuous Delivery),但我們要做什麼事才能達成這個目標呢?

這三個原則告訴我們要持續溝通。為什麼會強調持續溝通呢?這裡來聊個小故事:

圖片來源:壹讀

有本很有名的漫畫叫火影忍者,裡面有個崇高的角色叫火影,而主角漩渦鳴人一開始則是個忍者學校裡的吊車尾學生。但鳴人在故事的中後期,成功的練成火影無法練成的忍術。這個吊車尾鳴人練習的方法是:影分身之術。它能創造另一個鳴人,並且擁有自己的意識,當解除忍術時,會將當時的記憶和知識傳回本體。反覆操作就能短時間得到更多練習經驗,因此最終學成了高難度的忍術。

我們來換成開發情境思考一下:團隊有十個人,如果是九個影分身加自己組成的,工作一天後解除影分身,就可以知道當下所有需求、邏輯、技術、知識、進度等等,而且也會知道目前狀況該做什麼樣的決策,比方說進度超前,可以多花時間在優化程式;或是進度落後,該思考如何用品質換時間等等。

畢竟這是漫畫,現實團隊十個成員都會是不同個體,而各自放在腦袋的東西,只要不溝通是不會有人知道的,如果決策者不注意警訊的話,很容易會因為資訊不足而下錯決定;而有持續溝通的團隊則會像鳴人一樣,將成為一個強大的自我組織團隊,持續為公司產生價值!

因此,持續溝通是非常重要的敏捷精神!

可用的軟體是最主要的進度量測方法。

敏捷程序提倡可持續的開發。
贊助者、開發者及使用者應當能不斷地維持穩定的步調。

持續追求優越的技術與優良的設計,
以強化敏捷性。

能快速交付當然很好,但持續交付才是敏捷精神所提倡的。

為了要擁抱改變,在需求調整的過程中,技術債有可能會不斷產生,要如何做到持續?當然,除了團隊要追求技術之外,還要持續改善品質,才有辦法做到持續交付。

是的,為了改善品質,這時候我們就會需要重構

精簡──或最大化未完成工作量之技藝──是不可或缺的。

最佳的架構、需求與設計皆來自於
能自我組織的團隊。

團隊定期自省如何更有效率,
並據之適當地調整與修正自己的行為。

最後,團隊要有自信但不能自滿,隨時面對環境變化做調整,並持續精進個人技術,才是一個好的敏捷團隊。

重構與敏捷開發方法

許多敏捷開發方法的概念與重構在做的事很雷同,因此敏捷開發很適合使用重構,甚至會要求流程也要使用重構!

以下是幾個跟重構有相關的敏捷開發方法:

TDD / BDD

TDD(Test-driven development)與 BDD(Behavior-driven development)要求先要有規格,再開始寫程式,而最後再進行重構。換個角度來看,它們都是先處理簡單的目標,快速達成後,再開始改善架構。

雖然軟體是軟的,改善架構的難度理論上是簡單的,但只要範圍一大,難度就會指數性上升。TDD / BDD 建議每做一個功能,就重構一次,只要有做到頻繁重構,每次重構的難度就不會太高--因為每完成一個功能就立刻清理當下的技術債,就比較不容易被循環利息懲罰。

Scrum

Scrum 支持先交付不完美、但可以操作的成品,接著得到使用者回饋,進而持續改善產品。

同樣地,重構也支持先設計不完美、但可以跑的程式,後續再做設計的改善。

今日回顧

  • 持續交付,並且產品與團隊都要一同持續改善,這就是敏捷精神
  • 重構可以改善品質,它也非常符合敏捷精神

參考資料