軟體專案管理 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進行描述。

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

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