开发者学习笔记【阿里云DevOps助理工程师认证（ACA）课程：需求管理和版本规划基础】
课程地址：https://edu.aliyun.com/course/3112069/lesson/18993
需求管理和版本规划基础
内容介绍：
一、需求收集与分析
二、基于用户故事的需求拆分与澄清
三、需求优先级与排期
一、需求收收集与分析
需求的定义：
IEEE 软件工程标准词汇表 97 年中定义需求为用户解决问题或达到目标所需的条件或全能。
系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或全能。
一种反应上面1或 2 所描述的条件或全能的文档说明。
软件需求包括以下几个层次：
第一，业务需求。
第二，用户需求。
第三，功能需求。第四，非功能需求软件需求规格说明等。
需求的管理流程包括这么几个方面，首先是需求收集，之后要做需求分析，再者要进行需求分解与澄清，最后我们要对需求进行优先级排序和排期。
首先我们来学习需求收集，在最初我们获得的是原始的用户需求，我们还需要进行进一步的需求收集来获得真正的用户需求。
一般来说，需求获取方法包括：
第一是访谈，
第二调查问卷，
第三需求讨论会，
第四竞品分析，
第五文档与数据
有时我们需要进行大数据的挖掘，最后是原型。
当我们获得真正的用户需求后，还要再进一步的进行需求的分析，需求分析究竟是做什么呢？也就是把用户需求转化成我们可以实施的产品需求，针对待开发软件提供完整、清晰、具体的要求，确定软件必须实现哪些任务。我们现在比较常用的一个需求分析的工具是影响地图，它从 3 W 1H 的几个方面来对需求进行分析。首先就是确定目标我为什么要做这个需求，其次就是我们要看它影响到了谁，以及谁会对这个需求有影响。how就是我们是如何影响的，或者是怎么样反过来影响。最后我们基于这个影响的分析决定我们要做什么样的产品需求。
二、基于用户故事的需求拆分与澄清
第二部分我们来学习基于用户故事的需求拆分与澄清。在这之前我们先要学习需求的层级，用户需求转化成产品需求之后，一般是比较大的需求，也就是 Epic story。史诗故事，简称我们称它为史诗，一般被定义为一个非常大的用户故事，是产品中的主干任务。史诗级用户故事还可以拆分成特性，也就是 feature 特性，是能对用户提供价值的完整功能，描述了产品具有的一个完整功能特性，一般也比较大，可能持续数周，横跨几个迭代，特性再进一步分解。 拆分成用户故事，也就是 use a story。每个用户故事都对用户有价值，但是单个用户故事却有可能不能被用户正常使用，或者是整个功能的细分场景。当我们具体要实施产品时，我们还会把用户故事再拆分成工作任务。
什么是用户故事？
用户故事就是描述需求的一种表达方式，从用户的角度来描述用户渴望得到的功能。用户故事一般有三个要素，角色、活动、价值。角色，也就是谁要使用这个功能。活动就是需要完成什么样的功能？商业价值，为什么需要，这个功能带来什么样的价值？用户故事的书写要遵从一定的格式，英文的格式是， as a role， i want to do some activity do that have business value。中文翻译过来就是，作为一个角色，我想要做什么样的活动，以便于实现什么样的商业价值。举例，作为一个网站管理员，我想要统计每天有多少人访问了我的网站，以便于我的赞助商了解我的网站会给他们带来什么收益。
用户故事要遵从 3C 原则。什么是 3C 原则？
是 Art conversation, confirmation.，card 也就是卡片，用户故事一般写在小的纪实卡片上，可能会写上故事的简短描述工作量估算等。 conversation 就是交谈用户故事背后的细节，来源于和客户或者产品负责人的交流沟通。 confirmation 确认用户故事要通过验收测试确认才能被正确完成。一般用来写用户故事的卡片，正面会写上用户故事，比如作为什么用户角色，我想要完成什么样的活动，以便实现什么样的商业价值，而背面就会写上我们的验收标准。
下面我们来学习用户故事的验收标准。 acceptance Criteria，简称 AC。验收标准代表了用户故事 3C 中的 confirmation 准则，同时也是我们一会要讲 invest 属性中的 testable 的具体体现。 在用户故事 card 中， AC 一般用 given when then公式来书写。 given 就是指用户触发操作之前处于的系统状态， when 触发系统结果的操作， then 系统预期返回的结果。比如我们的用户故事是，作为一个网站管理员，我想要统计每天有多少人访问我的网站，以便于我的赞助商了解我的网站会给他们带来什么收益。我们的验收标准就可以这样写， given 网站运行一天后，when，当我点击首页访问人数按钮时， then 我可以看到这一天一共有多少人访问了网站。
当我们拿到产品需求的时候，一般是比较大的 epic 或者特性，我们还要遵从 invest 原则，进一步地对产品需求进行拆分成可以实施的用户故事。
什么是 invest 原则？
independent 独立性，要尽可能的让一个用户故事独立于其他的用户故事。
negotiable 可协商性，一个用户故事的内容要是可以协商的，用户故事不是合同。
valuable 有价值，每个故事必须对客户具有价值，无论是用户还是购买方。
estimable 可以估算的开发团队需要去估计一个用户故事，以便确定优先级工作量安排迭代。
small 短小，一个好的用户故事在工作量上要短小，要确保是在一个迭代中能够完成。
testable 可测的，用户故事必须是可测试的，只有成功通过测试，才能说明该用户故事已经被完成开发。
最后我们还要进行需求澄清与评审。需求澄清包括两个阶段，第一个阶段是产品负责人，也就是我们的产品经理最初和用户来澄清用户的需求，当产品经理通过需求分析把用户需求转化成产品需求后，还要和我们的开发团队，即我们的 Scrum 团队进行进一步的澄清。我们可以开几个需求讨论会来进行需求澄清。 最后我们的需求评审要有一个产品定稿会，这是一种仪式或承诺，向各团体要确认这个需求。产品负责人，他的责任是做产品设计初稿，召集评审产品定稿规。而技术负责人也就是我们的开发测试，他们的责任是要参加review，参加评审，提出意见，确保逻辑完备性。
三、需求优先级与排期
需求定稿后，我们就可以进行需求优先级与排期。优先级一般是在我们做了需求分析，需求分解之后，对它进行优先级的排序。排优先级的方法有很多，我们主要介绍有四种。第一种是莫斯科法则，它包括 must /should /could/ would not， must 就是指必须做的要求或特性，是系统的基础，没有他们系统就不工作或没有价值。 should 是应该做的，应该有的价值或者功能，这样系统才能工作。 could 可以做的，提供了产品的附加价值，可以让这个产品更具有亮点。 would not 暂时不考虑做的，在产品中没有的功能。 我们也可以通过常用的矩阵分析法，比如把重要且紧急的排在第一位，其次是重要不紧急，紧接是紧急不重要，最后才做不重要也不紧急的。还可以从满足核心用户优先的二八原则来进行排序，或者满足核心业务的投入产出比最大的需求优先这个角度来进行需求排序。具体使用哪一种方法，还需要根据产品经理在当时的情况下来做出决定。
我们对需求进行优先级后，可以用户故事地图对需求进行进一步的梳理，最后能够对需求进行排期，规划我们的发布和迭代。 这个用户故事包括横轴是它的业务流程，比如我们购买，包括我们的管理账户浏览、购买、支付、配送、退货这样一个业务流程，而纵轴是我们根据商业价值来定的优先级，从高到低，比如管理账户最开始的时候我们肯定要进行注册和登录的功能，其次我们才进一步的提供其他的功能，比如修改密码，手机验证等。 通过这样的梳理，我们就可以对需求进行发布规划和迭代规划。
发布和迭代之间的关系是什么呢？一个项目我们可以有多个发布，而一个发布我们可以有多个迭代去实现。一般发布规划应该是 3- 9 个月一个发布或者更长，而迭代一般是 1- 4 个周。在发布规划里我们规划的是用户故事，而在迭代规划里，我们需要把用户故事再进一步的拆分成任务进行实施，但是现在在很多互联网的企业里，他们也是一个迭代，就是一个发布。
我们主要讲解的内容，需求的收集与分析，基于用户故事的需求拆分与澄清，以及需求优先级与排期。
发布规划 |
迭代规划 |
|
时间的区间 |
3~9个月（或者更长） |
1~4个周 |
计划中的项目 |
用户故事 |
任务 |
