敏捷 需求管理工具

传统的瀑布工做模式使用详细的需求说明书来表达需求，需求人员负责作需求调研，根据调研状况编制详细的需求说明书，进行需求评审，评审以后签字确认交给研发团队设计开发。在这样的环境下，需求文档是信息传递的主体，也是一份契约。

然而详细的需求说明书有如下5大弊端：

• 单向的信息传递，容易出现理解误差。
• 文档很正式，咱们会误觉得它必定是对的，不去质疑它，让咱们中止做出判断。
• 有了详细的文档，咱们不会反复讨论它，相互确认。
• 书面文档不利于团队共享责任，它扮演了证据的角色。Scrum强调团队共享责任，不管是需求人员、开发人员和仍是测试员，你们的共同目标是经过讨论、协做，正确理解需求以后把这些需求变成客户真正须要的功能，而不是单向的任务传递。
• 编制详细的、表达准确需求文档须要花费大量的时间，若是需求变化频繁，维护成本更高。

 敏捷使用产品Backlog来管理需求，产品Backlog是一个需求的清单，按照需求的商业价值排序， 高优先级的需求在Backlog的最上层。产品Backlog是一个渐进明细的清单，它有4个主要特色，称之为DEEP：

• Detailed 合适的详细程度，高优先级需求更加明细，低优先级的需求粒度更大
• Emergent 涌现式的，需求是慢慢涌现出来的，渐进明细的
• Estimated 通过估算的
• Prioritized/ Ordered 根据商业价值排好顺序的

在产品Backlog中，需求的主要表现形式是用户故事。用户故事是从用户的角度对需求的简短描述。用户故事是将团队的焦点从描述、编写功能需求转移到讨论需求的最佳方式。

用户故事是从用户的角度来描述用户渴望获得的功能。一个好的用户故事包括三个要素：

• 角色：谁要使用这个功能。
• 活动：须要完成什么样的功能。
• 商业价值：为何须要这个功能，这个功能带来什么样的价值。

用户故事一般按照以下的格式来表达：

英文：
As a <Role>, I want to <Activity>, so that <Business Value>.

中文：
做为一个<角色>, 我想要<活动>, 以便于<商业价值>。
好比：做为一个网站的普通会员，我指望在我下订单后，未发货以前能够取消订单，这样对我来讲更灵活。

咱们目前是用的国内的一款敏捷工具Leangoo在作需求管理！

Leangoo是一个很是简洁的看板协做工具，咱们能够经过Leangoo建立产品Backlog看板来管理敏捷需求。经过leangoo看板对产品backlog条目进行可视化管理，让整个团队很是直观的了解需求的优先级和规划安排。

下图就是一个产品Backlog看板的示例：

在Leangoo看板上，咱们能够建立多个列表，而后在每一个列表上添加故事卡片。

由于咱们须要将近期高优先级的需求放到Sprint中，因此在看板上能够建立这几个列表：待整理原始需求，之后的迭代，下个迭代待梳理故事，下个迭代就绪故事，当前迭代，已交付。
咱们能够根据需求的优先级把需求分别放到这几个列中。当前迭代的优先级最高。

创建好了列以后，咱们就能够往列表里面增长卡片了，每一个故事一张卡。

咱们能够为每一张卡片添加工做量，以及故事的验收测试要点。验收测试要点以检查项的方式体现。

除了工做量，检查项，咱们能够对这个故事进行一些讨论，也就是评论，也能够@某位成员！

咱们也能够为卡片设置标签

标签一般是用来给卡片分类，也能够用卡片标注优先级！

（每张卡片的优先级能够位置来决定的，每一个list里面的卡片根据位置对卡片进行强制排序，高优先级的卡片放到最上面，低优先级的需求卡片在下面）

卡片ID

咱们也能够为每一张卡片设置ID,便于卡片定位沟通和跟踪，在菜单栏开启就能够。

卡片多选

当咱们开启卡片多选的时候  能够批量移动卡片，为卡片批量添加标签，为卡片批量添加成员等等 ，这也是我最爱的功能之一

燃尽图

当一个迭代结束时，咱们要对完成的故事进行评审会议，评审经过的故事能够挪到已交付的列表中。

Leangoo会根据故事卡的变化自动生成发布燃尽图，点击菜单-看板统计，就能够查看！不只有燃尽图 还有任务周期，任务分布等

以下图所示：

经过上述的方式，咱们就能够很好的管理咱们的产品Backlog了。

最后还有一点提醒，敏捷强调透明性，因此，可视化管理产品backlog很重要，若是条件容许，咱们能够考虑经过大的显示屏幕将产品Backlog进行可视化，有触屏大电视会更好。