敏捷前，先做好一件事
【敏捷前，先做好一件事】 檢視 千萬別被scrum看起來簡單的框架誤導，以為scrum的活動(Planning、Daily、Review、Retro)有進行，就代表敏捷了。而是要以當初進行敏捷的痛點或改善為指標，到底有沒有被解決掉，而非活動有沒有執行為依據。 以"為何而做"為依據，最好敏捷啟動前的檢視。 ※基礎檢視 細拆scrum可以分成四個面向，執行、驗證、需求、市場。以漸近變革過程的話，一步步把四個面向依序做好，先學會把事情做好，回頭檢視下做的對不對，會比較容易切入。再以工程來檢視執行面，要先確定是否有足夠穩定的開發基礎來支撐整個敏捷活動。 ※初衷檢視 有沒有在錯誤的出發點下套用敏捷?以為痛點用敏捷就能解掉? 舉個案例， 曾經輔導過團隊，想利用scrum來解決每個人工時不準確的狀況，甚至期望多幾次Sprint後，Task單上的工時就會準確。主管把每個人每個衝刺的總工時精算後，用任務單填滿，更鼓勵工時精確度頒發獎勵。 看別人的案例總是覺得很不可思議，再回頭想想自己，有沒有犯了同樣的錯呢? 敏捷不是解藥，它只會不斷的把有問題的現象加大反應、突顯出來。 在於有沒有能力去主動解決。敏捷前的心態、能力養成，是個很重要步驟，也很容易被忽略。 ※團隊層面檢視 ●如果還沒成立團隊， 要先檢視上、下層有沒有共識、支持、資源，否則就算進行敏捷，只是換個開發方式而已，體質沒變的話，可能會讓事情變更糟糕。一般來說，成員的第一個感受絕對是會議時間變多，沒時間執行，導致慢慢排斥、參與度低然後失敗收場。 ●如果是現有團隊， 要先確定一下目前 團隊的成熟度 ，到底禁不禁的起過渡的變革時期的低潮，撐不撐的過去，或者，目前團隊適不適合。 敏捷團隊的期待是，不需要其它單位的資源或協助，就能夠在團隊內完成所交付的事。假設不是這狀態的話，請先調整後再進行。 敏捷團隊的期待是，大家都能自主完成事情。這通常也表示，團隊成員有一定的成熟度和經驗，都知道自己該做些什麼。在執行過程中，可能會和別人互相影響、配合什麼工作，大致都能提早辨識出來。 反之，假如團隊成員經驗都相當資淺，現實面來說，就要考慮是不是真的要敏捷。有可能在Planning meeting時，成員就規