# 一個敏捷實踐的誕生 / 黃冠中 (Aaron Huang)

{%hackmd @ModernWeb/SyA2U6SmT %}

> 共筆請從這開始

投影片: https://docs.google.com/presentation/d/1AdoOkCFYgctrGjZPlz7kB6BEJvYKDQdXPblciMt5M9A/

* **鼓勵大家常常換工作**
* **不想這麼激進也可以常常參加 Conf，吸收別處的經驗**

## 傳統軟體生命週期帶來的痛苦與反思
* 過於樂觀的產出預測
* 参差不齊的品質
* etc....
*

Waterfall vs DevOps

## 求道自路

即使開發方法再好，不對的產品，公司還是會倒

## 理想的工作流程

傳統軟體方法論：像是十字路口的紅綠燈
紅綠燈的問題，很容易因為單點故障，而造成系統崩潰
現在軟體開發方法像（國外的）圓環，沒有紅綠燈，相當於把權力下放

領導者要做的是什麼.
創造了一個框架, empower每個人(每台車的價值上), 設計一個規劃.
每台車都可以安全的通過, 都不用紅綠燈.

> 如果導入到台灣..會發生什麼事, 圓環中間會被加上十字路口, 而且圓環會有紅綠燈
RRRRR
## 賦權與自組織

## 可量測
感覺得到問題，但沒有好的方式告訴老闆
> 每個動作都要可以測量, 更客觀的去看工作上的bottleneck發生在哪裡.
不然只能自己murmur

## 可持續
若要讓產品成功，可持續性是最重要的

## 如何開始

## 一窩蜂敏捷開發

Hyper Driven Development
> flow: 公布,準備起飛->第1場演講->更多的演講->狂熱->妄想->新流派員!->降溫->回到常態, 現在終於能理性分析利幣了.

每個團隊都是不一樣的，不同的團隊有不同的合作方式

到了新的團隊，先了解你的團隊

- 從流程的可持續性出
- 試驗性的調整並循環改善
- 客觀的數據提供改善流程的依據
- 整理工作流程，區分任務階段

實作 -> 觀察 -> 測量 -> 數據

## 存在即合理

瞭解團隊過去的歷史
> observe 做為一個agile coach , 如果是盲目的去做, 就無法答到可持續性. (媽媽覺得你餓)

## 明確的劃分流程

## 將問題可視化
透明度的體現, 一但我們將metric 可視化了之後, 就可快速的看到bottleneck在哪, 要怎麼去改善.

'Cumulative Flow Diagram' vs 'Nmber of tasks'

### 累計流程圖 Cumulative Flow Diagram
把每個細節都連成線

## Enhancement
scum會議, 四大會議, 其實是不同時間點的改善會議.
在 retro 用客觀數據來改善 process

## 一個敏捷實踐的誕生.

----
> 聊天室

這個 Bookmarks 密密麻麻到看不到了
> 應該要擺直的比較清楚
>> 我說的不是職涯 喔懂了 哈只剩icon，是網頁

鼓勵常換工作
可是我每次去面試都被嗆 Q.Q
說穩定性太差 (回嗆之前的公司沒成長空間 你們能讓我成長我就會穩定)

拿著公假來這裡被鼓勵換工作XD (讚喔)

剛剛照相機一柱擎天嚇我一跳...
> 我覺得有一位不太會拍 一直干擾
>> 昨天我看到攝影師，前後左右到處移動
>> 甚至還在投影幕前拍講者（？？？？？）
>>> 有點傻眼 像機器人 到處按而已啊
>>> 今天有看到另外一位比較專業，會挑比較不干擾別人的點
>>> 還會有直接擋到投影幕的 -> 對啊 我都不知道拍出來投影幕有他的存在感 有什麼意義
>>> 有專業的相機，在遠處拍就很清楚了吧

草書字體好漂亮
> 求字型

我覺得問題是不follow的很辛苦，是沒人要follow

