Scrum Master

哪些人適合作 Scrum Master ?
常見組織轉型時會直覺的找現有的角色作 Scrum Master ，
但是 Scrum Master 是一個 Coaching 的角色，
傳統公司裡面並沒有 Coaching 的角色，通常都行不通的。

傳統公司裡面的 Manager ，要麼是 R&D 的 Manager ，要麼是 PMO 的 Manager。通常會有幾個問題

1. R&D 通常由資深 RD 升上來，但是不善於管理(彼得效應)
2. PMO 會有自已與部門的考績考量，而這不一定能瞄準市場目標
3. 通常工作都會由 Manager 分派，而不是由成員主動爭取
4. 失敗的時候，總要有人背鍋，那個人就是 Manager (但是實務上常常看到 Manager 丟鍋給成員)
5. 不太關注成員的成長。(好啦，也許有的有)
6. Manager 要作太多的決策

Scrum Master 不是 Decision maker

情境：當 Team Member 無法決定求助 Scrum Master 時。
解法：也要看情境，干預或不干預是要付出成本的。
你要關心「風險」與「成長」，在沒有風險的情境下 Scrum Master 應該引導團隊自行作決定。
問問題是一個好的引導方式，過多的干預會讓團隊無法成長。

以小孩作比喻

如果把時間拉長一點，可以觀察出自已的取捨是否太偏向某一方(風險 or 成長)，
比如說幾個月，如果團隊仍無法自行決定，可能是你( Scrum Master )干預太多了，
Scrum Master 每一個決定都會影響到團隊。
Scrum Master 應該給自已訂一些目標，來判斷自已的取捨是否合理。

Ex:

• 團隊是否會自行分工
• 團隊是否會自行作決定
• 團隊是否會蜂擁處理最高優先權的東西
• more…

更多情況 Scrum Master 不見得能作 Decision。

Scrum Master 的責任

• Coach PO

  • 消除客戶與開發之間的障礙
  • 教導 PO 如何透過 Scrum 最有效率達到目標(How to maximize ROI and meet their objectives through Scrum )

  以下圖來說，Y 軸代表價值，X 軸代表時間。上圖的策略表示產品初期就發佈高價值的增量，
  隨著時間過去，單位時間能帶來的價值太少時，也許我們就不作了(虛線之後)，因為不符成本。
  而實務上，可能會更接近下圖，在初期有些基礎建設，這些建設不一定能帶來較高的(客戶)價值，
  但是可以降低風險，有時候更可能是初期必要的相依項目。這兩種策略沒有好壞，關鍵點仍是要能結合你的產品，
  與 PO 共同討論出取捨的方向。 User Story Mapping 是一個工具，怎麼樣找到 Walking Skeleton ，
  怎麼在這個基礎上豐富你的產品，這都是 Scrum Master 的職責。

• Coach Team

  • Improving the lives of the development team by facilitating creativity and empowerment

  • 以任何可能的方式提高開發團隊的生產力

    團隊常見的兩個問題，作太少或是作不完。可以嘗試一些工程實踐，但是別忘了工程實踐的目的是讓 Sprint Done。
    比如說：

    mini-waterfall 的流程可能會導致 Item 作不完，原因是 Testing 的角色在最後面才會進來，會有 Items 作不完，
    提早發現其實是件好事，不論是全都作不完、高優先權的作不完或是低優先權的全都作完都是很好的干預點，
    只要在 Retrospective 將作不完的東西攤開(透明)，分析問題就可以有機會改善

    引入不同的流程、開發方式都會有一個學習與生存的焦慮在裡面。可以透過 Coaching 降低學習焦慮，
    你要尋找適合的人選與資源，這是 Scrum Master 的職責。
    有的團隊的抗拒會比較強，Scrum Master 要找好時機進行，例如：Sprint 失敗時。

  • Improving the engineering practices and tools so each increment of functionality is potentially shippable。

    實例化需求(SBE)、驗收趨動開發(ATDD)
    實踐上怎麼作呢 ?
    在 Sprint 中的 Item 應該都有驗收標準( Acceptance Criteria)，
    這都應該在 Planning 或 Refinement 的階段被列出來，更進一步應該變成 test case。
    Example :
    Sprint 裡有 Item1、Item2、Item3、Item4

    Item1 應該會有 test case 1.1，test case 1.2…，Item2 應該會有 test case 1.1，test case 1.2…，
    正常一個 Item 應該在兩三天完成這個功能。
    這時候就可以測試 test case，假設 test case 4.3 作不完就不作了，這樣就不會留半成品。

    再透過持續整合(CI)的實踐，避免後面的改動，影響到前面。

    實務上，一種是團隊很喜歡作這類的實踐與改變，另一種更多
    「團隊作不到 Done，在 Retrospective 階段來趨動改善的過程」，為了解決問題。

1
2
3
4
5

Question:
1. Item1、Item2、Item3 會改到同一個模塊，所以 RD 會習慣同時開發(F2E反應)
2. 沒有持續集成(CI)，或是 CI 不包含自動化測試怎麼辦？
    - 如何快速寫出一個自動化測試試？
**

問一個問題，「什麼讓我們慢下來？，什麼讓我們不能更快？」

通常第一線的人員(Developer)不覺得慢是一個問題，甚至不會在 Retrospective 提出。Scrum Master 的職責是找到這個問題。

小結：

• Scrum Master 要讓團隊與 PO 深入理解 Scrum
• Scrum Master 就像是牧羊犬要保護羊群(團隊)，因為會有狼(插件 or something…，或是羊群裡有狼)
• Scrum Master 不作決策，更多是關心決策的過程甚於決策本身
• 具有生產力的團隊就是 Scrum Master 的產出
• Scrum Master 要發揮影響力(知易行難，怎麼作？)

情境題

避免爆雷，不描述課堂上的情境，但是將一些原則列下:

