內容簡介
用戶故事地圖作為一種有效的需求工具，越來越廣泛地應用于開發實踐中。本書以用戶故事地圖為主題，強調以合作溝通的方式來全面理解用戶需求，涉及的主題包括怎么以故事地圖的方式來講用戶需求，如何分解和優化需求，如果通過團隊協同工作的方式來積極吸取經驗教訓，從中洞察用戶的需求，開發真正有價值的、小而美的產品和服務。本書適合產品經理、用戶體驗設計師、產品負責人、業務分析師、IT項目經理、敏捷教練和精益教練閱讀和參考，也更適合用作企業培訓手冊，打造高效能的團隊協作能力。
Martin Fowler序敏捷軟件開發運動的興起為軟件行業帶來了諸多積極的變化，大型需求要進行拆分，這個意識的建立便是其中之一。切分后的需求稱為“故事”（story） ，故事的使用使得軟件開發項目的過程進一步可視化。通過故事方式來組織開發的產品，每一個故事實現都和整個軟件完全集成，每個人都可以看到產品在不斷成長。用戶也可以理解故事，開發者通過決定下一個迭代開發哪個故事來管理軟件開發項目。可視化程度的大幅提升，使得用戶可以深入參與到項目中來，而不是像以前那樣需要等上一年甚至更久時間才能拿到開發完成的新特性。需求拆分本身也有很多負面影響，容易丟失軟件系統全景圖（whole picture）便是其中之一。開發工作進展到后期，你可能得到的是一堆無法拼接在一起的碎片。也可能由于過度陷入細節而丟掉用戶訴求的本質，最終構建出用戶不需要的產品。故事地圖是一門在需求拆分過程中保持全景圖的技術。如果要用一句話來詮釋本書的話，非上面這句話莫屬了，這句話本身就很有價值。全景圖可以幫助團隊和用戶有效的溝通，幫助參與其中的人避免開發非必要的特性，也為一致的用戶體驗提供了基準。當我詢問ThoughtWorks（思特沃克）的同事如何開發用戶故事時，他們最常提到的核心技術就是用戶故事地圖。這些ThoughtWorks同事也是在Jeff（杰夫）的工作坊學到這門技術的，因為Jeff開發了故事地圖，也只有他能把故事地圖講到如此淋漓盡致的程度。Jeff寫這本書正是為了幫助讀者直接從源頭學習這門技術。但是，這本書并非單是為那些名片印著產品經理、業務分析師頭銜或者在線簡歷中寫著產品經理頭銜的人而寫的。在采用功能敏捷開發方法的十年中，最讓我失望的一點是，程序員把故事當作和產品經理之間進行溝通的單行道。在最開始的時候，故事的目的是激發溝通中的火花。要想開發出能有效支撐用戶活動的軟件，就需要求助于開發軟件中最關鍵的角色，因為只有程序員最清楚軟件可以做什么。程序員需要理解用戶想要達成的目標，需要在前期捕獲用戶需求的階段就參與進來，一起開發故事。懂得故事地圖技術的程序員能更好地理解用戶上下文，在軟件成形期間更好地參與進來，從而取得更好的工作成果。Kent Beck（肯特?貝克，最早提出用戶故事概念的人）發展了自己在軟件開發方面的理念，他呼吁團隊把溝通作為高效團隊的核心價值。故事，是程序員和其他角色溝通中的必備要素，故事地圖對這些要素組織為結構化，以此來強化軟件開發中最關鍵的部分——溝通。——Martin Fowler（馬丁 福勒）2014年6月18日Alan Cooper序在Mary Shelley（瑪麗?雪萊）的著名科幻小說《科學怪人》中，瘋狂的弗蘭肯斯坦博士用尸體碎片創造了一個生命，那時候電力還被視作一項新技術，弗蘭肯斯坦博士用電力給生物注入生命。當然，這只是小說中的情節，在現實世界中使用尸體碎片創造生命實際上根本就不可能。然而在軟件開發中，我們一直在試圖這樣做。在軟件中堆砌一個又一個新功能，然后陷入“為什么沒有多少用戶喜歡這個產品”的困惑中。這個謎題的核心在于開發人員將工程方法作為了設計工具，實際上兩者不是一回事兒。程序員逐個開發特性是完全合情合理的，并且經過數年驗證是一個行之有效的策略。同樣經過數年驗證的是，設計軟件產品的行為和范圍時，也遵循逐個進行的方式，這就有點像科學怪人的做事方式了。盡管有相通之處，設計軟件行為和開發軟件的實踐之間其實有明顯的不同，主要原因在于這兩件事是由不同技能特長的人來承擔的。像交互設計師那樣花好幾個小時的時間觀察用戶行為和提取行為模式，這樣的工作會讓程序員抓狂。而像程序員那樣花好幾個小時研究算法，對大多數設計師而言也同樣難以忍受。但是，當設計和開發兩類工作產生協同的時候，就會像弗蘭肯斯坦所使用的電力一樣，能夠創造出有生命的產品。團隊協作為產品注入生命力，并讓用戶也愛上它。雖然協作本身并不是什么新概念，但要做到高效協作實際上確實十分困難。程序員工作的節奏、語言和交互設計師之間有非常大的差別。程序員和設計師在各自的領域中都非常專業、精干，都有自己的工作規范，同時他們又有著共同的弱點。設計問題是很難用開發術語來描述的，同樣，開發難題也難以使用設計術語來說明白。這對姊妹學科之間缺乏共同的語言，而連接兩者恰恰是Jeff Patton（杰夫?帕頓）所擅長的。Jeff的用戶故事地圖方法能夠為程序員所理解，同樣也可以為設計師所理解。用戶故事地圖就像數字時代的羅塞塔石碑（Rosetta Stone）。撇開業界對敏捷的成見，敏捷軟件開發方法本身也不見得是一種良好的產品設計方法。敏捷開發是一種很好的思維方式，可以使設計方案更順利地交付，卻無法產出能讓用戶喜愛的產品。換句話說，我們看到過不少優秀的設計，文檔完成后交給開發人員，不管是敏捷開發還是非敏捷開發，設計的核心理念在實現過程中都會被抹殺掉。Jeff Patton的用戶故事地圖方法是連接開發和設計的橋梁。交互設計的核心是發現用戶行為并像講故事一樣把它們描述出來。軟件開發則是將這些描述拆分、實現并集成到產品中。在這個復雜的過程中，設計的核心理念非常容易丟失。是的，就像是手術失敗，所有的規定操作都做完，病人最后卻死在手術臺上。通過用戶故事地圖的方式來處理用戶故事，設計仍然保持其敘事結構，開發工作也可以得到很好的分解從而得以高效實現。設計師的方案以規范化的用戶故事形式描述，在開發過程中流動并保持其完整性。在傳統公司中已經證實，以兩三百人規模的團隊，要開發出能讓用戶喜愛的產品幾乎是不可能的。而創業社區則證實，四五個人組成的創業團隊可以開發出能讓人們喜愛的小產品，即使這些小產品也會最終隨著規模變大而失去光芒。我們面對的挑戰是如何創造出用戶喜愛的大型軟件產品。大型軟件產品用戶群廣，并且用戶從事的是復雜的商業活動。想把這樣的軟件做得有趣并且簡單易學，是非常困難的。要想避免將大型軟件產品開發成“科學怪人”，唯一的方法是學習如何充分協調好產品設計和軟件開發。在這方面，沒有人比Je ff Patton做得更好。——Alan Cooper（艾倫 庫珀）2014年6月17日Marty Cagan序我的職業生涯非常幸運，因為我一直有機會和世界頂尖的許多產品技術團隊合作。他們創造出用戶非常喜愛，并且每天都在使用的產品。這些團隊正在改變世界。我也曾經受命前往幫助一些做得不那么好的公司。創業團隊努力在錢燒完之前找到新的投資。大公司則掙扎于復制早期的成功。團隊無法持續為業務貢獻價值。主管則為新想法何時才能上線操碎了心。工程師對產品經理滿腹怨言。在這個過程中，我認識到頂尖產品公司在軟件設計開發上和普通公司之間存在巨大的差別。從主管行為到團隊授權級別；到團隊協作的方式；到組織在投資、招聘和產品開發方面的思考；到文化；再到產品、設計、開發如何協作共同發現對客戶行之有效的解決方案。這本書的題目是用戶故事地圖，但仔細閱讀之后，你會發現這本書的內容并不局限于故事地圖這一強有力卻看似很簡單的技術上。這本書更多講述團隊如何溝通、協作并最終交付好的產品。大部分人是沒有機會近距離觀察一個強大的產品團隊是如何運作的。讀者能夠了解的更多是自己公司以及前東家是如何運作的。所以接下來我會幫助大家來識別頂尖產品團隊和普通團隊之間的差別。我非常贊同Ben Horowitz（本?霍羅威茨）的文章“好的產品經理和差的產品經理”中的觀點，下面借用其形式，初步探討一下好的產品團隊和差的產品團隊之間的主要不同。好的團隊，有引人入勝的產品愿景，懷著傳教士般的熱忱在工作。差的團隊，像是由雇傭兵組成的，當一天和尚撞一天鐘，靠混的。好的團隊，從關鍵業務指標得到啟發，通過觀察用戶的痛點和分析用戶使用過程中產生的數據，不斷嘗試新技術解決現實問題。差的團隊，從銷售人員和用戶那里收集需求。好的團隊，理解誰是主要干系人，干系人所受的約束，承諾引入解決方案，方案對用戶和客戶有用，同時也滿足業務上的約束條件。差的團隊，只知道從干系人那里收集需求。好的團隊，掌握大量的技術手段，這些技術手段可以快速驗證哪些產品創意是值得開發的。差的團隊，召集會議來制定路標和排列優先級。好的團隊，喜歡和公司內有想法的主管展開頭腦風暴和討論產品。差的團隊，在團隊之外的人膽敢提議他們做任何事的時候，會覺得自己受到了冒犯。好的團隊，產品經理、交互設計師和開發工程師坐在一起，對功能、用戶體驗、技術可行性達成一致見解。差的團隊，各自坐在小格子間里，沒有文檔和會議安排，就不會主動響應其他人的請求。好的團隊，持續嘗試新想法以求創新，過程中會注意保護公司利益和品牌。差的團隊，仍然坐著等待開始嘗試的指令。好的團隊，對于創造出成功產品所需的技能很有信心，比如強大的交互設計能力。差的團隊，甚至壓根兒就不知道交互設計為何物。好的團隊，保證開發工程師每天有時間參與產品原型的討論，為做好產品獻計獻策。差的團隊，在迭代計劃會上展示原型，一心只為了估出工作量。好的團隊，每周直接和用戶交流，以更好地理解用戶訴求，并試探用戶對最新的產品創意的反饋。差的團隊，以為他們自己就能代表用戶。好的團隊，清楚地知道盡管他們很喜歡自己在產品上的創意，但這些創意中的很大一部分用戶并不見得會接受，即使有一些被用戶接受了，也需要經過多個迭代的打磨才能達到預期的效果。差的團隊，只開發路標上規劃的內容，能按時交付，只求不出重大質量問題就阿彌陀佛。好的團隊，理解速度和快速迭代對于產品創新的價值，更知道速度來自于正確的方法，而非強制加班。差的團隊，抱怨同事工作不夠努力，速度太慢。好的團隊，在評估方案，確認可行并對用戶和業務有實際價值后，共同做出承諾。差的團隊，抱怨自己公司是一個受銷售驅動的公司。好的團隊，使用工具，以便快速了解用戶是如何使用產品的，并基于數據做出判斷。差的團隊，認為統計分析是可有可無的。好的團隊，持續集成和發布產品，因為他們知道持續的小發布能為用戶提供了穩定可靠的解決方案。差的團隊，在經過痛苦的集成聯調之后，手工測試，一次性發布所有功能。好的團隊，專注于用戶。差的團隊，專注于競品。好的團隊，在關鍵業務目標重大影響達成后慶祝。差的團隊，在終于發布產品之后慶祝。我已經意識到讀者會困惑，上面所提到的這些東西和用戶故事地圖有什么關系呢？我知道你會感到驚訝。這恰恰就是我成為故事地圖鐵桿兒粉絲的原因。在我接觸過的敏捷專家中，真正有能力幫助產品團隊提升產品研發能力水平的并不多，Jeff Patton便是其中之一。我觀察了Jeff在產品發現（Product Discovery）階段親自動手和團隊一起工作的場景。我也把他介紹給公司，因為他做事非常高效。團隊也很喜歡他，因為他不但知識豐富，人也非常幽默。產品經理都聚到一起寫需求文檔，交互設計師忙于為產品進行涂脂抹粉般的設計，工程師躲在地下室寫代碼，這樣的日子在頂尖團隊中早已經銷聲匿跡。現在，是時候把這些現象清出你的團隊了。——Marty Cagan（馬蒂?卡根）2014年6月18日前言Live in it, laugh in it, love in it/Removes embarrassing,stains from contour sheets,that's right/And it entertains visiting,relatives, it turns a sandwich into a banquet——Tom Waits, “Step Right Up”這本書本來是想做成一本小……小……小冊子的，真的。我打算寫一個簡單的實踐，我稱之為“用戶故事地圖”。除我本人之外，還有許多人使用類似方法，通過構造簡單的故事地圖來使產品使用過程中的用戶體驗圖形化和可視化，從而提升團隊的協同效率。故事地圖可以使我們專注于用戶和用戶體驗，產生更好的溝通效果，最終做出更好的產品。做故事地圖這件事真的簡單得要命。和其他人一起工作，一個人來講產品的用戶故事，一邊講一邊把故事中用戶經過的重要步驟記錄在便簽上，并按照從左到右的順序水平排user_列。然后，回過頭來討論每個步驟的細節，在便簽上記下討論的細節，在每個步驟下面垂直排列。結果得到一個簡單的網格結構，從左到右講述故事，自頂向下拆分細節。這樣做快速而有趣。這些細節故事為敏捷開發項目提供了更好的待辦列表內容。既然這樣簡單，為何要勞神費力整一本書出來呢？即便是如此簡單的事情，有時候也會讓人很困惑。光是寫寫想要構建故事地圖的原因，在構建過程中會發生的事情以及故事地圖的好多種不同使用方法，就會占去不少的篇幅。這本書中需要寫的與這個簡單實踐相關的內容，比我起初預想的多得多。如果你正在使用敏捷開發過程，想必也是使用用戶故事來填充待辦列表的。過去我只是假設用戶故事是一個普通的實踐，認為在書里闡述用戶故事是浪費墨水的事情。但是，我錯了。自Kent Beck首次提出用戶故事以來，已經有十五個年頭，用戶故事比以前更流行，也更普遍被錯誤理解和錯誤使用。這讓我很沮喪，更重要的問題是，這也抹殺了我們能從用戶故事地圖中獲得的收益。所以，在這本書中我會盡最大努力來糾正在敏捷和精益軟件開發中關于用戶故事的錯誤理念。這就是我寫這本書的初衷。就像Tom Waits在歌詞中寫的那樣，就這樣把三明治辦成了一場宴會（it turns a sandwich into a baquet）。為什么是我我喜歡折騰，樂于看到用戶使用我開發的軟件并從中獲益。這種樂趣一直激勵著我。成為一個方法論專家并非我的本意。但學習流程和實踐如何結合發揮作用以產生更好的結果，進而傳授給別人，確實是我在軟件開發行業學習了二十多年才做到的。我也知道教的東西一直在變化。我對故事地圖的理解每個禮拜都在變，對這種理解的最佳闡述，也和我的理解一樣變得快。如此種種，讓我好幾年都沒法子靜下心寫書。但是，現在時機到了。用戶故事和故事地圖都是非常棒的主意，許多人從中受益，他們的生活更好，產品也更受歡迎。盡管有人受益于生活變好，然而更多的人還掙扎在用戶故事之中，我總不能坐視不管吧。我所能做的，就是寫這本書。如果這本書能夠改善他們的工作和生活，哪怕一點點，我都會感到很欣慰。謹以此書獻給那些還在用戶故事中掙扎的人越來越多的組織采用敏捷和精益開發流程，同時也采用用戶故事，所以可能會因為對用戶故事的曲解而落入如下陷阱之中。用戶故事聚焦于構建小特性，很容易“只見樹木不見森林”。開發出來的產品由彼此不匹配的部分拼湊而成，在用戶看來，這樣的產品就像是瘋狂博士的作品“科學怪人”。在開發大型產品的時候，逐個開發小特性會讓人們不知道整個產品何時能夠完成開發和發布。團隊中的工程師也會有同樣的困惑。用戶故事強調溝通，于是不寫任何文檔。這會導致大家忘記在溝通中討論的內容和達成的共識。好的用戶故事要有驗收條件，以至于只專注于寫驗收條件，卻對要做什么缺乏一致的理解。結果，團隊無法在計劃的時間點完成交付。好的用戶故事是從用戶角度來描述的，然而系統中有大量不與用戶產生直接交互的部分，團隊成員認為產品沒有用戶，用戶故事并不適用。? 如果你曾經落入上述任何一個陷阱，那么接下來對誤解的澄清就會對你有所幫助。你也可以從中學習如何從全局開始思考，如何在項目中進行估算，如何就用戶目標組織進行高效的溝通，如何開發一個能解決用戶問題的好的（產品）特性。誰需要讀這本書你當然需要！特別是你剛剛買了這本書，我認為購買這本書是一個明智的投資決定。如果你是從別人那里借的這本書，現在是時候買一本，等新書到手之后趕緊把借的書還回人家。不同的角色閱讀這本書都可以獲得獨特的收益。對于產品經理和用戶體驗設計師，閱讀這本書可以幫助他們彌補完整的產品用戶體驗和項目計劃之間的鴻溝。如果你正糾結于產品愿景和開發細節，或正在努力幫助其他人理解用戶和體驗，或正在苦苦尋求用戶體驗和產品設計方法，在工作中嘗試精益創業方法，用戶故事地圖都可以幫到你。產品負責人、業務分析師和IT項目經理應該讀這本書，幫助他們消除內部用戶、干系人和工程師之間的鴻溝。如果你苦于如何說服干系人，希望他們可以對產品達成一致的理解，或者你正努力幫助工程師理解全景圖，故事地圖都可以幫到你。幫助團隊和個人提升能力的敏捷教練和精益教練應該讀一讀這本書。如果你已經開始讀了，回憶一下公司成員對用戶故事的錯誤理解吧。遵循本書內容，使用用戶故事做簡單的練習，這本書介紹的實踐可以幫助你的團隊提升能力。其他任何角色。在使用敏捷過程的時候，會有產品負責人或者業務分析師這樣的角色，這些角色在需求管理上要投入大量的精力，能否高效使用用戶故事取決于大家是否都具備基礎的背景知識。如果大家不了解基礎的背景，就會質疑用戶故事沒寫好或者認為需求粒度過粗，細節不清晰。讀完這本書之后，你會發現用戶故事并不只是一種更好的需求撰寫方式，而是一種組織更有效的溝通方式。這本書可以幫你理解什么樣的溝通才能幫助你及時獲得需要的信息。希望你能從我所描述的眾多讀者群體中找到自己的影子。找不到的話，請把書送給其他能夠從中找到自己的人吧。找到自己了，對嗎？接下來我們就正式開始吧。這本書是如何組織的不久以前，我買了一臺新的彩色激光打印機。打開包裝盒，在打印機頂上有一個紅色的大信封，里面裝著一本標題為《使用前必讀》的小冊子。我當時還奇怪：“真的有必要先讀一下嗎？”我之前都是不會讀的，覺得沒什么用處。很幸運，這次我讀了，因為打印機內部的不同地方有很多塑料支撐件，這是為了保證打印機在運輸過程中不被損壞而加入的，如果我不清理，讓它們直接開始打印，這臺打印機就廢了。這個故事看起來有點跑題？其實一點兒都不跑題。這本書也有一章叫“使用前必讀”，闡述了兩個關鍵概念，以及本書使用的詞匯表。在開始讀這本書之前，我希望你能將這些概念熟記于心。如果沒有理解這兩個概念就開始毛手毛腳使用用戶故事地圖，后果自負。一萬英尺高空俯瞰用戶故事地圖本書的第1~4章從整體視角介紹用戶故事地圖。如果用過用戶故事并且也玩過用戶故事地圖，閱讀這幾章就足夠你掌握使用故事地圖的正確“姿勢”。第5章是一個精彩的練習，幫助你學習創建故事地圖的核心理念。和同事一起做一下這個練習，每個參與者都可以從中學習這些理念。我相信，在此之后他們為產品做的用戶故事地圖會比之前好很多。深入理解用戶故事第6~12章介紹用戶故事背后的故事，用戶故事的工作原理，如何在敏捷和精益項目中更好地使用用戶故事。故事地圖中有許多小的用戶故事，足以驅動每天的開發進程。即使是敏捷老兵，我相信也會學到此前并不知道的內容。如果剛開始使用用戶故事，你在本章學到的知識足以使那些自稱了解敏捷的同事感到驚訝。更好的待辦列表第13~15章深入用戶故事的整個生命周期。這幾章討論可以幫助你使用用戶故事和故事地圖的特定實踐，應用這些實踐可以創建出更好的待辦列表。更好的產品第16~18章深入介紹如何在持續迭代中使用用戶故事。你可以從中學習如何準備用戶故事，在開發過程中如何關注用戶故事，真正完成用戶故事開發，從每個開發完成的用戶故事中獲取反饋并不斷優化。我發現，不少軟件開發書籍的前幾章完全是多余的，所以一般都會直接跳過這幾章。但是，我并沒有在本書中設置這樣多余的章節。你需要通讀全書。如果在讀完每一章之后，都能得到一些可以直接應用于實際工作中的寶貴知識，我會感到非常欣慰。接下來開始我們的尋寶之旅吧。結語完，還是未完？這是個問題。就像好的軟件產品一樣，本書其實還沒有完。貫穿全書，有很多很不錯的好例子，這些例子都是我所碰到的人講給我聽的，說的都是他們用故事和故事地圖都做了哪些很棒很酷的事情。我的硬盤上還有好多好多這樣的故事，因此，由于時間關系而不能把它們修飾打磨好納入本書，簡直就是要我的命。關于故事和故事地圖，我還可以討論更多細節。我敢保證，你自己在使用故事時，肯定也存在一些問題想要找到答案。臨近本書完成時，我也有那樣的擔憂。作為舊日的開發人員、UI設計師和產品經理，我可以坦白告訴你，在產品發布的時候，我基本上都高興不起來。因為我知道我還有一些東西沒有被納入其中，還有一些東西只需要多一點點時間打磨和修飾，就能夠做得更好一些。如果你真的在乎自己的作品，你會和我一樣感同身受。下面我要重復我在前面所用的一句話：“偉大的作品永遠沒有‘完成’這回事, 只有放棄（Great art is never finished, only abandoned）。 ”我要閉嘴不說這本書是一部偉大的作品，但得承認我真的精心篩選過，要不然會做得更多。那個“更多”，我留給你，期待聽到你的發現，知道你是如何通過更好的協作來打造偉大產品的。目 錄Martin Fowler 序............................................................. 1Alan Cooper 序............................................................... 3Marty Cagan 序.............................................................. 5前言............................................................................... 9致謝............................................................................. 17使用前必讀................................................................... 21第1章產品全景圖......................................................... 35讓我們從頭開始....................................................................................................35故事是講出來的，不是寫出來的..........................................................................36講故事，要完整....................................................................................................37Gary 的悲劇............................................................................................................38邊講邊記...............................................................................................................39創意框架...............................................................................................................40刻畫用戶畫像........................................................................................................41講用戶的故事........................................................................................................42探索細節和可選項.................................................................................................45第2章計劃，為了更少的開發........................................ 51故事地圖幫助大型組織建立共識..........................................................................52創建故事地圖的過程可以幫助發現設計中的坑....................................................54要做的總是太多....................................................................................................55劃分MVP 發布計劃................................................................................................56劃分發布路線圖....................................................................................................57為成果排列優先級，而非功能..............................................................................57這是魔法嗎？沒錯.................................................................................................58為什么要反復討論MVP.........................................................................................60MVP 根本就不是產品............................................................................................61第3章計劃，為了更快的學習........................................ 63從討論機會開始....................................................................................................64驗證問題...............................................................................................................64在設計原型過程中學習.........................................................................................65要能夠質疑用戶所說的內容..................................................................................66在開發過程中學習.................................................................................................66迭代直至可行........................................................................................................68錯誤的做事方式....................................................................................................69基于驗證的學習....................................................................................................70真正的最小化試驗.................................................................................................71重點復述...............................................................................................................71第4章計劃，為了按時發布........................................... 73要讓團隊所有成員都清楚.....................................................................................74估算的秘密............................................................................................................75制定可逐步達成的開發計劃..................................................................................76不要將所有的迭代產出都對外發布......................................................................77關于估算的另外一些秘密.....................................................................................77管理研發預算........................................................................................................78迭代與增量............................................................................................................82開局、中局和末局策略.........................................................................................82根據開發策略切分故事地圖..................................................................................83都是關于風險........................................................................................................84“劇透”第5章主題...............................................................................................84第5章如何創建故事地圖............................................... 851. 分步驟寫出你的故事.........................................................................................852. 組織情節............................................................................................................883. 探索替代故事....................................................................................................894. 提取故事地圖的主干.........................................................................................915. 切分出能幫你達成特定目標的任務...................................................................92就是這樣簡單！你已經學會了所有重要概念........................................................93請在家里或者辦公室里練習..................................................................................94這張地圖是現在的，不是將來的..........................................................................95實操案例...............................................................................................................96練習容易，落地難.................................................................................................97故事地圖僅僅只是個開始.....................................................................................98第6章用戶故事的故事................................................ 103Kent Beck 的創意.................................................................................................103簡單的事情并不一定容易做到............................................................................104Ron Jeffries 的3C 原則..........................................................................................105文字和照片..........................................................................................................107小結.....................................................................................................................108第7章如何把故事講得更好......................................... 109Connextra 公司的用戶故事模板...........................................................................109模板僵尸和萬能犁............................................................................................... 113提升討論效果的檢查單....................................................................................... 115創建度假照片...................................................................................................... 117需要操心的事情還多著呢................................................................................... 117第8章不要把所有內容都寫在卡片上............................ 119不同角色，各有所需........................................................................................... 119我們需要一張更大的故事卡................................................................................ 120信息輻射器和信息冰箱....................................................................................... 122錯誤的工具和錯誤使用工具................................................................................ 124第9章卡片只是個開始................................................ 129在頭腦中構建清晰的圖像................................................................................... 130養成口述用戶故事的習慣................................................................................... 130檢視產出............................................................................................................. 131你又不是用戶...................................................................................................... 132開發過程就是學習的過程................................................................................... 133不僅僅是軟件...................................................................................................... 134為學習做計劃，學習如何做計劃........................................................................ 134第10 章做產品好比烤蛋糕........................................... 135食譜..................................................................................................................... 135切分大蛋糕.......................................................................................................... 137第11 章碎石行動......................................................... 141故事的大小很重要............................................................................................... 141把故事比喻為石頭............................................................................................... 142史詩故事是大石頭，有時可以用來攻擊他人...................................................... 144用主題來組織故事............................................................................................... 145忘掉這些術語，專注于講故事............................................................................ 145從機會開始.......................................................................................................... 146探索最小可行方案............................................................................................... 147在交付階段深入每個故事的細節........................................................................ 148在開發過程中保持日常對話................................................................................ 150評估每一份產出.................................................................................................. 151與用戶和客戶一起評估....................................................................................... 152與業務干系人一起評估....................................................................................... 152發布和持續評估.................................................................................................. 153第12 章誰是碎石負責人.............................................. 155有價值的-可用的-可行的.....................................................................................156一個成功的探索團隊需要更多的人參與.............................................................158神勇三蛟龍..........................................................................................................159產品負責人好比音樂制作人................................................................................162這項工作并不簡單...............................................................................................163第13 章從機會開始.................................................... 165針對機會展開對話...............................................................................................165深入挖掘機會，丟棄機會或思考機會.................................................................166機會不應該是一種委婉的說法............................................................................170故事地圖和機會..................................................................................................170挑剔.....................................................................................................................176第14 章通過探索來建立共識....................................... 177探索不是開發軟件...............................................................................................177探索的4個核心步驟.............................................................................................178探索活動、討論和工件.......................................................................................191探索的目的是建立共識.......................................................................................192第15 章通過探索來進行驗證性學習............................. 195大多數時候，我們其實都是錯的........................................................................195糟糕的往事..........................................................................................................196同理，聚焦，形成想法，制作原型，測試.........................................................197如何把好事弄糟..................................................................................................200短期驗證學習循環...............................................................................................201精益創業思想改變產品設計................................................................................202故事和故事地圖呢...............................................................................................206第16 章提煉、定義和開發........................................... 209卡片，對話，更多卡片，更多對話…… ...........................................................209細分和提煉..........................................................................................................209故事工作坊..........................................................................................................210在沖刺或迭代計劃階段開展故事對話................................................................. 213人人參與并非明智之舉....................................................................................... 215分解和瘦身.......................................................................................................... 217如何在交付階段使用故事地圖............................................................................ 222如何使用故事地圖來可視化進展........................................................................ 222在故事工作坊中使用簡易地圖............................................................................ 223第17 章故事呢，就好比《行星戰機》.......................... 229把碎石子兒重新聚集起來................................................................................... 230地圖繪制要適度.................................................................................................. 232千萬不要小題大作............................................................................................... 233第18 章開發完成后怎么學習....................................... 235團隊回顧............................................................................................................. 235和團隊外的角色一起回顧................................................................................... 238夠用..................................................................................................................... 240向用戶學習.......................................................................................................... 241從發布中學習...................................................................................................... 242預定計劃中的結果............................................................................................... 242使用故事地圖來評估發布是否準備就緒............................................................. 243結語........................................................................... 245
