# 2022-09-26

## Leon's note
### Interesting Points
- training 最好是貼近真實、減少模擬成分，因為太明顯的模擬會讓參加者去猜測主事者想要什麼
- 如何克服遺忘曲線？使用 [space repetition（間隔重複）記憶法](https://zh.wikipedia.org/zh-tw/%E9%97%B4%E9%9A%94%E9%87%8D%E5%A4%8D):
- SM 的課題之一：actively do nothing，很重要，也很難
- learning pair 的制度
- sprint planning part2 拆 task 並非絕對必要，也是有很有經驗的 team 光看 item 就知道要做什麼
- 讓與會者幫自己貼上標籤（先準備好標籤給與會者選），這是為了後續分組算 diversity
- 4人 / 5人 / 6人 的 team 會有截然不同的溝通體驗
- 可以的話，把 stakeholder 換個詞來稱呼，因為 stakeholder 其實表達不出什麼具體含意
- 迭代是不斷發生的事情，並不是非得依附在 sprint，即：sprint 只是個時間區間，與迭代沒有絕對關係
- LeSS refinement 是十分累人的，在現場放幾張椅子，目的不是要給人坐而是 SM「觀察」，當有人坐下的時候代表是時候休息了
- 在現場 refinement 可以考慮使用葬禮式的方式輪流排序 item
- 線上很難做到，但線上卻可以很快速地讓所有人做完第一次排列
- 在討論現場（e.g. refinement）遞給每人一支筆，可以減少少數人主持發言成為 bottleneck
- **少做原則**：不要自己把 scope 做大，寧願做少一點之後補做，因為做錯了、多做了就是多花錢，且這是要不回來的
- **事後抱怨原則**：事後抱怨比事前說明容易，有時要對方一開始就講清楚並不實際，不如先丟一版給他抱怨（如同刻意問錯答案手法）
- 從激起討論的角度來說，user story 寫得很清晰，不見得是一件好事，會讓 user story 變得像是 document 一樣
- 「做了幾次應該要有進步，下次要多拿 item」其實是個思考誤區
- Definition of Ready 不見得是個好的實踐，團隊應該追求的是 outcome 而不是 output
- increment 3V
- Valuable: 對最終用戶有用，不能像是單一顆七龍珠一樣
- Visible
- Vertical: 不集中在技術棧中的某一層，而是能跨越
- 軟體開發中一種**最理想**的狀況：每個 commit 都直接整合到 shippable 的產品上

> Q: 根據 product backlog 的 TAI 的精神，backlog 變成類似備忘錄的用途是否是壞味道？backlog 裡面堆積有許多 item 是否是壞味道？
> A: 這牽涉到 PO 與團隊間的合作信任，實際上 PO 並非做「自己」想做的東西，而是擔任一個協調者、窗口，主責協調外部政治勢力，所以 backlog 變化的 TAI 也並非根據 PO 自己的喜好，而是要反映現實需求

### LeSS
- LeSS is Scrum: LeSS 本身就是 Scrum，但指的是 2017 版的 Scrum，2020 版以後的 guide 已經因為商業化被改得有些奇怪（例如明確的角色被改為 accountibility）
- 我們經常太過強調自我摸索，但有時先給明確的指令，讓學習者 follow 後再根據理解發展出自己的作法，學習效果是更好的
- LeSS 比起單團隊 Scrum 也就是多了 overall retro
- overall retro 討論的是跨團隊合作的議題，一般會有主管角色加入
- overall retro 一般不會在 sprint 結尾 retro 結束後接著做，而是會在下一個 sprint 一開始 planning 完後進行
- 在 sprints 中發生的事件，可以分為為了 WHAT 和為了 HOW 而做的，sprint 螺旋的左邊是 WHAT、右邊是 HOW
- WHAT 類型的事情是 LeSS 各團隊一起做，是集中性的，通常無法臨時發生而是需要先計畫並配合 timebox
- HOW 類型的事情則是各團隊分散式地做，會依需求而突發，不必所有 team 都在場一起參加

### Refinement
- refinement 並不推薦在線上進行，目前還沒有發現一種特別適合在線上進行的做法，有些公司即便 WFH 也會要求在 refinement 時員工到現場
- refinement 不是一種「發明」的活動，而是一種「發現」的活動
- 有時候如果有某些環節不清楚就會很難進行下去，因此「最好」的情況是「所有人」都到場
- 很違反直覺地，LeSS 會刻意最大化團隊間的依賴，例如讓 2 teams 「同時」做互相有關的 item
- 估點是為了促進溝通
- 估出來的點數本來就不會是準的，因此對於估點結果糾結相鄰點數的差異是沒有太大意義的，要更改點數的話至少要是一次跳兩格的差異才有意義
- 根據「事後抱怨原則」，並不一定要有所有詳細資訊才開工，refinement 也不一定非得要問到所有資訊
- Key Examples 是無法描述很泛用的場景的，而是一種有名有姓有數字的特殊場景
- 因此要用多個 Key Examples 來包圍出一個完整的場景

### Item
- item 太大，可能會對「透明性」有所影響，因此才需要拆小並寫 AC
- AC 不是一種合約，不是訂下就不能改的
- item 不一定要是 user story！refactor 也可以是 item，但從 3V 角度來看並不是個好 item

### PO
- PO 不應對 item 評價（大/小/難/易）
- PO 是
- Police Officer: 管理能不能花錢做某個 item，他不一定知道細節
- Political Officer: 協調外部政治勢力
- PO 做的其實就是花錢買東西的工作，買的東西有好有壞，但沒有什麼不能買的
- PO 一般不參與 retro，除非當次 sprint 有許多與 PO 協作相關的議題，當然團隊也可以自由邀請 PO 參加

## Alex Notes
- Startup
- 企業都假設 人員不會離職
- 目前就是用 一個星期就會離職 的方式 模擬，跑完完整一個Sprint
- 互相交流學習，可以學到很多
- Scrum Master
- 不會只與一個Feature team 作Link，多個Feature team 共用
- 此次Training 會更主動 Active do nothing. 因為只有一個禮拜
- Diversity :
- 會使用各種團隊因素，增加團隊多樣化 ，先自己選擇，再計算Diversity因素，只能增加，不能減少．
- Sprint :
- 主要的意義在 協調，達成可預期性
- 迭代 與 Sprint 不一定是同步的，一個迭代會有多個Spirnt
- LeSS名詞
- Item : PBI
- Task : 團隊要完成 PBI的工作在Sprint
- Sprint Planning I : 依 Ordered PBI 作，每一次 使用 3-5 個PBI，
- PBI 太小沒意義，太大要Split，
- 再來要做 Detailing理解 要做什麼（以外部的角度），會得到Acceptance Criteria， 表格 or GWT的方式表示
- Estimation : 每一次，都會拿固定的的點數，不要指望越做越快（一次比一次更進步，所以每次拿的的PBI點數要增加），不現實．
- 
- Sprint Planning II
- Sprint Backlog:團隊的計畫 如何完成 PBI計畫
- 目的 ：評估如何做，把Task列出來，推算能不能做完，如果做不完就還給PO
- 有一些團隊 可能會做簡單的設計
- 有一些團隊 可能不做Sprint Planning II
- 
- Potentially Shippable Product Increments (PSPI) : 在Sprint 過程中，對每一個PBI，如果可以，只要完成就能夠提前先Release。
- 
- Sprint Review : 看每次的Increment, 產生Feedback放到Product backlog，經過Review完，理論上要影響到Product backlog使之改編
- TAI （Terry Agility Index）有多大的比例PBI 經過Review 會改變，包括內容與順序，REF:https://less.works/blog/courses/2016/04/19/terry-agility-index.html
- 
-
- PBI 沒有準備做他之前 不用細化，PB Refinement: Sprint 過半的時候執行，一個Sprint 接下來就是下一個Sprint中間沒有其他東西，ＰＢＲ 會做 下一到二個 Sprint ， 基本上做的內容跟Sprint plan 1 一樣．
- 彈簧左邊 都是 What，右邊的部分都是How，Estimation 用的顏色不一樣，代表跟How相關
- 
- Ｑ：根據 TAI 的概念，Product Backlog 若變成一種類似備忘錄的用途（PO 感覺這 item 好像未來可做就放進去），是否是一種壞味道？
Product Backlog 很長是否也是一種壞味道？
- PO 應該指引PBI 優先順序，要指引正確的方向，讓大家信任，如果PBI 方向定得不好，會失去信任，
- Product Owner (Problem Owner) :協調各方政治勢力。作為單一聯繫點。
- Sprint Planning I & II 兩禮拜的 大概兩小時，一個星期大概一個小時，Review.Retro 也是一個小時．
- 如何Scale Scrum
- 其他人分享
- Overall 的部分會團隊打散 作 PBR ，不然人太多
- 如果有團隊 SPII有問題，有相依性的Task 退回，會請代表出來橋，在通知所有人．
- Spring Review 是否一起開 ：每個團隊會擺攤，開放功能給大家玩，看有沒有問題．
- Chief Product Owner : 一個PO如果對 四到五個團隊，就會很吃力，所以除了CPO需要其他PO
- PO 是否要參加SP2 ，PO待命，有優先權問題，在找他．
- 每個人對Scrum理解不同，當Scale時，可以選擇
- 保持Scrum 價值
- 在上面架構新東西解決問題
- 不斷Drill down 進去，都是迭代
- 不同團隊都在同一方向，不會有不一樣的方向。
- 
- SPI : 有幾個呢？
- Backlog Refined : 打散來做，
- 跟What 有關的集中來做 review, planning來調整，跟How有關的 個團隊自己做．透過Retro 調整
- What是集中式的，計畫好的，透過Timebox 控制．
- How是分散式，發現問題，在做就好，也沒有所有的人都參加，也沒有Timebox
- Review Meeting : 也是一個
- Retro : 每個團隊有自己的Retro(一般來說PO不參加)
- Overall Retro : 解決團隊間的問題，會等到 Sprint planning 後，再由管理，PO，代表，討論跨團隊問題
- Scrum Master : 教給大家做Scrum，不在這張圖之中．
- Scrum VS LeSS
- Less is Original Scrum : Scale Scrum 精神，只多一個Overall planning.
- Scrum 因為商業化越來越奇怪，Scrum Guild越修越怪，2017年版本比較正常
- Issue, bug 是否是 Product Backlog? 等待上下文做進一步討論．
- 產品
- Spaced repetition
- 遺忘曲線
- 要有效率地複習
- 
- 組織知識體系，幫助思考，就像麵團變成甜甜圈的過程，最後會做出甜甜圈
- 做軟件，先有產品才能抽象，所以一開始沒辦法把麵團做出來．而是 先有各種不同的甜甜圈，最後才有麵團，
- Impact Maaping
- 可視化 我們做什麼來服務我們的目標，我們做什麼可以產生積極的影響，行為對商業價值的影響．
- Goal : Why
- Actor : Who
- Impact : How
- Deliverable What
- Impact Mapping只有一個終極Goal
- 
- User Story Mapping :
- 有時候一個角色，有時候多個角色
- Backbone : 主要的功能
- 功能列表：要達到這一些主要功能需要做哪一些事情。
- 串成 完整的 場景 ，幫助我們做拆分還有prioritization
- 
-
- 拆分，不會是均勻地拆分(左邊)，如果均勻，代表需求不會變化與現實不符，應該是有一些大小區分（右邊）．
- 
- Take a bite to start，都沒有做過，該著麼拆？
- 挑一個特點的功能（能夠代表User，需求，商業利益）跟技術無關，深入地做他，等到對這個需求有所瞭解之後，再開始完整的拆分．
- 拆分需要符合3V
- Valuable : 有價值（七龍珠，要齊全了才有價值，）
- Visible :可以衡量
- Verticle : 希望能夠跨幾個Service，與Microservice核心理念相衝突．MS希望每個Service 獨立，但實際需求上 功能會有跨service
- 
- 重構是不是好的Backlog Item，但可以是個PBI，ＰＯ什麼都可放，所以PBI可以放，所以User Story 不等於 PBI ，Item 會包含非User Story 的東西．
- https://doughnut.odd-e.com/
- Wiki Pedia 底層是 WikiData ，他是語言數據模型，可以給電腦用的知識體系。
- Notebook 有很多 note
- PBI list
- Fetch Person info form Wikidata
- 需要圖片跟地圖
- 作為ＰＯ不要對項目評價 e.g.很難，很簡單
- Spilting -> detailing - > estimation
- 如果讓一新團隊用探索的方式執行，新東西太多會無法執行，會先給固定，再調整．
- Refinement 沒有比較好的辦法在遠端上．
- General : 大家對這個ＰＢＩ。
- Scope : 要做的範圍有多大
- Assumptions : 不確定的地方，可能需要澄清，澄清之後就會移到Scope
- Key Examples :
- 最重要的就是 Tile，每一個Example 都需要一個Title ，但如果寫的太明白就變成 Spec.
- 基本上 是GWT的格式．一個Case只能很特化的說明，有名有姓，不能夠泛化，
- 要泛化則使用使用多個Use Case來表示，並且拿來做驗證
- 
- PO 成了中間的傳話筒，Donor 提需求的人，這是不對的，ＰＯ只是建立雙方聯繫．
- PO別名Political Officer
- PO別名Police Office
- 
- Scope如果沒有定義好，會多花PO的錢．
- 做少，可能不開心，但是可以繼續往下作
- 作多，可能不開心，但是花掉的就回不來了
- 實例化需求要解決的是教育問題，
- E.g.線性代數學習 ， 會用多個題目來驗證學習成果，不會只問會不會
- 實例化需求時，一開始越浪漫越好，用Example 來Confirm，正向的一定要有 GWT，反向的話不一定要有GWT，但是一定會有Title.
- 如果有問題 沒有問到，就看會不會影響到目的，e.g. 圖片地圖，顯示順序，如果沒有影響，就團隊決定就好．
- 實際上執行，每個PBI都會需要Team 交換著看，然後給意見．
- Facilitator ：要幫助大家參與
- 如果大家都站著 可能要 休息，
- 給筆 讓大家一起寫，避免討論集中在某幾個人身上．
- 誰要參加： PO , Team , UX , DevOps , User , Product , DBA , Operation ，誰都要來，不是發明的場合，是發現的場合，就看能不能全部參加齊全．
- 不要使用Stackholder 這個詞，沒有任何的含義．
- 需求是否打破沙鍋問到底，
- 不是簽字畫押的場合（陷入Contract問題），所以不會，
- Basic Law :
- 事後抱怨總是比事先說明好一點，與其讓她說清楚他要什麼，不如給他一點東西抱怨，這比較容易做到．
- 有些人在乎，
- DoE : Definition of Ready，有穩定的輸入，才有穩定的輸出，Team 穩定的flow是好事
- 看中的是output，不是Outcome，所以不建議
- PS:額外討論時覺得，DoE 可以拿來做不同 Level 的Bridge，如果Sprint team都是自家人，有共同的目標與利益，Scrum 程度都一樣時，可以不用DoE，但如果彼此利益不一定一致，Scrum程度也不同時，可以適度透過DoE的方式，讓Outcome不會受到影響．
- Spring goal : 由 PBI 反推Goal沒有意義．
- 估點 ：
- 以感覺為主，實際上花多久時間，沒有那麼重要，一開始會給定幾個之前做的PBI作參考的錨點。
- 葬禮式估算（不說話，自己移）
- 第二階段，就看有沒有問題，移動時要說明
- 第三階段，除非一次移動兩格，才要移動．
- 為什麼要估算：
- 對優先級會有影響，很小但很有價值，優先就會比較大．
- 幫助Ｈight Light 引發討論，促進討論，Align 將來的預期．
- 哪一些Item 須要估算:所有的Item 都要估算，一百個Item 也是一起估算，也不會花太久時間。
- 什麼時候可以更新，任何時候，只有estimation是事實時，沒有意義．
- 團隊 不願意給 ，因為Contract Game. 把估算當成承諾。把估算當成團隊KPI．估算濫用很普遍，所以No estimation，估算本身沒有害處，看如何使用．
- DoD 只能多不能少，DoD 是一個度量標準，定義最低水平．
- 目的，保證透明度還有其他的（沒說到）．DoD的Owner 是PO，DoD代表最佳軟件開發方法的理解．
- 如果沒有人用Dead code ，就算是UT也不能留在上面．
- 所有的人都要提交到主幹上．只允許 update all，不會在local 留下沒有Checkin的版本
- 用Main only 的Branch 策略，是最理想的狀態（沒有任何的中間States)
- Initial working agreements
- 很多的團隊就會有很多的工作協議。
- 團隊會在多次迭代後，找出最好的工作協議．
- 分工作的原則
- 比較像黑社會談判來分PBI，DEV團隊像是黑社會角頭談判，一個老大在前面，後面跟一群小弟，PO就像是警察，默默的在後面等著被召喚。
- 
- 最大化團隊的依賴，造成最多的Dependcy
- 認領完就不知道原本的Priority長相，理論上進了團隊就沒有Priority
- 領進來會需要先做跟別人有關的，優先級會提高．
- 團隊認領在Sprint Plan I執行