1.需求分析的演變 在需求分析方面,敏捷ACP相對于傳統(tǒng)PMP項目管理有其顯著的改變,從冗長的需求文件演變成短小精悍的用戶故事。用戶故事的目的是以更快的速度、更少的消耗應(yīng)對現(xiàn)實世界需求的快速變化。用戶故事的描述只要足夠(Enough)就好,細(xì)節(jié)描述可以通過與客戶或用戶進一步討論確認(rèn)。每個用戶故事可以以用戶故事卡片的形式寫到開發(fā)團隊的任務(wù)看板上。用戶故事卡片的背面會記錄該用戶故事的驗收條件和可以確定故事完成的所謂定義或標(biāo)準(zhǔn)。 2.用戶故事的要點 用戶故事的基本格式是“作為(角色),我想要(功能),以此實現(xiàn)(商業(yè)價值)”。角色即為使用這個待開發(fā)系統(tǒng)的角色,功能是該角色的具體需求(Requirement),商業(yè)價值是最根本或深層次的需要(Need)。每個用戶故事要限制其大小,理想的情況是所寫的故事能夠讓一兩個程序員花半天到兩周時間完成代碼和測試。通常通過故事所對應(yīng)故事點的多少來衡量完成每個故事的可能工作量。故事點是一個相對估計的方法,表明一個故事相對于其他故事的大小和復(fù)雜度。不同項目團隊的故事點的設(shè)定不盡相同,不具備彼此工作量的比較意義。開發(fā)團隊根據(jù)自身的速率(即每次迭代完成故事點的能力)來衡量把多少個用戶故事納入本次迭代。 3.用戶角色的建模 通過傳統(tǒng)PMP中涉及的頭腦風(fēng)暴和名義小組會議等形式列出初始的用戶角色,通過親和圖來對所有用戶角色進行二次分類,最終確定待開發(fā)系統(tǒng)的用戶角色。通過應(yīng)用敏捷項目管理的虛擬人物和極端人物的方法來編出可能遺漏的用戶故事。比如考慮同時擁有多個男友的女子想要額外的保密需求。 4.故事詳細(xì)的獲取 用戶故事一般是用業(yè)務(wù)語言寫成的句子,通常最好由用戶或客戶來寫。如果用戶不愿意寫的話,開發(fā)團隊可以通過訪談、問卷調(diào)查、觀察和故事編寫工作坊等形式來開展實施。故事編寫工作坊是快速捕撈故事最有效的方法,建議在開始每個發(fā)布計劃之前舉辦。通過工作坊畫出待開發(fā)系統(tǒng)內(nèi)部高層級之間的交互關(guān)系,并構(gòu)建可能的系統(tǒng)原型。需求一旦被合理的捕獲,產(chǎn)品經(jīng)理和開發(fā)團隊可以對一些大的史詩故事(Epic Story)進行進一步裂解,通常分解為可在一次迭代中就可以完成的用戶故事,并且根據(jù)表征商業(yè)價值的不同對用戶故事進行優(yōu)先級排序。最后,通過用戶故事地圖、發(fā)布計劃和迭代計劃等方法把用戶故事納入不同的發(fā)布或迭代中。 |
|