00.使用者故事好處
a.使用者故事強調口頭溝通
b.人人都可以理解使用者故事
c.使用者故事的大小適合做計畫
d.使用者故事適合於迭代開發
e.使用者故事鼓勵延遲細節
f.使用者故事支援隨機應變的開發
g.使用者故事鼓勵參與性設計
h.使用者故事傳播隱性的知識
01.在嘗試之前，你或者會天真地以為只需要把一堆軟體需求寫下來，開發人員就能夠精確地開發出你所想要的。然而，我們有時候連簡單的午餐選單都無法準確地描述，寫出軟體需求的難度可想而知。
02.短時間的即時反饋能促進相互學習與理解。文件所表現出的精準和精確的家鄉不會子啊談話中出現。沒有人會對一次交談簽名確認，所以也不會有人後來拿出來指著說：「就是那次三個月前某周二，你說過密碼不能有數字的。」
03.使用使用者故事的目的並不是讓我們事無鉅細地記錄下想要的特性；相反，使用者故事作為提示語句提醒開發人員在將來需要與客戶進行溝通與交談。
04.我認為，寫出「完美的」需求永遠都是高不可攀、遙不可及的。
05.相對於追求完美的需求，更有價值的是運用頻繁的溝通來加強恰當的故事。
a.使用者及客戶通常都不會準確地知道自己的實際需求
b.即便軟體開發者知道所有的需求，很多需求細節只能隨著他們的開發進展變得清晰
c.就算假設所有的細節可以在前面弄清楚，人們也沒有能力理解這麼多的細節。
d.就算我們真的能理解所有細節，產品的專案也會經常變更
e.人非聖賢，孰能無過
07.這種方式中，他們對需求的思考不斷地建立及討論使用場景，在不同（opportunistic）層面的抽象的設計之間來回切換。一旦發現需要切換抽象層次，他們立刻就會切換思路。
a.不再需要依賴於使用者預先完全了解及溝通他們的確切需求
b.也不再需要依賴於開發人員能夠完全事無鉅細地掌握需求
c.能夠擁抱變化
08.在參與性設計中，系統的使用者作為軟體行為設計團隊的乙份子。他們的參與不是因為管理層的指令（「你們應該組成乙個包括使用者的跨職能團隊」），而是因為他們被所使用的需求及設計技巧大大吸引，從而自動成為團隊密不可分的一部分。從一開始，使用者就在幫助建立使用者介面的原型，而並不是登到審核最初的原型後才參與進來。
09.故事及場景易讀、易懂，因而能激發使用者的積極性，成為軟體設計的參與者。同時，隨著使用者漸漸掌握如何使用對於開發人員直接有用的故事來描繪他們需求是，開發人員與使用者間的關係會白嫩的更加密切和主動。這個良性的迴圈使所有開發中社會及的人或者軟體使用者獲益良多。
10.緣於對面對面溝通的重視，故事能夠促進團隊內隱性知識的積累。開發人員與客戶之間以及他們內部的溝通越密切，越多的隱性知識能得到傳播與加強。
11.故事在乙個團隊內部能大大促進隱性知識的積累，但是還是不適用特大規模多團隊的結構。這時，確實需要把有些交流記錄下來，不然難以保證資訊在大型團隊中充分共享。
12.使用者故事適合於迭代開發，我們很容易從乙個史詩故事入手，並在後來需要時把它分成多個小故事。
敏捷讀書之使用者故事 《使用者故事與敏捷方法》解讀
本期分享mike cohn 使用者故事與敏捷方法 精益思想五步 價值，價值流，流動，拉動，盡善盡美。使用者故事是精益思想五步的核心載體。首先，使用者故事是價值載體，是承載使用者價值的基本單元。使用者故事要承載價值，而價值也要承載在使用者故事這種歸一化的載體中。其次，使用者故事是節拍器。故事有節奏的流...
08 使用者故事與敏捷方法 估算使用者故事筆記
00.估算故事最好方法 無論什麼時候獲得有關故事的新資訊，都允許我們改變之前的想法 適用於史詩故事和小故事 不需要花很多時間 提供進度和剩餘工作的有用資訊 不太精確的估算也不會有太大問題 可以用來制定發布計畫。01.程式設計師估算時，客戶也可以參加，但是他不能提供他人人的估算或者在聽到自己不贊成的估...
08 使用者故事與敏捷方法 估算使用者故事筆記
00.估算故事最好方法 無論什麼時候獲得有關故事的新資訊，都允許我們改變之前的想法 適用於史詩故事和小故事 不需要花很多時間 提供進度和剩餘工作的有用資訊 不太精確的估算也不會有太大問題 可以用來制定發布計畫。01.程式設計師估算時，客戶也可以參加，但是他不能提供他人人的估算或者在聽到自己不贊成的估...