Odd-e Certified ScrumMaster 心得分享 3 - 快速交付，小步快跑

快速交付，小步快跑

雖然，認識 Agile 或是 Scrum 已經有一段時間，自認對於快速交付及小步快跑也有一定程度的理解。但是，卻沒有像這次在課堂上感受這麼深刻。

在課堂上，我們進行了一個 workshop，規範了一個明確的產出物作為目標，然後我們有 30 分鐘作為一個 Sprint 來完成一個可交付的產出。時間相當的緊湊，事後想想，如果採用 Scrum 的模型來執行，我們應該每 3 分鐘或 6 分鐘應該進行一次進度的同步工作。然後，在每 3 分鐘到 6 分鐘的時間，為最後的產出做努力。

但是，相場實際的狀況卻是，大家開始討論起該怎麼完成這個產品。整個過程中，我們大約有一半的時間在討論與規劃，就是還沒針對最終產出物捲起袖子開幹。等到，大家討論出一個方針後，我們開始進行製作產品的相關工作。這個 workshop 最有趣的地方，就在於他還必須完成一個 Deployed 的動作。

我們必須讓產品上線，這個 Sprint 才能夠算成功。在製作產品完成後，我們還有五分鐘左右。於是，我們嘗試進行部署。卻發現部署的時間比我們想像的還要久很多。最終，這個 Sprint 我們宣告失敗。

這裡面，其實有很多隱含許多的觀念，底下是自己回顧的心得：

1. 以終為始：我們應該快速地，發布一版到正式環境，以確認團隊了解整個發布程序，並且排除發佈時的風險。對應到實際的案例上，軟體工程師應該都很常遇到，這東西在我們本地端執行都沒問題，但是一移轉到正式環境問題就一大堆。透過這樣的思維邏輯，我們可以更早地面對正式環境的狀況，不會在做了很久之後，才發現有東西需要調整。

2. 用最短的時間產出 End to End 的價值，頻繁地發佈。快速地取得回饋，要比周詳的計畫，但是做了很久專案延宕，無法上線取得價值來說，更有意義。

3. 在之前協同合作時有提到，以拔河為例。當只有一個人的時候，你肯定會用上 100% 的力量。但是，當人一多的時候，大家可能就有所保留。在整個 workshop 中，我們應該沒有發揮整體團隊 100% 的戰力。

4. 快速交付，小步快跑的開發習慣是必須要一段時間練習，讓自己逐漸熟悉這種模式的思維，以任務下來時大家的反應來看。我們都需要一些時間來精熟這樣的模式。

Odd-e Certified ScrumMaster 心得分享 2 - 順暢的溝通

順暢的溝通

在二戰之前，法國的陸軍部隊擁有實力堅強的裝甲車設備。但是，在二戰的時候，卻被德國的陸軍打敗。據說，這中間的關鍵就是「溝通」。當時，法國的裝甲車部隊使用旗語在不同的坦克車之間進行溝通，而德國的部隊則是使用「無線電」進行溝通的工作。

在旗語跟無線電之間，我們可以清楚的知道這兩個工具產生的溝通效率不同。使用旗語時，溝通的效果有限，除了距離的限制之外。在作戰期間，坦克車的操作人員也很難時時刻刻探出頭來檢視其他坦克之間的狀況。這使得法國的坦克車部隊，像是一盤散沙，雖然裝備強大但是沒有辦法集中戰力，發揮團隊的力量。

反觀，德國的部隊，因為可以很快的進行有效的溝通工作。當其中一部坦克，打通了某個關卡之後，可以快速地通知其他的夥伴集結，快速地針對現況做出應對與改變，近一步達到戰略上的效果，而獲得最後的勝利。

對比軟體的工作模式，我們可以看到一個團隊雖然共同在打造一個產品，或是執行一個專案。團隊成員之間也有透過會議來進行資訊的同步。但，感覺很多時候，成員跟成員之間還是彼此不知道對方在做什麼，進行怎樣的工作，如何進行。

這使得專案團隊之間，對於產生的問題，或是良好的工法無法有效地快速傳播。所以，我們現在是用「旗語」還是「無線電」？

Odd-e Certified ScrumMaster 心得分享 1 - 協同合作

大約在兩年前吧，有一次到趨勢科技參加一個 Scrum 的分享會議，那時候第一次遇到 Daniel 老師。那次會議中分享了如何組成一個 Scrum 團隊，說明了 Cross Function Team 如何組建。

之後，也經常在社群裡，聽聞許多人對於 Daniel 老師的課程讚譽有加，所以當社群內出現了報名資訊後，我就立馬用手機完成了報名程序。接著，過著一段非常忙碌的專案執行生活。一直到上課前一天，都還有著許多工作上煩人的事。

但是，既然都已經報名了這個課程，就必須讓自己放空好好的沈浸在課程之中，以發揮學習最大的效益。

在課程中，我記下了大量的資訊，每一個 Key Word 都有一些啟發，基於養成習慣持續性的交付這項學習心得來看，只好把心得的部分切成許多小的 story 來 release 了！

協同合作

   Scrum 本來就是延伸自橄欖球運動中的爭球，所以一直以來我認為一個良好的 Scrum Team 就是要像一個合作無間的球隊，成員間彼此有默契，能夠互相合作。但是，一個團隊的協同合作就像拔河一樣，當只有一個人的時候，你可能會發揮 100% 的力量。如果，現在我們有一個團隊一起進行，每個人的力量貢獻度就不一定是 100%。

   「協同合作」是我在第一天筆記時，寫下的第一個關鍵字。在第三天，我們在討論什麼是一個好的 Product Backlog 時，卻突然有了體會。在哪份 Product Backlog Item 上，已分配好的工作都有指定一個負責人。

   假設，今天我們在談的是協同合作。一個 Product Backlog Item 為何是指定給特定人士來完成？ Product Backlog Item 是一個 User Story，是一個對於客戶來說有價值的 End to End 功能特性的交付。這其中涵蓋許多的細節，包含分析、設計、開發、測試等一切我們必須進行的工作，也是一個交付的目標。

  既然，這是一個目標性的交付，應該是由團隊一起協同合作，完成一個 Product Backlog Item 的交付，否則團隊會在什麼時間點進行合作？

  大家只是各自處理各自的任務，是一個不協同合作的偽團隊罷了！仔細想想，這也是最常看到的分工模式。雖然，大家一起在為一個產品或專案努力，但是彼此之間卻互不相干，不互相幫助。

  一個良好的團隊，應該是共同為一個目標努力。中間有什麼問題需要協助，需要補位，喊一聲就會有人接替。我想，在這樣一個團隊下工作，應該是相當愉快的一件事。所以，也要好好跟團隊同仁分享一下這樣的概念，促進團隊在協同合作上的成長。