XP 2002 會議

記住精神

會議正式開始時，Ken Schwaber 發表了一場演講。Ken 開場時的主題是，敏捷開發不僅僅是重新包裝一堆舊技術，而是一種新穎且革命性的東西。將敏捷視為舊主題變體的文章，例如 Barry Boehms 最近的 IEEE Computer 文章，根本沒有理解敏捷的特別之處。

Schwaber 將 Scrum 描述為一種產品開發方法，其範圍不僅限於軟體。他說，XP 提供了許多 IT 組織所缺乏的工程實務，而 XP 和 Scrum 的結合結果是敏捷流程中最純粹的。

根據他的經驗，有兩種專案有興趣採用敏捷，一種是有問題的專案，另一種是好奇的專案。他發現前者較好，因為他們會遵循敏捷建議，而後者通常會對各種想法說「但是」。他批評了從敏捷方法中汲取一些想法的常見做法，他說這就像從精緻的瑞士手錶中取出一個精良的彈簧。

Schwaber 建議幾個真正的敏捷標記

• 經理認為在沒有所有需求的情況下繼續進行是可以的
• 業務人員對於交付軟體感到興奮
• 工程師在遇到問題時會被聽見
• 大樓內充滿熱鬧的感覺
• 團隊決定如何執行工作
• 人們不談論一般角色

他說敏捷是一種權力轉移，將 IT 回歸到業務中。在業務條款中，投資報酬率 (ROI) 是唯一真正的成功衡量標準。敏捷最大的危險是人們過於專注於實務，而忘記了更大的畫面，也就是敏捷開發的革命性面向。

實務與哲學之間的交互作用已經困擾敏捷和 XP 社群一段時間了。我認為這特別適用於 XP，因為它包含一些重要的哲學方法，說明軟體開發的方式，以及一些非常具體的執行實務。這導致了一個真正的問題，即 XP 的本質是什麼 - 是實務還是基礎哲學？這特別明顯，因為隨著您在 XP 中獲得更多經驗，實際遵循實務變得不那麼重要。但同時，您必須執行實務才能了解 XP 的真正意義（這是我在 XP 主題變奏 中探討的一個難題）。

在許多方面，我認為「敏捷」標籤幫助我們更容易思考分離。在 Snowbird 聚會 中真正的價值在於，儘管實務有所不同，但參與者在哲學上達成了許多共識。這就是宣言中的價值觀如此有意義的原因。我同意 Ken 的看法，敏捷在其基本要素（從預測到適應，從以流程為導向到以人為導向）的轉變更像是不連續性，而不是進程，儘管很難看到界線。

但我並不太擔心專注於實務 - 事實上，我認為這很重要。良好的開發實務對於實現敏捷開發的承諾至關重要。XP 在此提供的服務，例如其演化軟體設計技術，對於我們在未來保持靈活性至關重要。沒有所有部分，就沒有值得欣賞的瑞士手錶。

製作良好文件

敏捷研討會從不害羞地邀請那些許多人認為是敏捷事業反對者的人，例如 CMM 的 Mark Paulk 去年在 XP Universe 發表演講。今年 XP 2002 歡迎 David Parnas，他對 XP 採取了更嚴厲的批評立場。

他說 XP 的一大問題在於它專注於困擾軟體開發四十年的問題。XP 專注於程式碼有其好處，但未能解決其他重要的軟體開發問題。軟體最大的問題在於對意外事件的反應不佳，以及介面的定義與控制不佳。

他批評的重點在於 XP 的設計方法，他認為這會導致問題延後發生。這是一個經濟問題，現在省錢卻要付出後續的成本。專注於簡潔性固然很好，但目光短淺的簡潔性和有遠見的簡潔性是有區別的。真正的長期簡潔性需要規劃，規劃需要審查，而審查需要文件，因為從程式碼中得到的回饋來得太晚了。

但他並不主張大多數專案所做的文件。他認為大多數專案文件比沒用還糟，並批評「未定義建模語言」。XP 的測試案例不夠，因為它們無法完整。他偏好定義良好的數學方法，但表示形式方法社群並未走在正確的道路上，因為這些數學規格必須比程式碼更容易閱讀，這不是 Z 或 VDM 等常見形式方法所能做到的。

