學習筆記｜RSG 2021 學習筆記 (Part 1)

 

圖片來源：官網https://rsg.taipei/  

去年底參加了第一次的敏捷 Regional Scrum Gathering℠ TAIPEI 2021 盛會，因為11/4 ~ 11/6 是工作日的關係，時間蠻多搭配不上。還好主辦單位很貼心的經過講者同意，提供有期限的錄影回放，還有議程紀錄與共筆 -->  https://hackmd.io/@RSG/HJuRamrUt/%2FyXFFfNoyTLqOAXTgBYOL8w

趁著2022年初的連假空檔，除了吃飽睡飽之外，也來一點學習活動 XD。把之前時間搭配不上，朋友有推薦的演講先來補了其中兩個，分別是「重拾初心」- 全球敏捷轉型的反思 by Evelyn Tian 以及LINE TODAY的大規模敏捷之路 by Derek Chen。其他有意思的演講，之後再找空檔來繼續學習。

以下是簡介和簡筆部分。

1. 「重拾初心」- 全球敏捷轉型的反思 Evelyn Tian

以下簡介摘錄自演講介紹...

“敏捷宣言已經誕生20多年，全球都在如火如荼地展開敏捷轉型。反思你自己的敏捷之旅，你是否有 “吾日三省吾身“？你是否“知而不用乎？用而不任乎？任而不省乎？省而不行乎”？ 通過這個主題演講，我和大家分享我已經成功教練國際大、中型企業與輔導全球75個國家的敏捷實踐者們的經驗。通過組織、產品和團隊的實例，聚集於「重拾初心」的策略以達到持續改善的目的。”

Peggy 簡筆：

講者為專職教練和創業者，其學生橫跨76個國家。也因為這樣，相關經驗非常豐富，不但演講很生動風趣，也分享了許多有意思的觀察和案例，引發我們一些反思。

從晏子和秦景公的故事，帶出以下幾個不同層次的觀察發現和情境。

• 知而不用

• 用而不任

• 任而不思

• 思而不行

• 知而不知

提到的面向很廣也十分實務，例如常聽到的...

• Scrum-But ，「我們在用Scrum框架」，但是.... 

• We are special ... , so....  ->   在運用框架時，要去仔細思考，對照自己所在的環境與組織

• Project Owner 變成專業的Product Backlog 撰寫者，而卻沒有和客戶接觸，對於整體的 roadmap 更是沒有掌握度

• 關於Agile Coach 敏捷教練，其實 Manager 不知道怎麼和敏捷教練合作，敏捷教練也對發展什麼樣的技能沒有足夠清楚的了解

• 工具使用：如 JIRA等好產品，我們是否有讓這個好產品，好好的為我們服務？還是在日常的忙碌中，只記得去使用它，忘了當初使用的初衷和目的，忘了最重要的是人之間的互動
• ....

另外在談到相依性 - dependency的部分時，Peggy直接就連想到目前的專案...

不少功能和其他團隊有高度相依性，的確也會造成 lead time。這部分可以再更細分為技術成熟度的相依性、時程與服務的相依性。前者可以藉由讓團隊技術能力更加提升而減低相依性；而與其他 team 服務與時程的相依性，某些部分也可以藉由熟悉相關流程和技術 mitigate，但仍然無法全面抵銷，許多部分也是要靠「溝通」與協調，包含與PO合作的部分。

有興趣的朋友可以參考共筆，更多豐富的內容 https://hackmd.io/@RSG/HJuRamrUt/%2FNKUVitXIRiiCERVQGtBr4A

2. LINE TODAY的大規模敏捷之路 陳岳澤 Derek Chen

以下簡介摘錄自演講介紹

