# Scrum 軟體敏捷開發 之 郭老語錄篇
###### tags: `coding365` `開發方式`
:::warning
貢獻者
- 火柴
- William Mou
- ㄏㄏ
- ㄏㄏ
:::

## 前言
敏捷開發相對於瀑布開發，後者像是瀑布、不畏的往下流，敏捷像是涓流、負擔小、時擇路而流。

## 敏捷式宣言（Agile Manifesto）
* 個人互動的價值超越流程與工具
* 軟體製作的價值超越全面性的文件
* 客戶合作的價值超越契約協商
* 反應改變的價值超越跟隨計畫

> 軟體需求有一個不變的就是變
> 計劃趕不上變化，變化趕不上老闆一句話
[name=郭老]

## Exercise：員工走路績效比賽
:::info
* 員工的績效是要走幾步
* 比較老闆指示與員工自主的差別
* 不能撞到別人
:::
> 任務最重要的是績效，你賺 5 萬元老闆才會給你 ==3 萬元==
[name=郭老]

### 紀錄感覺情緒，認知想法、觀察行為事實，描述其間的差異
- 三者會彼此影響，且影響工作績效
- 情緒（情緒模式）
- 想法（價值觀）
- 行為（行為模式）

:::danger
最終影響 **「需求」**
:::
> 有的時候一個人不配合你做事只是因為心情不好
[name=郭老]

> 如果有人笑你，就笑回去。
> 這就是想法影響情緒影響行為
> [name=偽郭老]

## Agile 思考 (1)
:::info
分成兩種方法，沒有好壞，依照情況選擇
:::

### 當需求固定，使用 Waterfall 瀑布開發方法
- 定義式（理論）流程
- 指令與控制
- 規劃期望發生什麼
- 強調計畫
- 應用改變控制機制

### 當需求環境會變動，使用 Scrum 開發方法
- 實務流程
- 根據歷程來學習
- 為改變需求環境而規劃
- 擁抱改變
- 應用觀察並調適
> 因為無法又要馬兒跑又要馬兒不吃草
所以使用 Scrum 架構，有多少資源做多少事
[name=郭老]

## Scrum 架構
:::info
大喇叭（Product Owner）參加 Scrum 會議，就是一隻豬跟一隻雞的故事（？？？）
豬跟雞要賣早餐，賣火腿蛋餅
雞生蛋（Scrum Master），豬割肉（燒肝的開發團隊）
:::

<!--
> 你就當==雞吧==
> [name=郭老]
-->

### Scrum 四個角色
- 顧客：畫大餅的人
- 大喇叭：產品擁有者
- 雞：Scrum Master （美國）隊長
- 豬：Scrum 團隊的人 - 燒肝割肉
:::success
過程中雞跟豬要開會，配合下方 `Task Board` 使用：
:::

### Scrum 四個會議
1. 衝刺計畫會議（Sprint Planning Meeting）
* 項目開始時開會，原則上不超過 4 小時
* 決定該衝刺期間的待辦項目 `User Story` ，以及團隊的衝刺任務 `Task` ，紀錄於 `Sprint backlog` 。

2. 每日站立會議（Daily Standup Meeting）
* 衝刺時每日開會
* 15 分鐘主要用來了解團隊的工作執行狀況。
* 會議中：決定該衝刺期間的待辦項目，每天有三個 Day Scrum
1. 昨天做了甚麼?
* 修改工作版 `Task Board`：工作狀態、完成區`Done`。
2. 做了有甚麼困難?
3. 接下來打算做甚麼?
* 表達今天準備完成的工作，自待領區 `Not Check Out` 取工作，標上姓名代號與領取日期，移至領出區 `Check Out`
* 會議後：雞 `Scrum Master` 獲知工作完成資訊，繪製 `Burndown chart` 。
* 此時可修改 `Story` 的狀態，例如將 `Story` 移至 `Done`

3. 衝刺審查會議（Sprint Review Meeting）
* 衝刺最後日開會
* 由 Scrum 團隊對產品擁有者產生 Sprint Review Agenda（Demo 的準備文件）展演 Sprint Review 已完成的功能及品質特性 Sprint Demo。
* 檢討產品或 Project 的優缺點
* 隨後執行衝刺回顧會議。

