VIVOTEK Digest

經濟部統計處: 飲料店營業額在台灣逐年攀升

第一個常見現象：開週會
Why are meetings so ineffective?

Great movies tell stories that have deep emotional resonance

第二個常見現象：同事間的工作互換困難
Why is collective work difficult?

Machine learning or human learning?

第三個常見現象: 加班

Why work overtime?

不同角度的生命科學系

又下班了?! 我還想工作

Schrödinger’s Cat 薛丁格的貓

敏捷開發
Why OverCooked can teach you agile?

一款具備敏捷精神的遊戲

Get back in sync

Realtime review

The programmer as navigator

How to avoid boring meetings?

How to develop a cohesive team?

合作或協作（英語：Collaboration）

是指一種由兩個或兩個以上的個人或團體作為一個共同的目標而交集或在一起共同工作，舉例說明：

一個知識分子可以透過合作的關係而去分享知識，再而經過學習和共識達到創作的目標

一個人走得快

一群人走得遠

 Why collective intelligence matters?

Pacific Rim: Uprising (2018)

True collaboration yields better results

Iteration based method

Jeff Patton did an Iterative Mona Lisa.

敏捷帶來的影響
How does agile affect my work and daily life?

從同事電腦辦公桌

變家人散步吹吹風

關門 SOP

前是把家當旅館

現在是家事盡量管

從擔任ScrumMaster九個月以來，經歷了三個時期的轉變，
猶如禪宗《指月錄》裡，「見山是山，見山不是山，見山還是山」 的三重境界。

我是以R&D team leader的角色轉職ScrumMaster，
是團隊成員的直屬主管，擁有人事的管理權(招募、解雇及績效考核等…)。
在Scrum的相關介紹裡，都會建議讓ScrumMaster單純化，不要擁有管理權，
這會讓團隊成員對他頭上戴的帽子是ScrumMaster或是主管感到困惑，
甚至妨礙自組織團隊的形成。
往好處想，由於有主管的職權，在推動一些政策或改變時會比較容易，
前提是你必須確保自己要推行的事情是正確的。
既然這是無法避免的問題，我告訴自己要學會竭盡所能解決任何潛在的利益衝突，
尤其是要保持開放的心態鼓勵溝通，避免以威權領導團隊的情況發生。

即使有了心理準備，工程師畢竟是一種過於樂觀的生物，
執行時仍是遭遇了合併角色時可能會犯的那些錯誤。
首先遇到的是我們在doing agile而不是being agile，
我們遵照Scrum的規則執行必要的活動，但活動的進行卻不夠符合其背後的精神。
從Scrum第一天的planning meeting開始，我主導了如何將sprint backlog item拆成task的過程。
daily meeting時我站得太前面，像是傳統的那些會議，
部分團隊成員習慣直接對我報告，而不是其他成員。
當進度落後時，我會主動提出「建議」改變工作的進行方式，
理智上知道sprint是可以失敗的，仍然將sprint是否成功作為我的職責，
想方設法的讓團隊可以在時間內完成。
retrospective meeting時我會幫團隊寫下會議紀錄，作為下次retrospective meeting時的依據，
檢視列為action plan的項目是否有被執行，讓自己變為一個秘書或監督者的角色。

接著是第二階段，我參加了呂毅老師CSM的課程。
在兩天的課程中我學到最多的不是ScrumMaster該做什麼，而是ScrumMaster「不該做」什麼。
課程結束後我期許自己往教練的角色前進，以引導來取代教導；
列出了ScrumMaster該有的特質貼在螢幕前常常提醒自己，尤其是要有耐心，
不要認為自己比集體智慧還要聰明，給團隊足夠的時間，讓他們自己找到答案。
我開始站在團隊成員背後，不再參加planning meeting part.2，
daily時看到問題不會急著指正，只是記下來作為retrospective meeting的準備。
不再由我負責retrospective meeting的紀錄，由團隊自行決定到底要不要寫，
兩個團隊討論後各有各的作法，但都決定不再像之前一樣記在OneNote上。
團隊在這階段有更多的自主性，更符合自組織團隊的定義；
作為交換我們付出了一些代價，例如sprint失敗的機率增加，
在產品開發有些欠缺考慮的地方，造成品質下降。

來到今年，由於新人陸續的加入(佔了1/3)，兩個團隊重新分組。
Scrum的核心在於隨時檢驗與調適，依據上階段的成果和團隊目前的情況，
我又調整了自己的工作模式。
扮演理想ScrumMaster的前提在於你有理想的團隊成員，Scrum對此沒有明確定義；
就我的認識，我會以《Google模式》裡的智慧創做者(smart creatives)作為標準，
具有深厚的技術或專業能力，還有創造力與實踐執行的能力，
而且充滿好奇、質疑現狀，以不一樣的方法來應付問題與挑戰。
新人比例偏高加上重新分組，讓團隊的發展回到第一階段的成形期，
除了教練的身份外，我更需要的是老師的角色，傳承我的能力和經驗。
我又開始全程參與planning meeting part.2，只是我不再主導而是提醒，
在團隊的討論中丟出問題，提醒他們沒考慮的地方。
重點不在於討論出什麼樣的解決方案，而在於提問以引發討論，
藉由一個一個問題去淬鍊出越來越好的作法；
必要時我會補充技術上的專業，只有我具備而其他人不知道的資訊來協助討論。
在daily meeting和retrospective meeting時，我依循相同的精神和團隊互動，
依據要處理的課題切換我頭上戴的帽子，可能是ScrumMaster或是資深工程師。

