Agile 的 11 個謠言與 2 個真相

原文網址：http://www.javacodegeeks.com/2013/03/11-agile-myths-and-2-truths.html

我提供了許多 Agile 的訓練課程、也講了很多 Agile 的事情（BCS Bristol tonight）。 有些問題一再地出現，結果就是人們開始相信這些 Agile 謠言。 因此我一再地把時間花在拆穿這些謠言上。

我一直有一個小清單，上面有 11 個重複出現的謠言， 還有兩個對於一些團隊或公司比較難接受的真相。

Agile 謠言

1. Agile 是新玩意：錯！Agile 宣言在 2001 年就發佈了， Scrum Pattern 語言在 1998 年的 PLoP（譯註：Pattern Languages of Programs）發表、 Episodes Pattern 語言（XP 的前身）在 1995 年的 PLoP 發表、 Tom Glib's Evo 方法可以追溯到 1976 年，有些甚至還更早。

2. Agile 代表沒有文件：在 Agile 當中你想要寫多少文件都可以。 文件只是另一件可以作的事情，如果它帶給你好處， 那就把它放進時程中然後把它做出來——就像其他東西一樣。 請注意：文件通常沒人讀、常常傳遞失敗、被用來當防衛武器、 是大型軟體專案中第二昂貴的部份（僅次於重作）。

3. Agile 代表不做設計：錯！Agile 可能意味著「更多的設計」。 設計是所有開發方法、企劃會議...... 的一部分。 Agile 代表 big-up-front design 的末日，那個在開始寫程式五分鐘之後就會失效的玩意。

4. Agile 代表沒有規劃：又錯！Agile 通常要規劃更多東西。 同樣的，規劃要貫穿整個開發行為中、而不是只有再一開始的時候規劃； 規劃應該是每個人都要作的事情、而不只是一兩個人特有的工作。

5. 開發人員可以用他們喜歡的方式做事：錯！ 如果這點對你來成立，那你可能就做錯了，請打電話給我吧！（譯註：這哪招？） Agile 需要更多的紀律來規範團隊， 通常是由 Customer 或 Product Owner 這兩個角色來決定什麼東西該完成， 然後通常是由 Product Manager 或 Business Analyst 來執行。 如果開發人員作他們想做的事情，那這個角色就失敗了。

6. User Story 有正確的長度：User Story 沒有正確的長度。 請接受「每個項目都不同」的事實。

7. work 必須配合 Sprint：如果你正在執行 Hard Core Scrum，答案是肯定的。 如果你正在執行我的 Agile 方法（我現在稱為 Xanpan），那麼答案是否定的。 事實上，I advise letting stories span sprints in order to improve flow.（譯註：翻譯不能） 你可以讓 story span sprint，不過我們不會讓這件事情一直發生、 且會努力將它們打散成更小的 work。

8. Scrum 跟 Kanban 是世仇：沒這回事，不過它們背後的行銷手段可以透過這招獲得不少注目。 Xanpan 混合了 Kanban 跟 XP，而 XP 跟 Scrum 沒有差很多，這你就了了吧？

9. Agile 不能用在有明確死線的專案上：不，Agile 最適合在這種專案下運作。

10. Agile 不能用在 brownfield（譯註：砍掉重練）專案上： 不，Agile 最適合在這種專案下運作。

11. Agile 不能用在 greenfield（譯註：全新）專案上： 不對，不過你的首要目標是讓你自己進入到一個穩定的狀態： 想像自己在處理 brownfield 專案。

我認為用 Agile 的理想專案是：一個 brownfield 系統、確定在 3 到 6 個月後結案、 開發工作已經開始了但是需求還是很不明確。 接著是兩個關於 Agile 的事實：

1. 我們沒辦法用 Agile，因為...... （開放填空）

2. Agile 是個好主意，但是...... 我們應該等到完成 X、 確定要買 Y、然後買了 Z、新教宗也對我們放了祈禱樹之後......

你可以隨時讓自己打消念頭，或是找到一個「明天再作」的好理由。