1. 很多人第一時間會找 Scrum Master 問問題。
   • 這是好事 Scrum Master 要發揮影響力
   • Scrum Master 可以籍些說明 Scrum 在作什麼，團隊是怎麼運作的。
   • Scrum Master 不作決策更關注過程。
   • 不要急著解決問題。
2. Product Owner 要基於 Product Value 作排序
   • 如果要最大化價值，一個產品就一個 Product Backlog，不管是多少個 Team。
   • 一個插件有幾種可能
     • 放進下面幾個 Sprint Backlog。
     • 放進 Product Backlog。
     • 很異常的情況，才會終止 Sprint。
   • Scrum Master 要關注 Root Cause
3. 保持團隊與 Product Owner 的連結
   • 有時候 Product Owner 也身不由已。
   • 如果 Product Owner 不在決策圈或未被授權，要了解背後的原因。
   • 如果 Product Owner 太忙，想辦法減輕他的壓力。
   • 如果 Product Owner 有別的角色(Sales、Boss…)，找個適合的人作 Product Owner。
   • 改變文化 改變組織 改變作法。
4. 讓 Product Backlog 作為團隊工作項目唯一的入口
5. 在不被 fire 的情況下，對組織帶來改變與價值！要有勇氣。
6. 不要讓團隊與 Product Owner 成為甲方乙方。
7. 讓團隊自已挑選工作，而不是分派工作。
8. 觀注事實。
   • 團隊的 Velocity
   • 上個 Sprint 完成的點數
   • 誠實面對失敗( 柯語錄:面對挫折打擊不是最困難的；最困難的是面對各種挫折打擊，卻沒有失去對人世的熱情)。
   • 思考著如何讓 Product 的 Impact 發生
     • 昧著事實去滿足時程與範圍，可能會為此喪失品質與生產力(欠債…)。
     • 找到正道，但是也許會更花時間。
     • Change Your Company。
   • 觀注 Product 的成功勝於作了多少工作。
   • 盲人摸象的故事，每個人都對，也都不對。

Part-time or Full-time

Scrum Master 觀注改進，同時兼任多個角色時，容易陷入可量化產出的角色之中。
要想辦法讓 Scrum Master 的工作可視化，不然容易淪為開會召集人或訂訂便當與飲料的角色。
實踐：

• 使用 Scrum Master Check List http://scrummasterchecklist.org/ 。
• 建立 Scrum Master 的改善 Impact Backlog，並且設定優先級。
• 按優先級逐步的改善。
• 尋找一組 Scrum Master 彼此討論與評量，讓這個流程形成一個循環。
• Less 的解決方式是 Full-time Scrum Master 兼任多個 Team。

相同的作法，對不同的 Team 不一定有用， Scrum Master 如果能接觸不同的團隊是好的。或是從其它 Scrum Master 汲取經驗。

呂毅老師的實務分享

常見一個問題，Product Owner 常常單向對 Team 輸入訊息，導致最後的結果與 Product Owner 的想法有落差。

一些壞味道

• Planning 的時候大家「帶電腦」作自已的事或是在「滑手機」。
• 開會人數太多，部份人在討論時，其它人放空。

Solution：

• 讓成員不要帶電腦，收走手機
• Product Owner 講完換 Team 講
• 測試
• 拆散小組至 2-3 人
  • 有點類似 Lean Coffee 的作法，讓團隊拆成小組討論 。
  • PO 輪流在小組之間被問問題。
  • 如果等不到 PO 可以先寫在便利貼貼到白板上。
  • 設定 Time Box ，時間到請 PO 回答問題。

Ending

不要反射性的去解決問題，讓子彈飛一會兒…。

• 讓問題變透明，讓團隊看見問題
• 不急著干預，試著讓團隊自行解決問題
• 讓 Team 與 PO 直接交流，不要成為 PO 與 Team 的傳話筒。
• 要保持「意識」，不要條件反射去干預，要克服這個心魔。

Real Team

• 所有人的目標是一致的，而不是臨時組成的一群人。
• 俱備 End to End 的完整。
• 有限的人數，Scrum 建議 5~9 人。
• Mutual accountability
• Agreed way of working

一個好的 Scrum Master 的產品是 Well-Working Team， 這需要時間(以年計算…)。
如何打造一個 Team ，這比 Scrum Maser 有更多的討論，但是實務上在成為 Scrum Master 時，大多數人打造 Team 的基本功是缺乏的(彼得原理？)，這需要更多的學習…

參考

• [N 社筆記] 敏捷路上跌倒站起來 2018/11/1
• [閱讀筆記] The Great Scrum Master 第一章
• The role of the Scrum Master – Part I

心得小結

1. 還好上課有記錄，課程很有料，過了一個月想法仍源源不絕的出來。
2. 你可以繼續 Scrum 自助餐，但是那個不是 Scrum 不是守破離。
3. 一邊觀察 N 社團隊的運作一邊寫筆記，Change My Company。
4. GitBook 也很方便的筆記工具，寫完後同步到 Github 就能拿到九成完美的 markdown 。
5. Scrum 給團隊更多職責，所以團隊要更強才行。
6. Cross Learning 不僅僅是溝通層面而已，而是為了真正的 End to End。你的 End 到底到哪裡 ？如何 DoD？
7. 所有聲音都是真的，不要急著說服別人，記住盲人摸象沒有一個瞎子說謊。
8. 第二步我在哪裡？第一步看見全貌、先要透明，透明的意思是有共識，再此之上是溝通與信任…不要把人僅僅當作 Resource。
9. 團隊裡面不要有小團隊/人數控制在 5~9/保持團隊穩定/Real Team，好難…實務上怎麼作 ？
10. Walking Skeleton 可以貫通在 PBI/User Story/Task 之間，要盡可能的薄但暢通，再此之上才有增量。
11. 可交付的增量不是 Release，也不是 MVP。MVP 比你想像的還大。
12. Sprint 的觀念在蕃茄鐘或 GTD 也有反覆出現過，在 TimeBox 中反覆實驗，尋求改善。

