[遛書]敏捷教練－理解構建目標

[遛書]敏捷教練－理解構建目標

《敏捷教練》是一本很棒的書，裡面盡可能地關注在敏捷的本質，在各種儀式活動中敏捷教練可以運用的技巧以及該關注的敏捷基本精神。

這次遛的是其中第六章〈理解構建目標〉，主軸在透過 user story 對需求的釐清，怎麼樣促進團隊與客戶面對面的交談。

宗旨

•「交付價值」是基於「面向客戶」

• 面對面交談

重點摘要

• 如何使用 user story: 3C (Card, Conversation, Confirmation)

感謝 Daniel Teng 補充 3C -> 5C, 後面兩步是 Construction and Consequence，組成一個循環。這的確是使用 3C 討論確認後，團隊該一起產出的資訊，該做些什麼，可以得到什麼樣的結果。

[遛書]敏捷教練－理解構建目標

《credit: Daniel Teng》

• 親自示範、停、讓團隊自己寫

以身作則，並讓團隊參與與動手練習

• 確保環境（便利貼、筆、桌子/白板、空間…）

• User story template (As a ..., I want to ..., In order to ...)

• 整個團隊討論前，可先挑小團隊跟客戶/PO/領域專家討論，增進交談效率

注意事項

• 不要把 user story 當作需求文件，它只是幫助發問與交談的媒介。

User story 的重要性，不在於 user story 寫得多好，而在於能幫助團隊進行發問、質疑、討論與建議。

• 不要由需求單位說明需求，而是由團隊發問，這樣才能協助釐清與理解，減少盲點。(不會存在 common sense的問題)

避免知識的詛咒造成的問題，需求單位腦袋中的旋律，以為開發團隊也聽得到一樣的旋律。

• 不要用電腦跟投影機，這會扼殺交談。

電腦代表只有一個人能動手操作，而且他會只忙著操作而無法思考。投影出來代表大家目光只看著布幕，而不是面對面進行交談。

• 若因交談後，故事有所改變，就撕掉便利貼，再寫一張。（撕掉的卡片往往代表著交談所帶來的價值）

• 避免交談過程使用有技術含量的詞，需求人員會藉故溜掉。

• 驗收測試案例代表 user story 範圍，太多代表 user story 太大，或是討論太細。

一張紙整理術心得手稿

[遛書]敏捷教練－理解構建目標