原文翻譯：Dual Track Development is not Duel Track
長話短說（TL;DR:）
如果你以前有聽過『雙軌開發（dual-track development）』，這篇文章將會解釋它從哪裡來，以及它代表的意思。這裡是節錄的重點。
- 開發工作（development work）專注在可預測性（predictability）和品質（quality）。
- 探索工作（discovery work）專注在快速學習（fast learning）與驗證（validation）。
- 開發（development）和探索（discovery）被視為雙軌（dual track），因為它們是兩種不同的工作型態和思維。
- 探索是產品開發必要的部份，採用相同的敏捷（agile）和精益原則（lean principle）來實踐。
- 如果我們正確的進行探索工作，很多的想法會有巨大的變化或是被捨棄。
- 通常探索工作由產品經理、設計師和資深工程師主導，但是最好還是盡可能讓整個團隊成員都能參與，持續的進行探索工作以及讓整個團隊可以可視化進度。
- 持續的量測和學習，即使產品已經上市。
沒有人真得把它命名為雙軌（NO ONE REALLY NAMED IT DUAL-TRACK）
多年以前，我和一位朋友（Marty Cagan）開設一門為期三天的課程。通常談到敏捷思考（agile thinking）和產品思考（product thinking）怎麼結合成為一個流程（process）的時候，通常我會用這一個模型圖解釋，這個模型圖看起來有點像這個樣子：
我手繪了自己的模型版本，因此看起來並不完全一樣。 但是，Marty 問我這個模型來自哪裡。我打開了Desiree Sy （發音為 See）的原始論文，名為 Adapting Usability Investigations for Agile User-centered Design。
這是 Desiree。你肯定會喜歡她，她非常的聰明。
她在 2007 年的文章中描述了一種常見的模式，很多人已經在敏捷開發中，導入嚴格的設計和驗證工作。當時，Desiree 在現在改名為 Autodesk 公司的 Alias 工作，她和她的同事們在這樣的模型下工作得非常順利。她們所做的事情當時大多數人都認為是超級困難甚至是不可能。但是，對她們來說，這似乎很自然。雖然不容易，但確實有效。
Marty 問我『這個模型的名字是什麼呢？』
我說『它實際上沒有名字』，就只是個她們所使用的工作流程。
Marty 又問了『那她們稱呼這樣的模式為什麼呢？』
我從論文中擷取了一段文章：
我從裡面擷取最重要的部分，它是這麼說的：
針對設計和開發，我們和開發人員緊密合作。儘管從模型圖上，雙軌（dual tracks）看起來是分離的。但實際上，設計師需要每天與開發人員進行溝通。就是這樣子。 Marty 開始在對產品經理的教學中使用這個術語。由於我經常教同類型的學員，所以我也開始使用該術語。逐漸地，其他人開始使用該術語。
現在我要告訴你我討厭這個詞，為什麼呢？
產品開發是雙軌並行而不是雙軌進行（IT’S DUAL TRACK, NOT DUEL TRACK）
人們通常不會仔細的閱讀。如果你已經閱讀到文章的這裡，那真是的奇蹟。恭喜你。
但是人們確實會看圖片。 而雙軌（dual tracks）的模型圖似乎建議不同的角色進行不同的工作。例如產品經理和設計師弄清楚要開發什麼，開發人員從事開發。在最壞的情況下，您可能將其解釋為開發人員需要等待數週，等待產品經理和設計師完成工作。不應該是這樣，應該由整個團隊一起負責產品的成功，而不僅僅是負責產品開發，那麼整個團隊都會理解和貢獻這兩類型（discovery and development）的工作。
我想換個術語，換個圖片。 但是，我現在沒有更好的術語或圖片。 儘管我會嘗試畫一些圖片來補充這雙軌模型圖。
有兩種的工作類型，而且沒有解決的方法（THERE ARE TWO KINDS OF WORK, AND THERE’S NO WAY AROUND IT）
開發工作（DEVELOPMENT WORK）
如果你以前從事過敏捷開發，那麼你就會知道團隊會談論很多關於速度（velocity）的問題。 但是他們談論的速度是開發的速度。 團隊為他們的可預測性而苦惱。 在衝刺（sprint）開始時，他們將估算速度，最後測量其速度。 理想情況下，他們的預測是準確的。
當你交付高質量的產品時，質量至關重要。如果我們要發布產品， 質量、可伸縮性、性能、本地化以及許多其他問題都非常重要。因此，應該由其他人來構建，測試和審查完成的開發工作，以照顧所有這些問題。敏捷團隊將談論很多有關『潛在可交付產品（potentially shippable software）』的問題，這實際上意味著他們可能尚未構建足夠的產品來進行發布，但是一旦決定要發布，它們的質量就足夠高，可以放心的進行發布了。
開發工作（development work）專注在可預測性（predictability）和品質（quality）。
探索工作（DISCOVERY WORK）
軟體開發以及所有產品開發的悲劇之一是，我們構建的很多東西都沒有成功。它沒帶來期待的成果。所以，這是一個問題。 但是，在這之前，我們需要花點時間去了解我們所要解決的問題，針對我們要建構的產品做出正確的決定。我們透過探索工作來完成它。為了回答問題，驗證想法，並盡可能避免浪費時間過度投資在我們根本不應該開發的高品質產品。
我們希望盡可能快、便宜且安全的學習。 因此，速度在探索過程中也很重要 ——但這個是學習速度。
探索工作（discovery work）專注在快速學習（fast learning）與驗證（validation）。
因為目標是學習而不是工作軟體（working software），探索學習的循環有點像是這樣：
一開始是這樣的：
- 我們相信的是我們正在解決問題以及為誰解決問題
- 我們建構的解決方案可以用來解決問題
- 我們怎麼衡量成功
那是我們的賭注，我們的最佳猜測，我們的信念，和我們的假設。對於那些相信自己在做正確的事情的人來說，所有這些描述都是不舒服的文字。但是，事實是，我們一直在打賭自己可以從產品獲得價值。隱藏在該賭注中含有大量的假設、風險和疑問。為了專注在我們的學習，我們將選擇最讓我們感到恐懼的假設，風險或疑問，並確定要學習的實驗或方法。 然後去做，然後使用我們學到的知識來改變所有關於問題和解決方案的信念。
可悲的是，學習中最耗時和最昂貴的方法之一就是構建潛在可交付產品（potentially shippable software）。所以我們不應該這麼做，除非我們真得想不到其他的方法來幫助學習，或是我們真的相信自己的賭注是好的。記住，我們不是打賭我們可以準時做交付。我們是打賭人們會遇到我們要所要解決的問題，而且會很樂意嘗試、使用和採用我們的解決方案。
測試你的想法最昂貴的方法是建構高質量的產品
這就是學習循環的工作方式。 你還需要了解幾件事。
我們會盡一切努力在探索工作上。盡可能在幾小時內， 有時可能需要幾天。但是，我們希望不要花幾週的時間。因此，大多數的探索學習循環應該可以符合典型兩週衝刺（sprint）。
探索工作通常會導致想法被捨棄。 在每項測試的最後，您都必須做出決定：建造它、殺死它或繼續學習。 是的，我在這裡真正要說的是探索工作會導致想法被捨棄。 並非一切都向前發展。這會使得某些人感到非常不舒服。
探索的週期是有時間限制的。為了避免探索工作費用占據了我們所有的預算，我們會將測試或實驗的時間限制在幾小時到幾天內。
我們無法預測接下來需要學習的內容－這非常不容易。當我們學到真正有價值的東西時，它往往會真正改變我們的信念，並真正改變我們下一個最大的假設或疑問。這真的很糟糕。
探索循環（discovery loop）接在一起，有點像是這樣：
到目前為止，應該很清楚，開發和探索工作都是至關重要的。但是，您處理工作所用的心態以及執行工作的過程是非常不同的。
好吧，實際上有三種類型的工作．．．（OK, IT’S REALLY 3 KINDS OF WORK…）
要真正開始構建工作軟體（working software），您需要做出許多戰術設計決策。 這些可能不是需要驗證的冒險決定，但仍然需要做出決定。通常，設計師需要在開發之前花一些時間來精煉（refine）和完成設計工作，以準備編寫代碼。
如果您確認該產品值得構建，那麼在編寫代碼之前，您可能需要完成一些詳細的設計工作
所有工作同時間進行（IT’S HAPPENING ALL AT ONCE）
如果我們所有人都專注於探索工作，完成任務，然後將重點轉移到戰術設計和開發上，那將是非常酷的事情。如果所有團隊成員都具有相同的技能，那將可行。但是，由於有些人擅長編寫代碼，有些人擅長用戶體驗設計，而另一些人擅長於其他各種事情，因此我們有機會一次完成多種工作。
探索工作與開發工作同時並持續進行。
這些天，我畫了一個合在一起的模型，長得有點像這樣：
探索工作使用不規則的循環長度。這是『精益開發』，因此我們試圖讓探索週期盡可能短。探索中的想法不斷變化，並且常常被捨棄。最好的步伐是進入更深思熟慮的開發週期。我不確定如何在單張圖片中顯示所有這些東西。但是，上方的圖片是我的一種嘗試。
探索和開發顯示在兩個軌跡中，因為它們是兩種工作型態，兩種思維
兩個軌跡，但不是兩個團隊（TWO TRACKS, NOT TWO TEAMS）
但是，你不應該把它想成是兩個流程——僅僅是一個流程中的兩個部分。而且，我認為您正在損害開發人員和團隊中的其他人員，使他們不能參與探索工作。
通常，要做的探索工作還遠遠不夠，還有很多方法可以讓整個團隊參與其中。如果你感受到必須縮短探索工作的時間，來產生工作給開發團隊的壓力，那通常意味著你在了解足夠多的訊息以前，在確信自己應該這樣做之前，就已經決定要這麼構建軟體。在最好的情況下，結果是不確定的，通常結果都是不好。
整個團隊不僅負責按時交付，還負責產品結果
打破雙軌的迷思（BUSTING DUAL-TRACK MYTHS）
讓我再次打破人們對此模型的最大誤解。
迷思：探索是敏捷開發之前的流程。不應該是這樣子的。
探索是產品開發的必要部分。在實踐時要牢記同樣的敏捷和精益原則。
迷思：所有的工作都是從探索流向開發。不應該是這樣子的。
如果我們正確的進行探索工作，很多的想法會有巨大的變化或是被捨棄。
迷思：探索團隊和開發團隊是不同的團隊。不應該是這樣子的。
通常探索工作由產品經理、設計師和資深工程師主導，但是最好還是盡可能讓整個團隊成員都能參與。持續的進行探索工作以及讓整個團隊可以可視化進度。
迷思：一旦探索工作流向開發工作，探索工作就完成了。不應該是這樣子的。
通常探索工作由產品經理、設計師和資深工程師主導，但是最好還是盡可能讓整個團隊成員都能參與。持續的進行探索工作以及讓整個團隊可以可視化進度。
這種誤解確實讓我的朋友 Jeff Gothelf 感到困惑。他將高質量的軟體視為一個由我們建構出、最棒的和最後的實驗。
持續的量測和學習，即使產品已經上市。
從 Jeff Gothelf 的觀點，這些都是探索。無論我們從我們建構出的東西、紙本上的原型（prototype）、或是產品的下一個特性（feature）。 我同意他的觀點。
還有很多的故事（THERE’S LOTS MORE TO THIS STORY）
我已經在概念上談論了什麼是探索和開發工作，以及為什麼要將它們合併在同一個流程中。但是，關於實際上要怎麼做，我說得很少。你應該感到有些不滿意。對於這部份，我感到很抱歉。
但是，這是我正在撰寫系列文章的第一篇。下一篇將會包含：
- 如何在 Scrum 之類的典型敏捷開發中保持可見度
- 如何調整典型的敏捷計劃、站立式會議和評審會議，使他們專注於探索和開發
- 如何通過下一個最佳實驗來思考問題，並充滿信心的在探索上做更多的投資呢
您還有什麼問題？做這些事情，您最大的挑戰是什麼？請讓我知道我上面沒有提到的內容。