(fin)

要知道的事

• OS : Windows 10

易學難精的 Git 與 Flow

在使用 Git 時，分支的策略往往比 Git 本身更複雜。
Git 在建立分支是成本非常低的一件事情，
也因此很容易開出一堆分支，
這與團隊規模和 PR 的流程有關，可以參考文末的分支策略聯結。
因為 Git 開分支實在太便宜了，
我的 Remote Repo 不知不覺中竟然有了破千的分支。
大量的分支意味著大量的需求，其實是好事，
但是大部份的分支都已經功成身該退了，
當我使用一些 GUI 工具，為了顯示這些分支時，
這樣的數量反而成了阻礙。

解法

大量刪除遠端分支的方法

Step1. 可以透過正規表示式查詢大量分支。

1

git branch -r | awk -Forigin/ '/\/feature\/BTS14/{print $2}'

Step2. 同上的語法，但是後面 pipeline 串接 xargs push 到指定的遠端(這個例子是 origin)

1

git branch -r | awk -Forigin/ '/\/feature\/BTS14/{print $2}'| xargs -I {} git push origin :{}

特別看一下 {} git push origin :{} ，我們實際上是透過 push 語法刪除分支的。

補充

2019/05/09

大量刪除本地分支的方法

Step1. 可以透過正規表示式查詢大量分支。

1

git branch | grep "pattern"

Step2. 同上的語法，但是後面 pipeline 串接 xargs push 到指定的遠端(這個例子是 origin)

1

git branch | grep "pattern" | xargs git branch -D

參考

• Git 分支管理策略 - 阮一峰的网络日志
• 筆記：TBD 是三小?—What is Trunk Based Development?
  • 主幹開發主幹發佈/主幹開發分支發佈/分支開發主幹發佈

(fin)

2018/11/30

Planning 有沒有優先討論重點項目？

1. 最先討論上個 Sprint 的 UnDone
2. 順序等於優先權嗎？
3. 工作是事先 Assign 好，而不是
4. 兩個 Team 的 Backlog 放在一起，結果順序是
   • A Team (B Team 發呆)
   • B Team (A Team 發呆)

PO 只作明顯短期可見效果但低價的項目(沒有 Focos 價值)，如何引導 ?

Scrum Master 消失 ，Planning 沒有 Couch PO

• Scrum Master 兼任主管
• Scrum Master 兼任開發人員

KA 後台要中文 / 前台要英文

• 要問 Why：KA 面對的客戶也以中文為大宗，為什麼要英文？

2018/11/28

Demo 會議是由「 PO 介紹給 stackholder ?」

還是「 Team 介紹給 PO ,有 stackholder 最好。」
如果可以看錄影就當作 Demo 過了，那還需要 Demo 嗎 ?

三個 Team 各自有各自優先級最高的項目，這樣會不會陷入局部優化，過早進入細節 ?

• 無法集中火力處理優先度最高的需求

最大的 PO 沒進來

會後主管和小 PO 們再討論，有好有壞？
Scrum 怎麼說?

• 主管應該不要進來
• PO 最好能夠進來
• 不要在團隊裡形成小圈圈

2018/11/26

無限站立會議之卷

10:10 SRG 站立
10:20 A Team 站立
10:30 B Team 站立
11:30 RD1 周會

2018/11/23

• 你需要一個旁觀者，不然只是自 high

  • 觀查群眾的反應
  • 客觀點出講者的優缺點
  • 再好的內容沒有人聽也是枉然

• 成為 SM 之前要小心，不要急著成為 SM (特別是你是兼職的 SM 時)

  小心過早聚焦到細節，例如:安排會議/主持/作簡報
  不然你會變成「借會議室的人」、「照表操課的 Scrum Master」

• 用誇張口吻重複他說的理想，你就會知道他是在說理想還是說幹話

2018/11/22

情境:
團隊開發會與其它團隊開發相依或衝突，導致 Release 的品質有所缺陷。

• 用更多的會議/文件/Check List 作控管，有沒有辦法從 root cause 解決問題 ?

• 主管為什麼會想看「沒意義」又「不真實」的東西 ?

2018/11/21

• 口頭敘述

2018/11/19

• Scrum 不要拿 A 會議的時間作 B 會議的事
  • 觀注目的
  • 作該作的事

有關進步

運動員是否真的變得更快、更好、更強 ?

(fin)

目的

常常在一些社群看到，大神都超會下 command，
開始學習使用各種 command 之後，才發現那個美美的 terminal 不只是華麗而已，
實際上也可以加速閱讀，而且潮指數也是怒加一波(畫錯重點)，
當然要研究一下如何讓自已擁有一個賞心悅目的 commander 囉

作法

使用 Cmder ， 這是一個 Windows 的開發人員常用的 terminal 介面，
他可以執行一般的 CMD、Bash 與 PowerShell ，別想得太複雜，就是一個命令提示視窗。

安裝字型 on Windows 10

1. 下載 powerline，選擇 Clone or download > Download ZIP
2. 解壓縮後，選擇使用 AnonymousPro 字型(主要是要那些git icon的圖案，如果別的字型有 也可以使用)
3. 控制台>字型 把 ttf 拖進去安裝

設定 Cmder

1. Win + Alt + P 開啟設定畫面
2. Cmder > Settings > General > Fonts > 下拉選單選 Anonymice PowerlineCmder
   

使用 lua Config

1. 下載cmder-powerline-prompt，選擇 Clone or download > Download ZIP
2. 開啟 Cmder 安裝檔所在位置，找到 Config 資料夾
3. 將下載的所有 *.lua 檔放入 Config 資料夾

最後重啟 Cmder 就可以有一個美美的命令提示視窗了。
lua 也是一個程式語言，你大可開啟文字編輯器，看一下裡面作了什麼。

2018/12/02 補充

追加讓 PowerShell 在 cmder 裡面也美美的方法

步驟

