# 2022-09-27
## Leon's Note
### Interesting Points
- Temperature Reading as check in
- 很有溫度的感謝用詞：「謝謝 xxx 做了 yyy，感謝他為了 zzz 的努力」
- kata 題庫：https://cyber-dojo.org/creator/choose_problem
- 要克制依照使用者流程去拆 item 的衝動，因為即便做完其中一個，整條功能還是無法使用
- 關注核心業務邏輯，例如網銀轉帳，核心是錢從 A 帳戶轉往 B 帳戶，因此應先考慮完成轉 1 塊錢的功能，再去考慮其餘的登入、驗證等等功能
- 在考慮 item 實現的先後時，用「因果」去切開會是比較合理的作法，例如電商訂單退貨功能，一定是要先有建立訂單功能，才可能附加上退貨功能，這時候分為建立訂單 item 和退貨 item 就合理，而且建單功能一定會先做，退貨則是基於既有功能附加上的，即便沒做也不會影響核心流程
- 用一個實際指示物（e.g. 尖叫雞玩偶）來代表是哪個 team 造成共用 CI fail 並將指示物放置於顯眼處，讓所有人都看得見，用無形的力量去敦促該 team 修復，而不是口頭催促
- 6-8 個 sprint 可以發生一次 "Current Architecture Workshop" 讓所有 member 有機會認識當前產品專案的最新發展狀況
- PO 其實也有權力去 assign 哪個 team 做哪個 item
- 注意討論時的「名詞」和「動詞」，用詞儘量統一、精準，來勾勒出 domain
- cucumber test 描述的是 user 角度的場景，不應有技術相關詞彙出現
- 一種理想的狀況：儘可能不要在 local 端有未 commit 的改動，否則會與真實狀況距離愈來愈遠
- Terry 建議讓自己做到可以隨時 commit & push，並在接近下班前開始做一些收斂性質的 task 而不要開新副本，否則經常會因為亢奮而延遲下班
- 除了一開始 SP1 就先拿下所有當週要做的 items，有另一個作法是每個 team 就只先拿一張 item，做完才跟其他 team 和 PO 同步資訊並拿下一張
- 確保每個 team 都有至少一張 item 可以做的同時也避免過度承諾
- 「吃」下 item 之前先考慮，能不能做到 **DoD**？不應只是考慮技術可行性而已
- Done 和 Finish 還是不太一樣的，Done 在 Scrum 中甚至是有點神聖的事情
- 改 code 導致測試壞掉，代表的其實是這版新的 code 在某些情境是壞的
- GWT 的 Given 隱含了「本來就有的狀態」的意味
- 例如：「title 為台北且有顯示 photo & map 圖片的一篇 note」
- Focus 在要通過的驗收條件，即便偶然發現有 bug，除非擋到路否則就先不管它，若擋到路那修復這個 bug 就是實現驗收條件的必經的一部份
- e.g. wikidata id input 在 submit 後未更新問題

### 浪漫與經典
- 浪漫講求的是感覺，細節愈少愈好
- 測試應當浪漫，就像寫情書
- 讓初始測試通過的 easy code 也是一種浪漫，得過且過即可（有時甚至 hard code）
- 經典求的是「心靈的平靜（peace of mind）」，讓事情能夠做了就忘掉，因為無須擔心
- 農場小幫手 Jim 的故事 https://www.youtube.com/watch?v=VMDQumInZw0
- 重構就是一種經典
- 兼具浪漫與經典，就是有品質

### Refactoring
> "Programming is an ART of doing one thing at a time."
- 重構的時候才做「設計」，架構由此而生，而非預先設計
- behavior 的改動和 structure 的改動要拆開來做
- refactoring type 1&2
- type 1: 目的大都是「整理」，不太會影響整體的架構，比較類似於看到雜亂的房間想要收拾一下的感覺，通常伴隨於 behavior 的改動發生
- type 2: 目的是讓之後的改動更容易，通常會發生解耦合、改架構等工作，要在所有測試都通過的前提下執行，有的時候會是發現 behavior 很難改之後，先退掉對 behavior 的改動（或 ignore 新測試）轉而先把 type 2 refactoring 做好後再回頭專注於原本要做的 behavior 改動
- MTCEBMTEC: make the change easy before making the easy code

