软件项目管理 4.3.敏捷需求建模方法

软件项目管理 4.3.敏捷需求建模方法

【公众号 “项目管理研究所” 将会第一时间更新文章并分享行业分析报告】
归档于软件项目管理初级学习路线
第四章 软件需求管理
《初级学习路线合集 》


前言

大家好,这节我们学习软件项目管理---敏捷需求建模方法。

一、建模方法

敏捷思维认为项目需求是慢慢清楚的过程,对需求可以采用渐近明晰的方法应对变化。
软件项目管理 4.3.敏捷需求建模方法

敏捷需求从Product Backlog(产品待办事项列表)开始,需求的来源包含产品想法的一个有序列表,一个长短不定列表,可以是模糊的或是不具体的,逐渐完善,越来越明确。

每个迭代开发过程从产品待办事项选择部分需求以及细化形成Spring Backlog,细化的过程就是编写Story的过程。

Story的涵义:
按照迭代计划,逐步细化需求,形成Story(故事)
鼓励开发人员、测试人员、业务分析人员和产品
负责人合作编写故事,
确保所有的故事都足够小,可以持续交付工作。
最好每天完成至少一个故事。

因此,敏捷需求是通过User Stories(用户故事)来体现的,我们知道UML需求是从use case(用例)开始的,敏捷是从user stories开始的,他们的涵义基本一致的,而用户故事按照一定的语法形式进行表示,不需要技术语言来描述,只是以客户能够明白的,简短的形式来表达。

一个典型的描述模板如下:AS a作为某类型的用户,I wan希望达到什么目标,so that 原因如何如何 。
软件项目管理 4.3.敏捷需求建模方法

这是一个具体的user stories例子:这个故事是文件备份功能,stories描述如下:作为一个用户,希望备份整份硬盘,以便工作内容不会丢失。
软件项目管理 4.3.敏捷需求建模方法

获取到user stories后,需要与客户进行分析,相互沟通,讨论,并生成Story。

那么如何评价一个story是一个好的story呢?有一些标准是可以参考的。例如INVEST,那么他就描述了好的story的六个特征:I代表独立特征,N代表清晰描述,V代表需求的价值特征,E&S代表比较小,足以进行估算。

软件项目管理 4.3.敏捷需求建模方法

软件项目管理 4.3.敏捷需求建模方法

那么Story呢常常写在卡片上,所以称为Story cards,然后可以部署到墙上,可以讨论,这些都代表着需求分析从传统的写需求过程到讨论需求的过程。

软件项目管理 4.3.敏捷需求建模方法

那么这是部署到墙上的Story,成为Story wall。
软件项目管理 4.3.敏捷需求建模方法

软件项目管理 4.3.敏捷需求建模方法

二、Story排序

我们知道需求分为功能性需求和非功能性需求,我们前面用Story描述了功能需求。其实也可以用Story来描述非功能性需求,例如我们可以看:这是用Story来描述的非功能性需求,描述了系统,运行环境,开发语言的兼容性以及系统的健壮性。

软件项目管理 4.3.敏捷需求建模方法

迭代开发是基于优先级的,因此需要对Story进行优先级的排序,我们可以遵守一些规则来对Story来进行排序。

软件项目管理 4.3.敏捷需求建模方法

例如MoSCow,他是对Must have(系统必须实现的功能,否则系统无法运行),Should have(虽然很重要,但是可以省略的功能),Could have(扩展性功能,但是要求不是很低),Want to have(一部分用户的想法)来进行排序的。

软件项目管理 4.3.敏捷需求建模方法
软件项目管理 4.3.敏捷需求建模方法

例如采用MosCoW规则对某一个支付功能Story来排序,其中Must have是系统必须接受Visa卡和Master卡,Should have是可以增加美国信用卡,Could have可以增加PayPal卡,Want to have可以考虑最后增加礼品卡。

软件项目管理 4.3.敏捷需求建模方法


总结

总之 敏捷项目需求通过讨论的方式,循序渐进的方式进行确定的,并且可以采用user stories进行描述。

到这里,第四章 软件需求管理就讲解完毕了!下一章将全面介绍软件项目任务分解~

如果您觉得这篇文章有帮助到您的的话不妨点赞支持一下哟~~😉

后续将持续更新【软件项目管理初级学习路线】的全知识点,大家感兴趣的多多关注博主哟~
————————————————

发表评论

相关文章