--- # System prepended metadata title: '2022-09-26' --- # 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 ![sprint 螺旋](https://i.imgur.com/BwZ9el6.png) - 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點數要增加），不現實． - ![Imgur](https://i.imgur.com/kaXEmhX.png) - Sprint Planning II - Sprint Backlog:團隊的計畫 如何完成 PBI計畫 - 目的 ：評估如何做，把Task列出來，推算能不能做完，如果做不完就還給PO - 有一些團隊 可能會做簡單的設計 - 有一些團隊 可能不做Sprint Planning II - ![Imgur](https://i.imgur.com/l2wEvsG.png) - Potentially Shippable Product Increments (PSPI) : 在Sprint 過程中，對每一個PBI，如果可以，只要完成就能夠提前先Release。 - ![Imgur](https://i.imgur.com/bUmbKZR.png) - 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 - ![Imgur](https://i.imgur.com/p0uLOWS.png) - - PBI 沒有準備做他之前 不用細化，PB Refinement: Sprint 過半的時候執行，一個Sprint 接下來就是下一個Sprint中間沒有其他東西，ＰＢＲ 會做 下一到二個 Sprint ， 基本上做的內容跟Sprint plan 1 一樣． - 彈簧左邊 都是 What，右邊的部分都是How，Estimation 用的顏色不一樣，代表跟How相關 - ![Imgur](https://i.imgur.com/OPEXgXt.png) - Ｑ：根據 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 進去，都是迭代 - 不同團隊都在同一方向，不會有不一樣的方向。 - ![Imgur](https://i.imgur.com/Qgt7YEk.png) - 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 - 遺忘曲線 - 要有效率地複習 - ![Imgur](https://i.imgur.com/DeUjjhG.png) - 組織知識體系，幫助思考，就像麵團變成甜甜圈的過程，最後會做出甜甜圈 - 做軟件，先有產品才能抽象，所以一開始沒辦法把麵團做出來．而是 先有各種不同的甜甜圈，最後才有麵團， - Impact Maaping - 可視化 我們做什麼來服務我們的目標，我們做什麼可以產生積極的影響，行為對商業價值的影響． - Goal : Why - Actor : Who - Impact : How - Deliverable What - Impact Mapping只有一個終極Goal - ![Imgur](https://i.imgur.com/RAxD4EB.png) - User Story Mapping : - 有時候一個角色，有時候多個角色 - Backbone : 主要的功能 - 功能列表：要達到這一些主要功能需要做哪一些事情。 - 串成 完整的 場景 ，幫助我們做拆分還有prioritization - ![Imgur](https://i.imgur.com/HtScMLp.png) - - 拆分，不會是均勻地拆分(左邊)，如果均勻，代表需求不會變化與現實不符，應該是有一些大小區分（右邊）． - ![Imgur](https://i.imgur.com/ipkQad3.png) - Take a bite to start，都沒有做過，該著麼拆？ - 挑一個特點的功能（能夠代表User，需求，商業利益）跟技術無關，深入地做他，等到對這個需求有所瞭解之後，再開始完整的拆分． - 拆分需要符合3V - Valuable : 有價值（七龍珠，要齊全了才有價值，） - Visible :可以衡量 - Verticle : 希望能夠跨幾個Service，與Microservice核心理念相衝突．MS希望每個Service 獨立，但實際需求上 功能會有跨service - ![Imgur](https://i.imgur.com/sWiPgbQ.png) - 重構是不是好的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來表示，並且拿來做驗證 - ![Imgur](https://i.imgur.com/1iUnw3y.png) - PO 成了中間的傳話筒，Donor 提需求的人，這是不對的，ＰＯ只是建立雙方聯繫． - PO別名Political Officer - PO別名Police Office - ![Imgur](https://i.imgur.com/DKY8x0j.png) - 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就像是警察，默默的在後面等著被召喚。 - ![Imgur](https://i.imgur.com/4eMz3VI.png) - 最大化團隊的依賴，造成最多的Dependcy - 認領完就不知道原本的Priority長相，理論上進了團隊就沒有Priority - 領進來會需要先做跟別人有關的，優先級會提高． - 團隊認領在Sprint Plan I執行