Linux|軟件項(xiàng)目管理 4.3.敏捷需求建模方法 Windows|軟件|Ubuntu|操作系統(tǒng)

文章圖片

文章圖片

文章圖片

文章圖片

文章圖片

文章圖片

4.3.敏捷需求建模方法第四章軟件需求管理
前言大家好，這節(jié)我們學(xué)習(xí)軟件項(xiàng)目管理---敏捷需求建模方法。
一、建模方法
敏捷思維認(rèn)為項(xiàng)目需求是慢慢清楚的過(guò)程，對(duì)需求可以采用漸近明晰的方法應(yīng)對(duì)變化。敏捷需求從Product Backlog(產(chǎn)品待辦事項(xiàng)列表)開(kāi)始，需求的來(lái)源包含產(chǎn)品想法的一個(gè)有序列表，一個(gè)長(zhǎng)短不定列表，可以是模糊的或是不具體的，逐漸完善，越來(lái)越明確。每個(gè)迭代開(kāi)發(fā)過(guò)程從產(chǎn)品待辦事項(xiàng)選擇部分需求以及細(xì)化形成Spring Backlog ，細(xì)化的過(guò)程就是編寫(xiě)Story的過(guò)程。
Story的涵義：按照迭代計(jì)劃逐步細(xì)化需求形成Story(故事)鼓勵(lì)開(kāi)發(fā)人員、測(cè)試人員、業(yè)務(wù)分析人員和產(chǎn)品負(fù)責(zé)人合作編寫(xiě)故事確保所有的故事都足夠小可以持續(xù)交付工作。最好每天完成至少一個(gè)故事。
因此，敏捷需求是通過(guò)User Stories（用戶故事）來(lái)體現(xiàn)的，我們知道UML需求是從use case（用例）開(kāi)始的，敏捷是從user stories開(kāi)始的，他們的涵義基本一致的，而用戶故事按照一定的語(yǔ)法形式進(jìn)行表示，不需要技術(shù)語(yǔ)言來(lái)描述，只是以客戶能夠明白的，簡(jiǎn)短的形式來(lái)表達(dá) 。
【Linux|軟件項(xiàng)目管理 4.3.敏捷需求建模方法】一個(gè)典型的描述模板如下：AS a作為某類(lèi)型的用戶， I wan希望達(dá)到什么目標(biāo) ， so that原因如何如何。

這是一個(gè)具體的user stories例子：這個(gè)故事是文件備份功能， stories描述如下：作為一個(gè)用戶，希望備份整個(gè)硬盤(pán) ，以便工作內(nèi)容不會(huì)丟失。獲取到user stories后，需要與客戶進(jìn)行分析，相互溝通，討論，并生成Story 。那么如何評(píng)價(jià)一個(gè)story是一個(gè)好的story呢？有一些標(biāo)準(zhǔn)是可以參考的。例如INVEST ，那么他就描述了好的story的六個(gè)特征：I代表獨(dú)立特征， N代表清晰描述， V代表需求的價(jià)值特征， E&S代表比較小，足以進(jìn)行估算。

那么Story呢常常寫(xiě)在卡片上，所以稱(chēng)為Story cards ，然后可以部署到墻上，可以討論，這些都代表著需求分析從傳統(tǒng)的寫(xiě)需求過(guò)程到討論需求的過(guò)程。

那么這是部署到墻上的Story ，成為Story wall 。

二、Story排序我們知道需求分為功能性需求和非功能性需求，我們前面用Story描述了功能需求。其實(shí)也可以用Story來(lái)描述非功能性需求，例如我們可以看：這是用Story來(lái)描述的非功能性需求描述了系統(tǒng)運(yùn)行環(huán)境開(kāi)發(fā)語(yǔ)言的兼容性以及系統(tǒng)的健壯性。

迭代開(kāi)發(fā)是基于優(yōu)先級(jí)的，因此需要對(duì)Story進(jìn)行優(yōu)先級(jí)的排序，我們可以遵守一些規(guī)則來(lái)對(duì)Story來(lái)進(jìn)行排序。