Ward Cunningham 是誰？WikiWikiWeb、軟體模式與協作文件

Ward Cunningham 是程式設計師與軟體設計思想家，建立 WikiWikiWeb，並參與把軟體模式與團隊協作方法帶進工程社群。他的核心貢獻不是「發明一個可以編輯的網站」而已，而是讓文件變成可連續修改、互相連結、由使用者共同維護的工作空間。

如果要理解 Cunningham，應把 Wiki、模式與敏捷協作放在同一條線上：團隊如何把經驗寫下來、如何讓別人補充、如何在需求變動時保留脈絡，而不是只把文件當成最後交付物。

先講結論：Ward Cunningham 建立 WikiWikiWeb，並把軟體模式、協作文件與敏捷回饋放在同一條工程脈絡中；他的重點不只是可編輯網站，而是讓知識能被低摩擦更新、連結、修正並留下決策脈絡。

Q：Ward Cunningham 主要貢獻是什麼？ A：他建立 WikiWikiWeb，並參與把軟體模式、協作文件與團隊回饋方法帶進工程社群。

Q：WikiWikiWeb 改變了什麼？ A：它讓使用者能直接建立、修改與連結頁面，使文件從一次交付物變成可持續更新的共同工作空間。

Q：Wiki 的價值不只是多人共編嗎？ A：更重要的是低摩擦更新、連結脈絡與快速修正，讓團隊能在問題出現時留下經驗，而不必等專案結束才整理。

Q：軟體模式是什麼？ A：它把反覆出現的設計問題、適用情境、取捨與可能解法寫成可討論的共同語言，幫助團隊比較經驗而非盲目複製答案。

Q：Wiki 和敏捷協作有何關係？ A：敏捷方法重視短週期回饋，Wiki 式文件能記錄決策和經驗演進，但不能取代測試、審查、排程與正式責任。

Q：協作文件如何避免失控？ A：需要版本、負責人、審查規則、狀態標籤與爭議紀錄，否則頁面雖容易編輯，內容卻可能變成無法信任的筆記堆。

Q：哪些內容適合放進 Wiki？ A：常變動的知識、問題解法、設計討論與連結索引適合；法律、資安、正式政策等內容仍需核准版本與權限。

Q：Wiki 式文件有哪些限制？ A：開放編輯不會自動帶來正確性、完整性或安全性；團隊仍需查證來源、標示狀態、保留歷史並管理敏感資訊。

Q：圖片與文章的關係是什麼？ A：圖片是 Ward Cunningham、Wiki、軟體模式、協作文件與敏捷回饋的主題路線圖，不是 WikiWikiWeb 的原始介面截圖。

先看 5 個重點

WikiWikiWeb 讓使用者能直接建立與修改互相連結的頁面。
Wiki 的價值在低摩擦更新與連結脈絡，不只是「多人共編」。
軟體模式把反覆出現的設計問題、情境與取捨寫成可討論的語言。
協作文件必須保留版本、責任與爭議，否則容易變成無法信任的筆記堆。
敏捷方法重視短週期回饋，Wiki 式文件可以成為回饋的一部分，但不能代替測試與決策。

Ward Cunningham 做了什麼？

Cunningham 建立 WikiWikiWeb，並在軟體模式、物件導向設計與團隊協作方面留下影響。Computer History Museum 的人物資料與 WikiWikiWeb 本身，是理解他的工作與技術脈絡的直接來源；Agile Alliance 則提供敏捷原則的現代背景。

WikiWikiWeb 的重要性不在於頁面看起來簡單，而在於它把「寫作」和「導航」結合起來。讀者看到一個概念，可以直接建立連結、補充案例或建立新的討論頁；知識不必先被整理成封閉的目錄，才有機會被使用。

Wiki 如何讓文件一起長大？

傳統文件常由一個作者或小組在最後階段完成，讀者多半只能提出一次性修改。Wiki 把文件拆成許多可以互相連接的頁面，讓新增內容、修正錯誤與追問脈絡都能在同一個工作區發生。

但低摩擦不等於不需要治理。團隊仍要決定哪些頁面是規範、哪些只是討論；如何標註過時內容；誰負責處理衝突；以及刪除或回復修改時要保留什麼證據。沒有這些規則，Wiki 會從共享記憶變成無人維護的資訊噪音。

