请问有啥好的需求管理工具
推荐PingCode。
需求是整个软件项目当中最重要一项输入。软件开发和传统生产行业最大的区别在于，需求总是模糊的、主观的和随时变化的。相对于电子产品、汽车等制造行业有形的硬件需求，软件开发的需求的描述和验收是个难以解决的问题。
但是需求又是整个项目能否成功的决定性因素，所以我们必须对需求进行管理，从而使需求成为整个软件工程的基线。使得所有产品、设计、研发、测试、运维工作能围绕着统一的需求开展。保证项目能顺利进行，完成目标。
需求管理的难点？一般情况下，需求难以管理的原因有以下几方面：
1、需求描述的问题一般来说，最容易造成开发出来的产品与设计功能不符的原因便是需求描述的问题了。其实大部分情况下，写需求文档的人没有错，看文档的人也没有错。共享文档不等于达成共识。只是因为面对同一段描述，人与人之间的理解不相同，而且这种情况是一定会发生的。所以对于需求，一定要基于团队面对面讨论，保证对需求的理解一致。
2、需求变化的问题需求变化的原因很多，如一开始没有识别全，新增需求；业务变化导致需求变化；需求有误；需求不清晰等。需求变化将导致从设计方案到编码测试的修改，延迟交付，带来诸多麻烦。这就需要团队在迭代进行前，尽量保证需求清晰明确。
3、需求的优先级及排期问题什么样的功能能对用户产生最大的价值，这是需求管理中最重要的问题。因为在软件开发中，你想要开发的功能，永远比你能投入的资源多。因此，找到这一部分最有价值的功能，优先处理，尽早交付，才是需求管理的核心所在。
如何对需求进行分级管理？敏捷开发中，用户故事被广泛使用，但是我认为仅仅使用用户故事是不足以很好的管理整个项目的。（关于用户故事的诸多好处，就不在此多说了。）用户故事可以描述出真正有价值的需求，也能提供优先级和故事点规模为排期提供依据。但是繁多的同级用户故事会让人迷失在其中，只见树木不见森林。每次的交付和发布都会变成功能的东拼西凑，甚至有时候还会为了单个功能的价值，偏离整体的产品愿景。
因此，我们推荐按照 Epic Story - Feature - User Story 的层级顺序去管理需求。团队也可有自己的层级关系定义，取决于团队的喜好。
按照Epic Story-Feature-User Story对需求进行层级划分的好处在于：Epic一级可以与产品战略对齐，Feature一级作为版本发布规划的对象，User Story则进入迭代进行研发。
1. Epic Story
Epic Story即史诗故事，简称为史诗。一般史诗被定义为一个非常大的用户故事，是产品中的主干任务或者公司级战略举措，一般情况下会持续数月。我们对史诗的风险、业务价值、工作量进行评估，得到史诗的优先级，再依据优先级对史诗进行排期。
2. Feature
Feature即特性，特性是能对用户提供价值的完整功能。描述了产品具有的一个完整功能，特性一般也比较大，可能持续数周，横跨几个迭代。一般作为版本发布计划的规划对象。我们依据特性的风险、业务价值、工作量评估特性的优先级，进行版本发布的规划。
3.User Story
User Story即用户故事，用户故事是能对用户提供价值的功能场景。一般来说，特性可以拆分为多个用户故事，每个用户故事都对用户有价值，但是单个用户故事却有可能不能被用户正常使用或者是整个功能的细分场景。我们会对用户故事的故事点进行估算，放入迭代计划中进行开发。
推荐阅读
- 银行高管的薪酬结构图表最新的，请问在哪里可以收集
- 为啥知乎上普便有一种【我在北上广深打工，所以拥有更好的视野】这样的错觉
- 趣头条|你我皆风华正茂，拥有广汽三菱奕歌的日子是美好的
- 有啥方法，网站，项目可以自己练习计算广告学
- 在上海陆家嘴附近工作，请问去哪边租房会比较好
- 坐标合肥，请问在哪里能捕捉到程序员这种生物他们大都出现在哪里呢
- 孕妇到了预产期，小孩还没有入盆，请问是该等下去还是直接剖腹产
- 言论自由|
- 100W——150W有啥好的车
- 想做手机网游代充，请问要去哪里找货源