逃避方法論的監獄 - Ivar Jacobson

1.什麼是方法監獄
讓我們看一下用於擴充套件敏捷的四種最著名的方法（稱為方法框架）：Scaled Agile Framework（SAFe），Scaled Professional Scrum（SPS），Disciplined Agile Delivery（DAD）和Large Scrum（LeSS） 。

它們都受到世界各地組織的歡迎和使用。它們以重疊的方式和特定的方式為其使用者組織提供價值。重疊意味著它們包含相同的實踐，具體意味著它們具有一些可以產生差異的特殊實踐。如果組織採用這些方法中的一種，則其使用者通常不瞭解其他替代方案。

那麼問題是什麼？
它們都是單片的 - 非模組化的。

大多數方法（不僅僅是這裡討論的四個方法）是單片的，意味著它們不是以模組化方式設計的。這意味著您無法輕鬆地將一個模組與另一個模組交換，並保持其他模組不變。

相反，我們想要的是一個可重用模組庫，隨著使用者學習越來越多而不斷更新。由於每種方法都只是實踐的組合，我們需要可重用的實踐。團隊和團隊團隊應該能夠透過混合和匹配他們想要從庫中使用的實踐並將它們組合在一起，輕鬆地就自己的方法達成一致。

2.     他們有自己獨立的演講風格。
每種方法都有其獨特的特定結構，並使用自己的風格和術語來描述其選擇的實踐。該方法的所有者已經為自己決定了這些重要方面，而沒有遵循任何標準。因此，其實踐與其他方法的實踐不相容。

3.     他們有很多共同點-但是隱藏的。
此外，儘管每種方法都有一些獨特的實踐，但它與其他方法有很多共同之處。每種方法都“借用”其他方法的實踐並“改進”它們。因此，常見的是隱藏在新術語和“新”功能背後。我們使用引號來表明它並不是真正的“借用”，它並不總是“改進”，但由於對原始實踐的誤解或重新解釋，它常常變成原始的變態或混淆。同樣地，“新”特徵通常不是全新的，而是用於演變或改變先前存在的實踐的新名稱（“裝舊酒的新瓶”）。

4.     每一個方法是有一個控制監獄長 - 大師
Master決怎麼做，並在某些情況下，擴充套件實踐，並“借用”其他方法“改良”的方法。該方法反映了其大師的特殊觀點，偏見和經驗，而不是我們作為發展社群共同學習的內容。方法應該重用團隊或組織針對其特定挑戰和目的考慮的最佳實踐，而不是獨立於這些考慮因素的單個大師選擇的那些方法。

5.     每種方法都有品牌標識，通常是商標和版權。
如果其使用者喜歡其他方法的做法，則被迫“借用”這些做法並“改進”可能被重複使用的內容。相反，這種工作方式並不能激發與其他大師的合作。鑑於這些其他方法的大師對時間和資本的投入，他們必須以狂熱的決心捍衛他們的地盤，導致方法戰爭。

因此，採用一種方法 - 已釋出或自行開發 - 意味著你會被一塊巨石所困，它以其獨特的風格，使用許多常見的但卻不知道的做法，由一位為其方法打上烙印的大師守衛使其難以重複使用。您的方法無法輕鬆地重用全域性實踐庫中的實踐。相反，你陷入了一個方法監獄。
你一直堅持跟隨你的方法大師決定事情。在這裡要清楚，我們並不是說大師們有意識地試圖讓你進入方法監獄; 他們只是繼續做我們作為一個行業自我們起源以來所做的事情，因為我們不知道更好的事情。

因此，一旦你採用了一種方法，你就處於由該方法的大師控制的方法監獄中。Ivar Jacobson是本文的作者之一，他曾經是統一流程監獄的大師之一。他意識到這是“世界上最愚蠢的事情”（當然還有軟體世界），它不值得任何行業，特別是像軟體行業這樣龐大的行業。最近其他人也表達了類似的想法。

作為軟體專業人士，我們需要制止這種荒謬的發展。我們希望具有創造性實踐想法的人們進行協作，並共同為全世界提供可重複使用的實踐庫。我們希望他們為整個行業服務，而不是被迫建立品牌方法。 

