2013年3月16日 星期六

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、新教宗也對我們放了祈禱樹之後......

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

沒有留言:

張貼留言