跳轉至內容

敏捷開發框架下的軟體工程/第一階段/系統隱喻

來自華夏公益教科書,開放的書籍,開放的世界
系統隱喻


透過參考熟悉的事物或概念來描述系統

2 小時

與客戶第一次會議的筆記

註釋筆記

與客戶討論

什麼是隱喻?

[編輯 | 編輯原始碼]

在第一階段,功能需求領域涉及我們討論對商業問題或機會的處理方式。我們透過系統隱喻來實現這一點。

隱喻是將兩個看似無關的主題進行比較。它們在語言中被用來使語言生動,鼓勵解釋,並在沒有直接術語或其他解釋過於繁瑣的情況下提供理解的工具。透過從另一個角度理解和體驗某件事,我們可以在真正理解我們正在談論的內容之前,提供一種探索概念的方法。

也許最著名的隱喻是莎士比亞的開場白

整個世界都是一個舞臺

所有的男男女女都不過是演員

他們有自己的登場和退場

— 如你所願 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)。

一旦你有了隱喻,訣竅就是探索它所有的特徵,將它們寫在紙上或白板上。這些想法將直接流向使用者故事或功能需求。


案例研究 專案管理軟體

小組:軟體工程 2006


對於開發專案管理和團隊協作工具的專案,冰箱門隱喻很有用


  • 總是存在(你無需開啟它就能找到資訊),
  • 家庭留言(彼此之間,電話留言)
  • 日曆(今天,安排,即將發生的事件)
  • 購物清單
  • 安全帶(防止偷吃巧克力的小偷)
  • 靈感(“你需要那塊巧克力嗎?”貼紙)
  • 進度圖表(體重增加/減少)
  • 家庭清潔/烹飪輪班表
  • 當前工作(尤其適用於年輕人,已命名且有時標有日期的草圖)
  • 文件庫(音樂票,待付賬單) - 有趣地分層!
  • 可重新配置(資訊透過冰箱磁鐵固定在一起)
  • 教學角色(字母介紹單詞和資訊給小孩子)。
  • 星圖(孩子的行為管理,行為合同和獎勵)。
  • 公共場所,
  • 中心位置:我們作為正常生活(工作)流程的一部分經過它(但不會跳出來打擾)
  • 成就(孩子的學校證書)
  • 家庭照片(自己和親戚/嬰兒照片)
  • 報紙剪報
  • 空間有限,必須管理資訊以避免因雜亂無章而丟失(但這無需任何規則、設計或經理)(注意,我在這裡寫了“它這樣做”,門本身當然除了充當靜態儲存庫之外什麼也不做,是家庭積極管理資訊)。
  • 電話號碼(家庭/朋友/醫生等)
  • 比薩店選單/電話號碼

...並且在不影響真正工作的情況下完成所有這些事情(保持食物冷藏——我們的系統絕不能妨礙專案的進行)。這個專案的另一個隱喻是汽車儀表盤(見下文),另一個是圖書館。



對於另一個專案,一個面向衝浪者的社群衝浪報告系統,一個單一的系統隱喻難以捉摸。然而,這個過程非常有用。當我們探索可能的系統隱喻時——報紙;無線電雪報告;學校通訊——這些為什麼不能有效地作為隱喻的原因有效地建立了我們系統特徵的列表。

技巧

[edit | edit source]
W

hile 另一個隱喻可能更好,但隱喻不可能出錯,尤其是當你將其用作探索工具時。如果你意識到另一個隱喻更好,那麼很好,這意味著你在理解上取得了突破

最糟糕的結果不是“錯誤”,而是隱喻成為誤解的原因。以下是 c2.com/xp wiki 中摘錄的內容

問問自己,這個難題更像什麼熟悉的事物?它真的像從豪華咖啡機裡點咖啡嗎?它真的主要像在湖上駕駛(迎風行駛)帆船嗎?從多倫多開車去巴黎? (...不到 90 分鐘的路程,因為巴黎就在布蘭特福德的對面。-- RandyMacDonald) (只是為了避免加拿大文化假設)

