---
# System prepended metadata

title: Agile Tour 2020 learning point
tags: [Agile, Agile Tour-2020]

---

# Agile Tour 2020 learning point 
###### tags: `Agile Tour-2020`, `Agile`
>以下內容是本次Agile Tour所學習到的重點，不過只有我上到的部分，做個分享因為有很多課是在同時段但在不同Track

## 擦傷學習精神：
- 強調在實作中修正錯誤和學習
這位講師很強調實作，他以目前他開發的歐洲訂票的APP做舉例，歐洲有太多鐵路的大公司，各自都有APP，但其實太少接觸實際客戶的需求，各自的APP彼此之間只會提供自己的資訊，**但對使用者來說，重要的是他可能想法國巴黎到義大利的米蘭。**
因此他認為這些，或許直接當公司的客服，或者從APP的反饋反而就更快能蒐集到這些資訊。
因此他提供了整合這些列車資訊的APP，滿足了使用者這個服務，目前也不斷地deliver蒐集著客戶的反饋資訊。



- 內捲化
他本身也是Aglie coach，但也有相當多豐富的實務經驗，但他看到現在太多人有一些各種的**certificate**，因為這些機構都會提出他們的等級階梯，而這些人一直往上爬，但卻漸漸的被這些方法綁得太深，反而無法跳脫，也太少接觸或者離實際面太遠。
因此他建議大家，不要過度的依賴這個東西，有certificate也要搭配實際的經驗，這樣才有更加分的效果。
EX:其中一個舉例，有一位對輪胎非常了解的專家，但當輪胎壞了他卻不會換輪胎。

- 乾貨問題
現在代人很喜歡看這些乾貨，意思是專家們幫你濃縮的精華，初期對初學者確實有快速大幅度的成長，但到一定的程度時，你就會停住，因為讀完這些東西仍只有紙上談兵，是無法發現或徹底理解這些專家所遇到的問題的。

- 不求甚解
雖然以現代的用法多為貶義，但以陶淵明當年的文義，應非貶義。指的是看全貌，不糾結於其中每個字每個字的詳細意思。
>講師認為你能抓住不同知識的重點，並將其拚湊出一些方法去實作，但也並非說當你需要技能時就可以什麼都不學。
**書讀百遍 其義自見**

:::info
擦傷學習法的重點，就是很講求實作，這樣你能從中發現各種困難，並且你會在你有需要時，去找出方法去解決問題。
:::

## Outcome-driven development

狀況: 某個專案可能又收到新的需求，已經有很多backlog items，那我該怎麼做了？從Quality, Time, Cost分析:
| 犧牲的項目 | 作法      | 結果            |
|--------- | --------- | -------------- |
| Cost     | 增加人     |  只會讓時間變更長 |
| Time     | 延長時間   |  趕不上市場需求          |
| Quality  | 開發完就好 | 不測了           |

:::danger
綜合分析都無解，是不是可能是源頭就錯了?**
:::

## 把Requirement 換成 Opportunities
講師認為需求這個字換成機會對整個團隊會合適，**我們現在有了這些機會，哪些是我們現在做的會有什麼樣的效益**，而且寫成需求，其實需求字面上會讓人覺得應該是很明確的東西，但實際上往往不是如此。


## Ehnance development work with PPO key concept

###  Discovery & Learn
- analyze opportunity and create hypothesis
- Conduct Test to learn/validate
- :star: Fast & Cheap Tests :star: 
    1. Interview 
    2. Paper prototype
    3. Prototype with fake data
    4. **Prototype with real data !!!**
    5. Implementation and Release?
