Agile Framework

敏捷流言終結者

敏捷團隊不寫文件嗎? 敏捷專案可以隨時改需求嗎?
敏捷方法雖然很盛行，但外界誤解還是很多。
史上第一個 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個需求探索的流程。
祝福參加活動的朋友，都能吸收到滿滿的實務經驗。

活動前的準備

Adios User Stories. Embrace Value Stories.

Create value by satisfying both the user’s needs and the organization’s goals.

Here is the user story that we are all familiar with.

AS a [type of user]

I want [a requirement]

So that [user’s need will be fulfilled] 

This is the new and improved version, aka "Value Story"

AS a [type of user]

I want [a requirement]

So that [user’s need will be fulfilled]

And [the organization] will [be able to reach its goal]

靠北不是敏捷開發，不寫文件也不是

Image Source: http://giphy.com/gifs/western-cowboy-henry-fonda-xulayf0YLcCwo

有一個問題，每次在推廣敏捷方法的場合幾乎都有人提出。被問了這們多年，我想乾脆在這裡說個清楚。

問題是：你們不做規劃，不寫文件，怎麼確保產品的品質？

我的回答是這樣...

靠北不是敏捷開發
客倌您誤會了，既不做規劃，也不寫文件的那群人，用的是散兵游勇的「靠北編程法」(Cowboy Programming)，而不是團隊合作的敏捷開發法(Agile Development)。通常，施展靠北法進行開發的團隊，要不是懶惰，就是沒有能力分析問題，要不就是自我感覺異常良好的『自認型天才工程師』，不論是哪一種，最近幾年隨著敏捷方法越來越流行，這群靠北大師經常在開會時隨便講一講畫一畫，就開始動工，號稱自己用的是『敏捷開發』，所以不進行設計，直到自己對客戶承諾「包在我身上」的專案後來真的「『包』在我身上」，他們就拿敏捷當藉口說：「台灣團隊不適合跑敏捷」，「客戶不懂，所以不適合使用敏捷開發」。也因為這樣，才會有人寫出「為什麼我不推薦敏捷開發《嫁給RD的UI Designer》」的文章，真的是對敏捷誤會大了！

客倌您聽好了，開心的敏捷環境是這樣運作的：

We Are All Developers的團隊文化
每3-9個人編成1個開發團隊，如果人數超過9人，就加開1隊，依此類推。
每隊的成員當中，不論個別專長是需求、分析、設計、實作、測試、作文、作畫、道歉(這個很重要)還是其他，對外一律稱為Developers，大家的專長加一加，要能夠因應產品開發過程中，各個環節的技術要求。

Three Amigos，決定產品品質

Image Source: http://giphy.com/gifs/sY1yvrxROgCM8

產品品質好不好，要看團隊裡的「3個好朋友」能否發出1+1+1>3的聲音，其中：

    第1個朋友的聲音，叫做Customer Voice
如果Customer Voice發揮作用，不論是透過文件，還是面對面溝通，團隊成員就都能說得出「客戶目前面臨的問題」(稱為「需要」(Needs))，以及「目前來說，適合用什麼方法來解決問題」(稱為「需求」(Requirements))。

    第2個朋友的聲音，叫做Worker Voice
如果Worker Voice發揮作用，有關工期估算，以及需求的執行方式，就會「由下而上」交給實際開發的人負責，而不會交由「官大學問大的河馬」決定。(HIPPO=Highest Paid Person's Opinion)

    第3個朋友的聲音，叫做Quality Voice
如果Quality Voice發揮作用，具備測試專長的同事，從專案啟動的第1天，就會是團隊編制內的專屬(Dedicated)成員，而不是開發階段結束後才接手的「外人」。在每個需求進入開發前，扮演QA角色的人，會事先開出相關測試案例，讓其他人有所依據，而在開發告一段落後，尤其是在Release前夕，如果大家都跑光，只留QA下來加班，就不能算是真正的We Are All Developers文化。

Document Late，撰寫又快又好又便宜的文件

Image Source: http://agilemodeling.com/essays/documentLate.htm

在文件方面，很多人對敏捷軟體開發宣言(Manifesto for Agile Software Development)斷章取義，以為"Working software over comprehensive documentation" 就代表敏捷團隊不寫文件。對此，我只能說：錯，錯，錯。敏捷團隊不但會寫文件，而且寫的是很精確的文件。以我自己曾經帶領或擔任Coach的團隊為例，我們認為文件的最大用處不是用來規劃(Planning)未來，而是用來記錄結果，因此在Product Planning、Release Planning、Iteration Planning和Daily Standup這些規劃的場合，我們把相關人員聚在一起，用面對面溝通的方式，利用大面積的白板、便條貼、照片和螢幕擷取畫面，紀錄和需求相關的所有細節。在Iteration期間，Three Amigos之間只要有任何疑慮，不論是需求不清、作法不明，還是遇到卡關(Block)，相關人等一律直接「踹共」，一邊塗鴉，一邊就當場把問題講開，而不必多花時間刻作文、發Mail或請聖旨。
由於每個Iteration的實際產出，不但要經過QA的驗證，還會直接給使用者測試，因此歷經幾個Iterations累積出來的開發成果，在Release前早就「準備好了」。我們知道高品質的產品，一定要搭配相關的文件，因此在實務上，我們有些團隊是在Release前預留Hardening Iteration，讓團隊成員寫文件，也有些團隊，是在確定Release「安全下莊」之後，讓成員在比較不緊張的情緒下，才開Iteration來補齊前一個Release的文件。
拿結果來寫文件，就像是把箭射出去才描靶，和以往「先寫作文再做事」的主流開發方法比起來，我們不論是需求、分析、設計、布署，還是使用者文件，都可以寫得又快、又好、又便宜，這個最佳實務，就叫做Document Late。

相關文章：敏捷開發(Agile Development)

The Agile Product Development Illustrated