1. 下載cmder-powershell-powerlin-prompt，選擇 Clone or download > Download ZIP
2. 解壓縮 ZIP 檔
3. 開啟 Cmder 所在的資料夾，如下圖 > 開啟 config 資料夾
   
4. 將壓縮檔內的 user_profile.ps1，取代 config 內的 user_profile.ps1
5. 將壓縮檔內的 profile.d 資料內的所有檔案，全數貼到 config 內的 profile.d 資料夾內，如果不存在就建立一個。
6. 開啟 config\profile.d 資料夾，重新命名 goToFolder.config.example 為 goToFolder.config
   • 這個檔案內會設定一些目錄與 alias 。
   • 使用方法，在使用 cmder 開啟 powershell 的情況下，輸入 g + alias
   • 比如說在 goToFolder.config 中，設定一組 m, C:\User\Marsen
   • 在 cmder 輸入 g m 就會自動切到 C:\User\Marsen 的路徑底下
7. 還有很多 Alias 請自行研究。
8. 重啟 cmder 後就會載入新的設定，變成美美的 powershell 了

參考

• 整篇都是參考cmder-powerline-prompt的作法，原始 Repo 可能隨時會更新異動，不保証有效
• cmder-powershell-powerlin-prompt

(fin)

情境

• OS : Windows 10

在一個巨型的 Git Repo 當中，底下依專案分了許多專案資料夾，
參考下圖。

而今天發生了一件事情，我需要更新某幾個子專案的 POCO 的 .tt 檔，
這裡不說明 POCO 是什麼；簡單的說，有的專案會有 .tt 檔，
有的專案會沒有，而每個專案的資料夾結構又不一定相同，
所以要找出這些 .tt 是有點麻煩的，另外我的目標並不是 .tt 檔，
而是所在的專案，再用 IDE 開啟進行修改，
為此我需要列出專案資料夾

目標

用 Command Line 取得 Repo 資料夾內包含.tt 檔案的專案資料夾名稱

作法

1
2

