Linux|软件项目管理 4.3.敏捷需求建模方法 Windows|软件|Ubuntu|操作系统

文章图片

文章图片

文章图片

文章图片

文章图片

文章图片

4.3.敏捷需求建模方法第四章软件需求管理
前言大家好，这节我们学习软件项目管理---敏捷需求建模方法。
一、建模方法
敏捷思维认为项目需求是慢慢清楚的过程，对需求可以采用渐近明晰的方法应对变化。敏捷需求从Product Backlog(产品待办事项列表)开始，需求的来源包含产品想法的一个有序列表，一个长短不定列表，可以是模糊的或是不具体的，逐渐完善，越来越明确。每个迭代开发过程从产品待办事项选择部分需求以及细化形成Spring Backlog ，细化的过程就是编写Story的过程。
Story的涵义：按照迭代计划逐步细化需求形成Story(故事)鼓励开发人员、测试人员、业务分析人员和产品负责人合作编写故事确保所有的故事都足够小可以持续交付工作。最好每天完成至少一个故事。
因此，敏捷需求是通过User Stories（用户故事）来体现的，我们知道UML需求是从use case（用例）开始的，敏捷是从user stories开始的，他们的涵义基本一致的，而用户故事按照一定的语法形式进行表示，不需要技术语言来描述，只是以客户能够明白的，简短的形式来表达。
【Linux|软件项目管理 4.3.敏捷需求建模方法】一个典型的描述模板如下：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来进行排序。