他說這種數學方法需要建立在函數和關係上。找出需要監控和控制的變數，並從監控變數中形成受控變數的導數。然後可以將這些變數放入領域專家可以閱讀的表格形式，每個受控變數一個表格。他舉了一個航空電子系統專案為例，飛行員根據這樣的規格找到了數百個錯誤。當然，時間不允許他深入解釋這個系統。

關於 XP 設計方法的爭論很激烈，我曾用它作為 我在 XP 2000 的演講 的主題。嚴謹但可讀的規格的想法是我軟體生涯早期的一個主題。我在軟體研討會上的第一篇論文是關於如何以數學上嚴謹的方式使用圖形設計技術，這朝著相同的方向邁進。

我的觀點，我想 Parnas 會同意我，這種形式規格的價值在於找出錯誤的能力，以便比其他技術更有效地修復它們。如果您的開發方法是規劃設計，您希望在編碼開始之前設計大多數完成，那麼這一點至關重要，因為否則規格中的錯誤直到流程的後續階段才會被發現。

XP 從幾個方向解決這個問題。它使用短週期迭代意味著您可以從程式碼中獲得快速回饋，因為使用者可以在幾週內開始使用他們可以使用的系統。它使用重構允許以比沒有它時更低的成本修復目光短淺的簡化，並支援積極測試和持續整合。

問題的關鍵在於，這種形式的數學規範是否比 XP 的方法更具成本效益，以及在什麼條件下。我從不相信特定的方法一定適用於所有不同類型的軟體開發，因此最適合航空電子設備的方法可能不適合企業應用。我在企業界進行更正式方法的實驗，讓我相信領域專家無法與他們很好地合作，無法像迭代交付一樣找出錯誤。我也很驚訝於 XP 背景下演化設計的有效性，儘管我仍然偏好一點計劃設計。然而，儘管說了這麼多，我並沒有嘗試過 Parnas 的特定技術。我希望一些 XP 人員在與客戶合作時嘗試這些技術，看看它們是否值得使用。儘管我認為 Parnas 將這些技術視為在預測環境中使用的技術，但我認為沒有理由不能在迭代環境中使用它們。

使用二十年前被捨棄的做法

如果 David Parnas 是 XP 社群的局外人，那麼 Enrico Zaninotto 就是整個軟體開發世界的局外人，他是一位經濟學教授。他感興趣的是將敏捷方法與製造業的最新發展進行比較，這源於看到一個軟體開發專案使用 20 年前被領先製造商放棄的技術的經驗。

Zaninotto 概述了四個主要驅動力，這些驅動力增加了製造或軟體開發工作的複雜性。

• 系統可以進入的狀態數量
• 各個部分之間的相互依賴性
• 你可以執行的各種動作的不可逆性
• 環境中的不確定性

他將 Taylor 和 Ford 模型描述為通過專注於系統可以進入的狀態數量問題來處理複雜性。他們通過分工、標準化零件和固定可以製造的產品的裝配線來解決這些問題，從而限制狀態數量。Zaninotto 將瀑布式流程觀點視為遵循此模型。Taylor/Ford 模型的限制在於當你遇到無法預見的後果時。當你知道會發生什麼時，這種方法會優化情況，但會對不確定性變得脆弱。

製造業的典範轉移是豐田系統。在四個複雜性驅動力中，他說豐田系統攻擊不可逆性，允許改變決策。雖然 Taylor/Ford 控制資訊流，將其嵌入系統中，但豐田系統將決策制定推向行動點。

像豐田系統這樣的靈活系統最大的難點在於它們可能無法收斂。為了讓事情收斂，豐田系統將變異保持在界限內，並使用高水準的品質控制。Zaninotto 將這個收斂問題視為 XP 的限制點。XP 的真正界限是收斂仍然發生的界限。