D:\Repo\Taiwan\******.******.Repofolder
λ Get-ChildItem -Path .\ -Filter *.tt -Recurse -File -Name | ForEach-Object { $_.Split('\')[0] } | Group {$_} | select name

1
2
3
4
5
6
7
8
9

Name
----
FacebookShop
LineOrderFinish
LineOrderNotify
Mail
NMQMonitor
OrderMonitor
SyncImageToOthers

小結

總覺得寫得有點又臭又長，希望有更好的作法可以提供給我，
不限於 powershell 就算是 Linux 的語法也可以讓我參考一下。

(fin)

原文描述

Visual Studio 的 Test Explorer 在跑測試，
如果遇到失敗，會直接中斷，
比如說有 2000 個測試案例 跑到第 1300 個時測試失敗就會中斷
剩下的 700 個案例會不執行直接略過。

情境

實際狀況

並不是一跑到錯誤就會中斷測試，而是跑了 3 個失敗後中斷測試，
另外執行的測試專案，是使用 SpecRun.Runner 撰寫 Cucumber 語法跑 BDD 測試。

原因

當使用測試專案使用 SpecRun.Runner，預設 stopAfterFailures 是 3，
所以 3 個失敗就會略過。

更多

正常的測試都是會全跑完的。因為 Test Framework 標示 Test Method 的部份，
都是幫你內建 Try/Catch 攔下所有 Exception 的。

MsTest 的 [TestMethod] 或是 NUnit 的[Test](XUnit 是 [Fact])，其實就是層 Wrapper
你在方法裡面寫的內容，只要有引發 Exception 的例外，
都會被這層 Wrapper 攔下來，轉成測試結果的內容。

解決方案

測試專案根目錄應該有一份 Default.srprofile 檔，如下
將 stopAfterFailures 調整至適當的值(ex:500)，將會顯示所有失敗測試。
本案例開啟後，實際失敗的測試有 37 個

1

<Execution stopAfterFailures="3" testThreadCount="1" testSchedulingMode="Sequential" />

參考資料

• SpecRun skipping testing rather than running them when executing more than 16
• SpecFlow+ Runner Profiles

特別感謝 91、Green、余小章的協助

(fin)

工程人員一定要分析後才能投點嗎 ?(有關 Planning 會議很長)

記得設定 TimeBox
Scrum 是經驗法則，可以拿已經作過投點的 Item 作為比較基準。
如果有未知與風險，當下不要過度鑽入細節。
你可以

• 開一個小的 Task 用來作調研與評估
• 開一個很大 Task 之後再用來 BreakDown
• 如果它是高價值又高風險，就優先作它吧

如何加速會議進行?

決議與會議之外。先讓人看見問題與目標，與可能的方向。
SM 應該更關注決定的過程，而非決定的本身。

焦點討論法(如何問問題)

O↓ 事實(每個人看到的都不一樣)
↑R 感受(相同的事實不同的人不同的感受) → 往複 OR ，取得共識(有共識才透明)
Interpretive 意義與價值觀
Decisional 決定

Business DevOps

迭代與增量真的有幫助嗎 ? (Agile 之前我們怎麼工作的?/Scrum 真的好嗎 ?)

看情境

Agile 適合應付變化，而目前的世界變化很大。
不要為了 Scrum 而 Scrum 。
那樣會變成盲從，看見你的需要，務實的變革。

用一個問題打敗一個問題(Ruddy 老師引導法)

找到核心的問題，然後問 「怎麼作 ?」
學員回答後，老師常常會說「這是一個方法」，然後給予回饋。

這句話的潛台詞是「還有其它的方法」。

團隊成員恐懼端到端的開發(新手 SM 與新手團隊)

• 讓 1 個 Sprint 先完成 1 個最高優先級的 Item (初期導入 Scrum 怎麼作?)

Scrum 對團隊的要求其實蠻高的，
但是我們不需要端到端的工程師，而是團隊。
巴士因子可以是個判斷指標。
另外限制理論[求補充]告訴我們瓶頸會跑來跑去，所以要持續觀注與改善。

團隊估點從 100 → 200 (Data Team 從沒有信心 Commit 到 $#@…)

這個點數的增長不合理，而且還是以時數點數，
沒有任何東西可以讓一天變成 48 小時(喔…有人說，加班可以讓 8 小時變 16 小時)
持續觀注，如果失敗了就讓它失敗吧…
但是要失敗的有意義。

後續

11/23 團隊作的工作量實際上達到 254/3xx (Commit 3xx，完成 254。)，
sprint 是成功的，但是 Velocity 是失準的。

小心得:

1. 所謂的 Commit 如果不是對自已 Commit 起不了激勵作用,
   如果 Team 與 PO 不認為「我們是一個 Team」，而還是分 PMO 與 R&D
   那麼 Commit 就會變成畫押背鍋的儀式。
2. 氣象報告失準怎麼辦，颱風沒來大家都開心嗎？(從 100→254，是效率大爆發，還是浮報點數了？)

Scrum 的神奇魔力

當老闆就是 PO (PO 與 Scrum Master 出現了階級關係)

• 找一個小 PO (作 PO 真正該作的事)

正視真正的問題是「你沒有 PO」

當 Team 在兩個作法兩難的時候

• 作一個 Check Point，保留可以回來重新審視的機會

現實中有遇到類似的狀況，
執行的當下會列出所有的優缺點，再作選擇。
作完之後問自已，再作一次你會怎麼選擇 ?

成員本來會多作優化，跑 Scrum 之後沒在 Task 之上的事不作了。ex:重構、優化…)

在 DoD 應該可以解決這個問題，如果現況不會有問題，為什麼要作?
先作 Task 有列出來東西我覺得基本上是對的。
SM 的問題是「認為該作，但是沒有技術 Know How 所以不知道該列什麼?」
那還沒有跑 Scrum 前如何評量這個項目的效果呢?
至少在 Scrum 中我認為可以透過 Velocity 作為指標。
也可以透過 DoD 決定品質的程度(ex:)。
另外，重構不是重作，
重構應該是時時發生的，寫測試可以讓這件事被量化，
難以測試的代碼本身就有一定的壞味道(工程實踐與遇到的困難就以後再寫了…)。

Team 不該 Challenge Item Value 嗎 ?(這樣跟以前需求來就作有什麼不同?)

在 Scrum 中,
PO 觀注 Why ,觀注產品價值 ,觀注市場與策略
Team 可以決定怎麼作，與 PO 討論理解為什麼要這麼作，
並不是所謂的「需求來就作」，而把 PMO 的角色拿掉，
是為了減少隔閤，讓團隊更接近商務端。
聽起來這個情境，Team 與 PO 仍有抗拒心理…

身兼開發的 Scrum Master

Team(1+1+1+1…) x SM (0.9 or 1.1) = 生產力
讓 SM 成為乘數，而不要成為加數

小地雷:如果乘數小於 1(如何評量 SM 指數?)

業務單位的務實

業務/老闆會說，我才不管什麼開發方法，
作出來就好了(黑貓白貓能抓老鼠就是好貓…)
很務實，但是很傷害團隊…，不要有機會讓團隊聽到這種話

結束就結束了

參考

• [心得] ScrumMaster 自我突破訓練營
• ScrumMaster 自我突破訓練營 in 91APP ：ScrumMaster 的生存之道
• ORID 簡報- By 茶米
• Scrum Master 自我突破訓練營  —  心得分享

(fin)

2018/11/16

Bussiness Feedback

• T 國全 ○ 國，農曆年前啟動
• M 國的， Mxxxx 有 SKA 等級
• H 市場，百家等待中
  原訂
• KA MIRGRATION
• KA 12 月上線
  順序可能會再調整…，
  市場有反應是好的，
  只是我們還沒有產品準備好（或是跨一國要準備好久好久…）

團隊

• 抽一個 Scrum Team 的 Members 組成新的 Team ？
• 又變成 Project Team ，呂毅:「如果只有兩個月你還會關心團隊的成長嗎 ？」

2018/11/12

• 線上緊急狀況，周會取消、例會取消，如果一個會議可以隨時被取消，是否有必要開？
• 真實狀況是每個人都找到一個位置，讓事情發生;務實比「跑敏捷」重要
• 不儀式化，人性會躲避 ; 儀式化卻會導致效率低下(習慣成自然 or 麻痺)

2018/11/10

情境
團隊反應沒有時間 Code Review / 寫 Unit Test，
Pair Programming 隨你便，上級的反應說「有，最好」結果，「都沒有」

• 要求很強的個體，卻沒有任何練習;這樣的團隊會強嗎 ？
• 擁有很強的個體，卻沒有任何協作;這樣的團隊會強嗎 ？

2018/11/09

陶侃跟西西弗斯，兩個類似的故事

心態致勝? 還是自以為勝 ？

2018/11/06

沒有創業精神錯了嗎 ?

• 成就感從何而來 ?

  • 把事情完成
  • 把品質作好
  • 作得快

• 受雇階極一定要被激勵才能作好事嗎 ?

• 雇主與雇員的本質上的不同

  • 風險
  • 獲利

2018/11/02

時間

• 早上生病 約 10:30 到
• 站立 到 10:50
• 1-1 到 12:00
• 午休 到 13:00
• .Net Core 到 15:30
• 看 PR 到 16:12
• 開發 到 17:26
• HOTFIX 討論 17:45
• 開發 到 19:50

當會議吃掉了所有的時間…

重要性

你很重要，Why ？ What ？ How ？ 或只是暗示你 TTL(Time to leave)

2018/11/01

planning for all day half day

不透明

• Item 拆成 Task 的過程中釐清，可能會因細節不清、沒有權限、左右兩難、等待資源、等待許可等…導致進度緩慢耗時
• 為了對焦開了會前會，但不包含 A Team PO，結果 Planning 後半 A Team 又增加許多項目反而失焦
• 很簡單的事，因為複雜的系統變得沒有勇氣(信心)去執行

如何測量

本日佳句

• 這個不能作，不然會被罵喔

Action Item

• 開發祝武：Filco Majestouch MINILA Air 67 鍵無線藍芽機械式鍵盤|紅軸英文

CSM 心得第二篇寫到 Sprint Backlog , 越寫看到越多實踐「怪怪的」地方…

2018/10/31

Blue Demo Day

• Demo 失敗
• 檢討

不透明

• 分了 A Team / B Team ，Items 有 Dependcy ，導致工作互卡。
• 跨國團隊很多項目需要台灣 Tech Leader 決策

Team sol:

• 中間插入一個 Sync
  • 實務上跑起來不 Work ？
• 大家一起站立
  • → 很花時間
• 由某一個 Team 全部領走整群的 Item
  • → 主流程難以被切分
• 除了站立之外，團隊也要時時 Sync
  • → 當 member focus on Item 時，對其它人尋求協助的反應可能會變慢。

Action Item

• Custom domains on GitHub Pages gain support for HTTPS

2018/10/30

為什麼無法跟團隊成員說明自已的想法，原因還是出自於不信任？
每個人（含主管）在面對什麼？ 或許知道了也幫不上…
還有「主管」這種思維，不是一種文化不敏捷的味道；
表示著你還需要被管理，才知道該作什麼。

使命與遠景

• 8 億 : 開發者會覺得與我何干。所以我們調整成…○○？
• ○○ : 開發者會覺得?
  • A. 太棒了，激勵人心
  • B. 干我屁事
  • C. 聽起來很棒，可是…
  • D. 蛤？那是什麼，可以吃嗎？

抽樣調查

L●●:整合線上線下讓客戶更容易銷售產品，消費者有更好體驗
A●● 等 3 人:賺錢 x3
T●●:作出讓客戶達到業績的產品
A●●:改善現有線上電商的使用環境與體驗
R●●:開發良好的軟體改善客戶與使用者的體驗

小結:第一時間大部份是賺錢，或是不知道。少數第一時間說出來的，
又各不相同，每個人的目標不同，真的能有「使命感」？真的會有「成就感」？
沒有共識，何來透明？

OKR 與 DoD

• OKR 適合用在 Sprint 嗎 ？
• 每個 Sprint 為了討論 KR 而放棄投點值得嗎 ？
• KR 與 DoD 是否能結合 ？

（fin)

課程簡介

• Scrum Master 認証課程
• 講師 ： 呂毅(Lv Yi)
• 課前請看過 Scrum Guide 與 Scrum Primer

Daily Scrum

• 建議 Time Box 15 mins，每日同時同地進行，注意避免超時。
• 目的是 Adapt，觀注 Item 而非 Task。
• Scrum Master 不是會議的中心；避免讓團隊成員變成對 Scrum Master 或 PO 報告。
• Scrum Master 應減少(避免成為中心)
  • 發言
  • 眼神接觸
• PO 不一定需要每天參與 Daily Scrum，但參與有助於問題的釐清
• 不討論細節，只確認現況(Reality Check)與目標(Goal)的差距，細節可會後釐清

補充

• GROW
• 有的人就是很話澇，曾有團隊給每個成員紅/黃牌，當有人說得太久就給牌警告 XDDD
• Scrum Master 可以作的事
  • Does the team find the daily scrum useful ？ 成員有沒有發現站立的好處 ？
  • Do they manage themselves ？ 團隊是否自組織了？
  • Do they share their work ？ 他們的工作是共享的嗎 ？
  • Do they come prepared ？ 他們(這個 Sprint/Item/Task)準備好了嗎 ？
  • Do they report unclear ？他們的說明是否易懂？
  • Does it take too long ？是不是太耗時了？

我在 C 社是下午 5:30 執行 Daily Scrum，在 N 社是早上 10:30。
個人比較喜歡 C 社的作法，但有可能是被制約了，因為那是我第一個跑 Scrum 的團隊。

主觀的比較一下優缺點

Sprint Review & Retrospective

Review

• 展示我們完成了「什麼(What)」(面對 Stakeholder 練習別說技術語言)
• 建立 Product Owner 與 Stakeholder 的信任
• 取得來自 Product Owner 與 Stakeholder 的 Feedback
• 圍繞著 Product 進行 Inspect 與 Adapt
• Team Member 完成某些 Task 或 Item 之時，就可以找 PO 進行 View (Just In Time Review)

Retrospective

• 觀注我們是「怎麼(How)」作的
• 圍繞著 Process 進行 Inspect 與 Adapt
• 從經驗中學習，增進溝通
• 幫助團隊關注改善 Process
• 關注重複發生的問題
  • 有時是組織性的問題
  • 有時是團隊的問題

「每個人的觀點都是對的；但不完全是對的。」
上面這句話，要兩句同時看才完整。

回饋

盲人摸象的啟示，沒有人錯；但組合起來就不是大象。
不論那隻大象是你的團隊、組織、公司或是這個社會。
專案開始之初，首重看見全貌。看見全貌之後，確認自己在哪裡! — Ruddy Lee(李智樺) N 社敏捷教練
幸福的秘密,就是去欣賞世界上所有的奇特景觀,但不要忘記了湯匙裡的油。 — 牧羊少年奇幻之旅

Product Owner & Product Blog & Refinement

Product Owner

• 對產品有遠景
• 定義產品的功能，決定發佈的日期與內容
• 對功能作排序(價值、成本、風險…etc)
• 對產品獲利能力負責

為什麼 Scrum 的設計上只有一個 PO ，這讓下決定變得簡單；但實務上這件事不容易。
在 C 社期間與 Boss 的距離較短(公司規模小)， 但是 Boss 也是喜歡透過一個 PM 來作代理人，在 N 社公司規模更大，PMO 基本上是個巨型團隊，即使是 PO 仍需要與其它部門確認、核可、討論才能決定。不論大小，在工作實務上仍然像個 PM 或是窗口與代理人。

Product Backlog

• 要包含功能性與技術性的需求 Items
• Items 將被拆解為工作項目(Tasks)
• 只對高優先的項目作細部分解。
  • 價值、緊急程度需要可測量
• 多個團隊應該共用一份 Product Backlog
• 由商業計劃驅動，有時候你需要客戶的協助

好的 Product Backlog ，可以協助團隊 Refinement

• Ordered
• Detailed Appropriately
• Dynamic
• Estimated

Refinement

• 最高優先的 Item 可以提前 2-3 個 Sprint 執行 Refinement
• PO 與 Team 一起進行
• 你可以在 Sprint 中期進行一次
• 可以透過 User Story Mapping 進行討論

User Story 的目的是用來達溝通的，
溝通最大的目的在於分享觀點與學習，不要僅僅流於形式。

實務上 Refinement 隨時會發生，關鍵的成員討論並決策。
而且不難實現，隨時 Refinement 是第一線的開發人員很自然的思維與生態。
PO 在場的話更好，但是不是必要的。特別要記得設定 Time Box，避免討論多與實踐。

Walking Skeleton

這裡有關一些 User Story Mapping 的東西，我不清楚故不作說明，未來再作補充。
我們可以把 Y 軸的分群當作一個一個 Feature，很明顯我們不需要把每件事作到 100% ，那樣太慢而且沒有意義。

我們應該先完成 X 軸最上方一列的 Items ，要儘可能的簡單，
完成一個完整可動的骨架。

它的圖形會如下；

它不代表要被交付，它只完成了一個最簡單的閉環，能提供最基本的回饋(不需來自真正的客戶)。
當完成了 Walking Skeleton ，在這個基礎上我們可以填加其它的增量，應該在前 1~2 Sprint 就完成它。

Scrum Master 應該與 PO 一起找到 Walking Skeleton，在一個 Release 前 1/3 的時間就應該完成 Walking Skeleton。未必要 Release 它，因為它很可能是相當粗糙的，但是儘早完成可以幫助團隊降低風險，而且完成後 Value 的選擇將可視化，同時也完成了基本的 Architecture 。

當然所有部份都不完整，但是可以隨著時間逐漸完成。有些項目我們可能永遠不會作，因為不符成本。另外如果一個完整的 Walking Skeleton 無法在一個 Sprint 裡完成，請選擇 Risk 高的優先作。

估時

對每個 Item 估點數，請參考 Planning 的部份；但是點數對客戶與老闆其實沒有辦法理解，最重要轉換成時間。關鍵還是 Velocity ，這是團隊的戰鬥力，假設總共的點數估計為 50 點，團隊每個 Sprint 可以完成 10 點，團隊就需要 5 個 Sprint，以一個 Sprint 2 周來算，這樣就可以向客戶或老闆承諾 10 周的時間。

這裡的例子有點不懂，正常的 Scrum 估時只會專注在一個 Sprint，而 Product Back Log 如果沒有被估點的話，如何換算成點數？更如何向客戶或老闆提供這樣的數據？

估時很適用 Fibonacci 數列，F: 1、2、3、5 、8、13、21、…，很多的工具都有提供，主要以相對大小來比較對一件事情的看法。此外，不要因此被工具限制住了，比如說團隊無法在 8 跟 13 之間，就選擇個中間值吧，「?」也是一張重要的牌，這代表未知、混沌與風險。可以在所有的 Item 中挑選一個的當作基礎，每比較完一個項目，也再次作為比較基礎。「40」、「100」這樣的大牌也有其意義，這意味著 Item 過大，可以再作分解。

較成熟的團隊，也可以拿過去曾經估計過的 Items 作為一組「Reference Pool」，通常不需要估到很精準。

這樣的估計方法，需求的 Items 類型是不是需要很穩定 ？舉例來說，我們的產品如果包含 App、Web 與 Desktop ，團隊成員的 Skill Set 又很小，某些類型的工作只能由少數人開發，隨著 Sprint 有時候需要作 App、有時候需要作 Web；有時候兩者都需要作，這樣的估時算穩定嗎 ？
這是不是表示說 Scrum Team 所需要的團隊組成其實很高？又或是我需要將產品拆成 App、Web 不過這樣不就又回到 Component Team 了 ？那在導入 Scrum 的初期，人員的挑選要找通材，或是學習能力極強的人？

Splitting

The perfect is the enemy of the good

Task 也可以應用 Walking Skeleton 的方式切割，儘早讓整合測試發生，不用一步到位。如果有外部相依，可以考慮先用 Stubbing 的方式隔開，這可能會讓「整合測試」不完整 。

用 Walking Skeleton 的方式開發，QA 會反映沒有什麼好測試的，Sprint 的初期 QA 都在寫測項，等待 RD 完成開發，最後幾天拼命測試。如果先開發 Walking Skeleton QA 會反應這樣的測試並不完整？而 PO 會反應這樣的東西沒有商業價值。

開始第一個 Sprint

1. 組成團隊(PO、SM、Team)，這會挑戰目前的組織架構，這是難的地方。
2. 創建最初的 Product Backlog
3. 決定 Sprint 長短
4. Define Value & DoD

參考

• Agile Retrospectives: Making Good Teams Great
• Project Retrospectives: A Handbook for Team Reviews
• User Story Mapping: Discover the Whole Story, Build the Right Product
• 用户故事地图(User Story Mapping)之初体验

(fin)

雖然實施部分的 Scrum 是可能的，但結果並不是 Scrum。Scrum，
只有在完整的時候才會存在，也才能有效的成為其他技巧、方法論、和實務發揮的運作舞臺。
— Scrum Guide 結語**

Planning (with 2~4 hours timebox)

Planning 第一階段

• 說明要作什麼(What)。
• 對 Item 估點。
  • 基於 Velocity
  • 基於 Commitment

估計的方法

有 Size (大、中、小) 或點數(Story Point、Planning Poker)等方法，
實務上都使用點數較多，原因是多個項目的加總，在比較時點數較有感覺。

參考下例：
Sprint 1 有 4 個 Item，Size 是分別是大、大、中、小。點數分別是 13、13、5、2。
Sprint 2 有 5 個 Item，Size 是分別是大、中、中、中、小。點數分別是 13、8、8、5、1。

Velocity-Driven 或 Commitment-Driven 哪個比較好呢？
大多數的 Scrum Master 恐怕會跟你說團隊決定。
兩者的差異點在哪裡呢 ？ Scrum 是立基於經驗導向的流程控制理論
Velocity 有數據佐証，較為客觀；但是 Team members 與 Backlog Item 其實都是會變動的(理想上當然是穩定更好)，
如果 PO 與 Team 的互信足夠， Commitment 其實也可以符合經驗導向，比如說：「 我的 Develop Team 平均每個 Sprint 裡面可以交付 90% 的 Item。」
換句話說還是團隊決定，但是彈性是很大的，或許 Develop Team 有信心時使用 Commitment ，而團隊缺乏信心時或許可以用過往的 Velocity 作為標準。

Planning 第二階段

• 組織 Task 以達到溝通與完成 Items 的目的
• 接受來自第一階段的 Backlog Items
  • 要相信「Velocity」
  • 不要馬上分派 Task
    • 會形成 Silo ，被分派者會提早將專注力從 Item 移到 Task 上
    • 保持專注在 Item 上
• 對 Task 估時。
  • 估時請包含假勤/會議/教育訓練…etc
  • 別忘了 Backlog Refactoring 的時間
  • 在 Time box 裡估完成估計的 Task
  • Maintain → 用經驗法則抓一點 Buffer 吧
  • 用小時去估時 ex:1~8，如果超過 8 小時稍後再作進一步的工作拆解
  • Task 如果仍有模糊不清的部份，可以先估一個較大的時數，再進一步拆解
  • 隨著 Sprint 進行，隨時調整 Task (增/刪/修)

• 這是用來估計而非報告，不要混為一談；Scrum 在乎的是結果，而非時間。

• 只管相對大小，ex: Task A 與 Task B，由 Alice 與 Bob 領走可能會如下呈現

  • Task A Alice 領走估時 8 hours，Task B Bob 領走估時 4 hours
  • Task A Bob 領走估時 2 hours，Task B Alice 領走估時 4 hours
  • 其實不用追究原因，或是是否相同，這因人而異，不求準確
    • 我自已的理解是
      • 而是某人估了高時數時，能不能有人來支援他？
      • 能不能透估時發現 Team Member 的能力差異，並引入其它方法提升 Member 能力 (ex: Pair Programming、Sharing、讀書會…)
      • 承上一點，注意佔用 Sprint 的時間，並回頭檢核是否有效；沒有比較的改善，只是自我滿足。

Sprint Backlog
Tasks to turn product backlog into working product functionality.
Tasks are estimated in hours , usually 1-8 .
Team with more than 8 hours are broken down later .
Team members sign up for tasks , they aren’t assigned .
Estimated work remaining is updated daily .
Any team member can add, delete or change the Sprint Backlog work for the Sprint emerges
If work unclear, define a Sprint Backlog with a larger amount of time break it down later .
Update work remaining as more is known, as items are worked

Scrum Master 的 Check List

• Product Backlog Item 排序
  • 上一個 Sprint 未完成的 Item
  • Review Meeting 的反饋所產生的 Action Item
  • Acceptance Criteria 是否已經定義清楚了？
    • 需視 Scrum Team 的流程定義
    • User Story 的 Descriptions & Acceptance criteria 希望是 PO 與團隊一起共同完成。
      • 實務上蠻花時間的，寫出來的效果也不見得很好。(*也許是我們的操作方法不對)
    • User story 是用來溝通的，不是用來寫的！
  • 是否有人請假？
    • 可以提前確認
    • 有人請假要評估是否吃得下？
    • 吃不吃得下由團隊評估

PO 在 Sprint 中一直塞東西是不是一種不信任團隊的壞味道？
Team 毫無反應，就只是個接 Task 的 Team 是不是也是一種不信任？

我對 OKR 與 Sprint Goal 的認知。
不難理解為什麼 RD 會覺得干我屁事，又沒加薪也沒獎金，
看了兩本書、用口說說就能讓人激勵人心太不且實際了。
比如說：作功德，最後反而會讓第一線人當成幹話，幹話聽多了失去信任就更糟糕了。

Team

適當的領取 Item，過多的 Item 進去，只會在 Sprint 結束時，有一堆半成品。
而半成品在面對(市場)變化，失去產品的彈性。

軟體(代碼)的優化與重構只作一半，算不算是半成品？
軟體隨著架構或相依的套件升級或補丁，在 Sprint 期間通常會有必要升級或是改變寫法。
最後就變成下圖，擁有各種版本的 Code Base。

這會拖慢開發速度，讓新進成員難以理解，也難以用 Code Review 或自動化 Tool 解決，
目前比較理想的解法是 Pair-Programming 與時時重構。

可是，PO 願意花費這個時間去調整嗎？
可以用 Veloctiy 變低當作參考嗎？Veloctiy 變低的原因有很多種。
又或者由 Team 自行決定？
Team 要能自組織要多久時間呢 ？「不是拿掉主管，團隊就能自組織」;
如果是跨 Team 共同開發的產品又該如何？
Arch 的調整需要更其它或上層的團隊允可(這也會占用不少時間)
把產品拆掉變成多個服務？讓團隊成為服務 Owner ？
拆成服務又需要多久時間呢？
組織架構調整？

當對 PO 來說，這是沒有商業價值的事。，實務上該怎麼作？或該怎麼量化呢？
註記：或許這只是個過度理想化的偽議題，畢竟「凡存在，必合理」。

(fin)