1.需求分析的演變

　　在需求分析方面，敏捷ACP相對于傳統(tǒng)PMP項(xiàng)目管理有其顯著的改變，從冗長的需求文件演變成短小精悍的用戶故事。用戶故事的目的是以更快的速度、更少的消耗應(yīng)對現(xiàn)實(shí)世界需求的快速變化。用戶故事的描述只要足夠（Enough）就好，細(xì)節(jié)描述可以通過與客戶或用戶進(jìn)一步討論確認(rèn)。每個(gè)用戶故事可以以用戶故事卡片的形式寫到開發(fā)團(tuán)隊(duì)的任務(wù)看板上。用戶故事卡片的背面會記錄該用戶故事的驗(yàn)收條件和可以確定故事完成的所謂定義或標(biāo)準(zhǔn)。

　　2.用戶故事的要點(diǎn)

　　用戶故事的基本格式是“作為（角色），我想要（功能），以此實(shí)現(xiàn)（商業(yè)價(jià)值）”。角色即為使用這個(gè)待開發(fā)系統(tǒng)的角色，功能是該角色的具體需求（Requirement），商業(yè)價(jià)值是最根本或深層次的需要（Need）。每個(gè)用戶故事要限制其大小，理想的情況是所寫的故事能夠讓一兩個(gè)程序員花半天到兩周時(shí)間完成代碼和測試。通常通過故事所對應(yīng)故事點(diǎn)的多少來衡量完成每個(gè)故事的可能工作量。故事點(diǎn)是一個(gè)相對估計(jì)的方法，表明一個(gè)故事相對于其他故事的大小和復(fù)雜度。不同項(xiàng)目團(tuán)隊(duì)的故事點(diǎn)的設(shè)定不盡相同，不具備彼此工作量的比較意義。開發(fā)團(tuán)隊(duì)根據(jù)自身的速率（即每次迭代完成故事點(diǎn)的能力）來衡量把多少個(gè)用戶故事納入本次迭代。

　　3.用戶角色的建模

　　通過傳統(tǒng)PMP中涉及的頭腦風(fēng)暴和名義小組會議等形式列出初始的用戶角色，通過親和圖來對所有用戶角色進(jìn)行二次分類，最終確定待開發(fā)系統(tǒng)的用戶角色。通過應(yīng)用敏捷項(xiàng)目管理的虛擬人物和極端人物的方法來編出可能遺漏的用戶故事。比如考慮同時(shí)擁有多個(gè)男友的女子想要額外的保密需求。

　　4.故事詳細(xì)的獲取

　　用戶故事一般是用業(yè)務(wù)語言寫成的句子，通常最好由用戶或客戶來寫。如果用戶不愿意寫的話，開發(fā)團(tuán)隊(duì)可以通過訪談、問卷調(diào)查、觀察和故事編寫工作坊等形式來開展實(shí)施。故事編寫工作坊是快速捕撈故事最有效的方法，建議在開始每個(gè)發(fā)布計(jì)劃之前舉辦。通過工作坊畫出待開發(fā)系統(tǒng)內(nèi)部高層級之間的交互關(guān)系，并構(gòu)建可能的系統(tǒng)原型。需求一旦被合理的捕獲，產(chǎn)品經(jīng)理和開發(fā)團(tuán)隊(duì)可以對一些大的史詩故事（Epic Story）進(jìn)行進(jìn)一步裂解，通常分解為可在一次迭代中就可以完成的用戶故事，并且根據(jù)表征商業(yè)價(jià)值的不同對用戶故事進(jìn)行優(yōu)先級排序。最后，通過用戶故事地圖、發(fā)布計(jì)劃和迭代計(jì)劃等方法把用戶故事納入不同的發(fā)布或迭代中。