Scrum沒有標準作法，在不同的環境(context)中會有不同的應變，
一切都是trade off，只要想清楚每一個決定的得失，是否合乎敏捷的精神？
最忌諱憑直覺作出反應，讓自己習慣於過往的工作模式。

2/22 與 2/23 兩天去參加了一個外訓課程 - Advance Scrum Master。這個課程主要是給擔任過 scrum master 的人，想要提升自己的能力，或者組織要跑跨團隊產品的 scrum 的人聽得。我雖然沒有擔任過 scrum master，不過後面的那的目的，倒是即將在我們的單位內發生，因為我們在 Q2 開始，有一個專案會加入新的團隊成員，所以該專案的總人數已經超過一個 scrum team 的建議範圍，因此我們有必要開始注意跨團隊開發同一個產品的作法該怎麼進行。我在這裡借用一些篇幅，紀錄一下課程的收穫。


2007 年左右 Nokia 進行了一個 500 人左右的大型 scrum pilot，這就是後來 LeSS 的主要參考專案。跨團隊跑 scrum 有兩個主要門派，一個就是剛剛說的 LeSS，另外一個就是 SAFe。LeSS 叫做 Large Scaled Scrum，SAFe 則是 Scaled Agile Framework。比較上來說
LeSS 真的是比較 Less，而 SAFe 則是比較 Safe。聽起來好像甚麼都沒說對吧! 所謂比較 Less 是指在架構上，Less 跟跑一個團隊的 scrum 類似，幾乎不需要增加甚麼新的角色與流程，所以他的 Less 可以說是與 SAFe 的比較。而 SAFe 雖然增加了新的角色、流程、協作，但是這些新增的東西反而跟傳統開發模式比較容易接軌，例如 Architect 與 PMO 這些傳統瀑布下的角色在 SAFe 下反而會存活下來，所以他 Safe 的地方是對於一個跑慣傳統流程的公司來說，反而衝擊比較小。反過來說 LeSS 就會對傳統流程的公司是屬於破壞性的改變，所以才會說 SAFe 比較 Safe。但是 LeSS 的做法也會遇到比較難適應更大型的團隊，所以 LeSS 還有一個叫 LeSS Huge 的架構，基本上就是讓一定程度的人數組成一個 Requirement Area，這個 Requirement Area 相當於 LeSS，只是 Requirement Area 的 area product backlog 組起來還不能稱為產品，只是產品的一部分，所以會增加一個管理 Requirement Area 的架構。但那個管理架構本身也跟 scrum 類似，所以所有的設計理念都圍繞在scrum 本身。



LeSS 的做法，其實就是讓 PO 與 scrum master 可以管理多個 team，除此之外，所以的作為都跟原來的 scrum 一樣，除了在 planning 時有分上下半場，上半場由 PO 講解這個 sprint 的功能，並由各 team 領取 story，下半場則是各個 team 進行 story 的討論與切分，跟點數的評估。



而 SAFe 的做法是引進一個新的概念叫 Agile Release Train。Release
可以看成是由幾個 sprint 所組成，例如 5 個 sprint 加上一個整合的 sprint 組成一個 Release。所以各團隊的 sprint 可以不同步，但在 Release 前那個 sprint 要兜在一起。這個 Release 有個專有名詞叫 Program Incremental (PI)，而那個整合的 sprint 則叫做 Hardening Innovation Planning (HIP)，這個原來是進行整合並且 plan 下一個 PI 的機會，Hardening 有淬鍊的意思，不過後來因為大家覺得用 Hardening 似乎有鼓勵大家到這個 sprint 才進行整合，所以就把 Hardening 拿掉，稱為 IP 了。SAFe 成三層，最底下是 TEAM，也就是原來的 scrum team，只是多了剛剛說的 IP sprint，另外因為每個 team 看到的不是整的 product，所以稱 backlog 為 team backlog。第二層叫 Program 層，就是在這層定義 PI，這層的人稱呼也不同，原來的 PO 叫做 Business Owner，另位會有 Product Management 將 BO 整合在一起。最上層叫做 Portfolio，Architect 就放在這一層，也有 Epic Owner 負責大項目功能的定義，這一層會跟原來公司管理層銜接，所以會有 Budget、Stretagy 等在內。看完是不是覺得 SAFe 真的有點複雜! 我們在公司內目前如果遇到跨兩個以上 team 時，應該會以 LeSS 為主要的實作方式。