敏捷 123起步走~

【敏捷 123起步走~】

最近在公司試驗了小班敏捷體驗專案，先來介紹背景，再來分享過程。

背景：5人，專案大小2個月內，有4人未接觸過敏捷，意願高，技術中上，授權度高

算是極品團隊，那要如何讓在最短的時間內讓大家了解敏捷框架並實際開發呢?

當然就是發揮"做中學、學中做"的精神。雖然專案小、團隊小，但也不能馬虎應付敏捷步驟，否則反而適得其反。

分享過程，還是要提醒一下，每個團隊人員和公司文化不同，不一定能全套用，別人的解藥可能是你的毒藥，參考就好囉!

【啟動 - 為何敏捷】
●啟動會議 - 1.5小時
●團隊建立活動，信任的開始，讓大家先透過活動來認識彼此
●透過會議來向團隊稍微介紹一下敏捷核心精神，接下來會做哪些事情，讓成員有心理準備
●主軸內容：面對VUCA時代、由代工思維轉變成產品思維

【第一次Planning meeting - 成就感】
●讓團隊容易上手為主要訴求
●簡化過程，先請PO寫好這次Sprint要的User Story，討論過後，直接讓成員寫下Task
●這次的User Story要特別與PO設計一下，是容易拆出且不需要太多討論的項目
●訂些Task寫法規則，便利貼右上名字、右下粗估工時、完成時打勾、意外時標記
●因為專案規模不大，使用User Story Mapping取代To do、Doing、Done看板，讓系統全貌能慢慢浮現(這步要好好想一下)
●不用一步到位，過程中漸近調整就好，讓團隊成就感大於挫折感，也是個近程勝利

【Daily - 一天一觀念】
●透過每天的Daily後，補上相關的觀念
●以下的圖都會列印出來，然後貼在看板旁
●適團隊狀況或事件給予相關資訊，下圖是第一個Sprint會提到的
●與其一開始把這些都說完，還不如慢慢釋出消化，讓資訊更貼近實際狀況

          

          

          

          

【第一次Review - 產品思維】
●第一次如果可以的話，安排以內部Review為主，而這樣就需要在第一次的Planning meeting項目調整一下
●先讓成員理解這個會議是什麼，並鼓勵Demo者使用非技術(產品)語言來說明
●以產品思維做任何的提問與討論

【第一次Retrospective - 聚焦討論】
●分析評估團隊成員的個性與技術，再決定用何種方式進行。如果只有太開放的引導工具圖，可能會造成無法深入改善，需靠SM技巧。加強敏捷觀念使用敏捷原則，提供成員思考成長的方向。
●先處理好心情，再來想如何做好事情
●心情圖
●敏捷12原則聚焦改善

【第二次Planning meeting - 產品與任務強連結】
●影響地圖(Impact Mapping)
●同理心地圖(Empathy Map)
●使用者旅程地圖(User Journey Map)
●系統架構圖，為了讓大家對產品認知一致，所以透過以上三個圖來把架構圖一起完成，其實也是想降低開發團隊的不適感，刻意用RD比較熟的描述方式來描述產品。
●系統架構圖裡要包含Impact Mapping的影響者，並把過程中討論出來的功能也加入架構裡描述出來
●系統架構圖 -> 產品架構圖 就是目的，未來也會從以上步驟慢慢精煉出所要的User Story
●當下不需要完整，隨著時間與經驗而發展清楚且正確的產品全貌(盡量延遲決策)
●以產品思維來建立任務

結論：
當SM知道為何要這樣做時，表示已經進入「守、破、離」當中「破」的狀態，會想去多多嘗試不同的組合運用，試著透過迭代嘗試找到最大效益。所以，當SM引導團隊敏捷的同時，其實自己也是敏捷狀態。

拍立得的創立及發明者,蘭德(Ed Land):「每一項錯誤都是一個累積最後成果的事件。」

如同這次專案過程，用了不同的方式運行，過程中找出最適合團隊的模式，即使失敗了，也僅是剔除一個不可行的方法而已。但如果成功，可是會大大造福更多團隊，有更多的選擇來面對VUCA時代的來臨。

敏捷也可以是一種生活哲學，專案如同自己的每個生命事件，道理大家都懂，不斷的透明、檢視、調整達到持續改善，成為更好的自己。但，做到的人卻不多，往往在做決策時卡住停滯，根本在於"擁抱失敗"還只停留在你的"觀念"而不是"信念"。