此為過去的舊文，2015 年 8 月 25 日初次發表於 logdown。
圖片來源：www.freepik.com
2015 年隨著團隊組織方式的改變，個人在團隊中的角色也有了改變，改變至今大概有三個多月，從不同的角度在看事情時，也能得到許多有趣的想法，加上幾次參加C.C. Agile也都能得到意外的驚喜，讓自己反省：自己真的Agile了嗎？真的了解scrum？
敏捷宣言 (Manifesto for Agile Software Development)可能很多人都能朗朗上口(事實上，若隨堂考我，書上或網路上能查到的東西，我通常背不出來，除非我是一個指導別人怎麼跑敏捷開發的顧問，不然背的滾瓜爛熟有什麼意義？)，但其中一句：Responding to change over following a plan，就這樣的一句，都不見得是容易做到的，有時內心其實是在抗拒的，因為人本質(well，我不是心理學家，我可能無法證明這件事)上是有點害怕改變，因此做任何事前，都會有計畫並希望所有的事情都照計畫走。
過去的軟體開發便是想管控變化，很多團隊都使用瀑布模型、使用CMMI...，有趣的是，Royce在論文中提瀑布模型的目的，是要拿它當例子來說明軟體開發不能這樣做！有了完整的分析、設計和計畫，然後盡可能避免變化，但大家都知道這不可行，於是有人提倡了敏捷開發，但即便用了某某敏捷開發方法，擁抱改變依舊不是件簡單的事，因為內心還是有waterfall依舊陰魂不散地在很多小地方出現。在敏捷團隊中，還是有可能聽到這些對話： 「因為沒有細部設計，到時候可能會重工...」
「因為沒有細部設計，我無法決定...」
「某某某又改了什麼設計，重工浪費很多時間...」
回頭想想，敏捷精神到底是什麼？我覺得最核心的部分是快速取得回饋並盡快做調整(或稱trial-and-error process)，如果在這個核心上來看scrum的幾個活動、產出或實踐，也許就能知道自己是否做得好或不好？
Planning meeting - 重點不在於設計是否一定要細到如規格書一樣才能估時數，細節足於開工就夠了，重點在於團隊的理解是否偏離使用者的需求，一些細節在實作的過程中都還能跟PO確認與調整。
Daily scrum - 重點不在於昨天做了什麼？今天要做什麼？還需要多少時間？重點在於我遇到什麼困難，是否需要援助，在會後，scrum master或團隊是否能幫助有困難的人解決問題。
Burn down chart - 重點不在於進度是在線上或線下，重點是在線上時團隊能做出怎樣的調整？在線下時，是否有細節被隱藏，當提前完成時，是否還能再加入新的story。
Review meeting - 前陣子曾在C.C. Agile聽到一個團隊，因為平時story一完成馬上就跟PO驗證，因此除非真的要展示給stakeholder看，或是要跟團隊討論product backlog的優先順序，不然是不舉行review meeting，若核心精神是快速取得回饋並盡快做調整，那當一個story完成馬上與PO確認，有問題在還有時間的情況下，可以調整不是更好嗎？所以重點還是在於如何快速驗證story是否完成。
Retrospective meeting - 重點在於團隊是多認真看待持續改善這件事，願不願意說真話，能不能提出有意義的建言。更重要的是團隊能獲得多少自主調整的空間，在獲得這空間後，團隊是否努力改善自我。
Continuous integration and regression testing - 這幾乎是最能反映核心精神的實踐，由於就是有持續整合與回歸測試，因此能快速取得回饋(建置失敗或無法通過測試)，才能快速調整(修正)。
在原始的scrum中並沒有明確提到user story refinemenet meeting，但在後來很多scrum教材或實施上，都會有這個會議來釐清stakeholder的需求，團隊過去也在這個會議的進行方式上做過多次調整，在團隊分組後，到目前也調整了兩次進行方式，但運作起來總覺得哪裡卡卡的，最誇張的一次是分組後的第一次refinement meeting：全員加班到隔天凌晨，那一次對團隊士氣的殺傷力其實很大，個人認為PO與團隊之間出現了些小裂痕。
因為團隊成員或多或少對於設計有高度的興趣，因此後面的幾次調整還是讓團隊能參與what的設計，個人提出了一些建議，至今我仍然還在想：以我的角色，我當時應該出手建議嗎？後來這建議和其他團隊成員與PO的意見變成了一個新流程。即使是分組後新的流程，回頭看看過去執行的情況，腦海中浮現過去scrum master說過的一句話：我們該不會是mini waterfall吧。
當refinement meeting的重點不在於釐清問題與背後的情境，不在溝通和確認需求，不在找出what，馬上投入到how的細節設計，這設計真的滿足stakeholder需求嗎？當設計細節已經細到UI上的某個元件如何呈現、要有哪些多國語系的key時，這和過去waterfall的差別又是什麼？當為了避免開始施工時發現問題，回頭大幅修改設計(這個自己可能也要反省，因為自己也曾抱怨類似的問題)，因此希望能夠在refinement時確認所有細節時，這樣真的算是擁抱改變嗎？
過去我很喜歡《搶救貧窮大作戰》這個節目，節目尋找經營不善的店家，協助老闆到其他的店進行非常嚴苛的訓練，在獲得技能後改善原有的經營方式，這節目後來有回去追蹤過去參加受訓的店家，有的能延續好的成績，有的則變回跟受訓前沒兩樣，現在想想，這會不會是在守、破、離的成長過程中，其實並沒有在守的過程中，真正理解那些規則、教條背後的意義，並自以為是地進到破與離的階段？或是只在守這個階段原地踏步？
回到敏捷開發或是scrum的方法中，這些活動或教條，依樣畫葫蘆，反覆練習，直到熟練，但真的了解背後意涵嗎？當要根據團隊的情況對現行方法進行調整，進一步到破的階段時，是否沒有偏離原先的價值？是否能擺脫waterfall的心魔？這或許是轉換角色後，我思考最多的問題。當然，如果一開始抓住的核心觀念是錯的，那自然會練成九陰白骨爪或是逆練九陰真經。
