Agile Manifesto Illustrated(English/Chinese)

 Manifesto for Agile Software Development

Split Requirements: Techniques that make work doable

Material used on Agile Product Manager training.

敏捷流言終結者

敏捷團隊不寫文件嗎? 敏捷專案可以隨時改需求嗎?
敏捷方法雖然很盛行，但外界誤解還是很多。
史上第一個 Scrum Master: John Scumniotales 參與製作了流言終結者，10個問題，10個答案，幫您快速破除迷思。

https://www.yumpu.com/en/document/view/28103508/john-scumniotales-paul-dupuy-jeff-mckenna-serena-tim-walker-al-

利害關係人網路圖

專案管理不論採用哪一種管理方法，「人」都是最重要的元素。對於專案執行的過程或結果，受到影響的個人或群體，稱為利害關係人(Stakeholder)。站在敏捷專案管理的角度，利害關係人到底怎麼分成哪些類型？有各自扮演甚麼角色呢？

Inspired by Dan Rawthrone & Doug Shimp, Exploring Scrum: The Fundamentals.

Business Owner簡稱BO，就是提供資源進行專案的人，在小公司可能直接是老闆，在大公司通常就是主管，BO的職責是給予大方向，提供衡量專案成功的明確指標，並在專案執行過程中隨時掌握重要的資訊(Informative)。

Product Owner簡稱PO，就是在BO的授權下，帶領團隊執行專案的人，PO的職責就是善用團隊資源，創造產品的最大價值，對專案最終成果負完全責任(Accountable)。

Delivery Team就是實際負責執行(Responsible)的跨職能團隊，除了由PO擔任對外的唯一需求窗口以外，還包括一位專門幫團隊「喬事情」的「嬤嬤桑」(在號稱使用Scrum開發的團隊，就是Scrum Master)。

User就是專案產品的最終使用者，真的懂得敏捷精隨的團隊都知道，不論你覺得自己的產品有多棒，使用者才是老大，使用者才是真正的顧問(Consultative)，有關產品概念吸不吸引人、設計美不美觀、功能好不好用......，這些問題的答案，只有接觸了真正的使用者才會知道，而且揭曉答案的時機要越早越好，Delivery Team需要整合使用者經驗(User Experience, UX)的運作實務，就是這個道理。

Subject Matter Experts簡稱SMEs，就是專案執行過程中必須用到的「外力」，這群人和Delivery Team最大的差別是，SME僅提供支援(Supportive)，而不用對專案負責。

例如，公司副總預計在12週後發表一支APP，副總身為BO，指派產品經理擔任專案的PO，從各部門挑選了UX研究員、UI設計師、Developer和QA組成Delivery Team負責執行，團隊雖然在第11週就提前完工，但能不能如期上架，要看App Store的審核結果，審核人就是典型的SME。

Agile UX Day_Two

人本產品設計與開發：敏捷使用者體驗實務營的第二天

這一天，我們
用「生死簿」排出痛點(Pain Points)的優先順序

用使用者的情境故事，集思廣益探索解決方案，整合出團隊共同的創意

用淺顯易懂的方式，呈現視覺化的操作流程

用紙、筆、手、口，測試使用者對產品概念的接受度

用競爭對手的產品，訂出產品適用的 Benchmark


同時操作13個產品和服務設計的專案，我們的團隊和學員陣容實在太強大了

活動結束後，68個朋友預約了下一次的活動

下次的活動內容，會針對朋友們提出的願望來設計，活動名稱就叫 UXA，意味著怎麼把UX的能量，轉換成敏捷的需求和開發實務，時間訂在2016年12月底，帶隊的都是業界實際的Agile 和 UX Coaches，敬請期待囉!!!

Agile UX Day_One

人本產品設計與開發：敏捷使用者體驗實務營的第一天

原本開放給會員和親友的聚會活動，爆棚成為100多人的大會
第1個整天跑下來，大家頂著體感溫度超過32度的高溫，透過不插電的手作風，緊湊地跑過10個需求探索的流程。
祝福參加活動的朋友，都能吸收到滿滿的實務經驗。

活動前的準備