敏捷需求通靈法典
過去專案在需求處理方面，先是客戶訪談，然後再根據會議中所討論的，整理出需求的規格和說明。可是，不管撰寫需求的人寫的再怎樣詳細，雙方總是會有誤解，開發人員會以為客戶或是 PM 要的就是這樣，而客戶或 PO 會誤判以為開發人員已經聽懂。這樣的事情老是一而再的發生。
還有傳統的方式，會先寫完需求文件, 可是這段時間通常不短，等到寫完後交給開發，才又發現客戶已經要改需求了。另外，中途當需求有變動，卻發現要改的地方很多，你不容易每個地方都找出來修改，常常會放棄處理，導致文件和真實需求或系統不同。
為了解決解決以上問題，Gojko Adzic 提出一個改善的做法，利用測試範例來說明系統的行為，讓雙方不會只看抽象的敘述而是從實際的案例上來解釋事情。
總的來說這個做法的目的其實就是為了團隊能交付正確的軟體，那麼 Gojko Adzic提出的作法就是那著名的 Specification by Example！
- 參考課程：如何寫出人人有共識的需求
活動流程
- 簽到 ＆ 破冰
- SBE 簡介
- 案例研讀和討論
誰適合來?
所有人。
但是！若體溫過高者，請回家休息。
關於分享者
敏捷三叔公（柯仁傑 David Ko）
Odd-e Agile Coach
目前在 Odd-e 擔任 Agile Coach，幫助企業導入敏捷、改善流程和提供培訓，台灣 Agile Tour Taipei 的組織者之一，也是國內最大敏捷社群的創始人，致力於推廣敏捷技術。
擅長敏捷開發流程、敏捷測試、軟體測試、設計衝刺 (Design Sprint) 和 DevOps 轉型。
Agile Summit、DevOpsDays Taiepi 的主辦人，譯有 Scrum and XP from the Trenches 繁中版。
要收費嗎?
- 300元 (現場收費，無收據/發票)
- 付款者皆可以領 Daniel 抖內的『實例化需求』一本，另外想再多帶者將加收 500元/本，無發票。
書籍介紹：https://www.amazon.com/instantiate-demand-deliver-software-Chinese/dp/B0098HQV04
為何要填寫公司/職稱資訊?
填寫正確公司資訊可以讓講者對大家有所認識;填寫正確的職稱可以讓講者在分享前大致理解該講深入點還是笑話多一些？！所以請大家幫忙填寫正確的公司/職稱資訊。
關於主辦者
Agile.Taipei 是一群對敏捷思維與方法的推廣有熱情或是狂熱的人所組成，我們不隸屬於任何其他社群/組織/企業，我們期待藉由各種形式的經驗分享和技術交流，能讓在北北基地區工作生活的夥伴們能接觸新思維，工作能更快樂。
