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

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)