2.方法和方法監獄的歷史
曾幾何時，我們有大量不同的符號來描述軟體工程中的元素。然後我們在1997年獲得了統一建模語言（UML）標準，並且所有這些不同的符號都被一個標準所取代 - 符號戰結束了。符號只是方法的一個方面，因此我們需要一個類似的方法用於方法的所有其他方面，這是一種允許方法所需的所有多樣性的標準。
軟體行業遵循從正規化到正規化以及從方法到方法的曲折路徑。

1. 隨著每一個主要的正規化轉變，例如從結構化方法轉向物件方法，從後者轉向敏捷方法，基本上整個行業都拋棄了他們對軟體開發的幾乎所有知識，並重新開始，新的與舊的術語。舊的做法被視為垃圾，新的做法被炒作。透過培訓，指導和工具的形式，使軟體行業從舊到新的轉變成本極高。
2. 隨著每一項重大的新技術趨勢，例如面向服務的架構，大資料，雲端計算，物聯網，方法作者也“重新發明輪子”。他們創造了新的術語和新的實踐，即使他們可以重用現有的術語。成本不像前一點那麼大，因為有些變化並不是我們所做的一切都是根本性的，因此影響僅限於雲開發，但仍然存在重大而愚蠢的浪費。

• 1960-1980：結構化方法時代，
• 1980-2000：物件方法時代，
• 2000年 - 現在：敏捷方法時代

敏捷方法時代
敏捷運動 - 通常被稱為“敏捷” - 現在是軟體開發中最受歡迎的趨勢，並被全世界所接受。敏捷運動將重點從技術實踐上轉移開來，將團隊，工作和人員放在首位和中心位置。 
雖然聽起來很奇怪，但在之前的時代採用的方法並沒有過多關注人為因素。當然，每個人都理解該軟體是由人們開發的，但很少有關於如何讓人們在開發優秀軟體方面獲得積極性和能力的書籍。最成功的方法書在這個主題上非常沉默。基本上假設這是管理層的任務。隨著敏捷，許多新人的實踐開始發揮作用，例如自組織團隊，結對程式設計，每日站立。
鑑於敏捷對程式設計師賦權的影響，很容易理解敏捷已經變得非常受歡迎並且是最新的趨勢。此外，鑑於敏捷對我們軟體開發的積極影響，毫無疑問它應該成為最新趨勢。而且，雖然一些敏捷實踐將被其他更好的實踐所取代，但敏捷作為一種哲學和態度並不是一種會消失的時尚。在可預見的未來，它將與我們同在。

雖然不同的時代已經貢獻了知識和經驗，並且其中很多都是針對每個時代的，但它們都導致了由少數大師控制的方法戰爭的延續。

3.如何逃脫方法監獄
大多數方法包括（或暗示）生命週期，技術實踐和人員實踐有一些共同點。然而，這是隱藏的並且不容易被發現，因為不同的大師使用不同的詞彙和語言來描述這些事物。因此，我們尋找的共同點包括詞彙和語言。我們將詞彙稱為核心，將語言稱為核心語言。

共同點=核心+語言=本質

從核心開始
鑑於核心旨在幫助描述方法和實踐，它需要包含在任何方法中始終普遍存在或應該被視為“事物”。從本質上講，我們始終擁有的東西，在開發軟體時總能做到並始終產生。

在2009年，SEMAT社群成立，其任務是“重新發現軟體工程...... [1]包含廣泛認可的元素核心，這些元素可以針對特定用途進行擴充套件”，我們SEMAT志願者團隊（來自世界各地的約20人）與核心合作，同意這些事情稱為普遍性應該是“適用的，無論開發中的軟體的大小或規模，以及參與開發的團隊的規模，規模或風格”。“從本質上講，它提供了一個獨立的實踐框架，用於思考和推理我們所擁有的實踐和我們需要的實踐。核心的目標是建立對軟體開發核心內容的共同理解。“  

作為2010年尋找核心工作的輸入，SEMAT的三位創始人（Ivar Jacobson，Bertrand Meyer和Richard Soley）撰寫了一份願景宣告。我們三個人都明白，找到核心需要遵循標準和原則。我們首先就內容中包含元素的一些標準達成一致。

要素應該是：普遍的，重要的，相關的，確切的，可操作的，可評估的和全面的。  

