---
tags: RSG
title: 敏捷領導力演進
image: https://i.imgur.com/nQhaXAd.png
---

{%hackmd @rsgtaipei\setting %}
{%hackmd @rsgtaipei\countdown %}
{%youtube 24DXcoFmCHc %}
[toc]

:::info
主　題：敏捷領導力演進
副　標：RSG暖身活動3
講　師：RSG TAIPEI 2022 講師組志工- 曾文仙
主持人：Jean
日　期：2022/9/28 (三) 21:00-22:00

免費下載 最新版 Scrum Guide 2020
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Chinese-Traditional.pdf

許多人常常在問，甚麼是敏捷領導力?
其實，Scrum Guide ( Scrum指南) 就是最好的敏捷領導力的詮釋，並提供敏捷運作教戰守則。

Scrum 指南的歷史，起源在1995年由Ken Schwaber 和 Jeff Sutherland 在OOPSLA 的大會上首次聯合發表 公開了 Scrum 的正式定義。Scrum Guide 因應時局變化、從1995年到現在，經歷7次版本更新，2010 、2011 July、2011 Oct、2013、2016、2017 到目前2020年版本。
在本次的分享，透過Scrum Guide 版本的演進分享，讓您掌握敏捷領導力的變化，也更新你所知道的敏捷知識，對於想完整認識Scrum Guide的你，是一個很好的機會。

:::
:::danger
關於 RGS Taipei 2022 專屬的管道，
官網: http://www.rsg.taipei/

「RSG TAIPEI粉絲團」 : https://line.me/ti/g2/CYY7jhPc3xi_ImsKqXuoNQ?utm_source=invitation&utm_medium=link_copy&utm_campaign=default
:::

