本次迭代的任務目標和計劃，讓所有項目成員能在接下來的日子里更流暢地進行各自的工作。在這個會議上，項目經(jīng)理會和團隊一起對用戶故事進行工作量評估，并拆分成具體的任務點，項目組成員根據(jù)自身情況主動領取任務，如果存在困難應該在這個會上提出，大家共同商議出解決方案。
（迭代+計劃會議+拆故事+領任務）
小項：用戶故事，這是個新的概念，您能具體介紹一下么？
Y先生：用戶故事（User Story）是從用戶的角度來描述用戶渴望得到的功能，對于敏捷開發(fā)來說，它是開發(fā)的基礎。不同于傳統(tǒng)的瀑布式開發(fā)方式，用戶故事是把原本需求拆成最小粒度的Story，以方便拆分Task，估計開發(fā)時間，領取開發(fā)任務，它應遵循INVEST規(guī)則（Independent 獨立性、Negotiable 可談判性、Valueable 有價值性，Estimable 可估計性、Sized Right 合理的尺寸、Testable 可測試性）。
用戶故事的拆分有兩個層面：大故事拆分成小故事，小故事拆分成任務。大故事拆解成小故事除了能通過“小規(guī)?；适?rdquo;防止小瀑布，同時也有助于識別出需求的某些細節(jié)；而小故事到任務的拆分，也就是我們常說的任務分解，可以看作類似瀑布模型中的詳細設計，在這種方式中，每個任務都能在較短的時間（1-2天）完成，完成所有任務后能達到高質(zhì)量實現(xiàn)用戶故事的目的。有的人認為任務很難拆分，甚至沒有必要拆分，這種思想就像是在瀑布開發(fā)模型中不做詳細設計一般，設計思路還沒有理清就撲入了代碼的海洋，這種做法寫出來的代碼質(zhì)量可想而知。
任務分解同時可以用來制定工作計劃，分解出來的任務就是在實現(xiàn)故事的過程中要做的事情，每個任務需要的時間就是做這些事情分別需要的時間。從這個角度來看，如果我們很夠很好地將故事分解成任務，準確地評估故事的規(guī)模，無論是使用物理看板還是TFS等工具進行任務管理，都能較好地做好迭代計劃并順利執(zhí)行。下面是一個簡單的在線購書網(wǎng)站的用戶故事拆分示例：
小項：那么采用用戶故事評估出來的工作量會與中心目前采用的功能點估算結果相沖突么？
Y先生：這個情況我們也有考慮到，目前我們是以中心功能點估算的結果為依據(jù)，將工作量分配到以用戶故事分解出來的任務下，所以不存在沖突的問題。
小項：了解了，那除了任務分解方面，咱們還有哪些其他做法與敏捷相關？取得的效果又如何呢？
Y先生：站會，這個非常重要?，F(xiàn)在每天早上8點半到9點來我們辦公室，會看到所有的小組基本都在開站立會議，這個會議很短，一般在15分鐘以內(nèi)，每個人只需要回答三個問題：上次會議后完成了什么？下次會議前需要完成什么？遇到什么困難和阻礙？這個步驟一般都是在看板前完成，各項任務可視化的討論方式有利于對項目整體執(zhí)行情況的把握，問題能夠盡快地被發(fā)現(xiàn)和得到解決，保證項目按計劃進行。
另外還有每個迭代結束時的迭代評審和迭代回顧，這個我們通常作為一個會議來開，時間一般定在每個迭代結束的當日下午，在這個會議上大家會展示本階段的項目成果，這是個重要溝通和反饋的過程，同時在這個會議中，會對本次迭代所有的故事、度量、事件從以下三方面進行歸類：做的好的、做的不對的、改進意見。通過這個會議的開展，達到項目過程的不斷改進和團隊的不斷進步。
總之敏捷是一種思想，要想真正達到完全實現(xiàn)我們?nèi)孕璨粩嗵剿?，還是開頭那句話：敏捷嘗試，我們一直在路上。
小項：好的，這次的訪談就到這里吧，感謝Y先生帶領我們了解了敏捷那些事兒，屏幕前的你有沒有覺得受益匪淺呢？還是你也有些話不吐不快？如同前幾期所說，項目管理方面不管您有任何的問題和疑問，或者是好的經(jīng)驗想要分享，歡迎聯(lián)系小項，我們將會懷著最大的誠意，歡迎您的到來！(文/小項)