相關內容被解釋為“所有軟體工程師都可以使用，無論背景和方法陣營（如果有的話）”，並且“ 全面地”適用於核心元素的收集; 他們必須共同掌握軟體工程的本質，提供支援軟體工程團隊關鍵實踐，模式和方法的地圖“。

我們還確定了以下被認為對於查詢核心至關重要的一般原則：質量，簡單性，理論，現實性和可擴充套件性，理由，可證偽性，前瞻性觀點，模組性和自我改進。

理論意味著“核心必須依靠堅實，嚴謹的理論基礎”，現實性和可擴充套件性“核心應適用於實際專案，包括大型專案，並儘可能基於成熟的技術”，自我改進 “核心應該是伴隨著促進其自身發展的機制“。

此外，願景宣告還闡述了核心應具備的功能：實踐獨立性，生命週期獨立性， 語言獨立性， 簡潔 性， 可擴充套件性，可擴充套件性和正式指定。可擴充套件性得到解釋，因為核心必須支援最小的專案 - 一個人為一個客戶開發一個系統 - 它還必須支援最大的專案，其中可能有系統系統，團隊團隊和專案-of專案。  可擴充套件意味著核心需要具備新增實踐，細節和覆蓋範圍的能力，以及新增生命週期管理和定製核心本身以使其特定於域或將軟體開發工作整合到更大的工作中。

根據這些標準，原則和功能SEMAT團隊著手尋找核心。(banq注：從哲學上看，現象就是本質，核心是否存在還沒有經過論證，就開始尋找核心了)


其次是語言
為了解釋核心中的普遍性以及實踐和方法，我們需要一種語言。僅僅使用英語並不夠精確，所以我們需要有一種語法和語義的形式語言。
該語言必須為其主要使用者設計，他們是參與軟體開發工作的專業軟體開發人員。該語言還必須允許有能力的從業者建立和改進實踐，而無需學習高階語言。  
該語言應支援四個主要應用程式：描述，模擬，應用和評估。“國家概念可能在核心語言中發揮重要作用，代表工作進展。”

同樣的願景陳述對語言提出了相當具體的要求。例如“語言應該為開發人員社群（不僅僅是流程工程師和學者）設計”，這是一個重要的要求，要求在使用方法時提供比現在更加直觀和更具吸引力的使用者體驗。另一個要求的例子是語言必須提供“驗證機制，以便有可能評估聲稱應用給定方法元素的專案是否真正做到了，而不僅僅是對它進行口頭服務。”

我們需要的不僅僅是核心 - 我們需要實踐和方法
核心和核心語言的作用將用於描述具有共同點的實踐和方法。為了實現這一目標，必須在描述大量方法時應用一個有用的共同點。我們需要就實踐和模式是什麼達成一致。我們舉例說：“一種做法是一種方法的獨立問題。例子是......迭代開發，基於元件的開發“，”每個實踐，除非明確定義為連續活動，否則具有明確的開始和結束“和”每個實踐為其利益相關者帶來定義的價值“。
憑藉這些原則，價值觀和要求，SEMAT團隊已經清楚瞭解逃離方法監獄需要什麼。
(banq注：難道讓大家跟著SEMAT團隊逃離方法監獄，進入你的布袋嗎？)

4.如何逃離方法監獄
從想法到有形的結果是很長的路要走。我們首先必須達成共識。

本質 - 軟體工程的共同點
作為對“世界上最愚蠢的事情”的回應，2006年在Ivar Jacobson International（IJI）開始了關於方法監獄逃生路線的工作。2009年，SEMAT社群成立，並於2011年將工作轉移到OMG，最終在軟體工程中產生了一個名為Essence的標準共同點

Essence在2014年成為採用的標準。因此，Essence並非像“宙斯的眉頭”那樣閃光，而是根據願景宣告精心設計的。

使用Essence
我們將透過呈現在Essence之上描述的實踐來展示其用法，而不是將整個理論置於Essence之後 - 使用Essence作為展示實踐的平臺。 

我們選擇將使用者故事描述為Essence實踐的一個示例 - 在此處將其命名為User Story Essentials。下面的圖2顯示了（不詳細閱讀）14張卡片的集合，這些卡片代表了練習的標題要點。

我們不打算在這裡描述整個練習，而是讓您對基本練習的外觀有一個很好的理解。
因此，我們選擇了下面簡要描述的一組代表性卡片。  

