# Example Mapping - Context

軟體開發是一個學習的過程，開發人員學習領域知識。再將知識變成可以運行的程式碼。測試人員也依照領域知識來提練出測試的腳本及案例。

理想上，大家溝通順暢，經由領域專家而學習到的知識，開發及測試人員對需求都有一致的理解，沒有人不清楚我們所要做的事。

但現實上我們常常在玩背後寫字遊戲，從第一個人接收到的資訊之後就變了。接下來的每一次轉達，更是以等比級數的速度失真。


# 問題是什麼??

:::warning
為何要在背I’m 後寫字?? 但全部寫成文件就比較好嗎??
:::

軟體開發可以是一個漫長的程序，為了能讓參與的人都可以對要面對的問題都有一致性的理解。應該在不同的階段要有不同的工具來輔助我們進行溝通。

Example Mapping 所要處理的是那溝通的最後一哩路

## 開發過程常會遇到的問題

身為開發者
1. 做到一半發現故事太大
2. 需求不明確、不一致
3. 細節沒有討論到，要一直去找人討論

身為提出需求的人
1. 開發人員誤解需求，造成要重新打造，浪費很多時間

身為測試人員
1. 超多的 bug
2. 對於測試的範圍不是很清楚

## Example mapping 擅長...
1. 發現並擴展問題域
- 在還沒開發前去找出你所不知道的東西，甚至會找出新的 user story
2. 用共創的方式設計出 Acceptance Tests
- 常常會因為用這種方式可以找出新的規則
- 還可以讓原有的 Acceptance 更加完整
3. Sharing understanding
- Example Mapping 是由 Product Owner(Business Analyst), Developer, Tester 一同建立
- 所以可以讓大家對於系統該如何運行有共通的理解。
- 建立統一語言(單字)
4. 幫助我們解構一個太大的 User Story

## Force
我們想一個可以明確進行溝通的文件
這是一個 "活的文件"

## Example Mapping 的組成

Example Mapping 大致上由下列幾個元素組成
- Rule
- Example
- Question


## 準備
Timebox

## Steps

0. Exmaple Mapping 是一個很短的活動，記得先訂下一個小鬧鐘，不要太長(30分鐘以內)!!!
1. User Story from your backlog
2. 列出所有的 Rule
3. 列出想的到的範例
4. 開始問問題

最重要的是第 4 步，找出你不知道的部份!!!

專注在 problem domain, 而不是 solution domain

:::info
火車訂位系統的範例
:::

[reference](https://www.youtube.com/watch?v=VwvrGfWmG_U)

## 退一步來看看

這一份完整的 Example mapping，並開始思考

If you are a Prodcut Owner, 看看這些是不是已經包括所有你想跟開發者的事情了?? 有沒有哪些你還沒有說的部份??

If you are a developer, 看看這些是不是已經足夠你進行開發?? 還有沒有哪些細節沒有想到?? 這些事情是不是可以在一個 Sprint 中完成??

If you are a tester, 想想這些資訊是不是足夠讓你測試並驗證這個系統?

## Vote it to decide if it is good to go?

在最後大家可以對於結果來行投票，以決定要不要開始進行開發

通常如果大家決定

- too many green?
- too many red?