00.使用者並不知道所有的需求，所以不能單純依靠引出（elicitation）
01.不同大小的網用來捕獲不同大小的需求。第一遍，我們可以用大網眼的漁網撈一遍需求池，一次得到所有的大需求。通過這些大需求，形成對軟體的整體感覺。接下來，用網眼稍微小一些的漁網得到中等大小的需求，暫時還不用顧忌那些小需求。
02.拖網表達了另乙個含義：需求會想魚一樣，會成長，也可能會死亡。今天漁網可能會漏掉乙個需求，因為這個需求對於系統來說不重要。但是，根據每輪迭代的反饋，系統會朝著事先不可預知的方向發展，有些需求會變得越來越重要。同樣，有些曾經被認為是重要的需求，重要性可能會降低，有時甚至降低到我們認為這些需求已經無效。
03.我們承認無法為乙個專案編寫出所有的故事，我們還是應該在早期嘗試編寫我們可以編寫的故事，即便許多故事還只能停留在十分籠統的階段。使用故事的好處之一就是可以用不同的詳盡程度來編寫。
04.我們使用的技巧必須是足夠輕量的，並且不戳戳逼人，可以持續地、或多或少地應用於故事蒐集：使用者訪談、問卷調查、觀察、故事編寫工作坊。
05.僅僅因為這些問題是由使用者提出就認為只是使用者才有資格提出解決方案，這種觀點是不對的。
06.如果有機會觀察使用者使用軟體的情況，千萬不要錯過。這種機會可以讓你快速直接地從使用者**獲得反饋，從而可以更早、更頻繁地發布軟體。
07.扔掉原型
在畫好簡單原型後幾天內，一定要仍掉或擦掉它。原型並不是開發流程中的乙個長期工件，因為長期留著可能會導致不必要的困惑。如果覺得在故事編寫工作坊中還沒有發現所有故事，可以把原型保留幾天，在看看是否還能寫出一些漏掉的故事，然後在考慮扔掉它。
*使用者接下來最有可能做什麼？使用者會在這裡犯什麼錯誤？在這裡，使用者會有什麼困惑？使用者需要什麼額外的資訊？
08.如果乙個故事是多餘的或者能被更好的故事替換，就扔掉這個故事。
09.留意在故事編寫工作坊中誰的貢獻更多。有時，有些參與者在大部分或者整個工作坊期間都保持沉默。如果有這樣的情況出現，在中間休息時去和這個參與者談談，確定他並不是不適用這個過程。有些參與者不願意在同時或上司面前說出自己的想法，因此不要在整個過程中評價某個故事好或壞。一旦參與者覺得大家只是在記錄而不是評價故事，會更樂意參與。
10.我再次重申故事編寫工作坊中的討論應在較高層面上。我們的目的是在短時間內寫出更多故事。這不是設計介面或者解決問題的時候。
敏捷讀書之使用者故事 《使用者故事與敏捷方法》解讀
本期分享mike cohn 使用者故事與敏捷方法 精益思想五步 價值，價值流，流動，拉動，盡善盡美。使用者故事是精益思想五步的核心載體。首先，使用者故事是價值載體，是承載使用者價值的基本單元。使用者故事要承載價值，而價值也要承載在使用者故事這種歸一化的載體中。其次，使用者故事是節拍器。故事有節奏的流...
08 使用者故事與敏捷方法 估算使用者故事筆記
00.估算故事最好方法 無論什麼時候獲得有關故事的新資訊，都允許我們改變之前的想法 適用於史詩故事和小故事 不需要花很多時間 提供進度和剩餘工作的有用資訊 不太精確的估算也不會有太大問題 可以用來制定發布計畫。01.程式設計師估算時，客戶也可以參加，但是他不能提供他人人的估算或者在聽到自己不贊成的估...
08 使用者故事與敏捷方法 估算使用者故事筆記
00.估算故事最好方法 無論什麼時候獲得有關故事的新資訊，都允許我們改變之前的想法 適用於史詩故事和小故事 不需要花很多時間 提供進度和剩餘工作的有用資訊 不太精確的估算也不會有太大問題 可以用來制定發布計畫。01.程式設計師估算時，客戶也可以參加，但是他不能提供他人人的估算或者在聽到自己不贊成的估...