4. 衝刺回顧會議（Sprint Retrospective Meeting）
* 衝刺結束時開會
* 大喇叭（產品擁有者）不參加僅做紀錄。
* 主題鎖定在「流程」上頭，回顧衝刺好的與帶改進事項。
* 聚焦在團隊的「開發流程」，並決定下一次衝刺的「開發流程」

### Scrum `Task Board` by Scrum Master
> ==七分鐘富一生，所以七分鐘可以過一生==，我們也可以用七分鐘來演示一天
[name=郭老]

#### 表格大綱
Not Checkout|Check out|Done|Sprint Goal
------------|---------|----|-----------
| | | |Story Burndown Chart
| | | |Task Burndown Chart

#### 實際範例

:::info
* `Story Burndown Chart` 是給老闆看的，一件事情就是一個 `Story` ，每 100% 完成一個才能把圖表往下畫。
* `Task Burndown Chart` 需要把每個 `Story` 細分成 `Task` ，每個 Task 有自己的名稱與時間。
:::

## Agile 預估與規劃
### 計畫 Vision
* 團隊估算買票、賣票這兩個需求的User Story，需花費時間?
* 根據團隊Velocity，共需做多少Sprint?

### 選 Product Owner 和 Scrum Master
* 選出 5~8 個功能性需求
* 每人擁有 100 單位，依商業價值給分
* 此需求值多少、可製造或節省多少錢、降低多少風險?
* 開發此需求所用技術，團隊瞭解程度?
* 團隊分數加總

### 建立產品待辦清單的 User Stories
* 一個 `Functional Requirements` 通常會有很多 `User stories` ，我們可以針對每個 `User stories` 設計以下表格，以完整的敘述所要做的事情。

| 三大項 | 細節 1 | 細節 2 | 細節 3 |
| -------- | -------- | -------- |---|
| 描述 | As a (User Type) | I want to (goal) | so that (reason)|
| 限制 | 註冊時要... | 啟動時要... | 刪除時要... |
| 劇情演示 | 劇情 1 | 劇情 2 | 劇情3 |

* 例如「允許賣家註冊」，可根據三種角色，寫出三種 user stories。
* 做為一個賣家，我需要註冊我的個人資料(電子郵件、電話、住址)，使得我可以張貼並賣票。
* 做為一個票卷安全管理者，我需要一個唯一的使用者帳號以 及複雜的密碼，使得我可以保護客戶的個人資料。
* 做為一個票卷市場經理，我需要一個賣家分析的報表系統， 使得我可以撰寫市場規劃書。

* 檢驗是否好的 user story (INVEST)
* Independent
* Negotiable
* Valuable
* Estimable
* Sized Appropriately
* Testable
### Story Points

* 實作完成 User Story 的 Effort，沒有單位，一種相對工時比較
* Story Point 2 的 User Story 為 Story Point 5 的 工時 1/2 倍再小一點
* 第一次定義 Story 的相對大小
* 從所有 Story 中選出一個團隊認為中間偏小的 Story，令點數8
* 以此 Story 的大小為基準，評估第 2 個Story
* 依序，估計其他 Story 的大小。
* 預估大小先不考慮排程，團隊更能客觀預估
* 允許變更 user story 交付條件或情境
* 允許迅速修正預估大小
* 每輪出點數後須說明各自的原因
* 目標和目的
* 讓全組成員了解每個 story 的做法
* 以全體共識為主，==不可威脅利誘==

### 郭老語錄

> 有的時候一個人不配合你做事只是因為心情不好
[name=郭老]

> 假設你生病不能出門，每天待在家裡就會得憂鬱症
[name=郭老]

> 七分鐘護一生，所以七分鐘可以過一生
[name=郭老]

> 如果有人笑你，就笑回去。
> 這就是想法影響情緒影響行為
[name=偽郭老]

> SB 是 Sprint Backlog 不是傻逼
[name=郭老]

> 通常有跑 scrum 的公司，星期一早上都在玩牌
[name=郭老]

# 郭老跟你說早安

---
分隔線

---
😠
自己去下面玩

海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海報海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹海豹