從"你叫這敏捷?"部門談起 From the “you call this agile?” department

Dmitri Zimine 用一個假設的範例說明打斷一個程式設計師兩個小時，解決銷售案的問題，實際上會如何浪費掉兩個星期。「如果 Sarah 花了兩個小時在舊專案上，那麼他在新專案上會損失一整天的生產力。」

我同意切換工作有壞處。無庸置疑。

Dmitri 指出開發經理應該「告訴開發員堅守原來的計劃。提供保護避免他切換腦中的內容。提醒他專心在一個重要且有趣的工作上有多酷。向他保證我會處理所有的壓力。」

聽起來好像這我也會同意。我完全同意管理階層有責任提供程式設計者一個抽象層，讓程式設計師可以假裝他們在工作寫程式的時候，外界的事物完全不存在。

然而這結論裡有件事讓我覺得很驚訝。Dmitri 只看到了成本/效益方程式的一面。他提出了一個很有說服力的論點說明為什麼 Sarah 不應該中斷他仔細規畫好的兩個星期步驟，但他完全沒有提到另一面的論點: 可能會損失重要的客戶/銷售。

Agile development(敏捷開發) 應該是有關於敏捷的。它應該代表你可以很快地更改計劃。敏捷不應該是一個死板的程式團隊奴隸般投入他們的兩星期步驟，以致為無法重新安排行事曆來滿足客戶的需求。Dmitri 的結論對我來說等，恐怕和敏捷開發正好相反。敏捷不應該是為了排除一個官僚化僵硬的程序，而掉進另一個同樣沒有計算到客戶需求的程序。

我不知道這個假設範例的細節。也許在現實生活中這個客戶的需求沒真的那麼緊急。但是也許它就是這麼緊急？也許這個客戶可以拯救公司一命，讓每個人都變成 Web 3.0 時代的大富翁，但是因為 Sarah 堅持要遵守兩星期長的計劃(因為它「敏捷」)，讓他們沒了興趣？不確定... 這只是故事的一面。

最近微軟釋出了新版本的 IE。他們在代理伺服器的偵測程式裡製造了一個問題，使得一小部份的 Copilot 客戶遇到當機。在此同時，Copilot 開發團隊，也就是 Fog Creek 裡的 "Ben", 正忙著把 Copilot 2.0 完成好推出上市。但你知道嗎? 我們安裝了 IE 7 的客戶遇到當機。這令人無法接受。Ben 停下他手上的工作，安裝舊版的編譯器，取出舊的原始碼，修好了當機問題，把修正版放上伺服器。這打斷且延遲了 Copilot 2.0，而且這切換有壞處。但這仍是一個正確的決定。正因為有能力處理切換工作這種高難度心智挑戰，我們的產品才會更好。這是程式設計師賺大錢的理由。你給他們昂貴舒服辦公椅、無限零食供應、豪華午餐、超讚三十吋液晶螢幕，因為這樣能讓他們去解決微軟在他們程式裡製造出來的，把原本一個正常工作的 DLL 搞亂的新問題。

是的。切換很痛苦。是的，你要打斷某人的工作時，需要計算到切換的代價。但是每個決定都有好處和壞處，當我聽到有個經理只說到壞處而沒有考慮到好處時，這經理並不稱職。

這些網頁的內容為表達個人意見。
All contents Copyright © 1999-2006 by Joel Spolsky. All Rights Reserved.