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 的交付，否則團隊會在什麼時間點進行合作？

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

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

IBM MobileFirst 7.1 拒絕存取

延續之前 MobileFirst 7.1 的 Server Farm 機制無法正常啟用，經過好一陣子與 IBM Lab 之間的往返，還是沒有一個好的解決方案。

所以，只好考慮直接裝一套新的 Server，並且把專案移轉到新的伺服器上來。
但是，在移轉之後卻出現如上圖所示的錯誤。

因為，通常我們會在 App 啟動時，使用 WL.Client.connect 與 MobileFirst 伺服器連線，以確認 Client 與 Server 之間的版本，並檢查管理者有沒有設定任何通知訊息。

但是，在移轉後，App 端會出現「Access Denied」的錯誤，無法正常啟動 App。

伺服器端，也可以觀察到下列的錯誤訊息：

FWLSE0335E: Authorization failed: 
ClientId f5ac9a8cda443cfca33d1e7f926a71f90f8c67a1 was not found 
on the server.

這個情況，可以透過移除該 App 並且重新安裝，來解除此問題。

所以，我們大概可以推測，MobileFirst 的 Client 端在跟 Server 連結之後，會在手機端留下一些資訊。這些資訊，應該是 MobileFirst 用來確保安全的機制。

1. 可以避免，我們連接到的 Server 與之前的不同
2. 從伺服器端的角度來看，如果先前該手機已經跟伺服器註冊過。但是，現在我們卻無法在伺服器上找到該 ClientId 的話。這個裝置是不是該被視為有問題的裝置。

當然，這種安全機制，有時候還是會造成我們的困擾。

所以，為了避免要求大量使用者重新安裝 App，我們可以採取下列兩種方案，來解決此問題。

1. 在 MobileFirst 7.1 之後，與先前開始有所不同，採用 Session Independent 作為伺服器運作的預設機制。當採用 Session Independent 時，MobileFirst 的相關資訊就會被存於資料庫中。所以，必須調整 MobileFirst 處理 Session 的機制，讓資訊是存於記憶體之中。這樣，就可以解決上述遇到的問題。但是，當採用這樣的機制，勢必會影響到後續 Server 做平行的擴充。所以，除非是以單一機器提供服務，不然不建議採用這個解決方案。

2. 既然，App 移除重裝之後就可以解決此問題。那麼，就是需要在程式中加上一段清除手機上暫存的這些資訊，如此就可以使 App 恢復正常運作。經測試，先前假設沒錯，就是有一段資料被存在手機上。移除之後，就可以正常與伺服器連線。

「參考資料」
1. MobileFirst 7.1 Server Access Denied when using WL.Client.connect API

IBM MobileFirst 7.1 WebSphere Liberty Server Farm Unresponsive

前一陣子有客戶反應，他們公司的 MobileFirst Server 無法正常啟動。

於是，開始這段伺服器搶救的過程。

1. 因為 console.log 及 message.log 中都沒有紀錄錯誤訊息，所以為了看更多的資訊，必須打開 trace.log

需要再 server.xml 中加上下列資訊，就可以產生 trace.log 了！

<logging maxfiles="10" maxfilesize="20" 
         tracefilename="trace.log" 
         traceformat="BASIC" 
  tracespecification="com.worklight.*=all:com.worklight.*=all:*=info">
</logging>

中間經歷了很多次重開的過程，Server 就是無法順利啟動。

在沒辦法之下，我只好使用 MobileFirst 的 Configuration-Tool 試著用 update 的方式，中置一下 worklight admin 服務及 runtime environment 的三個 war 檔案。

突然，其中一部 Server 正常啟動了。

心想，應該修好了！

結果在啟動另一個 Server 時，卻卡住了！

這時候剛剛啟動的 Server 也無法正常運作。

觀察一下 tracelog，後來我發現每 30 秒會出現一次下列紀錄

com.worklight.core.clustering.ClusterSynchronizationTask

解到這邊，我一直觀察資料庫內的資料跟伺服器運作的模式。
感覺，就是同步作業失敗，然後一直重做。

上網找了一下資料，看起來跟這個問題比較像的是：
IBM MobileFirst 7.1.0 Liberty Server Farm Unresponsive

但是，內文也是說重建 Server Instance 跟重新設定 Server Farm 就好了！

目前，重建後只能讓單一伺服器恢復運作。
只要想同時啟動 Server Farm 中的兩個伺服器，就會陷入同步失敗的問題。

現在還在等 IBM 原廠回覆此問題的正確解法。