其實講者講的我都同意
不過我還是有個問題
如果都是一群 junior
這樣還適合走 Scrum 或 Agile 嗎？

> 應該還是可以吧?? 但理論上管理層不會這樣安排, 除非是內部不重要的系統??
> 但有請教練比較不會走歪
>> 是有 Scrum Master
>> 不過問題在於 junior 太多
>> 所以大家開發時候比較...卡
>> ** '存在即合理' , 如果一群junior的話, 合理性是在哪?是否接受度高, 意即, 也許卡卡的..在一開始就是可以接受的? maybe是練兵的project??
>>> 可能除了討論開發的東西，還要花時間回顧跑敏捷的流程
>>> 看大家覺得怎麼調整會跑更順
>>> 敏捷沒有標準跑法，只要能讓團隊持續成長就好，不同團隊有不同風格(推)
>>>> 會再繼續問這問題，是因為新人通常也不會有甚麼反饋
>>>> 如果只是團隊持續有成長的角度來看
>>>> 無論怎麼運行都會有成長
>>>> 但是以系統架構的角度來看，容易有很多技術債
-> 感覺是需要senior當code reviewer，要用PR不是直接讓大家push。不然code quality也是無解，但這就需要 CI/CD工具才能達成。

>> 都是 Junior 的話，還是需要真正懂的人來帶領。做一個比喻，在 pair 結對編程的時候，兩個人都對目前的領域和技術都不熟悉，不懂帶不懂，會有效果嗎？
>> 至少需要一個資深和一個資淺的人配合，或是兩位都是資深的才有效果
>> pair 不能兩個junior，要一個senior或是兩個都senior才有效
>> 我的重點不是資深與否，而是『真正懂』，技術上需要，實踐敏捷的過程也需要有這樣的人存在
>>>> 我們講的senior一般是指懂的，你做十年只會if/else我也不認為是senior （十個一年的概念還是junior）
所以現在還有mob，直接帶一群人一起
=> 同意喔, 還是要至少一個資深的帶, 請Scrum master 倒不如直接接去別team拉一個資深的帶, 或請人. 那會這樣'安排' 應有其他考量吧.

Scrum 本身的假設就是團隊中的能力是相似的差距不大的
> 不過我覺得理想上的要求有點高了，因為他希望每一位都全能，後端缺人可以前端的補上（極端的情境下）

>> 既視感太強

> 『本身的假設能力不相上下』這句是錯的，scrum team 組成的要求只有能夠完整端點對端點交付組成的跨職能團隊，並沒有對於能力程度高低的任何假設前提
> 如果說團隊能力需要足夠到能夠完成任務，這樣是正確的，焦點是團隊整體能力，不是個人能力
>
>> 可以解釋一下 完整端對跨職能團隊 嗎
>>> 可以。用簡單的解釋方式來說，就是假設團隊完成一個任務，需要前後端、測試，才能完成交付，那團隊內的成員，就需要有所有的職能，但不是所有人都需要具備所有能力。
>>> 比如說後端工程師有可能同時也會做一部分的測試工作，或許他的測試功力沒有專職測試的人強，但是可以在需要的時候做這件事情。
>>> 有的團隊因為任務特性可能需要資料工程師，甚至是商務分析師，那麼在組成團隊的時候，就必須有這些職能，我要強調的是『職能』，而不是一個專屬職務。因為一個人可能具備多種職能，但可能某一、二項是最深入專業的，團隊的組成也沒有一定要強迫工程師要跨端。
>>> 重點是整個團隊需要有能力可以完成，所有需要完成任務的專業
>>> 這樣解釋跨職能團隊，有比較具體嗎？

我後來都覺得是看團隊的態度和學習意願，只要大家願意頂多走慢一點，常常是大家在那裡扯後腿

感謝聊天區的各位回覆我的疑問
真的覺得 Conference 處處有溫暖

- end