（1）使用者故事要點User Story Essentials（概述卡） - 概述了以下方面的做法：

• 簡要說明，讓我們深入瞭解為什麼（好處）和何時（適用性）我們可能會使用這種做法
• 內容列表 - 顯示練習中所有元素的命名練習元素圖示（每個元素都用自己的卡描述）。

• 主要是黃卡 - 解決方案領域的Essence顏色編碼 - 告訴我們這種做法與我們正在構建的軟體系統和/或其要求有關。
• 一張綠卡 - 關注客戶領域的Essence顏色編碼 - 告訴我們這種做法也關注我們如何與商業/客戶領域的關注，如機會和利益相關者。
• Zero Blue藍卡片 - Essence有三個關注點，第三個顏色用藍色代表Endeavour區域。User Story Essentials練習在此區域沒有卡片。

• 文字描述 - 封裝模式提供的指導的關鍵方面。
• 命名關聯 - 顯示模式主要與哪些其他元素相關 - 在本例中為User Story元素。
• 參考連結 - 參考資源卡上的命名參考 - 它反過來提供一個或多個指向更多指導或資訊來源的指標。資源卡是圖2中描述實踐的14張卡之一。

• 沒有專家支援，任何書面流程都無法使新手成功。
• 語言越多，閱讀其中任何一個的可能性就越小。
• 在涉及更詳細的詳細支援指導時，不要“借用和重寫”其他人的話，最好簡單地參考本指南的原始來源。

• 活動的描述。
• 表示我們成功執行活動所需的能力和能力水平。例如，該卡需要第2級的利益相關者代表能力和第1級的分析能力（所有這些都在Essence核心中定義，並且可以立即從電子可瀏覽的HTML和卡中鑽取）
• 活動所處空間的指示 - 即“它幫助我們做什麼”（通用核心“活動空間” - 在這種情況下“瞭解要求”）
• 表示活動目的的表示為它實現的最終狀態 - 在這種情況下，識別使用者故事並生成表達與使用者故事相關聯的值的物理故事卡。

• 一個簡短的描述，清楚地說明了這個東西是什麼以及它用於什麼。
• 專案進展的一系列狀態 - 在這種情況下，從透過準備開發到完成來識別。（將這些視為看板委員會的候選專欄 - 儘管團隊可能也希望代表其他臨時狀態，具體取決於他們當地的工作實踐）。
• 多個使用者故事都涉及的“父”（核心）Alpha（本例中的要求）。

• 簡要說明。
• 我們逐步詳細闡述的細節層次 - 在這種情況下表明我們最初確保已經捕獲並傳達了相關價值，並且我們還需要在某個階段繼續列出驗收標準 - 第三個虛線輪廓詳細程度表明我們可能會或可能不會捕獲關聯的對話 - 例如，如果我們是分散式團隊，則在電子工具中。
• 工作產品描述的Alpha - 在這種情況下的使用者故事。

把它們放在一起
我們現在已經描述了使用者故事要素練習中使用的不同型別卡片的代表性子集，因此我們不會描述其他卡片，因為故事會很快變得熟悉和重複。
現在我們瞭解所有卡片的含義，我們還需要從高層次瞭解整個練習的工作原理。卡片本身為我們提供了所有關於元素如何組合在一起以提供端到端故事所需的線索 - 哪些活動可以進展併產生哪些元素，但是用這些術語來講述聯合故事也很有用。透過不同的活動進行端到端的流程。

• 首先，我們需要查詢使用者故事。這會在初始識別狀態中生成一個或多個使用者故事，每個使用者故事都由故事卡記錄，其中包含足夠的資訊以確保使用者故事的值已表達。(banq注：尋找需求，透過角色扮演等方式)
• 在逐個故事的基礎上，我們將選擇我們希望接下來完成的使用者故事，並使用準備使用者故事活動來推進使用者故事以便開發，這涉及確保我們有接受在故事卡上列出的標準，在此期間我們也可以獲得任何支援對話的捕獲。作為同一活動的一部分，我們還充分闡述了相關的測試用例。
• 此練習描述的最後一項活動是我們如何努力接受使用者故事，成功完成將使用者故事移至完成狀態。

