1樓：靜聽天際
總結一下，關於題主的幾個問題的回答。
如何分析 user story？
user story 是從使用者的角度提出問題並找到解決方案，進而分解出可執行的 task。假設要給 segmentfault 加個問卷調查功能，那麼就從使用者怎麼使用問卷入手，從各種互動中最終發現頁面具體邏輯和需求，確定需要哪些頁面、如何互動、如何呈現，從而完成分解。
山寨的說，user story 的源頭就是 stakeholder 想要的需求/功能，分解過程就是這個需求怎麼用，最終結果是這個需求怎麼做。其實，這跟傳統的寫產品文件沒有區別，只是能讓整個產品團隊都明白需求點的來龍去脈，也許能夠更加調動所有人的積極性。
就算是設計 api，也可以用 user story，把 api 呼叫者當做 user 來理解就好。
要是不清楚怎麼設計 user story 也沒關係，能分解的需求就是好需求，定出 task 才是關鍵。
如何分解 task？
task 的關鍵是要有一個明確的完成條件，比如實現 xx api、實現 yy 功能點等。如果程式設計師負責寫單元測試用例的話，通過單元測試是一個比較明確的完成條件。
要足夠的小，不能超過 16 小時，或 2 ~ 3 天吧，目的是為了能夠很好的控制延期風險。
不要太小，半天或一天做個需求最舒服了，太小的話計劃所花費的成本可能都大於實現需要的成本了，不划算。
sprint 計劃會議如何開展？
先準備好差不多成型的需求，如果沒有，讓少數一兩個人先細化的差不多。
開會討論需求，讓所有人清楚。有 user story？很好，講給程式設計師聽，讓大家參與進來。沒有 user story？無妨，反正明確了需求讓程式們做就是。
分解 task，確保每個人的 task 足夠明確可完成，不是很大，沒有失衡。
可能要開幾次會議，每次發現有任務分解不下去的時候終止會議，下去解決細節問題，等解決後再開會。
2樓：匿名使用者
諮詢公司當然像忽悠啦，不像才是奇怪呢~以前 stackoverflow 做調查，thoughtworks 是程式設計師最不喜歡的公司（貌似不是之一），可見一斑~
下面我來根據自己山寨的 scrum 理論和實踐經驗，稍微談一下自己關於的理解，不一定正確。由於我並不是對著任何教材或官方文件來回答問題，所以請不要吐槽我說的**不夠標準哦~
scrum 過程的特色在於它是個可控的黑箱。每個 sprint 都是相對固定的時間長度，一旦 sprint 開始，其中的需求就不應該發生改變，時間結束的時候應該能產出計劃好的產品。從外部看來，一個 sprint 就像一個黑箱一樣，給固定的輸入，得到固定的輸出。
為了可控，scrum 的 sprint 計劃會議極為關鍵，要點是保證需求穩定不發生改變。計劃會議的最終目
的是讓 scrum team 中的每個人都明確自己的工作量和依賴關係，而要確定這些東西的大前提就是需求足夠的清晰明確，且 sprint
結束前都不發生任何變化。不變是 scrum 能像黑箱一樣執行的大前提，試想，如果需求做到一半砍掉了或者發生很大的內容變化，以前開會定下的各種
task 就會發生根本變化，導致計劃成為廢紙一張，sprint 也就執行不下去了。因此，一般 sprint 計劃會議最終決策的時候，必須有
stakeholder 過來拍板認可，也算是在這個場合裡給大家一個準信，確保這些 task 像潑出去的水一樣不會再變了。
需求穩定還只是一個要點，最終還是要落實到 task 上。從需求到 task 其實還隔了幾道牆，一方面並不是所有的需求都是真實需求，有時候
stakeholder
自己可能都不清楚自己想要什麼，另一方面從產品概念到實現也不是一目瞭然，需要把各種細節提前約定清楚才行。這裡面就需要引入一些需求分析的工具。
user story
是幫助需求分析的一個工具，各種敏捷方法貌似都比較推崇這種需求分析的方式，這種方式跟寫一個需求分析文件或產品設計文件都沒什麼本質差別，只是個工具。
從題主的描述來看，我猜想你所在的團隊之前應該從未使用過 user story 來分析需求，所以感覺會比較虛也比較難以分解成
task。如果諮詢顧問們無視你們之前的需求文件/產品文件的風格硬要用 user story 來套的話，有可能他們犯了形而上的錯誤。
能夠清晰的分解成可執行、短小的 task 的需求才是好需求，無論用 user story
還是拿友商的同類產品直接山寨還是老闆某天洗澡突發的靈感，只要是個 stakeholder
想要做且細節都定義清楚了的需求都是好需求。反之，如果無法分解，那就是需求分析的失敗了，管你什麼炫酷的方法都是浮雲。像題主所說，一個任務給 200
或 300 的估計，那就是需求完全沒有細化的結果，要知道那個數字的單位一般是小時，而一個 task 一般都不要超過 16 才對。
一旦需求分析完成，分解 task 就應該水到渠成才對。如果技術團隊因為技術細節不確定而無法分解需求，那麼暫停會議，會下討論清楚再來。分解
task 本身沒什麼好說，跟傳統的分任務一回事，其中 scrum 比較可取的一點就是那個 planning
poker，每個人把自己的時間當做資源，通過 planning poker
這種比較好玩的方式分配自己的時間直到時間耗盡。當然啦，這種形式本質上就是想確保每個人都能均衡的完成任務，免得出現瓶頸，如果達到同樣的目的採用其他
方法排任務也無妨。
如何編寫敏捷開發中的user story
什麼是user story？ 30
3樓：匿名使用者
user story是對軟體的使用者或買主有價值的功能點的描述。user stories 由以下三點組成：
用來制定計劃和作為提醒的一段書面描述
用來充實story的細節的談話
測試用例
4樓：匿名使用者
user story描述是通過傳統手寫記錄在卡片上，ron jeffies起了很好的名字，card（卡片），conversation（會話），和confirmation（確認）。思考方法是：card 包含story正文，通過會話得出細節，並記錄在測試用例中。
這種雕刻匾如果用精雕軟體做的話，用的什麼功能？用的多大的刀。？求大神指導，謝謝
用大型雕刻機，你不是賣石頭沒必要買。人工雕也不貴。請問普通 怎麼才能做成雕刻機的圖來進行雕刻？謝謝了！精雕繪圖軟體，維巨集系統雕刻機 普通 瞭解大量資料知道 的立體感怎麼建立，輪廓怎麼修改 描線 內 建模 分色 堆料容 去料 磨光 選刀 出刀路 破解維巨集轉nc 裝載維巨集 對刀 開始雕刻 詳細的做...
用如果那麼如果那麼造句用如果那麼造句
如果你不好好學習，那麼你就不會有一個好成績 如果你不堅持鍛鍊，那麼你就不會有一個健康的身體。如果你不工作，那麼你就沒有錢 如果你沒有錢，那麼你就不能買喜歡的東西。如果你將困難當成千丈溝壑，那麼你將墜入無底深淵 如果你將困難當成墊腳石，難麼你將躍向理想的彼岸。如果沒有雨露的滋潤，那麼花兒也不會開的那樣...
做麵包植物油什麼時候加做麵包如果用植物油什麼時候放
一般油是刷copy在麵包桶上再放入麵糰bai。也就是剛開始的時候du就要用到zhi。製作方法 原料1.1 麵包用麵粉 或高筋dao麵粉 3杯1.2 雞蛋 1個 1.3 牛奶 各種口味均可 200ml 1.4綿白糖3 5大勺 1.5 鹽 1小勺 1.6 黃油 奶油 牛油 20克 1.7 酵母 隨機附贈...