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

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

秒懂 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)的原理！

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，白話的意思就是「再說啦」。

善用Agile+UX，英國打造人民有感的數位政府