大家都認為，弄清楚需求、講好使用者故事,是PO的責任(因為Scrum 是這麼說的)。但我們也都知道如果對工作，沒有深入的了解，是絕對無法把事情作好的，因此工程師一定要比誰都更了解需求。也就是比誰都更會講故事 — 軟體開發是一種工藝。
(會講故事，所指的是對劇本也就是使用者故事的描述及場景深度的了解,而且能表達的出來。當然，並不是一定要真的強迫工程師在大家面前說故事。其實真正說出來比空想的要好上許多，只是太浪費時間了。但通常我會透過跟開發團隊坐下來以比較輕鬆、非正式的聊天方式《用問答的方式》，設法激發他們進行超過Scrum基本會議的討論。當然，要不要這麼作完全視團隊所面臨的問題了，基本上抉擇就是會不會太浪費時間，這是底線。至於為什麼要作超過Scrum規範的討論呢? 理由是追求更「敏捷」)
.
重點：
* Scrum 遇到需求糢糊，不知從何下手的時候，怎麼辦？
* 讓工程師們看著影響地圖impact mapping說故事。
Scrum 對需求糢糊，不知從何下手的時候，該怎麼辦呢？
一個好的作法是透過一種稱為「集思廣義」的作法(很流行的作法，看起來也很客觀，可以治標，至於該不該這麼作？就要視團隊的狀況而定囉!)。首先，尋找有經驗的專家學者二至三名，然後讓他們和需求的相關人員共聚一堂一起來發覺、討論需求。大家一起透過腦力風暴的方式產出許多使用者故事來描述需求。接著，運用「使用者故事地圖」user story mapping 將需求階層式巨觀的大架構(big picture)給呈現出來，並以此作為需求的骨架。最後，再依照著PO所訂的使用者故事地圖的優先順序，逐一的將需求放進Sprint中來進行開發的作業，讓它們成為每個Sprint的開發目標。用這種方式來找到較明確的需求，也就是透過階層化的方式讓需求依大小及先後順序更明朗化，透過看見需求的共同目標來讓問題變得更容易解決些。
一些疑惑：
？真的能找到厲害的專家來協助嗎？值得嗎？還是找曾經作過的長官來參與就ok了?(千萬不要和直屬長官合作，說來話長XD)
？ 應該產出多少張需求呢？200、300還是400張。一張使用者地圖就夠了嗎?
？ 排成使用者故事地圖了。但是需求，還是覺得很糢糊？
》看起來似乎這麼作便能解題，但是你的心裡一定不免有一些疑惑，這樣的處理方法之下，我們到底作對了多少？又作錯了多少？怎麼作才對呢?
其實，真正的關鍵是出在治本或是治標的問題上頭。
上面的方法理想化了一點，它是治標之道，基本上可以解決問題，只要能專注的去執行它便會有效果的。真正值得你關注的，應該是你負責進行開發作業的工程師，他對需求的了解程度才是重點，解決了這個問題才是真正的治本！
你看見了嗎！工程師也看見了嗎?
需求必經之路就是討論的過程，唯有透過討論來取得溝通上的共識，才可能開始開發的作業。而談到溝通的時候，說故事則可能是最佳的溝通方式之一，所以敏捷開發以使用者故事的方式來描述需求。但工程師很少說故事的(他們通常沒經過太久的討論就迫不及待的直接將使用者故事breakdown 成Task了，而且還是以真正的時間小時或天來作估算，至於什麼是故事點story point？工程師總是認為它太抽象了，好像沒什麼作用？！還是直接用小時來作估算比較實用，如果你這麼作了，那真是可惜，它破壞了敏捷對需求的不確定解決之道，也就是只作相對估算，而不作絕對性的猜測)。要對如何來維持需求自動調整的素養，往往是敏捷開發的一個基礎課題，是一般工程師在開始實行敏捷化時較不容易接受的原因。多花一點時間來作訓練是值得的，通常最適宜的訓練時機點是refinement meeting的所謂的前置作業時期。
聆聽負責開發的工程師描述還沒開發但預備進行開發工作的作法「工程師說故事」是一種好的需求探討與協作(聽眾的回饋是一大重點，千萬別把它稱作是工作報告，那就太waterfall了)。
.
我還在找怎麼怎麼稱呼它會比較合適的名稱，就先叫它"工程師說故事"吧XXD。
.
但問題是，大部份的工程師都不擅長說故事。如果連需求都描述不好，又如何能開發出符合需求的好產品呢?
.
工程師能好好的描述需求的時候，才可能真正的解決問題
講故事太太重要了，尤其是講到讓別人可以感同身受的時候，這就成功的達到了溝通的最高境界。那些成名或成功的電影製作也就是這麼回事。從原著劇本到改編劇本，然後到每個演員的過場劇本，它們都有著相同一致的目標，就是感動你我。只要我們受到感動了，它也就成功了。要知道如果將故事講得凌亂無序，真正的需求又怎能浮現出它的輪廓來，目標也才可能逐漸的變為清晰而可見了。
.
全力以赴是唯一的選項 — 飛越奇蹟 Eddie the Eagle.
.
老闆老以為產品沒作好時，最難過的人是他。其實「掉東西的人，比送東西的人還要難過」。工程師接到任務在寫程式的時候，只有會不會的問題，很少有人會故意偷斤減兩的,每次都一定是全力以赴的！要知道，開發人員只要看到需求下來，總是立刻就用盡全力來撰寫程式的，也不知浪費了多少個深夜的好眠，就為了完成任務。但產品究竟是為什麼還會有那麼多問題呢? 答案是，因為一開始就沒搞得很清楚啊?！(要知道，在開發產品的時候，正確的方向，其實比速度更重要太多了)
.
DoR 就是開始開發動作時的底限
用「問五個W」的方式作開始很直覺也很直接，是很好的作法。但如果能採用impact mapping的方式，讓工程師來看圖說故事的話，那就更棒了。原因是，工程師可以依據影響地圖的路徑開始作故事的描述。而聽眾也可以看到它上、下有關係物件的陳列，再來聽故事的說明時，自然就清楚多了。
.
小結：
請讓工程師們看著影響地圖 Impact mapping說故事！
需求開發上的工具不多，較有名的有 Jeff Patton的「使用者故事地圖」,再來便是 Zojko的「影響地圖」了。許多人都認為二者十分相似，運用起來應該是二者選擇其一的抉擇問題，但實際上它們是非常適合相結合的。使用者故事地圖能讓我們看見需求的 whole pictures,而影響地圖則可以讓工程師看見業務目標所對應到的開發功能，並依照影響路徑來說故事。二者缺一則「對需求到底準備就緒了嗎?」就不容易弄清楚了，也就不容易作到治根或治本之道了。(請注意，impact mapping的運用方式一定是部份的。只有針對重要的、複雜的功能才有必要花這個時間)
.
DoR: Definition of Ready 需求是否備妥的定義
DoD: Definition of Done 完成的定義
.
DoR是敏捷開發的大門,DoD則是Sprint成果的關鍵。
DoR的目的其實是為了DoD.它決定了團隊是否能順暢開啟Sprint衝刺速度的關鍵。但它太抽象了，不但沒個準則又要讓還沒開始開發作業的工程師來決定需求的資料是否備妥了，還真難！因此，每當有負責的工程師把一長串的使用者故事製作成excel表格用來確認DoR的項目是否備妥時，我就會有一種帶他們使用Waterfall的罪惡感。在敏捷開發中很少提到DoR的，正是它太容易走叉了，如果因此而落入傳統的開發方式，則不如還是不要好了。這一點在組織越龐大，分工越細的地方越容易發生，不得不時時警惕！
正是為此我才會致力於提倡讓「工程師說故事」這個作法。想用抽象化的故事描述來克服未來的、那些不確定性的因素，企圖在抽象轉向明確化之間先行解題。這裡「解題」的意思是指先用完整、抽象化的產品敘述來描朔產品的雛形，用它來取代看見需求直接就Coding下去，太快明確化的弊端。讓工程師在需求探討的時候先抽象化的進行解題的思維，就此加深對需求較為全面性的了解，而不是一如以往的，一味的用嚐試錯誤的方式進行開發。
Ruddy Lee 分享空間 