
「User Storying Mapping」讀書筆記 (6)
Ch 8. It’s Not All on the Card, Ch 9. The Card Is Just the Beginning, Ch 10. Bake Stories Like Cake & Ch 11. Rock Breaking
這幾章講比較細一點的執行層面。
卡片上的內容
故事卡(上面可能只列了簡短故事標題),可以幫助對話溝通,但是開發軟體的人,往往不只有工程師,不同部門的人,會有不同的意見和聲音。例如:
專案經理:這個功能或產品,對顧客、使用者和我們的公司有什麼助益?這個功能要花多久的時間?有什麼風險?目前狀況怎樣?
商業分析師:這個會怎樣運轉?商業規則是什麼?
使用者經驗設計師:使用者是誰?他們的目標是什麼?
測試人員:極端情境是什麼?有什麼狀況下會失敗?
開發人員:這個軟體看起來會是怎樣?互動會是怎樣?
There are many different kinds of conversations with different people for every story.
因此,一張小卡顯然是不夠的,沒辦法紀錄各個面向的考量。我們可以參考圖書館的目錄索引卡(library card catalog),轉變成開發時可以使用的卡片。

卡片上可以註明標題、敘述(誰、什麼、為何、相關連的故事)、故事編號(可能會有系統記錄這個故事,這個編號是拿來做後續追蹤)、預估所花的資源(規模、人員、預算)、價值(重要性排序)、評判標準(怎樣這個功能才算成功?)、依存度(是不是需要另一個功能才能完成整個故事?)、狀態(什麼時候要發布、已經進行中還是已經完成)、日期(故事創建日期、開始日期、完成日期)
這個卡片的主要功能:幫助討論建立共享見解、幫助記憶、幫助追蹤。
故事卡只是開發過程的開端
整個開發過程,可能先從故事卡開始,然後會再補充流程圖、線框圖、人物誌等,幫助討論,然後有共識之後,就進入開發階段,工程師寫程式、測試人員測試功能等,然後再進到使用者實際使用,或是關係利益人也有回饋,收集可以改進的地方,然後再次進到故事卡。
故事卡注重大家可以討論,開啟對話,也別於以前文件式的溝通方式,大家只看文件檔,沒有討論,釐清問題。
在開發時,也可以討論產品的品質,由三個面向下手:
使用者經驗:從目標使用者的回饋來看,是不是夠直覺?是不是用起來很好玩?產品看起來美嗎?是否符合品牌形象?
功能層面:運行起來沒有錯誤,沒有 Bug。
程式層面:是不是和標準一致?是不是容易擴充或是維護?
大家要記得一點,我們都不是使用者,真心建議要找使用者來做測試,已獲得回饋,記得我們就是希望在學習的過程中,慢慢修正軟體,讓它符合使用者想要的。
像做蛋糕一樣,拆解任務
故事(Story)主要寫我們想要完成和評估測試的東西,而交付任務(Delivery Tasks)就是我們想要完成這個故事,必須要做的工作。你可以想像你想做一個蛋糕,蛋糕是要給小孩慶生用的(有使用者、有情境),你要完成一個蛋糕,就必須有食譜,需要備料、混合原料、放入烤盤、放入烤箱、裝飾蛋糕,一步一步完成蛋糕。開發程式也是一樣的道理,你需要設計使用者介面、定義好商業規則、可能寫主程式、需要抓哪些資料、要做手動測試還是自動測試。
當然有時候如果你想做一個高級豪華大蛋糕,時間、預算都不夠,這時候你就要考慮替代方案,可能改做很多個杯子蛋糕,總比做一個不熟的大蛋糕來的好。所以程式開發也一樣,可能大功能無法在有限預算內完成,我們要思考替代方案,找尋其他不會耗費那麼多資源的方式,把功能做拆解,完成一些小功能,可能結果稍差一些,但還是能幫助使用者完成任務。
If the story describes a solution that’s too expensive, consider a different solution that helps you reach the goal.
If the story describes a solution that’s affordable but big, break it into smaller parts that allow you to evaluate and see progress sooner.
Don’t break down big things into big plans. Break big things into small things with small plans.
怎樣的大小才合適?
剛剛說到我們可以拆解故事,來不及做大蛋糕,我們可以做小蛋糕,但蛋糕究竟要多小才是剛好適合的?從使用者個角度來看,能幫助他們完成他們想做的事,就算合適。從開發團隊角度來看,這個功能只需要幾個工作天就可以開發並測試完畢,就算是合適大小。從商業角度來看,他能幫助公司達到商業目標成果,就算合適。
A right-sized story from a user’s perspective is one that fulfills a need.
A right-sized story from a development team’s perspective is one that takes just a few days to build and test.
A right-sized story from a business perspective is one that helps a business achieve a business outcome.
其實你也可以把故事想像成石頭,巨石可以敲碎成岩石,岩石還可以敲碎成礫石,本質上都是石頭,只是不同大小有不同名稱。而討論,就是可以把大故事,變成小故事最好的方式。

故事也有大有小,史詩鉅作(Epic)、故事(Stories)、主題故事(Themes),主題故事就是幾個故事分類在一起,在主題下,每個故事都有相關連。但其實這些定義沒那麼重要,重要的是怎樣才是比較重要故事,我們可以拿來開發。
我們會先從「機會」開始討論起,我們可能會發現一些使用者的問題,然後可能也有一些點子,然後我們會評估這些點子是否值得執行,或是這些問題真的值得解決。
Use opportunity discussions to agree the problem is worth solving — to make a go-forward or trash decision.
在決定我們的機會點後,我們會試著找去最小可行性的解決方案,我們會更深入討論我們的使用者是誰?他們的需求為何?他們現在怎麼解決他們的需求?我們的方案會怎樣更好?我們的方案會怎樣運作?需要多長的時間見出來等。
Use discovery conversations and exploration to find a small, viable solution.
然後我們會開始討論還軟體和服務還有什麼細節沒注意到的,有哪些還要補充。然後大家確認我們要建的東西,哪些要先著手。在開發過程中,仍然還可以持續給予建議和溝通。
Use deep-dive story workshops to discuss the details, break down stories, and really agree on specifically what we’ll build.
Use conversations as you build to fill in details and give feedback on what’s being built.
可能會討論產品的品質如何?使用者體驗是否愉悅?功能是否運行無礙?哪些已經做完,哪些有延遲?工作流程有什麼地方可以改進?除了內部團隊的回饋外,我們也會詢問使用者真正的意見,和他們做測試,觀察他們在使用我們的產品,有沒有發生什麼問題。或是產品是不是真的幫助他們達成他們的目標。我們也要讓關係利益人知道我們目前的進度到哪,有獲得什麼意見。我們會用一些客觀的標準來評估產品的成果,可能透過軟體背後收集到的量化資料、訪談時觀察到的質性資料。這些進一步都可以形成洞見,用以繼續發展我們的產品。
Frequently reflect on product quality, your plans, and the way you work.
Learn by testing meaningful chunks of working software with customers and users.
Keep your progress and quality visible to stakeholders inside your organization.
Use metrics and face time with users to really learn if your target outcomes were met.

