《修改軟件的藝術》
進行一個預期九個月的專案,到第八個月時,我們發現進度比預期晚了六個月。問題在哪?怎麼會變成這樣的呢?
其實我們一直是晚了六個月,只不過我們到第八個月才發現罷了。
—
敏捷迭代的重點,讓你不斷再次確認目標是否產生變化,是否要調整方向步伐,我們是否能如預期般達成目標。
如果不行,在目前的情況下,我們能做什麼是最有價值的行動呢?
在這過程中,避免因為工作任務顆粒度過大,導致資源無法釋放,無法因應變化去選擇有更價值的工作進行,因此承擔機會成本。抑或是得把已經投入資源進行開發,卻仍無法產生價值的半成品放一旁,因此承擔了沈沒成本。
越早發現問題,修復問題的成本與風險越低。頻繁確認目標以及實際的落差、頻繁交付價值、調整行動,這才能應對現代軟體產品的變化性。
我喜歡這本書,也推薦給想要體會在遺留代碼系統中的敏捷實踐為何的朋友。九個實踐如下:
1) 在問如何做之前,先問為什麼做、給誰做、做什麼。(user story template)
2) 小批次建置,每一段之間都是自動化的鐵路,異動量少,建置發生問題時,根本原因越容易找出來,能得到更快的 feedback ,就能更快的做出反應。
3) 持續整合(Continuous Integration), 持續整合說真的跟 build solution 用哪一套的關係不大,重點在團隊能在多快的時間內讓大家寫的程式變成一份並確認執行無誤。
持續整合的有效性與即時性也絕對跟你團隊的分支策略有關。(建議基於主幹的開發)
4) 協作,如何透明順暢頻繁地溝通,又不會花太多無謂的溝通成本,如何確保大家的程式碼理解一致、閱讀無誤。extreme programming 裡面有非常多良好的實踐可以解決這些問題。
5) write clean code,高內聚、低耦合,職責明確,互動簡單,意圖清楚。(簡單設計simplicity 的四條原則)
6) 測試先行,test first, 其實是 think first, identifying requirements first. 在你動手寫產品程式碼之前,總要先搞懂需求的期望是什麼,需求怎樣叫完成。
要滿足使用者哪些情境,才叫符合預期。(這就是驗收測試驅動開發, ATDD)
這才是我們為何要寫程式的目標,接著以終為始,從 ATDD 往下 drill down 多個 TDD 循環以完成所有情境的程式碼,並在每個 TDD 循環中,一分不多一分不少的把力氣花在該花的地方上,並且在每一次的綠燈情況下進行重構。(包含測試程式)
這,才是實務上會 work 的 TDD,這才是為什麼 TDD 是種開發方法論,而不是測試方案。
7) 用測試描述行為,事實上 test-first + test as scenario, 怎麼把繁複的需求功能抽絲剝繭成關鍵情境,並進行排序來達到 baby step 的效果,到這邊6+7 就是 實例化需求(specification by examples)+驗收測試驅動開發(ATDD)+測試驅動開發(classic TDD, 紅燈、綠燈、重構)
8 ) 最後實現設計,意圖導向設計,重構、重構、重構,你得知道怎麼辨識出 code smell, 你得知道重構技巧,你得知道怎麼用最短時間、最低風險,正確地重構你的設計,來讓用的人很好用,看的人很好懂,改的人很好改。
這邊要避免不必要的過度設計,又是一整門學問了。(過度重構也是一種浪費,通常是以 #過度解耦 的模樣呈現。)
9) 從遺留代碼中學習,耐住性子去尊重這些遺留代碼。他們過去有其存在的價值與原因,至少你的薪水可能就是這堆線上又髒又臭的代碼在幫你賺的。
一定要壓抑住自己重寫系統或功能的衝動。
重寫跟重構不一樣的,重寫在實務跟價值上是不會 work 的。
而且,如果每次碰到遺留代碼就想重寫,你就永遠無法具備重構實務產品的能力。
當然,重構之前一定要有測試保護,這也是為什麼你該學的單元測試,是 #針對遺留代碼 如何優雅低風險低成本的加入單元測試。
沒有單元測試的保護,沒有單元測試提供的反饋(自己能做到的獲得最快的反饋實踐就是單元測試),就無法「快速進行較進階的重構」
—
當然,以上有蠻多是書裡沒提到的細節,也是我上課會提到、甚至設計成 workshop 的內容。
寫著寫著沒想到寫這麼多,沒辦法,共鳴點太多了,裡面真的沒啥廢話,也沒啥太打高空的東西。
都是扎扎實實該落地的實踐,要想當個基本功紮實、穩定輸出戰力,要想領的比別人多,就得比比別人具備更多能產生價值的能力。
不要再被你身邊的環境或公司受限住了,那都是你下意識給自己的藉口理由。
你覺得這些東西在你現在的公司工作用不上,所以你不想學。
但因為你不學、不會,又怎麼進得去把這些東西發揮地淋漓盡致的公司呢?人家怎麼會願意用你呢
👉 修改軟件的藝術,請參考 天瓏資訊圖書 上的介紹, https://www.tenlong.com.tw/products/9787115467768
※ 對實踐 5,6,7,8,9 有興趣,想透過實作了解的更透徹的朋友,可以參考底下兩門培訓:
1)演化式設計:測試驅動開發與持續重構 202009,https://dotblogs.com.tw/hatelove/2020/05/08/202009-Evolutionary-Development-TDD-and-Continuous-Refactoring
2)【針對遺留代碼加入單元測試的藝術】202011,https://dotblogs.com.tw/hatelove/2020/05/08/Unit-testing-effectively-with-legacy-code-202011
敏捷 方法論 在 91 敏捷開發之路 Facebook 八卦
「敏捷其實快不起來!認真打底才能起飛」
事實上鈦坦的高階主管核心圈每個人的敏捷觀跟他們的人生,都真的很敏捷。是少數我輔導的客戶中,已經不太需要我再帶什麼敏捷的觀念給管理階層。
我這三年半在那邊幫忙輔導,就是幫忙跟團隊一起把系統打底打扎實,讓團隊能力能迅速提升到更高的層次,讓既有的祖產(legacy code)系統能開始動手術,從架構面把未來 migration 的部分都切開、準備好(我們這三年做了非常多系統的升級、遷徙,那都是像飛機同時在空中飛,在空中要換引擎等級的難度,不停機、不踢人,依據條件比例做 A/B testing 導流),再讓幾位有潛力特質的人當內部種子,在我不在、甚至離開時,他們有能力把新進團隊成員帶起來,有能力面對 legacy 核心進行重構與整理。
當然開發團隊需要進步的地方還很多,但要能同時兼顧產品商業價值/時程,能因應變化迅速自組織產生應變,能像夥伴(而非同事)一樣合作,能讓團隊真的像一個團隊(公車指數幾乎等於團隊人數),算是這個業界很少見的。
我想到第五項修煉裡面,當時 TOYOTA 橫掃全球車市,提出很多製造業封為圭臬的方法論,有許多管理者去 TOYOTA 參考與取經,但這些人總有一部分人說,「你們TOYOTA的 XXX 我們也有,OOO 我們也嘗試過了…」
但他們都只是看到一個單點,都只是看到表面,沒有全局、沒有想經歷過程,只想照虎畫皮就想得到一樣的成果。
那些冰山下的全貌,該打底的功一點都不能少,甚至要求要比傳統的開發方式更高、更多,從基礎建設、系統架構與對應產業領域特色的設計、團隊技能養成、新進成員養成、產品團隊協作、持續改善(包含怎麼觀測、怎麼透明、怎麼讓大家講出內心的話、怎麼自組織的持續訂出改善項目並行動),都涵蓋在目前成果的過程裡面。而敏捷的內化,是大家需要一種共同的價值觀、做事與思考的方式,貫穿各個環節的「線」。
只看敏捷,甚至只看到 scrum,只看到那些活動,自然跟去參訪 TOYOTA 的取經者一樣:「我們也有 daily, 也有回顧, 也有 scrum 啊」
要去找到沒有的部分,要去理解過程,要有決心跟行動力去嘗試,去面對挫折與夠小的失敗,要能建立起持續改善的模式。
—
他們有我一起幫忙,很多公司沒有我一起幫忙,這也是一個特別明顯的差異。
鈦坦是很明確的方向,找專業的人來處理團隊不擅長的事,而公司最重要的動作就是,讓這一個合作的價值最大化,並讓團隊把吸收能力開到最大,慢慢找到團隊適合的種子養成對應的能力,慢慢在不需要外力輔助下,團隊能具備動能做到類似的事(簡單說就是正視弱勢、短板,然後讓團隊找到補足這一塊短板的方式)
敏捷 方法論 在 91 敏捷開發之路 Facebook 八卦
一個新的敏捷團隊建立,在成熟度演進的四個階段。每個階段的特徵表現跟需求並不相同。
終極目標當然是自主管理,但這是階段演進的,不會因為敏捷轉型、scrum或什麼方法論,就讓團隊一步到位,直接進入後面的階段。
所以往往要幾個 sprint (3個以上) ,團隊才有機會趨於穩定,最傻的莫過於就是任務編組,在每一個專案結束就把有默契的一組team拆掉重組,等到下一個專案要開始才從各處重組一個team。這通常都是組織管理者為了政治利益跟籌碼的產物。
#敏捷
#團隊成熟度進化
From 《個體與交互—敏捷實踐指南》