軟體專案管理 4.3.敏捷需求建模方法

專案管理事業的愛好者發表於2022-05-28

軟體專案管理 4.3.敏捷需求建模方法

【公眾號 “專案管理研究所” 將會第一時間更新文章並分享行業分析報告】
歸檔於軟體專案管理初級學習路線
第四章 軟體需求管理
《初級學習路線合集 》


前言

大家好,這節我們學習軟體專案管理---敏捷需求建模方法。

一、建模方法

敏捷思維認為專案需求是慢慢清楚的過程,對需求可以採用漸近明晰的方法應對變化。

敏捷需求從Product Backlog(產品待辦事項列表)開始,需求的來源包含產品想法的一個有序列表,一個長短不定列表,可以是模糊的或是不具體的,逐漸完善,越來越明確。

每個迭代開發過程從產品待辦事項選擇部分需求以及細化形成Spring Backlog,細化的過程就是編寫Story的過程。

Story的涵義:
按照迭代計劃,逐步細化需求,形成Story(故事)
鼓勵開發人員、測試人員、業務分析人員和產品
負責人合作編寫故事,
確保所有的故事都足夠小,可以持續交付工作。
最好每天完成至少一個故事。

因此,敏捷需求是通過User Stories(使用者故事)來體現的,我們知道UML需求是從use case(用例)開始的,敏捷是從user stories開始的,他們的涵義基本一致的,而使用者故事按照一定的語法形式進行表示,不需要技術語言來描述,只是以客戶能夠明白的,簡短的形式來表達。

一個典型的描述模板如下:AS a作為某型別的使用者,I wan希望達到什麼目標,so that 原因如何如何 。

這是一個具體的user stories例子:這個故事是檔案備份功能,stories描述如下:作為一個使用者,希望備份整份硬碟,以便工作內容不會丟失。

獲取到user stories後,需要與客戶進行分析,相互溝通,討論,並生成Story。

那麼如何評價一個story是一個好的story呢?有一些標準是可以參考的。例如INVEST,那麼他就描述了好的story的六個特徵:I代表獨立特徵,N代表清晰描述,V代表需求的價值特徵,E&S代表比較小,足以進行估算。

那麼Story呢常常寫在卡片上,所以稱為Story cards,然後可以部署到牆上,可以討論,這些都代表著需求分析從傳統的寫需求過程到討論需求的過程。

那麼這是部署到牆上的Story,成為Story wall。

二、Story排序

我們知道需求分為功能性需求和非功能性需求,我們前面用Story描述了功能需求。其實也可以用Story來描述非功能性需求,例如我們可以看:這是用Story來描述的非功能性需求,描述了系統,執行環境,開發語言的相容性以及系統的健壯性。

迭代開發是基於優先順序的,因此需要對Story進行優先順序的排序,我們可以遵守一些規則來對Story來進行排序。

例如MoSCow,他是對Must have(系統必須實現的功能,否則系統無法執行),Should have(雖然很重要,但是可以省略的功能),Could have(擴充套件性功能,但是要求不是很低),Want to have(一部分使用者的想法)來進行排序的。


例如採用MosCoW規則對某一個支付功能Story來排序,其中Must have是系統必須接受Visa卡和Master卡,Should have是可以增加美國信用卡,Could have可以增加PayPal卡,Want to have可以考慮最後增加禮品卡。


總結

總之 敏捷專案需求通過討論的方式,循序漸進的方式進行確定的,並且可以採用user stories進行描述。

到這裡,第四章 軟體需求管理就講解完畢了!下一章將全面介紹軟體專案任務分解~

如果您覺得這篇文章有幫助到您的的話不妨點贊支援一下喲~~?

後續將持續更新【軟體專案管理初級學習路線】的全知識點,大家感興趣的多多關注博主喲~
————————————————

相關文章