我沒有在 Zaninotto 的演講中表現得最好，會議晚宴有一個非常好的樂隊和大量的 Mirto - 這導致了一個晚且疲憊的夜晚。而且在最好的情況下，8.30 對我來說從來都不容易。但我對這次演講著迷了。Zaninotto 用非母語演講，朗讀了他的文字，但在許多方面，傳遞的簡潔性放大了內容的品質。豐田系統和敏捷流程之間的聯繫是一個領域，Mary Poppendieck 已經繪製出來，這讓我進一步探索它，但 Zaninotto 為我已經學到的東西添加了新的想法。（這是少數幾個真正值得閱讀全文的情況之一。）

可逆性的問題，以及不可逆性是複雜性原因的概念，這一點特別讓我感到興奮。DSDM 有趣的事情之一是，其九項核心原則之一是「開發期間的所有變更都是可逆的」。將可逆性放在此類方法論的最上方是不尋常的。一種說法是，可逆性是增量變更的必要保護。這表示最糟的情況是暫時的問題，以及回復到先前的狀態。當然，那些暫時的問題可能很嚴重，就像任何電腦缺陷一樣，但一旦發現故障，即使無法立即找出根本缺陷，您也可以隨時透過回復來修復。

當我閱讀 最近的 FDD 書籍 時，我注意到在他們的核心實務清單中，他們包含了組態管理。組態管理未包含在 XP 中，並不是因為它不必要，而是因為 XPers 假設組態管理是基本能力的一部分。然而，遇到似乎不了解如何正確使用組態管理的人並不少見。

讓我印象深刻的另一個元素是可逆性和迭代開發之間的相互關係。如果您做出錯誤的決定並迅速發現它，那麼您可以使用某種形式的可逆性來撤消您的錯誤，或者您可以在錯誤失控之前進行重構。但是，如果您無法快速偵測到它，那麼它就會嵌入系統中，並且難以逆轉。迭代週期讓您能夠在錯誤難以逆轉之前及早發現錯誤，而重構進一步降低了移除錯誤的成本。最終結果是，您不必在第一次就把事情做對，消除了複雜性的主要來源。嚴謹流程的大部分思考都是關於應對不可逆流程，而一旦消除了這種複雜性，用於應對不可逆性的技術就會變成多餘的負擔。

XP 實務的隱喻

Bill Wake 是今年全體會議演講節目中唯一一位著名的 XP 領導者，他的貢獻比許多其他全體演講的語氣輕鬆。他的主題是隱喻，不是指 XP 中的隱喻實務，而是指各種 XP 實務的隱喻。以下是那些我注意到的摘要。

• 測試優先就像數學問題，他們只告訴您偶數答案 - 重點不是答案，而是執行。
• Spike 就像木工，您只建造一個來看看它是如何運作的。在您製作物品之前，測試優先也會在此發揮作用，因為您可以找出物品應該如何配合。
• 集體程式碼擁有權就像電影和電視節目（例如白宮風雲）中的情境室。重點是，每個人都可以存取所有資訊，因此能夠為問題解決做出貢獻。
• 配對程式設計就像四手聯彈，或者像是雙打摔角
• 反覆運算就像時鐘上的擒縱器
• 學習 XP 就如同學習外語
• 持續整合就像平衡支票簿。如果你一年才做一次，那會很痛苦，但如果你每週都做，那會很輕鬆。
• 乾淨地回家（以綠色條列登入）就像日內交易，在一天結束時讓你的投資組合保持平衡。
• 站立式會議就像比賽的起跑器，在那之後每個人都朝著同一個方向前進
• 反覆運算回顧就像運動隊伍觀看他們上一場比賽的影片

隱喻是 XP 中有爭議的主題，我發現當一個隱喻運作良好時，它會令人難以置信地滿意，但想出一個運作良好的隱喻非常困難。將這種類型的隱喻思考作為強制性的練習會受到限制，因為它要求你做一件困難的事情，而更簡單的事情通常就足夠了。因此，我在使用 XP 時不會太擔心隱喻，但我不會讓它阻止我使用好的隱喻，如果它出現的話。

