軟體專案管理 4.3.敏捷需求建模方法
【公眾號 “專案管理研究所” 將會第一時間更新文章并分享行業分析報告】
歸檔于軟體專案管理初級學習路線
第四章 軟體需求管理
《初級學習路線合集 》
前言
大家好，這節我們學習軟體專案管理---敏捷需求建模方法，
一、建模方法
敏捷思維認為專案需求是慢慢清楚的程序，對需求可以采用漸近明晰的方法應對變化，
敏捷需求從Product Backlog(產品待辦事項串列)開始，需求的來源包含產品想法的一個有序串列，一個長短不定串列，可以是模糊的或是不具體的，逐漸完善，越來越明確，
每個迭代開發程序從產品待辦事項選擇部分需求以及細化形成Spring Backlog，細化的程序就是撰寫Story的程序，
Story的涵義：
按照迭代計劃,逐步細化需求,形成Story(故事)
鼓勵開發人員、測驗人員、業務分析人員和產品
負責人合作撰寫故事,
確保所有的故事都足夠小,可以持續交付作業，
最好每天完成至少一個故事，
因此，敏捷需求是通過User Stories（用戶故事）來體現的，我們知道UML需求是從use case（用例）開始的，敏捷是從user stories開始的，他們的涵義基本一致的，而用戶故事按照一定的語法形式進行表示，不需要技術語言來描述，只是以客戶能夠明白的，簡短的形式來表達，
一個典型的描述模板如下：AS a
這是一個具體的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進行描述，
到這里，第四章 軟體需求管理就講解完畢了！下一章將全面介紹軟體專案任務分解~
如果您覺得這篇文章有幫助到您的的話不妨點贊支持一下喲~~??
后續將持續更新【軟體專案管理初級學習路線】的全知識點，大家感興趣的多多關注博主喲~
————————————————
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/498914.html
標籤：其他