敏捷開發框架下的軟體工程/第一階段/系統隱喻
| 系統隱喻 |
|
|
在第一階段,功能需求領域涉及我們討論對商業問題或機會的處理方式。我們透過系統隱喻來實現這一點。
隱喻是將兩個看似無關的主題進行比較。它們在語言中被用來使語言生動,鼓勵解釋,並在沒有直接術語或其他解釋過於繁瑣的情況下提供理解的工具。透過從另一個角度理解和體驗某件事,我們可以在真正理解我們正在談論的內容之前,提供一種探索概念的方法。
也許最著名的隱喻是莎士比亞的開場白
| “ | 整個世界都是一個舞臺 所有的男男女女都不過是演員 他們有自己的登場和退場 |
” |
— 如你所願 2/7 | ||
在日常對話中,我們說“振作起來”,“淹沒在檔案堆中”,“展開通往和平的路線圖”和“我的記憶有點模糊”。我們用來形容某事物的隱喻可能非常有啟發性。例如,我們用來描述商業的詞語通常基於戰爭隱喻:“敵意收購”,“失地”等等,而這些反過來又會影響企業的管理。雷·傑克遜(引用自執行長論壇)在討論商業實踐時,借鑑了軍事的經驗教訓
我認為它教會了我,世界永遠是不完美的,你的知識庫也是不完美的。在軍事行動中,你從字面上講,永遠不會擁有“全部事實”。因此,它教會你在不完整的資料下進行操作:利用你掌握的資料,將其轉化為資訊,並弄清楚你需要做什麼。我想我瞭解到,清晰比確定性更好:總會有一個時機,你會擁有足夠的資料來繼續前進。如果你等待確定性,它永遠不會到來。軍隊讓你適應不確定性。
我學到的另一件事是,不要拖延做決定,要果斷。你學習了一個不斷做出決定,然後根據新出現的更多資訊來審查這些決定的過程。這在商業上非常有用。
軍隊還教會你仔細管理資源。例如,在海軍任務中,你只有有限的燃料、有限的彈藥等等。當然,你最重要的有限資源是你的員工,因此你需要照顧他們並培養他們——你不能讓他們累死!軍隊教會你始終要非常注意你的資源以及如何才能最好地利用和節約它們。
我認為你也會學到很多關於領導力和溝通的知識。我喜歡“人們不希望被持續激勵,他們只想瞭解他們應該做什麼”這句話。
大多數軍人都有高度競爭性,具有“我們來這裡是為了勝利”的勁頭,因此他們擁有這種堅韌和奉獻精神。商業的某些方面就像戰鬥一樣,因此這些態度可能會有用。
另一個有用的態度是設定你的目標,然後不顧一切地追求它們。當然,戰爭和商業的目標不同。戰爭是為了戰勝敵人——這是一場零和遊戲。另一方面,在商業中,你的目標可能是成為最賺錢的公司。這並不是一個像戰勝敵人那樣需要戰勝敵人的目標——更像是實現你自己的目標。
(另請參閱營銷的機動理論,它明確地——並且有爭議地——使用了軍事/商業隱喻:“軍械庫——競爭性營銷人員的線上資源是“進攻藝術”的獨家主機——如何攻擊和驅逐更大的競爭對手”。)
拉科夫和約翰遜(1980)認為,我們透過隱喻生活。
在軟體開發中,系統隱喻被敏捷社群採納為核心實踐。極限程式設計解釋的作者肯特·貝克將系統隱喻定義為
“一個每個人——客戶、程式設計師和經理——都可以講述系統如何運作的故事。”第 179 頁。
Wake 認為,我們尋求系統隱喻有幾個原因
共同願景:使每個人都能就係統如何運作達成一致。隱喻表明了問題和解決方案的感知方式的關鍵結構。這可以使理解系統是什麼以及它可能是什麼變得更容易。
共享詞彙:隱喻有助於為物件及其之間關係提供一個通用的命名系統。這可以成為一個最好的意義上的行話:一個強大的、專門的、專家使用的簡寫詞彙。給某事物命名有助於你獲得對它的控制權。
創造性:隱喻的類比可以為系統(包括問題和解決方案)提供新的想法。例如,隱喻“客戶服務是一條裝配線”。這表明了將問題從一個組傳到另一個組以進行處理的想法,但它也提出了一個問題,“當問題到達生產線的末端時會發生什麼——它會掉下來嗎?”這可以揭示出可能隱藏和滋生的重要問題。
架構:隱喻透過識別關鍵物件並建議其介面的各個方面來塑造系統。它支援系統的靜態和動態物件模型。
另一個好處是通用性。我們可以使用隱喻在開發之間進行移動:“就像生菜專案一樣,但更像是一種灰水方法”是開發新專案時使用的真實句子。
選擇隱喻需要付出努力。希望在達成關於適當隱喻的共識時,你會經歷深刻而豐富的過程。這是過程中的重要部分,你應該嘗試識別和捕捉這些想法。Jefferies(2001)在一個關於基於代理的資訊檢索系統的生動描述中,描述了“這個程式就像一個蜂巢,出去採集花粉並將其帶回蜂巢”。雖然 Jefferies 沒有描述它們,但他們很可能首先嚐試了其他隱喻。也許“吸取所有知識的吸塵器?...不,有很多,而且資訊是有結構的——不只是一個大灰塵球,也許是圖書館?不,那是龐大而靜態的,我們想要的是選擇性地收集資訊的東西,就像車隊回收卡車......”。
一些隱喻在軟體開發中被反覆使用。一些常見的方法
1. 電子表格隱喻
2. 指令碼隱喻
3. 製造隱喻(例如 LinesStationsBinsParts 或 AssemblyLine)
4. 會計隱喻(雙入賬存檔符號)
5. 購物車隱喻(電子商務)
6. 拍賣隱喻(電子商務)
7. 黑板隱喻(人工智慧)
8. 文件處理器(桌面系統,其中“模型”被儲存為檔案)
9 虛擬空間隱喻(例如 VR)
10 桌面隱喻
11 工具和材料隱喻
12 按鈕無處不在的隱喻
13 人 - 一個人被僱用做這份工作會怎麼做?
(其他有時有用的隱喻:銀行、法院、報紙、農場、路線圖、警察人像識別)
在沒有人能想到合適的隱喻(有或沒有生動的意象)的情況下,方法是開發一個“樸素的隱喻”。這意味著你更直白地描述系統(學生管理系統將具有學生和註冊物件等)。這樣做的缺點是它實際上不是一個隱喻——你不會獲得任何更深入的理解或見解,因為它植根於你已經知道的東西。儘量避免“接近計算”的隱喻——像 CD 架這樣的概念過於接近計算,沒有用處。
過程
[edit | edit source]那麼,我們如何使用這個系統隱喻呢?對於一些敏捷的支持者來說,系統隱喻構成了大部分程式設計的基礎,隱喻的基調和主題直接轉化為類和模式。
我們採取了一種更輕便的方法。系統隱喻主要是在這裡討論第一次迭代的功能需求的工具。它也可能有助於激發對第二次迭代互動設計的思考。
隱喻應該用簡單的術語表達。正如 Ryan 所說:“系統是一家麵包店”比“系統將文字解釋為命令,並針對生成結果物件的構建器執行這些命令,並附加各種裝飾器,透過管道和過濾器將它們排序到正確的箱子中;使用者可以根據需要瀏覽和食用它們”更合適。(C2 2006)。
一旦你有了隱喻,訣竅就是探索它所有的特徵,將它們寫在紙上或白板上。這些想法將直接流向使用者故事或功能需求。
對於另一個專案,一個面向衝浪者的社群衝浪報告系統,一個單一的系統隱喻難以捉摸。然而,這個過程非常有用。當我們探索可能的系統隱喻時——報紙;無線電雪報告;學校通訊——這些為什麼不能有效地作為隱喻的原因有效地建立了我們系統特徵的列表。
技巧
[edit | edit source]hile 另一個隱喻可能更好,但隱喻不可能出錯,尤其是當你將其用作探索工具時。如果你意識到另一個隱喻更好,那麼很好,這意味著你在理解上取得了突破。
最糟糕的結果不是“錯誤”,而是隱喻成為誤解的原因。以下是 c2.com/xp wiki 中摘錄的內容
問問自己,這個難題更像什麼熟悉的事物?它真的像從豪華咖啡機裡點咖啡嗎?它真的主要像在湖上駕駛(迎風行駛)帆船嗎?從多倫多開車去巴黎? (...不到 90 分鐘的路程,因為巴黎就在布蘭特福德的對面。-- RandyMacDonald) (只是為了避免加拿大文化假設)
你是說肯塔基州的巴黎,對嗎?:) 也許是在寒冷的冬天走極地路線...
* 任何試圖透過刪除來清理它的人都沒有解決根本問題,所以我把它放回去了。下一個 WikiGnome:澄清從多倫多到巴黎的駕駛問題,或者暫時保留原樣。
不,最好保留!它非常漂亮地說明了細微的誤解是如何產生的。開發者一號說:“這就像開車去巴黎”,意思是短途旅行。開發者二號腦海中浮現出從英國到法國穿過英吉利海峽隧道的景象,並考慮如何避開火車。開發者三號(在美國)思考著潛艇汽車。這裡的誤解突出了在討論中,尤其是在關於系統隱喻這樣至關重要的事情的討論中,意義取決於上下文的重要性。-- BenLast
因此,我們必須小心,避免“錯誤的見解”。
在你放棄一個隱喻而選擇另一個隱喻之前,一定要捕捉到第一個隱喻的所有特徵——它們在規劃遊戲中仍然有用。此外,要記錄導致你改變隱喻的事情。隱喻中的錯誤之處可以和正確的之處一樣定義你的系統。
隱喻需要足夠熟悉,以至於需要使用它的人群能夠理解。說它是“一個針對碳排放的增值會計系統”可能對財務會計師來說是一個完美的隱喻,但如果程式設計師不理解這種會計方法,那麼它將起到混淆而不是啟迪的作用。
有時隱喻會限制理解。基於紙張的行和列的電子表格在電子表格的開發中是一個強大的模型(!),但從紙張到現代電子表格真正能力的概念飛躍非常大。這會導致引入“魔法”的風險:“它就像一個魔術白板”。雖然這有助於包含白板的所有基本功能,但系統的真正創新隱藏在“魔法”的外表之下。
我們還需要知道何時放棄隱喻。上面用冰箱門隱喻描述的專案管理開發也用汽車儀表盤描述過。這在早期階段作為系統隱喻非常有效:不顯眼但可以批判性地監控重要指標等,但在用作介面設計的基礎時變得笨拙(錶盤、帶皮革裝飾的轉向盤等)。
隱喻只有在你有機會發揮作用時才能發揮最佳效果。一旦你開始回到描述計算事物特徵(安全性、登入等),試著將你的思維提升到更抽象的隱喻。一種方法是考慮加強版的隱喻——超級 x 會是什麼樣子?但要小心,如上所述,你必須比“神奇的 x”更具體。
示例:儀表盤
[edit | edit source]|
小組:軟體工程 2006
儀表盤隱喻在開發專案管理系統(實際上是支援敏捷開發框架的系統)方面很有用。使用汽車儀表盤提供關鍵資訊的熟悉概念是思考專案組需要始終看到哪些資訊的有用方式;哪些事件會提示警示燈等等。一些團隊將隱喻延續到整個開發過程,它在嘗試混合向下鑽取以獲取更多資訊的概念(這不是汽車儀表盤通常的功能)時變得複雜。
|
如果你真的卡住了,那麼讓一個簡單的隱喻起作用的一種方法是考慮商業機會的隱喻(而不是資訊系統本身的隱喻。這在商業機會本身難以理解時可能特別有用。
http://en.wikipedia.org/wiki/Metaphor http://c2.com/xp/SystemMetaphor.html 最後更新於 2006 年 2 月 15 日 2006 年 7 月 24 日 檢視 Jackman, R. (2006) 商業是戰爭嗎?軍事事務能(不能)教給 CEO 什麼 http://www.ceoforum.com.au/200206_ceoinsight.cfm 檢視 2006 年 7 月 21 日 Jefferies, R. (2001) 什麼是極限程式設計 http://www.xprogramming.com/xpmag/whatisxp.htm 檢視 2006 年 7 月 21 日 Lakoff G. & Johnson, M. (1980) 我們所生活的隱喻 http://theliterarylink.com/metaphors.html Wake, W. (2000) 系統隱喻 http://www.xp123.com/xplor/xp0004/index.shtml 檢視 2006 年 7 月 21 日 Wake, W. (2000) 經過驗證的系統隱喻 http://c2.com/cgi/wiki?ProvenSystemMetaphors 檢視 2006 年 7 月 21 日 http://knowgramming.com/ http://twoscenarios.typepad.com/maneuver_marketing_commun/2005/05/military_metaph.html

