软件项目管理 5.3.敏捷任务分解
【公众号 “项目管理研究所” 将会第一时间更新文章并[分享行业分析报告]】归档于软件项目管理初级学习路线
第五章 软件项目任务分解
《初级学习路线合集 》
前言
大家好，这节我们学习软件项目管理---敏捷任务分解方法。
一、敏捷项目的任务分解
敏捷开发过程是通过用户故事，将需求具体化成可以进行迭代开发的任务。
https://img2022.cnblogs.com/blog/1683514/202205/1683514-20220531113256215-1447441293.png
Epics是由许许多多小大的，不确定的需求组成，不能直接通过迭代开发，需要划分为较小的，真正的user stories。
https://img2022.cnblogs.com/blog/1683514/202205/1683514-20220531113256285-122968349.png
另外Epics有时包含着太多且模糊的需求，所以常常包含着不同的特性，而一个特性就是一组可以归为一类的需求。
因此敏捷项目的分解级别如下，Epic是比较大的story，那么Epic可以分解为一类，一类就是一个Feature，那么Feature下可以分解出一些user story。
https://img2022.cnblogs.com/blog/1683514/202205/1683514-20220531113251567-2085630581.png
例如：某Epic是硬盘备份功能，我们可以分解出两个story。第一个story是作为power user 为了更好管理文件，登记文件规模，创建或者修改日期，对文件或者文件夹备份。
https://img2022.cnblogs.com/blog/1683514/202205/1683514-20220531113256223-874237021.png
第二个story是作为user,为了使备份的驱动器不会被不需要的内容装满，需要标识出不需要的文件夹。
https://img2022.cnblogs.com/blog/1683514/202205/1683514-20220531113256242-2074213071.png
这也是一个Epics分解的例子：Epic分解了四个story。
https://img2022.cnblogs.com/blog/1683514/202205/1683514-20220531113256256-1689093414.png
https://img2022.cnblogs.com/blog/1683514/202205/1683514-20220531113256312-1695791211.png
story编写完成之后，应该写出接收标准，那么他（如下图）可以作为用户测试story的依据。
翻译：验收标准只是一个高级别的验收测试，在敏捷用户故事完成后，它将是真实的。通常情况下，它会写在故事的背面。这是一个很好的方法，可以确保故事被理解，并邀请团队就我们试图创建的业务规则进行谈判。
https://img2022.cnblogs.com/blog/1683514/202205/1683514-20220531113256281-127129425.png
例如这个story是创建账户功能，设立验收标准如下：
[*]确保这个用户在系统中存在。
[*]确保用户的信用状况是满意的。
[*]确保账户类型是正确的。
[*]确保账户是唯一的。
[*]账户密码是6位数字。
https://img2022.cnblogs.com/blog/1683514/202205/1683514-20220531113256222-1968308499.png
那么这就是5条接收标准。
二、任务分解输出-列表
敏捷项目的任务分解输出可以是对backlog列表进行细化的过程，将编写完成的story汇总到backlog列表中，那么他也是后续规划的基础。
https://img2022.cnblogs.com/blog/1683514/202205/1683514-20220531113256344-1558449492.png
总结
总之 敏捷项目任务分解就是将Epic分解成多个story的过程。
到这里，第五章 软件项目任务分解就讲解完毕了！下一章介绍软件项目成本计划~
如果您觉得这篇文章有帮助到您的的话不妨点赞支持一下哟~~
来源：https://www.cnblogs.com/pmolrj/p/16329838.html
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！
页:
[1]