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
在文件方面,很多人對敏捷軟體開發宣言(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)


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