你是說肯塔基州的巴黎,對嗎?:) 也許是在寒冷的冬天走極地路線...

* 任何試圖透過刪除來清理它的人都沒有解決根本問題,所以我把它放回去了。下一個 WikiGnome:澄清從多倫多到巴黎的駕駛問題,或者暫時保留原樣。

不,最好保留!它非常漂亮地說明了細微的誤解是如何產生的。開發者一號說:“這就像開車去巴黎”,意思是短途旅行。開發者二號腦海中浮現出從英國到法國穿過英吉利海峽隧道的景象,並考慮如何避開火車。開發者三號(在美國)思考著潛艇汽車。這裡的誤解突出了在討論中,尤其是在關於系統隱喻這樣至關重要的事情的討論中,意義取決於上下文的重要性。-- BenLast

因此,我們必須小心,避免“錯誤的見解”。

在你放棄一個隱喻而選擇另一個隱喻之前,一定要捕捉到第一個隱喻的所有特徵——它們在規劃遊戲中仍然有用。此外,要記錄導致你改變隱喻的事情。隱喻中的錯誤之處可以和正確的之處一樣定義你的系統。

隱喻需要足夠熟悉,以至於需要使用它的人群能夠理解。說它是“一個針對碳排放的增值會計系統”可能對財務會計師來說是一個完美的隱喻,但如果程式設計師不理解這種會計方法,那麼它將起到混淆而不是啟迪的作用。

有時隱喻會限制理解。基於紙張的行和列的電子表格在電子表格的開發中是一個強大的模型(!),但從紙張到現代電子表格真正能力的概念飛躍非常大。這會導致引入“魔法”的風險:“它就像一個魔術白板”。雖然這有助於包含白板的所有基本功能,但系統的真正創新隱藏在“魔法”的外表之下。

我們還需要知道何時放棄隱喻。上面用冰箱門隱喻描述的專案管理開發也用汽車儀表盤描述過。這在早期階段作為系統隱喻非常有效:不顯眼但可以批判性地監控重要指標等,但在用作介面設計的基礎時變得笨拙(錶盤、帶皮革裝飾的轉向盤等)。

隱喻只有在你有機會發揮作用時才能發揮最佳效果。一旦你開始回到描述計算事物特徵(安全性、登入等),試著將你的思維提升到更抽象的隱喻。一種方法是考慮加強版的隱喻——超級 x 會是什麼樣子?但要小心,如上所述,你必須比“神奇的 x”更具體。




示例:儀表盤

[edit | edit source]
案例研究 儀表盤

小組:軟體工程 2006


儀表盤隱喻在開發專案管理系統(實際上是支援敏捷開發框架的系統)方面很有用。使用汽車儀表盤提供關鍵資訊的熟悉概念是思考專案組需要始終看到哪些資訊的有用方式;哪些事件會提示警示燈等等。一些團隊將隱喻延續到整個開發過程,它在嘗試混合向下鑽取以獲取更多資訊的概念(這不是汽車儀表盤通常的功能)時變得複雜。



案例研究 與達芬奇對話

小組:克里斯蒂·傑克遜和喬納森·昂格,奧塔哥博物館


達芬奇會說話的機器人頭是一個有性格的互動式機器人。機器人可以接受語音並進行回應。它主要針對兒童設計,能夠教育使用者瞭解達芬奇的作品和生活。

當有人啟用感測器時,達芬奇會向訪客打招呼。他可以談論四個主要主題:藝術、歷史、機器和科學。這個專案與設計人員合作,他們正在製作實際的頭部。



align="left"


