Java 建模：子整體軟體開發

	Java 建模：子整體軟體開發		英文原文

內容： 靈活軟體開發 過程是第一位嗎？ 子整體（holon） 子整體軟體 開發 培訓模型 沒有安全網的軟體開發 過程？什麼過程？ 結論 參考資料 關於作者 對本文的評價 相關內容： Java 建模系列所有文章 XP 精粹 以使用者為中心的設計 更多 dW Java 參考資料 宣言 Granville Miller (rmiller@togethersoft.com) 顧問和開發人員，TogetherSoft 2001 年 8 月 Granville Miller 暫時放棄需求收集主題，著手討論另一個引人入勝的主題：子整體軟體編程。 讓我們找找這個方法如何補充和擴充靈活開發運動原則，以及它在主流開發界中的出現如何可能改變軟體開發人員的教育和軟體開發實踐。請在討論論壇與作者和其他讀者分享您關於本文的想法。 在我早期專欄的結論中（請參閱參考資料），我曾確保此專欄將會專門討論靈活開發過程中需求收集的各種方法。然而，當我開始著手那個專欄時，我意識到可能值得從靈活軟體開發這個較大的討論開始。但當我開始著手那個主題時，我發現自己渴望去討論子整體軟體開發這個相關主題。 這並不奇怪，因為我相信子整體軟體開發是靈活軟體開發的下一步。我對此十分雀躍，我選擇改變我的路線，並且引入我非常獨特的子整體軟體開發宣言。我們將在下一次返回需求收集這個主題。 靈活軟體開發 靈活軟體開發運動對軟體工程的理論和實踐造成了巨大的衝擊。它的擁護者成功的挑戰和駁斥了實踐證明的優秀的系統開發準則，並用自己的來代替它們。 運動的基礎在於四個核心價值，在靈活軟體開發宣言中第一次對它們進行了概述 （請參閱參考資料）： 個人和互動優於過程和工具 有用的軟體優於綜合的文檔 客戶合作優於合約協商 對更改作出反應優於遵循計劃 實際上，這些價值標誌著對那些受傳統軟體開發方法支援東西的背離。最高目的在於建立一個更有益於成功的軟體開發環境。的確，靈活運動在軟體開發的曆史上留下了自己的印記。然而，雖然靈活運動具有革命性，但它畢竟只是更複雜更有益的開發實踐的第一步。 子整體軟體開發才是下一步。 過程是第一位嗎？ 在工業革命時期，Frederick Winslow Taylor 先生對人的工作方式進行了研究。 他進行了時間和動作的研究，目的在於最佳化身體技能的使用，有效創造產品。Taylor 的出名在於他對效率原則的執著。他著名的引述概括了他對工業時代工人的心情：“過去，人是第一要素，而將來，系統很可能會成為第一要素。” 效率的追隨和系統第一或者說過程第一原則是現在我們稱為品質管理的兩個基本組成部分。 品質管理就是研究和實現那些正確的實現就會提高品質的活動。關鍵詞是正確的實現。這些片語成了品質管理的安全港灣式表述。可以肯定的說如果您的業務、製造或工程實踐不能提高品質，您就沒有正確的實現它們。 雖然我不相信軟體開發中存在品質管理危機，但我的確看到了失敗正在我們的行業中產生。這些失敗往往是過程和技術造成的，理由在於過程沒有被正確實現或技術不成熟。不過我覺得把失敗歸咎於過程和技術常常是一種逃避。尤其當您考慮 Alistair Cockburn 的斷言 — 在成功的軟體開發中過程和技術是第二位要素（請參閱參考資料）的時候。 人是任何軟體開發項目的第一位要素。任何好的第一線管理員知道他或她的小組成員是項目首要和最有用的資產。一個永遠不會被取代的軟體開發準則是優秀的人編製優秀的軟體。不過，如果這樣的話，開發項目失敗時，我們該歸咎於人嗎？答案是否定的！ 子整體（holon） 我相信，尋找能反映優秀的軟體開發技巧的行為的最佳地方是不太可能的。只有戰場。對於導致單個士兵取得巨大成功最有用的兩個準則是訓練和主動性。最棒的軍隊允許單個士兵在戰鬥期間對於如何達到他們的目標作出決定。許多戰鬥勝利是通過許多士兵作為個體思考和行動、同時又作為團隊一起戰鬥而取得。 一個維持自身獨立性、同時又作為整體的部分發揮作用的實體稱為子整體（holon）。 這個術語是 Arthur Koestler 通過把詞整體（holos 或者說“the whole”）和部分（on 或者說“the part”）相結合而發明。子整體曾用於描述社會、細胞和組織的行為，還有最近的製造行為。我相信子整體的（holonic）行為是軟體開發人員實際的並且很可能是理想的工作方式。 事實是，在開發軟體時，我們繼續遵循了 Frederick Winslow Taylor 的思想。時間和動作的研究提出了學術上軟體工程周期的令人驚異的規律。然而，軟體開發，就像資訊時代許多其它要素一樣，已經和時間和動作無關了。與之相關的是創造、革新和人。 對於軟體開發，我們繼承了工業時代誕生的思想 — 死守著基於製造業的裝配線生產的思路和環境。在這個環境中，個人是成不了氣候的。 他沒有授權製造變革，也因此在要求變革的生命週期（軟體開發週期）失敗時，不該歸咎於他。或許，是時候停止把過程和技術作為第一位要素了，讓真正的第一位要素 — 人 — 作為中心。 子整體軟體 開發 軟體工程是一種手藝。它需要運用智慧。它的準則很複雜且需要知識。 最好的準則仍處於開發狀態。因為軟體工程領域如此廣博，沒有哪個人可以完全“掌握”它。還因為這一領域在不斷髮展，知識的保持需要不斷努力和學習。 如果您是個優秀的開發人員、建模者或管理員，您該知道我的意思。您曾面對多種技巧，然後例行公事的選出一種用於工作的最好的技巧。您在危機中調整並設法找出一種解決方案。您使子整體具體化。您需要一個在任何給定時刻指定您接著該做什麼的軟體開發過程嗎？根本不需要。 真正的子整體軟體開發組織承認不同的人有不同的思維方式。有些人的思維方式是抽象的、其他人是具體的；有些人是戰略上的計劃者，其他人則以行動為取向。子整體組織使用的技術使人們在選擇完最佳工作方法的同時共同工作。這些組織允許人們用他們發現的最佳方法工作。簡言之，子整體軟體開發要求不斷的學習和個體適應。它鼓勵差異。 培訓模型 我作出這些警告的斷言 — 我們的培訓沒有像它應該的那樣成熟。與之相比，士兵的訓練可以回溯到幾千年前（最保守估計）。它已經發展成熟了許多個世紀。新的技術改變了我們作戰的一些方法。但戰爭的很多基本模式沒有因技術的改變而改變，士兵的訓練也是如此。在我們接納技術上的改變時，還要適應這些永恒的教訓。 有效戰鬥訓練的一半是提供士兵一個可供選擇的戰役戰術庫。另一半涉及到教它們隨著訓練創造出自己的戰術。 同樣，我要鄭重宣布軟體開發人員有效教育的一半在於知識和技能的獲得。 另一半在於學習對變化進行處理、在不斷變化的領域中快速前進。簡言之，去革新。 沒有安全網的軟體開發 許多軟體開發過程幾乎不提供安全網。有些人提議重複過程自身，就好像不斷重複查看同一個狀態圖最終就會得到更多資訊一樣。重複我們的助診檔案可以改善它們，但只有引入反饋方法後才生效。當有必要知道我們在何處有可能誤入歧途時，簡單的重複是不夠的。 補充活動 一種可以結合進來以糾正預期錯誤的活動正成為一種成長趨勢。這種活動稱為 補充。例如，我們用域分析權衡用例建模以確保隨後的物件模型不起作用。這些補充性的活動可以讓我們不犯常見錯誤。 沒有了補充活動，第二位要素如過程和技術成為我們唯一的安全網；如果我們陷入困境，我們可以歸咎於它們。因為大多數軟體開發過程最多隻有兩維，或許這種歸咎是它們應得的。的確，除了給我們控制的感覺，過程再無其它用途，它是一張虛假的安全網。 過程？什麼過程？ 這是不是意味著您可以拋掉軟體開發過程並真的在沒有安全網的支援下開發呢？ 除非您有準備接受項目失敗的責任。 在另一方面，如果您沒有在適應，您就不會嘗試做事情的新方法。如果您不嘗試新的東西，您就不會學習、發展並成為最優秀的。這是個不斷探索的過程，我們中沒有哪一個人有可能在任何時候立刻完成。 即使您選擇了已建立過程的安全網，您也不一定在完全的遵循它。除非小組的每個人的想法相同才不會這樣。如果您的確找到了小組中每個人都覺得最佳並適用於您所從事的所有項目的終極過程，請發送給我。然而，我並不期待收到許多滿足上述條件的過程，因為 Jacobson 定律表明這種過程不存在。我相信即使在高度團結的小組中，也沒有哪個過程會適合每個人的思考方式。我們之間存在著太多的差異。 結論 子整體軟體開發是靈活運動的邏輯擴充。它需要高度理解用於編製軟體的技術，還需要開發人員對交付使用系統負責。子整體軟體開發小組把過程用作指南，而不是支柱。 該小組並不墨守成規，或者說當常識起支配作用時忽略過程。 本文不是一篇定義，而是宣言。其中提出了一種較好的交付使用軟體系統方法的見解，此方法利用許多靈活過程中定義的活動。同樣，我考慮了軟體開發的最佳準則和作為開發期間糾正錯誤方法的緊迫的補充活動。 我們將在下一專欄繼續討論這個主題，其中我們會返回已確保的關於用例、功能和使用者劇本的討論。我將向您展示如何讓這些元素成為您子整體軟體開發工具箱的一部分，並且還將描述這些元素如何支援一種前載的、平衡的或後載的編製軟體方法。請別離開。 參考資料 請參與有關本文的討論論壇。 有關前載與後載軟體開發過程對比的討論，請參閱 Granville Miller 的文章 “Sizing Up Today's Lightweight Software Processes”（IT Professional，2001 年）。 在 Agile Alliance 首頁您會找到“靈活軟體開發宣言”（Manifesto for Agile Software Development）。 Alistair Cockburn 的首頁反映了他對於靈活軟體開發的個人討論（還有他將於 2001 年後期由 Addison-Wesley 出版社出版的書的預先介紹）。 另一個靈活過程，極端編程（Extreme Programming）得到了重大關注。Role Model Software 的開發人員 Roy Miller 和 Chris Collins 在他們的文章 XP 精粹（developerWorks，2001 年 3 月）中提出了綜合的 XP 概述。 有關 holinic 的一些準則的概述，請參閱研究論文“子整體製造系統（Holonic Manufacturing Systems）”（由康乃狄克大學電子和系統工程系的 Peter B. Luh 和 Ling GouDepartment 撰寫）。 智能製造系統（Intelligent Manufacturing Systems）已成功的在整個製造行業推廣了子整體的思想。 Intelligent Systems Group 是卡爾加裡大學機械和製造工程系和電腦科學系的合作小組。這個小組的研究目標是為了開發合作代理或者說子整體的體繫結構、工具及示範系統。 IBM 的 以使用者為中心的設計首頁提出在大規模軟體開發環境中如何規劃和發展最佳準則的有意思的初步認識。 IBM 和其他行業領先者建立了 XMI，一種新的、結合 XML 和 UML 優點的開允許存取業標準。 請閱讀 Java 建模專欄所有部分。 可以在 developerWorks Java 技術專區找到更多 Java 參考資料。 關於作者 Granville 對於物件導向社區已經有十幾年的經驗了。他是進階用例建模系列的合著者，並在全世界範圍的各種物件導向技術會議中介紹過教程。他的物件導向開發的實踐方法來自於他在多家公司供職的經驗，其中包括從處於創業階段的公司到相當成熟的軟體業巨人在內的各種公司。他目前正在教授有關靈活過程、方法和 Java 技術的研習班、教程和課程，同時還在輔導和協助實現一些有作為的項目。請通過 rmiller@togethersoft.com 與 Granville 聯絡。