## 語法教學
[RSG-2022 HackMD 快速上手]
(https://hackmd.io/gpZFfUicRd--qK-TVHyqKA)

## 常用 emoji
:x: :ng: :+1: :100: :kiss: :wave: :accept: :collision: :sun_with_face:

當日議程＆打字討論區 

敏捷領導力演進-留言區
===

正式開場前的閒聊區 （21:00前）
------------------

>可以用這樣的語法方式來標注姓名、表示意見唷～如果你想用什麼方式表達意見，也可以在正式開場前在這裡聊聊啦！
> 那麼我先自我介紹，也請大家在這邊自我介紹好嗎 
> 我是今天講座的主持人Jean，大家晚安 ~ 教師節快樂 ~。

切換到雙欄，即可在左邊欄做輸入

底下請挑選一格，幫我把你的名字打在 `=` 後面，並簡單自我介紹 

>[name=陳稼軒]一位在公部門打滾15年的資深參謀，剛踏入專案管理領域的小書童，便被它的專業所吸引，目標是將所學專案管理知識運用在工作上，並推動軍方事務革新。
>[name=diro]熱愛敏捷與程式設計，在公司軟體部門推動敏捷已經有七年，持續到處吸收新知識
>[name=]
>[name=]
>[name=]
>[name=]
>[name=]
>[name=]
>[name=]
>[name=]

## 開場：（21:00-21:05）

- 如果大家都願意使用文件，想請大家優先把意見具名（可以使用暱稱）打在文件上，有如便利貼一般收集意見，再進入回饋交流。
- 本次調性為「示範場」，許多作法皆是初步嘗試，請各位多加包容，也希望大家都能夠全程參與到最後，針對本次議題做各種向度的交流。

>[name=陳稼軒]
>[name=Fiona Chou]
>[name=]
>[name=]
>[name=]
>[name=]
>[name=]
>[name=]
>[name=]
>[name=]

## 議題分享交流：
1.使用Slido收集問題與調查，是線上活動常用的方法之一
2.使用Slido將問卷調查結果即時呈現

即將開始!!! :+1:

## ==講座共筆==
>這邊大家可以邊聽邊一起做筆記，**重複了也不需刪除**
>

1990就開始了

愈來愈精簡，但威力更強大
:child:


[Scrum Framework](https://scrumfacilitators.com)
敏捷強調==經驗主義==，好的壞的都要面對
:smiling_face_with_smiling_eyes_and_hand_covering_mouth:
==經驗主義==

Waterfall 強調很多phase

傳統專案管理的方式比較強調依程序及步驟完成

1.Sprint planning
2.Daily scrum
3.Sprint review
4.Sprint Retrosective

敏捷從強調3個角色(PO/SM/開發團隊)
> 2022為==one team==


:::info
有經驗的master只是犯了更多錯誤
:::
:question:
從過錯中反省才是真理，逐步修正，逐步完善
:star2:


[https://scrumguides.org/revisions.html](https://https://scrumguides.org/revisions.html)

[The Evolution of the Scrum Guide]
(https://medium.com/serious-scrum/the-evolution-of-the-scrum-guide-10-to-19-f3ac4d82cfcb)

一定要講一下 chicken&pigs 的故事

老的都會講 ==Grooming== --> 現在都講 Product Backlog Refinement
讓產品或程序越來越優化

以前站立會議常用3個問題來進行，新版的也修正了!

scrum master確保正確的進行，而不是要去lead

新版scrum guide只有13頁!
要避免過往大家認為必須照著scrum guide去運行敏捷，而失去敏捷的真諦。

:+1:
看重scrum event和圖表資訊所代表的意義，而不是資訊或事件本身

>[name=JJLai]
>One team又出現了 :face_with_one_eyebrow_raised:
>看來要重新認識Scrum Guide了 :gem:


do not commit <-> forecast of work
++plus a **plan**++
團隊運行一定會遇到問題，不要過度拘泥於解決問題而去拆解問題，而要回歸到，我為何要做這個sprint
### 站立會議

:::warning
Daily Scrum -> planning event, not status event
:::
圍繞在==sprint goal==

daily scrum報告的內容，從以個人為主=>==團隊為主== :man_and_woman_holding_hands:
### 回顧會議

新版scrum guide修正了回顧會議中團隊探討的問題必須納入下一個sprint去改善的作法。


#### 5 Values
>1. commit
>2. courage
>3. focus
>4. open
>5. respect

推薦大家要學習時，建議要新舊版一起對照看！
也可藉此深思scrum guide演進與修訂的原因。
>[name=老師]分享連結
[Scrum Guide Revisions](https://scrumguides.org/revisions.html)
[The Evolution of the Scrum Guide— ‘10 to ‘19](https://medium.com/serious-scrum/the-evolution-of-the-scrum-guide-10-to-19-f3ac4d82cfcb)

:yum: 點心連結??

## 案例解析
[:link: ](https://www.scrum.org/resources/blog/product-goal-sprint-goals-simple-example) 這是投影片連結 :smiley:

設計資訊時那些是重要的
目的：英國最大的麵包店
+ Product Goal 1:網站焦點在London
+ 服務擴展到手機w

:::info
GOAL! PRODUCT GOAL!
:::

組織願景很大時，可以透過拆解，讓團隊同時進行或是逐步進行，來逐步達到願景及目標！ :100:

將Product Goal 1拆出不同的Sprint Goal
Sprint goal：語意上的共識，讓大家可以focus


定義出什麼是做好

DoD
巨觀整個產品的規範、品質

## Q&A
1. 如果像是一些DoD需要經過資深工程師 code review 那再 Sprint review 時應該如何檢核？
Sprint review針對完成的項目做回饋
回顧時可事先訂定標準，團隊要有共識

2. 小團隊(3-5人)也可以run scrum嗎？需要指派scrum master或product manager之類的嗎
原本就是以小團隊運行最好，3-5人的溝通是最適合的人數
開發團隊本來就要進行許多事，需要有人去判斷價值，而在新組成的團隊中也需要scrum master去引導

3. 如果這次的sprint 目標是 討論出軟體的系統流程，那麼review 時要看那些東西？因為在討論出一個定版時，主管可能都看過了，那還有需要再 sprint-review 時看嗎？
可以從「設計好的系統流程是要給誰用，目的是什麼?」切入去review，也可從利害關係人的角度看，可能是不同結果

4. DOD 一般是怎麼決定出來比較好的呢? 是團隊成員共同決議出來的嗎? 或是也需要透過 PO 認可呢?
DoD是團隊成員決議出來的，PBI什麼叫完成則是由PO決定

5. 很好奇要如何落實在健身上(或是其他目標)，是否可以請老師分享呢
不要天馬行空過於空泛，要減重20公斤。將目標切分成階段執行(比如每週1公斤)，逐步達標比較快看到成果，階段目標達到後一樣要回顧，然後納入下一個階段改善。

6. daily scrum 因為是每天，出現成員覺得浪費時間，不願意參與，該怎麼說服成員這件事生是好的且必要的
如果是一種report，就不會有人想要執行，要討論的主題是在此時可以得到別人的input，建立團隊間成員的互動，覺得對工作是有幫助的，做這件事情的目的，是為了改善目前的工作。

7. 但有沒有可能開發者又身兼Scrum master?
開發者可以兼任scrum master 或PO，但PO和scrum master不能兼任，因為PO是定義出工作項目，而scrum master是想辦法讓團隊可以成長的人，兩者的角色有所衝突

9. 如果團隊中大家都沒有scrum的經驗，請問要怎麼實行？像scrum master是否要另外聘請專業的人？
開發者可以身兼PO或Scrum Master，但PO和Scrum Master有工作上的衝突，不建議一人身兼2角色。團隊中如果沒有scrum的經驗，建議可以聘請Scrum Master。

9. 想問當團隊經常被business 端臨時插單需求，又要趕在sprint 結束前完成，有建議的 Sprint 管理方式嗎？
要由PO來決定，但是必須在團隊的負荷之內
工作的內容必須平衡，有東西插單，就必須拿走一些，以達到永續發展

## 想帶走的想法或今天的心得