對於這個專案,使用了演員隱喻

  • 向觀眾致敬。
  • 表演一個場景
  • 演員可以說話、唱歌、跳舞和使用手語
  • 將戲劇的想法和概念傳達給客戶
  • 展現幽默感
  • 時尚和風格的展現
  • 擁有具有不同情感的性格和角色
  • 與觀眾進行口頭和非語言交流的技巧。
  • 他/她可以成為公眾的道德榜樣。
  • 反映生活現實給觀眾。
  • 觀眾也可以體驗到其中涉及的不同情緒,
  • 比如恐懼、喜悅、平靜、悲傷、焦慮、快樂。
  • 促進商業冒險。
  • 提供一種逃避/幻想的方式
  • 提供娛樂、知識和欣賞感
  • 提供資訊以進行教育。
  • 演員可以代表名聲。

這個隱喻有助於我們理解這個系統,因為它展示了我們在開發系統時需要考慮的特徵。



商業機會的隱喻

[編輯 | 編輯原始碼]

如果你真的卡住了,那麼讓一個簡單的隱喻起作用的一種方法是考慮商業機會的隱喻(而不是資訊系統本身的隱喻。這在商業機會本身難以理解時可能特別有用。

案例研究 eLivingCampus

小組:軟體工程 2008


小組首先為整個專案開發了隱喻

  • 咖啡杯:好的內容、可回收、標誌、勵志名言、
  • 百科全書:儲存資訊、索引、圖片、摘要、可搜尋、定期更新、準確、線上和紙質版
  • 活生物體:動態的、輸入/輸出、條件、智慧的、提供想法、
  • 路線圖:資訊根據需要一目瞭然地進行邏輯組織,還可以找到詳細資訊、圖例和關鍵結構、移動、很好地轉換為數字(移動 GPS 等)、可摺疊(以突出顯示感興趣的區域)。
  • CD 架:可以容納大量資訊、可以由使用者分類、可擴充套件、資訊可以進行取樣、

其中一些隱喻過於接近於計算。例如,百科全書和 CD 架並沒有真正提供新的見解——它們描述了任何通用的計算機系統。

也許是因為 Living Campus 本身並不是學生以前遇到過的事情,所以我們改變了策略,開始思考 Living Campus 本身的隱喻。哪些熟悉業務(或機構或流程)的特徵可以用來幫助思考 Living Campus——然後,這些隱喻的資訊需求是什麼?

align="left"

Living Campus 資訊基礎設施專案得益於對其他業務的資訊需求的思考

  • 戰時宣傳:有選擇地積極、組織良好、緊迫感、有針對性的資訊、持續廣播
  • 奧運會:複雜的網路、許多不同的需求、結果和其他媒體的即時整合、針對不同市場定製、自豪、競爭、不同級別的贊助商、嵌入整個的標誌
  • 公司營銷:標誌、聯絡方式、客戶描述、推薦信、展示創新、獲得關注需要創新、案例研究
  • Count Calendar(紐西蘭長期執行的農業電視節目):與農業相關,但大多數觀眾不是農民,教育與娛樂相結合、敘事、更多資訊、贊助、風格
  • 綠色和平組織:尋求頭條新聞,但有證據支援、道德制高點、
  • 建築開發:計劃、許可證、“這裡發生了什麼?“、工程建模、效果圖。
  • 博物館:教育與娛樂相結合、展品、類別、必須正確(雖然要注意使用者理解的重要性)、可能很無聊、漫遊、混合觀眾、可變、風格、互動、樂於助人的工作人員
  • 美術館:(博物館+)、佈局、精英化、活動、解說資訊、資料庫、目錄、館藏、開幕、儲存、
  • 動物園:餵食時間、繁殖計劃、動物和遊客行為管理、學校旅行預訂、禮品店、保護、籌款、天氣、季節性
  • A&P 展覽:以社群為導向的社會、得到其他社會支援、學校參與、競賽、社群參與、戶外(一些展覽館)、天氣應急措施、活動、展示社群、動物和植物、商業攤位、適合所有人、營銷、本地化但區域和國家結構、獨特的人物、互動、委員會結構、



參考資料

[編輯 | 編輯原始碼]

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

華夏公益教科書