2018年11月13日 星期二
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。
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)
2015年9月26日 星期六
秒懂 MoSCoW排序法，專案聚焦不再瞎忙
敏捷方法陣營中，DSDM Consortium提出的MoSCoW排序法，在「願望很多、時程很趕」的專案世界裡，是很實用的需求管理招式。
MoSCoW的作法就是在進行Iteration Planning(當期規劃)時，把需求分為4大類，其中：
1. Must Have(M): 對Iteration Goal來說，沒有交付就不能達標的事。
2. Should Have(S): 對Iteration Goal雖然重要，但目前仍有替代方案，就算沒有交付，也不影響達標的事。
3. Could Have(C): 與Iteration Goal沒有直接關係，如果交付可以加分，但就算忽略也不會影響達標的事。
4. Won't Have It Right Now(W): 和Iteration Goal完全沒有關係的事。
根據DSDM的建議，M、S、C類的需求，在規劃時應該各自配置60%、20%和20%的工時，在開發週期內，M類需求如果沒有做完，團隊就不做S類需求，S類需求沒做完，就不做C類需求，至於W類的需求，顧名思義就是要團隊敬而遠之，避免花時間在上面的事。
因此，如果用MoSCoW法管理需求，整個開發週期執行下來，就算預計的工時和實際工時有落差，也能確保「最重要的事獲得最早而且最多的資源」，這就是敏捷團隊「要事先行」(First Things First)的原理！
2015年9月9日 星期三
The Product Backlog Iceberg Revised
敏捷需求大師Mike Cohn，曾經用冰山(Iceberg)比喻專案的Product Backlog，很貼切地表達了專案的所有需求和需求之間，也有大小輕重緩急的概念。
從敏捷開發的實務來說：
1. 排進目前Iteration執行的需求，不但要控制在一期做得完的大小，而且要分解出相關的Tasks。
2. 預計下個Iteration執行的需求，需要經過Grooming(或稱Refinement)，確保大小適中，而且備妥Acceptance Criteria，達到Ready的狀態。所謂的Ready Story，就是團隊在進行Iteration Planning時，不用花10鐘就能把相關的Task分解出來的Story。
3. 團隊和Product Owner同意排進Release Backlog的需求，就是Committed的狀態，這些需求當中，有的比較粗略，還需要進一步分解優化。
4. 至於當前Release以外的需求，說得好聽叫做Defer Commitment，白話的意思就是「再說啦」。
2015年1月14日 星期三
2015年1月9日 星期五
敏捷團隊跑得快，上面坐個老太太
徐柏峰
使用敏捷方法可以提升團隊開發速度，這是千真萬確的事，不過，如果團隊接的是政府標案，就算提早開發出成品，也不見得可以提早驗收請款。
使用敏捷方法，可以縮短問世時間，提升開發效能
VersionOne的年度敏捷調查報告指出，公司考慮導入敏捷方法的頭號理由，就是希望縮短「面市時間」(Time to Market, TTM)，也就是產品從概念產生到上市銷售之間的時間。對承接政府標案的廠商來說，TTM可以比喻成拿到標案到開發票請款之間的時間。想當然，TTM越短，對廠商越有價值。QSM Accociates曾經出具報告指出，使用敏捷方法的團隊，TTM可以提升50%、產能(Productivies)可以提升25%。[1] VersionOne對實際使用敏捷方法的團隊進行調查，結果發現，高達87%的團隊成員認為，開發的速度確實比以往還要快。[2] 撇開這些有商業色彩的報告不說，身為Scrum共同創始人的Jeff Sutherland在國際學術研討會上發文指出，Yahoo導入敏捷方法後，平均開發速度(Velocity)比以往的瀑布式方法增加了35%。由於使用敏捷方法提升後速度提升的案例實在太多，因此Jeff Sutherland訂出超高標準說，導入敏捷方法後效能要達到瀑布式方法的400%，才稱得上是真正的高產能(Hyperproductive State)。[3]
公部門的辦事心態，不見得適合敏捷
敏捷團隊跑得快，這是親身經歷的事。筆者在2009年剛接觸敏捷方法的時候，在政府委外開發軟體的專案上，應用Iteration Planning、Iteration Review、Face to Face Communication和Working Software這些技巧，把原本7個月要結案的專案，提前在5個半月內就全部「打完收工」，而且從測試報告、使用手冊到結案報告也全都做完。筆者原本以為提早做完就可以請求驗收付款，結果就在請求驗收文送出之前，機關承辦人來電訓誡說，絕對不可以讓上面覺得進度超前，以後也絕對不要做這種「找麻煩的事」。承辦人的理由是，當初專案講好7個月做出來，如果提前就能完工，就表示專案「不應該花那麼多錢」，因此承辦人怕被指責說在圖利廠商。後來，專案從第5個半月起， 繼續演了5次的每周進度報告，會議上除了聊天打屁，就是刻意在會議紀錄上寫說哪份文件的格式不對，需要退回重改，一直到法定時間，專案才進入驗收請款程序。到了第2年，筆者接了其他政府機關的專案，同樣的戲碼依舊上演。原來，提早把事情做完，並不是每個組織都歡迎的事！冏
[1] Ned Kremic, Why is Agile Time to Market(TTM) delivery 50% faster?
See http://www.deltamatrix.com/agile-time-to-market
[2] VersionOne, 8th Annual
State of Agile Servey, p. 9.
[3] S. Downey and J. Sutherland, Scrum Metrics for Hyperproductive
Teams: How They Fly like Fighter Aircraft, IEEE HICSS 46th Hawaii International
Conference on System Sciences, Maui, Hawaii, 2013
2015年1月8日 星期四
小確幸是專案勝出的秘密
徐柏峰
從1985年開始，知名資訊顧問公司-The Standish Group，定期用批流年的方式，公布「全球」資訊類專案的成敗比率(Resolution)。不論是資訊還是專案管理背景的人，對The Standish Group的報告，應該都不陌生。
Project Resolution(2004~2012)
 |
| Source: Chaos Manifesto 2013 |
敏捷專案成功率是瀑布式專案的3倍
The
Standish Group在Chaos
Manifesto 2011報告中說，敏捷是全球軟體開發專案的救星(The universal remedy
for software development project failure)，專案使用敏捷方法，成功率會是傳統瀑布式方法的3倍。
Chaos Resolution by Style
 |
| Source: Chaos Manifesto 2011 |
小專案勝出機會比較大
事隔兩年，Chaos Manifesto 2013稍稍「修正」了官方說法，改口說：專案成敗的重點，是「大處著眼、小處著手」(Think Big, Act Small)的能力，因為根據The Standish
Group實證的結果，人事支出(Labor Content)在1百萬美元以下的專案，執行成功率是1千萬美元以上專案的7.6倍，失敗率是則是低於8分之1。報告中指出，以軟體開發這個領域來說，所有的大專案都能切成多個小專案，不過，切割不是把專案分階段交付這麼簡單，真正有用的切割，是把原本一大包的專案，根據商務價值來分成模組，分割成可以個別帶來小確幸的專案。
Project Resolution by Size
 |
| Source: Chaos Manifesto 2013 |
在台灣和大陸，規模1百萬美元以下的專案超過70%，應該比較具備成功的條件吧！
訂閱：
文章 (Atom)