軟體模式為什麼重要？

模式不是一段可以直接複製的程式碼，而是對反覆出現問題的命名與描述。好的模式會說明使用情境、限制、取捨、常見錯誤與可替代方案，讓團隊能討論「這裡是否適用」，而不是盲目套用名詞。

這種寫法也解釋了 Wiki 與模式為什麼互相適合：模式需要被補充案例、修正限制與連到其他模式；Wiki 提供了讓這些知識持續演進的介面。文件不再只是結果，也成為設計推理的歷史。

Wiki 和敏捷協作的關係

敏捷工作重視可運作的軟體、短週期回饋與團隊溝通。Wiki 可以承接這些回饋：把決策、需求變更、技術債、測試結果與未解問題放在可搜尋的脈絡裡，降低每次交接都要重新口頭解釋的成本。

不過，Wiki 不是敏捷的同義詞。敏捷仍需要可驗收的需求、可重跑的測試、清楚的優先級與責任。若團隊只增加文件頁面，卻沒有把內容連到程式、issue、release 與決策，文件量增加不代表協作品質提高。

今天如何使用 Wiki 式文件？

在工程團隊裡，可以把 Wiki 當成三種東西：第一是概念地圖，連接服務、資料表與責任人；第二是決策紀錄，說明為何選擇某個方案；第三是可更新的操作手冊，列出部署、回復與排錯步驟。

每一頁最好回答四件事：它解決什麼問題、目前狀態是什麼、誰負責更新、下一次如何驗證。對高風險流程，還要記錄最後檢查日期與回復方式。這些欄位讓文件具有可維護性，而不是只在新人加入時被讀一次。

常見誤讀與限制

第一，Wiki 不等於 Wikipedia；前者是協作技術與工作方式，後者是其中一個大型公共百科實例。

第二，開放編輯不代表所有內容都同樣可信。版本歷史、審閱規則與來源標記仍然重要。

第三，模式不是銀彈。模式提供共同語言，但實際設計仍要依團隊規模、效能、資料敏感度與維護成本判斷。

FAQ：Wiki 與工程文件

Ward Cunningham 最重要的貢獻是什麼？

可以概括成「讓知識能被快速寫下、連結、修改與共同維護」，並把這種協作精神帶進軟體設計語言。

Wiki 適合放正式規範嗎？

適合，但要區分草稿、決策與正式規範，並保留版本、審閱者與生效日期。

文件怎麼避免越寫越亂？

建立頁面命名、責任人、過時標記、連結規則與定期清理；最重要的是讓文件和實際程式、測試與工作流程互相引用。

官方資料與延伸閱讀

官方資料：WikiWikiWeb 改變的是文件的編輯權

Ward Cunningham 建立的 WikiWikiWeb 官方頁面說明，這個網站與軟體是為 Portland Pattern Repository 製作；讀者可以修改頁面或建立新頁面，內容由使用者共同書寫。這個設計重點不是「把文章放上網」，而是讓文件在閱讀、修改與討論之間持續演進。

Cunningham 在 C2 的詞源說明也把 wiki 一詞、快速編輯與 1995 年的網路軟體脈絡連起來。這能幫助讀者區分三件事：WikiWikiWeb 是一個具體系統，軟體模式是整理可重複設計經驗的方法，而敏捷協作則是更大的團隊工作脈絡，三者不能直接畫上等號。

判斷協作文件是否真的可演進

編輯門檻：新參與者能否快速修正一個小錯誤？
歷史可追溯：團隊能否知道某個決定如何形成？
衝突處理：不同版本的內容如何被比較與協商？
維護成本：頁面變多後，分類、搜尋與責任如何運作？

延伸閱讀與來源

WikiWikiWeb 的建立者、協作機制與原始頁面參考 C2 的 WikiWikiWeb 說明；「wiki」命名與 1995 年背景參考 C2 的詞源紀錄。若想比較文件協作與演進式設計，可延伸閱讀 YOLO LAB 的 Martin Fowler 重構分析與 Tim Bray Web 標準分析。

Ward Cunningham 是誰？WikiWikiWeb、軟體模式與協作文件