就像大多數隱喻一樣，我發現比爾的一些隱喻很有趣，但大多數對我來說都沒有用。持續整合 == 平衡支票簿運作得很好，我將擴充它，指出當你自動化支援時，平衡支票簿會更容易（使用 Quicken 很有幫助）。我也喜歡情境室/集體程式碼所有權的類比 - 儘管我從未看過白宮風雲。

但我從來不太喜歡四手聯彈 - 至於雙打摔角？至少我可以想像「鐵鎚」朗·傑佛瑞和「野蠻女人」安·安德森對戰肯特「阿爾法黑猩猩」貝克和羅伯特「黑洞」馬丁。（我只想確保羅布·米是我的搭檔。）

僅建置您需要的功能

吉姆·強森是 Standish Group 的主席，因此毫不奇怪，他的大部分演講都包含了 Standish Group 在過去幾年中追蹤的統計數據。經常被引用的標題是，只有 28% 的 IT 項目實際上完全成功：49%「有挑戰」，23% 失敗。

當然，這種統計數據在很大程度上取決於成功的定義，重要的是 Standish Chaos 報告將成功定義為準時、準預算且具有預期功能的大部分。像大多數敏捷社群一樣，我對此提出質疑。對我來說，一個延遲且超出預算的項目是估計的失敗。一個項目可能會延遲，遠遠超出預算，但仍然是一個巨大的成功 - 就像 Windows 95 對 Microsoft 一樣。專案成功更多的是關於軟體提供的價值是否大於投入的資源成本 - 但這很難衡量。

吉姆引述的另一項有趣的統計數據是軟體產品中未使用的功能比例很高。他引述了兩項研究：杜邦研究引述系統功能中只有 25% 是真正需要的。Standish 研究發現 45% 的功能從未被使用，而只有 20% 的功能經常或總是使用。

這當然符合許多敏捷主義者的軼事證據，他們認為傳統的需求收集方法最終收集到的需求遠遠超過可用的版本真正需要的需求。我認為這也表明大多數專案的規模應該只有目前規模的四分之一。如果你也考慮到軟體規模不經濟，這表示許多團隊也應該小得多。

這一點在約翰遜比較兩個 SACWIS 系統時真正顯現出來。SACWIS 是美國所有州都必須實施的兒童福利系統。他表示，佛羅里達州於 1990 年開始其 SACWIS 系統，最初的成本估計為 3200 萬美元，預計於 1998 年交付，開發團隊約有 100 人。當他們最後查看時，新的成本為 1.7 億美元，預計於 2005 年交付。他指出，明尼蘇達州必須建立與佛羅里達州幾乎相同人口問題的相同功能，導致非常相似的廣泛系統需求。明尼蘇達州於 1999 年開始工作，於 2000 年完成，有八人，耗資 110 萬美元。

此比較是 Chet Hendrickson 所說「每個大型系統內，都有一個小型系統試圖脫穎而出」的驚人例證。我無法聲稱真正判斷造成這兩個系統在成本和努力上如此不同的細節。Standish 集團將差異主要歸因於明尼蘇達州在最小化需求方面更成功，同時也使用標準基礎設施。至少它非常具有啟發性，說明了透過專注於將需求簡化為其精髓，你可以獲得多少影響力。當然，敏捷論點是，基於價值的短暫反覆運算比事先需求收集練習更有可能最小化需求。在我們獲得任何真實數據之前，這將需要一段時間。

無論你是否認同此敏捷論點，我認為 SACWIS 故事表明，軟體產業在了解建置多小規模才能提供價值方面面臨非常實際的挑戰。它表明，僅透過建置我們需要的功能，我們就可以大幅降低軟體系統的成本。我的看法是，事先需求流程會對你產生不利影響，因為人們經常在不考慮成本的情況下檢視需求。我檢視過的需求手冊幾乎從未提及成本，以及在收集需求時了解成本的重要性。在我看來，沒有成本的需求文件幾乎可以保證建置過多，特別是如果它與固定範圍/固定價格合約相關聯，而這只會將不必要的支出固定到位。