作者 Jeff Xiong 發布于 2007年7月4日 上午2時18分

社區

Agile

主題

企業級敏捷

敏捷的核心是什么？敏捷給軟件企業（以及軟件開發者個人）帶來的好處究竟在哪里？這個問題有很多不同的答案。例如“重視個人和交流”，軟件開發者喜歡這樣的態度，這是毫無疑問的。例如“重視可工作的軟件”，它的價值是顯而易見的。但在這一切的背后，敏捷的核心是什么？時下流行的觀點是：敏捷就是軟件行業里的精益（lean）生產，它的核心是消除浪費。ThoughtWorks中國公司的高層在近日接受采訪時明確指出了這一點。

首先考慮質量問題。一些軟件企業為了降低成本而忽視質量，但質量低下的軟件會造成返工的浪費，反而提高成本。相反，在日常工作中投入更多的精力來保證質量，反而能夠為企業節約成本。ThoughtWorks中國公司技術總監Michael Robinson用軟件工程的經典理論來分析這個問題：

任何一本軟件工程教材都會告訴你：假設在分析階段找到并解 決一個錯誤的成本為1，在設計階段解決同一個錯誤的成本就變成10，在實現階段就變成100，在維護階段就變成1000。敏捷軟件開發中的眾多實踐正是為 了避免低質量和返工的浪費。盡管它們一開始看起來似乎有些麻煩，但它們帶來的收益是實實在在的。

另一種常見的浪費則是“為將來準備的投資”。例如為了應付將來可能出現的需求變化而提前引入的靈活設計，如果需求沒有發生變化，這些靈活設計就會成為浪費：不僅浪費了將它設計出來的成本，而且浪費了繼續維護它的成本。制造業為了降低庫存成本而創造出“Just In Time”的生產和決策方法，ThoughtWorks中國公司總經理郭曉認為這些方法同樣適用于軟件行業：

如何消除預測錯誤的浪費？避免預測錯誤的 根本辦法就是推遲決策：決策下得越晚，就越不容易因為預測失準而造成浪費。當然也不能晚到錯過了時機、耽誤了工作才下決策，這就像豐田制造的Just In Time，決策也要Just In Time。過早的、含有太多預測成分的決策也會造成浪費，其危害絲毫不亞于過晚的決策。

在最近的兩篇Blog里，我談到了一些從更深層次思考敏捷的心得。在我看來，敏捷的、精益的、實用主義的決策往往是符合中庸之道的：它們往往是各種因素、選擇權衡之后的結果。敏捷方法極端重視提升客戶價值，為了達到這個目標而采取的手段通常都不可能是極端的。

中庸之道常常有效的深層原因是邊際效用遞減律：對一個方面的東西重視到一定程度以后，再加入更多的重視，收到的邊際效用遞減；同樣的重視度放到另一個方面上，能夠收到更大的邊際效用。讓每一分投入收到最大的回報，盡可能地消除浪費，這是精益的追求。

在另一篇Blog里我談到了如何進行精益設計。設計方案的選擇說到底應該是一次成本與收益的計算，而不是個人審美取向的衡量——當然，優秀的程序員能夠把這種計算變成本能，我認為這就是“軟件開發的藝術”所在。敏捷方法強調“簡單設計”，同樣是經過計算的結果。

在面對一個復雜并且靈活的設計時，首先要衡量的不是實現它的收益，而是“現在實現它”與“將來實現它”之間成本的差額。不論一個靈活的設計的收益和成本如何，只要這個差額非常小——等到未來實現它也沒有什么額外的困難，就應該毫不猶豫地推遲決策，等到真正需要的時候再引入靈活的設計。感謝現代化的IDEs，很多時候我們討論的這個成本差額確實非常小，這是敏捷設計通常取簡單方案的原因所在。

值得注意的是，隨時進行這種成本與收益的計算并不是一件易如反掌的事。計算本身也有成本。這是最佳實踐和工具支持存在的意義所在：你可以用較低的成本得到前人積累的知識。例如ThoughtWorks在介紹其項目管理工具Mingle時特別指出其中融匯了該公司多年從事敏捷軟件開發的經驗：

Mingle是一個敏捷項目管理工具。它為整個團隊在軟件交付過程中提供“一站”式服務，并通過有10年敏捷項目開發經驗的ThoughtWorks公司提供的開發框架共享所有的項目成果。我們帶來了敏捷開發方法，同時Mingle將會支持和推動這一切工作。

暢通的信息渠道，清晰的成本/收益核算，全面消除浪費，這是精益制造的核心所在，也是敏捷軟件開發的核心所在。

jwebee

我的個人網站