「持續改善」(Kaizen)的方法，最初是由日本持續改進之父豐田汽車公司會長-今井正明，所提出的管理概念，是指逐漸、連續地增加改善。

後來這個方法，引入戴明PDCA的概念，並追求質量第一為優先。敏捷崛起後，利用sprint疊代、review加上retro的方式，達到持續改善的效果。

即使在任何階段，都有可以再改善的項目與方法。

就像現在的團隊有點像「學習型組織」了? 但學習本身並沒有停止，學習是無止盡的，引導新人也是。你永遠都對於Team Member有所期待，你永遠都在引領著他們。

「一旦走入『持續改善』的這條路，是回不了頭的。」這是一張永遠沒有停靠站的單程車票。

也就是說，「選擇，比努力更重要。」

「時間向前走，沒有盡頭，只有路口。」

是你自己選擇了「學習」、「持續改善」這條路，剩下的就只是時間與勇往直前罷了。

我選擇留下，團隊成員也是。React讀書會願意留下來的人也一樣，他們已經為自己邁出了另一大步。

我們的團隊: https://goo.gl/pkaWXf

沒有機會讓大家仔細了解我們團隊是怎麼運作的。但我想在前一篇U型修練的三個階段，我們團隊正處於逐漸前往第二階段，自然流現的狀態。譬如:

「這個設計不符合原先平台的基本樣式設計，是否可詢問A Team確認是否這樣設計有特別的意思，或者改回就用原本預設的樣式?」

「我詢問B Team他們是否可配合commit的時候做CI，順便幫前端webpack做自動bundle build files & commit? 但還考慮到pre-prod 和 production的狀況。目前無法突破。」

「或許只在上測試區的時候做bundle build files & commit。在pre-prod 和 production直接拉code放上去就好。」

「我跟PO提出應該把這一區塊改成跟APP一樣左右滑動的時候，ICON會跟著有反饋的震動效果。」

「desktop版本的menu tree我想重構。」

「mobile的filter我想一次全部換掉。」

「跟A team什麼時候真正在同一個git上開發...。」

很多這樣的問題，以及解決方法不斷地在團隊中流竄著，並逐一被解決。

這是我所觀察，不一定正確，但至少有開始了。

每一天的站會，每一週的例會，每一次的1 on 1 coach，都是重要的，要不斷地重複重要且相同的觀念，不斷地與團隊成員對焦「願景」，達成共識。

相信最近大家都很有感覺，在列車行駛的過程中，火車頭的帶領是很重要的。不斷的修正列車行駛的路線，符合正軌，與達成這台列車所有乘客共同的目標與願景，也就是平安到達目的地。

團隊的領導也是。

很多剛認識我的人，會跟我說，你看起來就是一個脾氣很好的人，你要怎麼管這些人?

再問問自己，我是好主管嗎? 我到底是「好主管」還是「好人」? (from 游舒帆gipi)

最近朋友A的公司也面臨這樣的問題，人們所認為的好人卻不是個好主管，甚至對於整個組織的發展是有害的。

所以朋友A想聯合其他同事，找更上上層的主管，一同想辦法拔掉這位好人主管。此為「下剋上」的情節。雖然不成功便成仁很危險，但想必這樣的狀況積怨已久，而不得不這麼做了。我朋友A認為，

「主管他並沒有扮演好一個主管應該扮演的角色，他沒有帶領團隊成員成長，也沒有帶領部門成功，在他底下只是過的安逸，但沒有成長，部門的績效也不好，這樣在公司也不會有什麼樣的未來。而這些，都是這位主管所間接造成的。」

又回到第一篇我說的，那種相安無事的好。

或許有人會覺得朋友A好好待著，不惹事又可以爽爽過，不好嗎?

第一年你覺得不錯，再過兩年、三年，甚至十年，你可能已經麻痺了。

激勵領導大師Simon Sinek在演講中指出，好的leader，是當團隊遇到危難之急時，sacrifice自己，總是eat last；但除此之外，我認為能帶領團隊走出新的方向，並且讓每個人在團隊中，都能夠有展現自己價值的機會，那才是真正的leader。

這都是為了體現五項修練的系統性思考，最終成為持續改善的「學習型組織」。

工具以及方法都可以再找，但心態與思維難以改變。

如同我團隊投影片中所說，敏捷發展到後來，從疊代變成持續整合，並逐漸改善，成為Dev(開發)與Ops(維運)之間的合作文化，這就是DevOps，所以說DevOps是一種思維，一種團隊與團隊之間自發性的改變。

這樣各項的改變正持續發生在我們的團隊與週遭...

① 減少組織之間的穀倉效應(Silo Effect)

1. 與ops leader密切配合，並在做任何前端上線前，與ops leader討論並主動召開會議，討論上線後的做法；另外在上線維運期間的問題，也配合協助並指導其提出解決的solution。
2. 與QE Team在開發前就先對焦測試案例(test cases)，確認彼此對需求的認知是一致的，若有任何疑問，找PO一起討論。並在上測試環境之前，RD自動or手動自己跑過一次acceptance criteria，確保交付給QE的Quality。到上了pre-production和production，RD一樣主動協助確認一次自己做的需求是否都OK。

② 接受失敗，視其為開發週期中的一個元素 (就是團隊feel safe to take risk)
團隊成員在完成需求上線後，發生問題，協助其找出問題的核心；並鼓勵團隊成員重構程式碼，勇於面對重構後會有的side effect風險，只要做好足夠的防護措施，上線後的問題就是面對並解決它，不責備。

③ 逐漸改善
在專案很趕的狀況下，使用了暫時的症狀解。要求團隊成員要在下一次提出根本解，並且寫下plan逐一改善。

④ 善用工具和自動化
能自動化的東西，就該自動化。比如程式碼風格統一就使用ESlint & Prettier；與Art team之間的溝通就build up style guide；與後端的API串接，在還沒有資料時，就架設mock server做測試。

⑤ 任何事都是可以被量測的
我們每一季前都會和團隊成員，訂定季目標，確認本季的考核方式，會用數據化可測量的實際數字來做評核。

今天下午去參加facebook id8台灣VR/AR開發者大會，本以為會有很多宅宅工程師，後來發現是與FB合作的各家廠商間的打廣告競賽，一位曾經是developer的創業者這麼說:「台灣有很多優秀的工程師很可惜，應該多走出去，open mind一點，多思考這市場、老闆在想什麼，讓台灣走出去。其實台灣在軟體業會很有競爭力的。」

這是思維的改變。想想看，我們自己追求的到底是什麼? 不斷地問自己，跟自己過不去，因為你自己的路只有你自己去走才知道。需要我們走出去，去看待這個世界。