![PPO: Balance your investment & bests](https://i.imgur.com/a5HiJZs.png)
>從這裡分析後，才決定是否要放到Backlog。
>並且透過Discovery & Learn明確找出"Safe Zone" and "Stupid Zone"
>**這個概念我認為有發揮了Aglie的精神，為了不想跟Waterfall一樣，要到最後deliver才一翻兩瞪眼，何不在初期要投入時，就使用這種方式逐步的試水溫，保持在SAFE ZONE。**

### think about a "smaller" step, and also considered the bias.
:bulb:There's a Common Pattern to follow to help as tell it's a bias or a fact?
- Do people have a problem?
- Do they want our solution?
- Can we build it?
- Can they use(see) it ?
- Will they keep using it, adapt it, say good things about it?
![](https://i.imgur.com/hlAPolC.png)
>如果認為假資料的prototype就直接跳到要實作導入這段仍太過大歩的話，仍然可以再將中間切入一個小的step，以降低結果不符預期的風險

## 固定成本之下，如何選擇要優化的項目？
狀況:講師的團隊面臨要更新內部的大型系統，但需求非常的多，因此要將這些需求整理，去篩選出這些重要的部份放進backlog裡

- 真正的使用者發聲
    - 向end-user收集痛點清單：將近 400 個痛點。
    - 辦workshop初步訪問需求：確認需求是stakeholder/end user真正需要的。
- 價值排序，成本框定 
    - PO(Product Owner) 定義需求的價值
    - 量化因子（e.g. 痛點數、重要性、急迫性）
    - 專業評估（交由BU評估、需求商業價值排序)
    - 大主管和PO挺身協調歧見
:::warning
:question:**面臨的問題**
1. 如何對不同單位的人、不同的思維，**有效溝通**？
2. 如何盡可能貼近大家的需求？
:::
**面對不同的使用者，是無法全部透過文字溝通進行的，肯定會弄得很混亂? 那怎麼辦呢?**

- 功能畫面
    - 面對面、具像化（儘量不要透過文件溝通。用視覺化、可操作的畫面來溝通）
    - Paper Proto => Prototype, PowerPoint
- 業務流程
    - 面對面、具像化
    - 簡化版VSM：五個步驟引導。重點不是精美，而是能夠用共同的語言具象化出流程，並標出痛點。
    - 重點不是畫押背書，而是確切了解需求。
    - :star: IT 的工作是引導 BU 把真正的流程、需求說出來 :star:
    - 提煉出業務流程
![簡化版VSM](https://i.imgur.com/Q7MeLqC.png)
![VSM範例](https://i.imgur.com/bxfpXJV.png)

>這個講師的團隊，也採舉了類似的作法，避免在團隊開發了，或是已經開發了一部份的prototype出來，才發現這個結果與真正的user想像上差距很遠，因此他們也先畫出了紙本版的prototype來解決這樣的問題，目的都是不希望到最後又面臨了需求上的改變，所帶來的衝擊。

### 講師所認為的敏捷
- 真正的使用者發聲（要有人用、能賺錢）
- 有效溝通
- 自訂團隊遊戲規則：譬如讓團隊都知道如何處理「插件」。
- 透明 :arrow_right: 信任 :arrow_right: 當責與自管理
    - 因為是大家的共同看見，所以大家能夠一起遵守和信任。
- 檢視、調整 :arrow_right: 回應變化
    - 團隊之間不應該是敵對，而要互相反應與調適。
- 解決問題的心態

>**其中透明，檢視，調整**，**也符合Agile的3個核心精神**，透明的進度，定期的檢視狀況，並對當前的狀況作相對應的調整與變化。

## Start small, Learn fast
另一位講師，在歐洲銀行開發產品其中也提到他們的一些作法

* How we can deliver faster ?
    * Smaller scope
* What can be removed ?
    * Deliver key value
* How can we go live quicker ?
    * Feature toggle: 有哪些功能要給 end user 用？還是等更穩定一點再開放。
    * Continuous delivery

* How to reduce effort?
    * Automation

## Data driven
有些事情有沒有效，在開發時確實不容易知道，怎麼樣能佐證?
透過數據來反映事實。
* 讓數據說話
* A / B Testing
    * Netflix案例
        * 首頁註冊畫面的Case
        * 影片封面圖的Case
        
這兩個Case，都是希望提出與原先不同的做法，希望能達到更好的效果，但是在沒有做出來實際run，根本沒有人說得準哪個好。
在首頁的Case，Netflix，就曾經做了2版的首頁，並透過A/B Testing來分析數據，來來回回了5次，最後發現原版本比較好。
>為了讓後續的版本，使用一個正確且有效的結果，因此使用A/B testing，並且經過了統計分析，再將有效的結果release到產品中。

影片封面圖也是，他們試過了多次A/B testing，發現了一些用戶的習慣，與偏好。
- 用戶喜歡複雜的比情
![用戶喜歡複雜的比情](https://cdn.unwire.pro/wp-content/uploads/2016/05/hab_uks_1_arrow.png)
- 各國的用戶喜好不同
因不同的文化背景，儘管是同一部影集，各國的用戶的喜好也不同

- 少即是多
雖然很多用戶都是透過電視螢幕來觀賞Netflix，但也有不少是透過智能手機等螢幕較小的裝置來觀看，Netflix 認為「少即是多」的設計原能吸引用戶的注意力。
![少即是多](https://cdn.unwire.pro/wp-content/uploads/2016/05/OB.png)

>以上是這次在Agile Tour學習到的一些重點，將其整理出來分享給大家，其實這些課程裡面討論的都不會是Scrum或Aglie的流程，而是講師認定學員都懂這些東西，並將他們實際的應用case做分享，他們是怎麼用到這些Agile的精神的，希望我的這個整理分享，對Agile有興趣的你能提供一些啟發。