### Team Work
- pair 時，driver 並非完全不思考，反而他應該要是 smart keyboard
- 合作默契愈好的 pair 組，溝通的層次會愈高；反之不嫻熟的 pair 組則會有更多低層次溝通
- 高層次溝通：「這邊有個 feature envy 的 code smell，把它改掉吧」
- 低層次溝通：「請輸入 pokerHand，p, o, k, e, r, h, a, n, d」
- 理想的 Just In Time Leadership，就是當需要時，團隊會自然而然地出現一個 leader 帶領團隊解決眼前問題，這位 leader 可能是出於對該問題類型的熟悉、個人特質、興趣等等原因，並且會在問題解決後退位回到原本 team member 的身分
- 5 個人的團隊可能會是有良好溝通品質的上限，6 人以上的團隊會開始出現 sub group，此時會需要有具備經驗的 facilitator 或 SM 介入引導
- 要避免抽象地在空中描述，用共同看得到的畫面來對焦討論項目、用 example 來對齊認知

## Alex's Notes
### 早上回顧

- Assumption Mapping : 新概念．有機會可以查一下
- Impact Mapping (粗顆粒度)-> Story Mapping (細顆粒度)
- Impact Mapping 在Review的時候，再拿回來回顧，看是否產生正確的價值。
- Lean inception :

