精實啟動

啟動，敏捷專案的開端

天真的敏捷沒有任何前期工作，但實際上我們意識到我們必須做一些。對於 Thoughtworks 來說，「構思」就是「一些」。自從我於 2006 年加入 Thoughtworks 以來，我意識到公司中的所有敏捷專案都以類似的方式開始。專案團隊會聚在一起數週，在開始交付工作之前進行許多活動：這就是構思。

Thoughtworks 構思主要由路克·巴雷特於 2004 年左右開發。喬納森·拉斯穆森（《敏捷武士》的作者）和傑夫·帕頓（《使用者故事對應》的作者）都曾在 Thoughtworks 工作了一段時間，他們在自己的書中描述並進一步開發了構思技術，我從中學到了很多。

我們的構思因專案而異，但它們通常會產生業務與技術人員之間的一致性，並建立一個有序的使用者故事清單，其中包含估計值和發行計畫。

直到 2011 年，也就是我兒子出生的那一年，我對以這種方式促進這些敏捷構思感到非常滿意。問題是，我構思的促進者，但構思需要兩到四週的時間。而且我無法離開家超過一週。我必須讓構思精簡，想辦法讓它們在一週內完成。

在我兒子出生後，我第一次出差。在從聖保羅飛往舊金山的長途飛行中，我讀了埃里克·萊斯所寫的《精實創業》一書。從中我找到了縮短構思長度的完美藉口，並在一週後返回家園。

為什麼它被稱為「精實構思」？

這種新的構思風格絕對是 2006 年構思的轉變。團隊不再撰寫和估計使用者故事。在嘗試這種新風格時，構思這個名稱讓每個人都傳達了錯誤的訊息。我需要一個不同的名稱。

新的構思風格出於兩個原因而精簡

1. 構思時間較短，移除了所有與產品無關的事物（例如架構、專案等），使其「精簡」
2. 構思的最終結果是了解 MVP，這是「精實」創業運動中的主要概念。

因此，新的構思風格有一個明確的主導名稱：精實構思。

為什麼是「精實構思」？

當團隊需要反覆開發 MVP 時，精實入門會很有用。雖然這個術語經常被誤解，但 MVP 的核心特質是我們為了學習是否值得繼續開發產品而建構的東西。因此，我們會根據測試我們對使用者有價值的假設來選擇功能。為此，我們需要了解我們的使用者是誰、他們從事哪些產品支援的活動，以及如何衡量他們是否發現產品有用。

我們發現研討會在兩個主要情況下很有價值。

• 大型專案發現精實入門對於快速啟動並以精實風格工作很有價值。這樣的開始建立早期反覆運算，旨在發現和測試使用者真正重視的功能。
• 較小的組織（例如新創公司）使用精實入門將一些軟體前 MVP 測試過的想法轉變為軟體產品。

這個研討會特別著重於了解 MVP，它不能取代構思會議、客戶研究、架構檢討或競爭分析。這是一種特定技術，是了解建構成功產品所需內容的一部分。它與這些其他活動的契合方式在很大程度上取決於組織的特定背景和您正在從事的開發工作。

範例時間表

精實入門包含一系列活動，通常排程在一週內。我將在以下時間表連結中說明每項活動

這是一個範例時間表，請不要將其視為固定事項，但可以作為事情如何運作的良好範例。

我們以引言和開場白開始啟動，並以展示結束。在理想的世界中，每個人都會出席整個啟動過程。但是，我們通常會遇到一些人對啟動的方向和結果非常感興趣，但無法全職投入。必要的最低限度是這些利害關係人參加引言、開場白和展示會議。

自從 2020 年初 COVID 襲擊我們以來，我們開始執行許多遠程啟動。在遠程或混合（現場和遠程）設定中，初始對齊工作坊（例如精實啟動）變得更加重要。此 頁面 提供額外的提示和資源，供您進行遠程啟動。