2021 與 2022 對我來說是從業以來非常特別的兩年。參加了一次 iThome 舉辦的鐵人賽，得了個獎，又蒙博碩出版社厚愛，出了一本書：「你就是不寫測試才會沒時間」。短短兩年，這個普通得不能再普通的 RD，在社群間好像變得有一點知名度，也開始偶爾會有一些社群、企業，或是學校來找我去演講或是授課。曾經有一次，我還很有印象，有個社群活動的主持人介紹我時說的是：「歡迎測試專家，Kuma！」
慚愧慚愧，我不是專家。
我在 2013 年開始我的第一份工作，那時是在一間德商用 Ruby on Rails 開發倉儲管理系統。那時我認真見識到德國人的治軍嚴謹。首先工作不分大小，一律「要跑完完整流程」，也就是 SA -> SD -> Dev -> Unit Test -> 人工驗測，到每兩個月一次，為期兩週的 Code Freeze 大驗測，這時才能上線。當中流程缺一不可，所有過程都要有記錄，再簡單的功能也要照規格測。重點，Unit Test Coverage 要到 100%。
回想起來，我的第一份工作為我建立了不少重要的開發習慣與測試觀念，這些習慣後來解決（及預防）了我不少問題。例如，知易行難的「Code Freeze 期間絕對不加新功能」就是其中一個。這件事，我還蠻感恩的。
還記得最一開始接觸敏捷開發的課程，是在 2017 年，因為朋友的介紹，與幾位同事一起去參加了泰迪軟體難得南下台中舉辦的「Scrum敏捷方法實作班」。在那之前只懂得「你給我 deadline，我給你東西」的我來說，那幾天的課程，算是工作方式的大洗禮，也是價值觀的轉變起點。
說到底，我們到底為了什麼而要準時交付？應該也是為了創造價值吧。但，隨著工作的時間一長，這個連結會慢慢淡去。什麼意思？就是你會變得專注於「如何準時交付」。此時，你的目標被拉近了，變成準時交付了。雖說準時交付也沒什麼問題，但問題就在於當你專注於準時交付這個目標時，其他會影響價值的事情就會自動被忽略，例如彈性與環境變化。
當然，那時的我沒想這麼多，只覺得這種工作方式太讚了，可以有長遠目標，同時還能專注於眼前事物，這長遠目標還能隨外在因素調整。看我還不帶回去跟大家分享然後用爆？
然而，你知道，我知道，獨眼龍也知道，在組織內「導入敏捷」，是一件多麼難的事情。不管是從上到下，或是像我們一樣從下到上都一樣。不願意改變的人就是不願意改變。他寧可眼睜看著看板上他的工作卡在那邊三個月也不願意想辦法讓它流動一下，當他的 WIP 到達上限時他就會選擇開新工作來做，並且不告訴任何人，也不放在看板上了。你說，遇到這樣的同事，你要怎麼敏捷？
以前我會不太高興，我這不是在幫你嗎？我這不是在幫公司改善流程嗎？為什麼你們要這樣扯後腿？後來才知道，不是人家在扯後腿，而是人家就不困擾，你是要怎麼解決他們的問題？
我曾與我的好友 Enya Liao 聊過這個問題，她對我說，「一個組織會保持這個樣子，一定是大部份的人內心都希望它長這樣，不管他們嘴上怎麼說。」
經過一番思考，我懂了。
現在公司的工作流程會長這樣，肯定是長時間演進下來，大家共同（或各自）解決了一個又一個問題之後，逐漸成形的樣子，你一個小 RD，上一兩個課回來，就想用你的方式來改變大家，那以前大家共同面對的那些問題你能保證不再出現嗎？沒有的話，憑什麼我們要聽你的？
再說了，敏捷也不是一個方法論，也是一種思考的方式。像我這樣想也不想的把外面的一套流程就這麼搬進公司，要大家照做，也不問問人家要不要，這種手段，其實一點也不敏捷呀！真要說，敏捷其實也是一種提高價值的手段。首先不是每個人的價值都跟公司一樣，也不是你比較敏捷你就比較接近公司價值。重點來了：公司價值高你不一定開心。
但，Kuma，你話都說到這了，那你還要敏捷幹啥？
我的回答是：
敏捷是很廣泛的用詞，你打拳可以很敏捷，開車可以很敏捷，而當年滑雪小屋起草的「敏捷宣言」，這幾年也開始被不少人應用在各個「非軟體開發」的領域。開頭也說了，我不是專家，我認識的敏捷，也不過就是拿來解決我開發軟體過程中遇到問題的思考方式或是找到的解方而已。因此，我更傾向加上一個「開發」來形容我即將在本系列文章與各位分享的主題。
至於敏捷開發幫了我什麼？俗話說得好，說不清楚就舉個例。
在剛回台中時，我發現公司沒有配測試員在我們團隊，大家都是忙了好幾週，好不容易做完功能後，開始從頭自己測自己的東西，有問題就自己修，這過程差不多要再花一兩週。原因無他，不外乎兩週前寫的東西你會忘記，不容易修。而修的同時你也不知道有沒有順手改壞其他東西，為了安全，你也只能從頭到尾再測一次。一次加班，兩次加班，加到第三次我真的受不了了，於是就自己把單元測試加上，慢慢地情況就改善了。
注意了，是「慢慢地」。
有了單元測試，我們對工作的定義範圍就比較注重了，因為多做要多花時間嘛！於是我們就跟主管商量，這兩週就做這些事，如果高層問起進度，就可以以兩週為單位回報，主管發現這樣他也很好做事，而且這群人交出來的東西真的不太會錯，於是每次回報進度也就不用傷腦筋抓 Buffer 了。
後來發現還是有些東西的順序我們無法決定，因為我們要服務的對象（stakeholders）很多，而且每個 stakeholder 提的需求都是「這個很急你幫我趕一下」，但我們開發量能還是有個上限，需求一多，就會出現「這個我提這麼久了你怎麼還沒做」的抱怨。雖然我們很想定義這些功能誰比誰更重要，無奈在大組織裡，我們小 RD 根本沒有權限了解。於是我們就準備了一個大清單貼在牆上，每次 stakeholder 拿需求來時，我們就讓他為我們把他的單子貼到清單上他認為適當的位置。後來發現這些 stakeholder 也是有位階高低跟手臂粗細之分的。無論如何，他們可以用他們的方法「聊」出順序，我們就從不知先服務誰的壓力中逃脫了。
後來呢？
後來的故事還有很多，讀者接下來會從這一系列文章中慢慢了解到：「啊，原來 Kuma 真的不是專家呀！（咦）」
總之說到底，Kuma 就是個不太喜歡「卡住」的感覺，喜歡在工作中找瓶頸，並想辦法解決它，再繼續找下一個瓶頸的人。
如果你也認同，也想在工作（尤其是軟體開發）中持續不斷改善環境的人，歡迎你按下訂閱，持續鎖定本系列文章，希望這當中有一些你也遇過的類似狀況，看看有沒有能供你參考的地方。如果有，那就太好了。
啊啊
讀完真的超有感
尤其是這句話
「一個組織會保持這個樣子，一定是大部份的人內心都希望它長這樣，不管他們嘴上怎麼說」
還真是這樣
iThome鐵人賽
看影片追技術