Manifesto for Agile Software Development
2020年8月22日 星期六
2020年4月16日 星期四
Split Requirements: Techniques that make work doable
Material used on Agile Product Manager training.
2018年11月13日 星期二
2017年5月14日 星期日
2016年8月21日 星期日
利害關係人網路圖
專案管理不論採用哪一種管理方法，「人」都是最重要的元素。對於專案執行的過程或結果，受到影響的個人或群體，稱為利害關係人(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。
2016年4月8日 星期五
人本產品設計與開發：敏捷使用者體驗實務營 (暨台灣敏捷專家協會第二屆會員大會)
人本 = User Centered
培養團隊的擅變力
敏捷專案管理主張「訂定精實的需求，帶領敏捷開發團隊，透過視覺化溝通，駕馭充滿變動的專案」，是目前新產品開發或服務設計的主流工作方法，以美國職場為例，職缺徵才廣告中包括Agile關鍵字的工作，超過8萬筆，而且起薪就是80,000美元年薪。敏捷職缺為什麼值錢？因為對大部分的產業來說，「詳細規劃一次到位」的流程並不適用，導引團隊快速因應變更的敏捷能力，才是確保組織Build the Thing Right的核心技能。
活用UX幫產品創造價值
過去幾年來，從政府到民間，轉型使用敏捷方法的案例越來越多，但很多人把Scrum當成敏捷代名詞，以為寫幾張便條貼，就可以取代規劃和設計，把同事找來站著開會，就是在導入敏捷。不過問題是，在敏捷開發的團隊，專案的客戶族群怎麼定位？原始需求怎麼來？憑什麼提出變更需求？怎樣才能花費最小的代價，就確定設計方向正確，或是開發成果能讓使用者滿意？這些就是「使用者體驗」(User Experience, UX)的議題，也就是怎麼確保Build the Right Thing的議題。簡單地說，「使用者體驗就是使用者為了解決問題，和產品或服務接觸產生的感受」，以使用者為核心的設計與開發(User Centered Design & Development)，可以提升產品對客戶的價值，增加投資報酬率。
本次課程延請台灣敏捷專家協會理事長徐柏峰與多位敏捷教練，根據新媒體產品開發、敏捷專案管理與使用者體驗設計的多年跨界經驗，透過3天的Workshop，以實際案例分享在敏捷團隊中導入使用者經驗的做法，以及讓「客戶放心、公司安心、團隊開心」的工作方式。
第1天：人本敏捷規劃，日期2016/7/17，星期日
時間
|
單元
|
學習目標
|
上午
|
Craft a Vision Statement
|
快速聚焦，建立團隊共同目標
|
Identify Target Users
|
導引式訪談
從大量使用者資料中，有效採掘大多數使用者共同特徵
|
|
Understand User Needs
|
從使用者的觀點描述問題
|
|
用餐
|
||
下午
|
Analyze Tasks
|
考量使用者需要以及組織目標，找出最值得解決的問題
|
Measure AS IS User Experience
|
訂定有效指標，並衡量產品或服務的「好用程度」
|
|
第2天：人本敏捷設計，日期2016/7/23，星期六
時間
|
單元
|
學習目標
|
上午
|
Story Boarding
|
透過情境故事，增進開發人員對使用者的了解
|
Wireflow
|
視覺化表達使用情境
|
|
用餐
|
||
下午
|
Paper Prototype
|
進入開發階段前，就得知使用者喜好的精實測試方法
|
Solicit Requirements
|
透過使用者故事表達需求
訂定簡明的驗收條件
|
|
第3天：敏捷實務專題講座與第二屆會員大會，日期2016/7/24，星期日
時間
|
專家講座
|
學習目標
|
上午
|
Agile Administration
|
Tom Liao：敏捷行政主管的壓箱寶
|
Agile RFP
|
林祖馨：敏捷專案RFP與合約訂定
|
|
Behavior Driven Development
|
Richard Tsai: BDD開發與自動化測試
|
|
Agile KPI
|
徐柏峰：掌握專案成本分布並監控專案實際進度
|
|
用餐
|
||
下午
(會員限定)
|
General Meeting
|
第2屆會員大會
|
Change for the Better
|
第2屆會員選擇分組
|
|
Goal Setting
|
分組目標設定
|
|
學習目標
1.
提升需求窗口和開發人員的溝通品質
2.
學會從使用者的角度開需求
3.
在資源和時間有限的情況下，設計產品並進行使用者測試
適合對象(因場地限制，本次活動僅對會員及會員同行友人開放)
1.
需要提升產品投資報酬率的團隊
2.
需要提升產品使用者滿意度的團隊
3.
預計轉型使用敏捷方法的團隊
預備知識：
曾經參與專案執行、產品開發或服務設計
活動時數
3天，共21小時(18 PDU)
活動地點
台北市客家文化會館，信義路3段157巷11號，捷運大安站走路3分鐘
報名方式
1.
於2016年5月1日前，透過Email報名 (會員及友人合起來發一封Email到agiletalks@gmail.com，這是Percy的信箱)，報名日期截止後，會收到繳費通知，報名Email格式如下。
主旨
|
Agile UX工作坊_Percy共4人
|
內容
(第一行為會員名稱)
|
2.
於2016年7月1日前匯款，並來信告知匯款金額及單據後5碼
銀行
|
日盛國際商業銀行
|
總分支機構代號
|
815-0015
|
帳號
|
105-28481850-000
|
戶名
|
台灣敏捷專家協會
|
匯款後通知信箱
|
|
聯絡人
|
徐柏峰
0978-016105
|
相關文章：人本產品設計與開發第一天
2016年4月3日 星期日
敏捷工作機會多，錢也比較多
Indeed.com是全球最大的職缺搜尋平台，職缺來源超過50個國家，每月服務超過1億8千人次，透過Indeed.com搜尋，可以發掘市場的趨勢，常在網路上看到補習班把PMP吹得天花亂墜，究竟目前的職缺現況是如何呢？
光以美國來說，如果在Indeed.com上以Agile為關鍵字的搜尋，約有超過8萬筆結果，最入門的薪資水平是每年75,000美元，不但職缺數量是PMP的5倍，年薪起跳更比PMP多5,000美元，
如果以敏捷專案管理的代表性證照PMI-ACP為關鍵字，雖然職缺還不算多，但數量正在逐年增加，而且起薪就是85,000美元。
 |
| 資料來源：Indeed.com |
 |
資料來源：Indeed.com |
2015年12月3日 星期四
打造人民有感的政府數位服務：英國案例分享
這是2015年發表的最後一篇研究專題了，雖然題目是打造政府數位服務，內容是真正的大型敏捷案例，想要把組織轉型敏捷的，想找敏捷專案驗收標準的，還是想為專案訂定「有感」KPI的，在這篇文章裏面都有線索。全文刊載在國家發展委員會《政府機關資訊通報》第338期，有需要的朋友直接去下載吧。
2015年9月29日 星期二
靠北不是敏捷開發，不寫文件也不是
 |
| 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 |
由於每個Iteration的實際產出，不但要經過QA的驗證，還會直接給使用者測試，因此歷經幾個Iterations累積出來的開發成果，在Release前早就「準備好了」。我們知道高品質的產品，一定要搭配相關的文件，因此在實務上，我們有些團隊是在Release前預留Hardening Iteration，讓團隊成員寫文件，也有些團隊，是在確定Release「安全下莊」之後，讓成員在比較不緊張的情緒下，才開Iteration來補齊前一個Release的文件。
拿結果來寫文件，就像是把箭射出去才描靶，和以往「先寫作文再做事」的主流開發方法比起來，我們不論是需求、分析、設計、布署，還是使用者文件，都可以寫得又快、又好、又便宜，這個最佳實務，就叫做Document Late。
相關文章：敏捷開發(Agile Development)
訂閱：
文章 (Atom)