當這個問題第一次在我的csm 培訓課堂上被問到的時候，我認為，這是個非常簡單的問題。可是當我試圖回答時，我意識到，事實上並不能簡單的釋解釋這個問題。
在我的培訓課堂上，我已經用「使用者故事」 和「任務」這兩種說法多年，在我頭腦中，兩種措辭是非常清晰的。使用者故事存在於產品待辦事項表中，而任務則是在做sprint計畫的時候被識別出來，進而存在於sprint待辦事項表中。
這樣描述似乎對提問者任然沒有太大幫助， 這就像在說： 鹽是怎樣放到鹽罐子的胡椒是怎樣放進胡椒罐的。 那麼到底最明顯的區別是什麼呢？
在第一次被問到這個問題時，我停頓了一會， 然後確定我能明確的描述兩者的區別。
乙個使用者故事，是由乙個或多個人來處理的，但是乙個任務，則是由乙個人去完成。
讓我們看看是否是這樣的情況：
乙個使用者故事往往是對終端客戶可見的功能特性描述。 交付這樣乙個使用者故事，通常是要涉及到乙個團隊的工作，包括開發，測試，介面設計和分析，資料庫設計 或其他一些工作。
很少或者幾乎不存在乙個使用者故事被單獨的乙個人實現出來（即使這種事情發生，那也是這個人充當了不同的角色。）
乙個任務，從某種角度來講，通常是為了某個具體的點進行編碼，設計，建立測試資料，為某個點自動化，等等，這些事情往往是由乙個人完成的。
你可以辯解說其中一些工作是或者應該通過結對完成，但是我認為這只是個細微，
我說乙個任務就是被乙個人來做的事情，視乎是比較猶豫的， 理由就是，就像許多任務是會議這種事情，比如，需要三個團隊成員參與的設計評估--我任然堅持認為這是乙個任務而非乙個使用者故事。
所以，可能最好的闡述兩者間的區別就是： 使用者故事包含了多種型別的工作，而任務則是受制於單一的工作。
故事與任務
任務 和 故事 的區別是什麼呢？嗯，這個問題問得不錯。區別很簡單。故事是可以交付的東西，是產品負責人所關心的。任務是不可交付的東西，產品負責人對它也不關心。故事如果太大就應該進行拆分，力求保證故事的大小在2至8個人 天之間。否則不好控制。例子 故事拆分為多個故事 故事拆分為任務 我們會看到一些很有趣...
CMMI跟Agile之間的衝突
infoq 剛才在別的討論組上，你還提到了cmmi跟agile之間的衝突，能不能再多講一下你的看法？bas 我認為cmmi一點用都沒有。infoq 呃 bas cmmi關注的是管理和組織，而不是開發本身。在cmmi的一大堆關鍵過程域 key process area 中，只有乙個是跟開發有關係的。大...
13 使用者故事與敏捷方法 使用者故事的優勢筆記
00.使用者故事好處 a.使用者故事強調口頭溝通 b.人人都可以理解使用者故事 c.使用者故事的大小適合做計畫 d.使用者故事適合於迭代開發 e.使用者故事鼓勵延遲細節 f.使用者故事支援隨機應變的開發 g.使用者故事鼓勵參與性設計 h.使用者故事傳播隱性的知識 01.在嘗試之前，你或者會天真地以為...