• 在我們開始第一次Sprint之前查詢使用者故事，但也允許在臨時基礎上進行此操作。
• 在第一個Sprint之前準備使用者故事活動，然後在Sprint規劃期間為每個Sprint準備下一個Sprint的使用者故事。
• 目標是在完成後立即接受使用者故事，以便在Sprint Review結束之前為Sprint完成選擇所有使用者故事。

• 這種做法是嚴格限制的 - 它告訴我們如何做好一件事，並且在涉及我們想要在其他空間（Scrum，Kanban，......）中使用的其他實踐時，不會限制或限制我們的任何其他選擇。
• 這種做法非常簡潔 - 它在上面的圖形中有點壓縮，但是實踐中的卡片大致相當於A4的一面。
• 這種做法是可以訪問的，並且可以與之互動 - 卡片以各種方式使用 - 包括使註釋團隊的工作方式立即可見，自我評估當地實踐的充分性和優先改進領域。
• 這種做法以簡單，標準的方式表達 - 現在您瞭解了User Essentials中的這4張卡片，從任何其他來源理解任何其他Essence練習都沒有障礙 - 只因為您喜歡這個使用者故事練習，您現在不是在其方法監獄中被俘 - 您可以自由地在公開市場上漫遊，從任何其他來源選擇任何其他做法。
• 該實踐“插入”Essence標準核心，從而確保它以明確定義的方式與任何其他基本實踐互操作。
• 同樣的事實可以立即評估任何實踐的範圍和覆蓋範圍（我們的實踐將活動新增到Essence核心活動空間“理解需求”和“測試系統”中，但不會對Essence概述的其他13個活動空間新增任何內容核心（“實施系統”，“部署系統”，......） - 所以如果這是我們採用的唯一做法，很明顯我們沒有商定或定義的方式來做這些其他事情（可能是也可能不是一個問題，但是是清晰可見的事實...）。
• 它包含所有必需品 - 你可能會或可能不會做很多其他事情，但是如果你不是以這種方式做這些事情（或者是本地修改的等價物，或者可能明確地沒有明確地做一個特定的方面理解和明確的理由）那麼你可以合理地聲稱自己在做“使用者故事”嗎？

5.離開方法監獄
許多公司現在正在對其現有方法進行本質化。例如，用塔塔諮詢服務公司（TCS）的話說：“TCS已與其所有核心行業合作伙伴（如SAP，甲骨文，微軟和其他公司）以及TCS的客戶合作，並正在與這些公司的核心方法團隊合作。幫助促進Essence標準的協作採用，並將這種非法標準轉變為事實上的標準。“
這些公司在實踐庫中獲得可重用的實踐。團隊和組織能夠混合和匹配不同方法的實踐，並建立自己的工作方式。今天，我們相信在Essence之上描述了大約一百種做法。Ivar Jacobson International已經開發了大約50種實踐，並在https://practicelibrary.ivarjacobson.com的實踐庫中提供了25種實踐。 
那些公司正在退出方法監獄。他們不再依賴大師了。他們不會沿著曲折的道路前行，但他們期望可持續發展。方法戰爭結束了。然而，退出方法監獄並不是他們所期望的全部。他們有更高的抱負。他們正走在工業規模敏捷的道路上 - 將軟體開發從主要是工藝轉變為主要是工程學科，但在軟體開發和使用方法方面仍然敏捷。 
為了取得成功，我們仍將依靠我們授權團隊的工藝，但這將以編碼工程實踐的共享基礎為基礎，可以在不同的技術領域和專案型別的不同排列和組合中重複使用。這將使我們能夠在所有專案中始終如一地保持高水平的工藝，並透過未來的挑戰和變化無限期地維持這一點。
我們還需要一個支援組織，其學習文化對新想法開放，並且對實驗很滿意。討論這個問題超出了本文的範圍，但我們參考已發表的論文（見[8] - [10]）。
精華也在學術界取得進展。世界各地的大學都在不同程度上教授精華。來自Pekka Abrahamsson教授的話，“在斯堪的納維亞最大的技術大學之一，挪威科技大學在特隆赫姆，2017年春天，我們成功地向460名學生講授了軟體工程專業課程。...精華賦權學生們可以控制他們的專案，工作方法和實踐。我們終於超越了Scrum和看板....資料和結果讓我信服，因此我未來的軟體工程教育將由Essence推動。“ 
也許轉向Essence是這些公司和大學“世界上最聰明的事”。