在課堂上，我們進行了一個 workshop，規範了一個明確的產出物作為目標，然後我們有 30 分鐘作為一個 Sprint 來完成一個可交付的產出。時間相當的緊湊，事後想想，如果採用 Scrum 的模型來執行，我們應該每 3 分鐘或 6 分鐘應該進行一次進度的同步工作。然後，在每 3 分鐘到 6 分鐘的時間，為最後的產出做努力。
但是，相場實際的狀況卻是，大家開始討論起該怎麼完成這個產品。整個過程中，我們大約有一半的時間在討論與規劃，就是還沒針對最終產出物捲起袖子開幹。等到，大家討論出一個方針後，我們開始進行製作產品的相關工作。這個 workshop 最有趣的地方，就在於他還必須完成一個 Deployed 的動作。
我們必須讓產品上線，這個 Sprint 才能夠算成功。在製作產品完成後，我們還有五分鐘左右。於是，我們嘗試進行部署。卻發現部署的時間比我們想像的還要久很多。最終，這個 Sprint 我們宣告失敗。
這裡面，其實有很多隱含許多的觀念，底下是自己回顧的心得：
1. 以終為始：我們應該快速地，發布一版到正式環境，以確認團隊了解整個發布程序，並且排除發佈時的風險。對應到實際的案例上，軟體工程師應該都很常遇到，這東西在我們本地端執行都沒問題，但是一移轉到正式環境問題就一大堆。透過這樣的思維邏輯，我們可以更早地面對正式環境的狀況，不會在做了很久之後，才發現有東西需要調整。
2. 用最短的時間產出 End to End 的價值，頻繁地發佈。快速地取得回饋，要比周詳的計畫，但是做了很久專案延宕，無法上線取得價值來說，更有意義。
3. 在之前協同合作時有提到，以拔河為例。當只有一個人的時候，你肯定會用上 100% 的力量。但是，當人一多的時候，大家可能就有所保留。在整個 workshop 中，我們應該沒有發揮整體團隊 100% 的戰力。
4. 快速交付，小步快跑的開發習慣是必須要一段時間練習，讓自己逐漸熟悉這種模式的思維，以任務下來時大家的反應來看。我們都需要一些時間來精熟這樣的模式。
沒有留言:
張貼留言