說明：下面取自于微信對話，介紹了一種敏捷規劃的做法，供參考

唐XX 22:08 @張克強 能否談一下你們 規劃怎么開的
規劃會怎么開的，都有幾種拆分任務的方式？

張克強 22:09 planning meeting 迭代計劃會議
我們不拆任務，只拆故事 ,根據故事流轉來進行 ,看板方式

唐XX 22:11 對拆故事

丁XX 22:11 如果故事復雜度高或是客戶不在現場，可以提前開需求澄清會，為計劃會做準備

唐XX 22:11 我們專門有個迭代準備會。

唐XX 22:11 故事不拆分成具體的開發任務么？

張克強 22:12 不拆任務，看板流轉也可視為任務分解吧

唐XX 22:13 那你把故事拆的很小？？大概多少工作量一個人完成？

張克強 22:13 是的，追求小顆粒度

張克強 22:15 大概多少工作量一個人完成？ 指什么情況？

唐XX 22:15 就是說你這個小顆粒度的 衡量

唐XX 22:15 是3人天 or 5人天？

丁XX 22:16 最大要能在一個迭代內交付

唐XX 22:18 那是否跟蹤進度不是那么透明呢？風險不容易被暴露啊

丁XX 22:18 那當然

唐XX 22:19 我們現在要求一個故事拆分之后，不能大于5人天的工作量

丁XX 22:19 這里指最極端的情況

唐XX 22:19 嗯

丁XX 22:19 正常情況要保證在縱拆的前提下，越小越好

張克強 22:20 看板在于流動，在相同狀態停留時間一樣設計在5天以內

唐XX 22:20 那拆成這樣，就不細分任務了嗎？

清玉 22:21 故事也不是越小越好吧

張克強 22:21 不顯式的拆任務

張克強 22:21 以客戶感知為標準，關于故事的小

唐XX 22:22 就是說直接將 故事貼到看板上，看板上沒有開發任務卡，只有故事卡。。。

張克強 22:22 是的 @唐XX

唐XX 22:23 哦。。那你們早上站會的 怎么講的

張克強 22:25 看板移動

唐XX 22:25 但是前幾天可能沒有故事移動啊

張克強 22:27 也有的，有上個迭代拖下來的，有小的，完成的快

唐XX 22:27 現在很少一個故事、前端、后端同步開發的。。

唐XX 22:28 有點糾結，導致的原因就是，人員配置

唐XX 22:28 比如說有5個后端java開發，只有1個前臺

唐XX 22:28 h5

唐XX 22:29 然后這個故事就拖很久

金XX 22:31 我們有相同問題，人員配置應該是共性問題，值得研究的方向

唐XX 22:31 你們測試發現bug了，怎么在看板上體現的

張克強 22:33 bug對應的故事退回到編碼或者需求環節

唐XX 22:33 要看等級是吧。。1、2級bug就退回。。

唐XX 22:34 退回去可能導致 在制品 增加了

張克強 22:34 故事盡量拆小，解藕，解決同步依賴，但確實總有些同步依賴

張克強 22:35 @唐XX 只要是要修改的bug，都退回 ，不分級別，這樣才能顯示正確的在制品

唐XX 22:37 這些實踐的東西才能解決問題啊

總結

以上是生活随笔為你收集整理的关于敏捷规划的微信对话的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。