- Temperature Reading(Daily Scrum meeting?)
- Appreciations : 有沒有要感謝的人
- New Information : 會影響協作關係的．
- Puzzles : 困惑，
- Item Name Token : 只是溝通的標的，沒有具體的意義
- 了解使用者目的，真正幫助使用者，會比做這個PBI還意義重大．
- Sprint 有很多的迭代，拿了三個Item，每一個Item會跑完整的迭代。一個Item 可能是用很多場景，每個場景，就是一個迭代，一個Test Case就會是一個迭代
- 有依賴不得不溝通是副作用，主要目的TBD
- No Dead Code，實作的方式，沒用到的就是Dead Code，舉例來說，有人寫了一個Test Case，Checkin 後離職，後面的人就不知道這個Test Case在幹嘛
- Biz Domain跟solution Domain 交互的時候(UbiLang 定義)，要在PBR做掉．E.g. Book , location
- Item優先順序，
- 步驟的順序，不會這樣子拆
- 完整的Item 有優先順序，就按照優先順序．
- A與B 依賴某個技術項目，這個時候，AB 估算都是用獨立的故算．Q:那這樣子會不會造成Sprint肥大．沒有做那麼多事情？
- Worry w/recommendations : 擔憂與建議
- Hopes & Wishes :期待
- 一般團隊在週四作PBR，
- current architecture workshop. 一般也是在禮拜四上午或下午，三四個月做一次．描述目前系統架構．
- CI Fail rate 10 次 1 個fail，人數多你會希望小一點
- Chicken coop 拿走，代表有人在修，不要push.
- 如果在自己家，但不是自己幹的，要去問其他家，誰要修這個東西．
- 一個PO會不會有特別喜歡的團隊，實際上會有，PO可以指定
- Sprint 的週期，讓每個人可以對未來有預期的狀態，如果不是固定週期拿PBI會造成大家步調不一致。
- 先做小步驟，看有沒有用，CRUD可以分開，有時只是看一下感覺．
- 要做多少
- Done, 只有一個團隊DoD跟多個團隊DoD不一樣。
- Finish：可以想一想
- 故事
- 
- 農夫老了 工作做不完 開始找人，只有來了一個小孩Jim，問他會什麼，小孩說，刮大風我也能睡著，老農夫 決定試試，Jim 後來做的也中規中矩，一天一天過去，突然一天掛大風下大雨，暴風來之前一般都要先做準備，農夫開始找Jim，他正在睡覺，也叫不起來，最後農夫決定自己用，結果發現 馬都在馬廄 們都鎖好，乾草也很牢的固定在那邊，好像全部都準備好了，農夫跟Jim 問如何預測風暴的，Jim說每天我都先整理完畢，就可以睡得好覺
-
- User Story and Test Case ，可以浪漫一點，
- How 那一邊，就要經典一點，著麼好維護，少Bug. 經典 = peace of mind 如何得到內心的平靜．
- 架構師 ，我們持續做一些小決定，讓他維持 peace of mind
-
- 測試驅動開發
- 
- Refactoring type 1
- 紅燈(浪漫)，用紅燈來描述測試情境，只涵括包括的使用情境．
- 綠燈(浪漫)，在我們的情境上有能夠工作．
- 重構(經典), 紅綠重構 就算沒有也要做，有測試保護，有Working software. 不更改外部的行為，改內部的設計
- 設計從有實際上的Code重構開始，不是一開始就做設計， 設計是慢慢演進，再變成架構．
- When :從有實際上的Code重構開始
- What : 什麼東西提示重構，Code Smells
- How : 用IDE抽取
- feature envy，
- 紅燈，代表弄壞掉，某一些測試情境
- EC: Easy Change
- 當有浪漫的美，也有經典的美，才有Quality.
- E.g.有品質 外面看起來很好，結構也很堅固
- cyber-dojo.org
- 
- ERROR 先修掉，再處理 Assertion Fail
- 出現紅燈時產生真正失敗，才開始寫code.
- Refactoring cat
- {:height 611, :width 747}
- 寫code , programing is art of doing one thing of time. 跟攀岩一樣
- Behavior , Structure 是兩種不同的改動，要分開的。會是 BSSBSSSBS這樣子的節奏．
- Refactoring type 2
- Make the change easy before make the easy change
- 這邊需要解耦合 MTCEBMTEC
- 
- 上面的部分是 實作，下面是 理論基礎，如果把理論基礎當成實踐來做，就會有很奇怪的狀況
- Type 1 會伴隨著Behavior改動來的，Type 1 and 2 都會有Structure change.
-
- Less In Action Teams
- {:height 308, :width 402}
- Team
- 真實 長久不變往好的方向努力
- 有遙不可及的共同願景
- 成員會在這個團隊不斷的演進，並且不斷成長
- 公司可以重外面，導入新的想法Coaching
- 公司與團隊可以互相承擔彼此的壓力，
- Team Sport 是一個馬拉松，不是短期衝刺
- 如何建立一個Team
- Retro 方向
- 效率
- Working agreement ：團隊協議，約束我們習慣，提醒我們該做哪一些事情，為了做到Learning team.
- 主要是團隊 如何進化，
- DoD : 逐步達到完美的開發水準
- 讓整個團隊多做一點點的進步
- 還要跟外部Team 的關係
- 當下的Just In time leadership ，沒有指派特定的Team Leader
- Size最多5-8 個 在同一個Team
- 跨技能人才比較好，
- 如何快速達成共識，僵局的時fis of five
- Commit 代碼的 抉擇，要保持能夠Check in code.
- 上午做開放性的Case.
- 下午做收斂性的Case
- Commit = Push = Deployment.
- 4-5-6 五個人都會照顧其他人感受，6個人會出現SubGroup，就需要很多的Facilitating Task，有可能的話不希望團隊超過五個人．但是為了維持團隊 會給到7個人，才不會被團隊人員流動影響，但對SM中，他要做很多維持的工作，會很辛苦．
- Just in time leadership. 當一個情況出現，會自動產生一個Leader來協助解決問題．
- 小組的人，Leader 會換，只有社會化到一定的程度才有可能有長久的Leader
- Hunan kind - a hopeful history
- Learning team.
- E2E Test 目的
- 完整的展現產品目的
- 衡量目前開發進度
- PBI 的實現不會是用技術的Team
- E2E 的實現
- Cucumber 的 Backend 是 3A的 Arrange ，負責把相對應的資料Insert.
- 對於後面實際上的操作會寫在Command and Testablility
- 對外部的操作 會使用Mock的E2E Service，才不會因為外部的Service 損毀造成問題，最後External Service 需要每天跑個兩次，確保跟外部Service的接水