" LINE TODAY打造內容入口的服務，內建於LINE程式中，提供使用者即時新聞資訊、體育賽事及娛樂電影資訊，服務的國家包括台灣、泰國、印尼、香港，月活躍用戶超過1800萬。 隨著使用者的需求增加，產品的功能變得越來越多，團隊加入更多的成員進行設計與開發。我們發現團隊的交付時間拉長、無法快速的響應變化、成員間的合作與溝通複雜性上升。 於是我們開始思考，怎麼做可以幫助我們解決這些問題呢？變成一個更好的團隊呢？ 首先，我們跑了三小時的自由組隊工作坊，組成個多個特性團隊。接著，採用大規模敏捷框架「LeSS」，幫助我們對齊開發節奏，以使用者為中心關注整個產品，我們發現做得更少，但成效卻更好！”

簡筆：

首先很快的回憶一下 Less(Large-Scale Scrum) 架構

Source: https://less.works/

因為這幾年參與專案的複雜性和規模有上升的趨勢，不少時候都需要和鄰近團隊的合作，也感受到原有的scrum 似乎有些不足，所以開始前陣子開始往LeSS 這塊實務去了解。

講者 Derek 是 Line 全職的 Scrum master，在此次演講中，Derek 分享了許多滿有幫助的實務經驗。包含一開始 ( 2018年) 團隊組成和運作模式，一路秉持著敏捷的精神，try and error，一個個 iteration 不斷地精進。

演講主題從 Why --> How --> What 一路走下來

• Why：The origin of story

• How：Self-Designing team and LeSS adoption

• What : 5 experiments in our process

Peggy 覺得有幾個比較少見又有意思的Practice，包含

• 一開始六週的sprint schedule

• 自由組Feature team

• Scrum master : 專任和兼任都有

在Cross-team Coordination的部分，Peggy 也一邊思考著目前自己團隊組織的現況，目前最大的挑戰包含整個大的虛擬團隊成員位在不同時區，分布在台灣，印度，美東和美西。

• 對齊開發節奏：算是目前團隊完成度較高的部分。

• Demo together整體產品的聚焦：這部分因為時差的關係，還在調整內容和形式，先紀錄一下，之後回頭看。

• Hold overall retrospective：一樣因為時差，採用分段的方式。

• Send scouts to other teams：這個很有意思，本團隊這陣子的新Practice是跨時區同function team 會有weekly sync up meeting，平日用Slack , PR and mail 溝通。每日同一個時區的Feature team成員們會有自覺地把資訊帶回來。相較之下，比起沒有weekly function team sync up meeting 前，資訊流的確順暢些。
  

這些 Q&A 也很實務，不少人對於自由組 Feature team 產生不小的好奇心。

• 重新組隊時，抵死不從的人後來怎麼了（不認同或不接受該重組或流程的）？

• 重新組團隊後，遇到了哪些混亂與技術上的挑戰？  

• 好奇的問，你們在跑LESS, 一開始分完團隊，這個團隊的陣型就固定下來？還是你們多久會切換一次團隊成員？

• 多個團隊都是接同一個產品的功能，那各團隊的開發語言、框架、Know how，是否相同？如果是不同的情況下，要如何解決？

• 依據您的介紹，LINE的設計師(UI/UX Designer)歸屬於PO team而非Dev. Team。請問貴公司的設計師都是如何與 Dev. Team 合作的？是以waterfall 方式預先設計好產品規格後才交給Dev Teams 以多個 Sprints開發嗎？或是有其他合作方式？

• 請問老師，有沒有什麼型態的團隊不適用less,例如傳產？

• planning 從一開始的一週, 變成一天, 這樣的設計會完整嗎？ 不周詳的plannig, 會不會造成開發中，才發現有問題，導致打掉重做
  

有共筆就是好:D ，因為共筆的內容已經很豐富了，也包含Q&A的部分。Peggy 就不多描述了，有興趣的朋友可以參考此篇 https://hackmd.io/@RSG/HJuRamrUt/%2FZxnHoOtKRTmPMhvQhzVaHA

希望以上的分享對有需要的朋友有點幫助囉，也歡迎交流討論。

喜歡此篇文章的朋友，歡迎轉貼。轉貼時請保持原內容與註明原文標題、連結以及作者即可，謝謝您。