前言敏捷开发已经有20多年的历史，在国内也掀起了热潮已经有5年了。 虽然网络上有很多理论和方法的文章，但实际上很少深入解决问题，必须由团队自己来思考。 例如，讨论如何解决敏捷开发、需求跟踪和记录问题。 本文主要讨论需求管理如何在敏捷团队中落地，即如何更好地跟踪和记录需求，而不破坏团队的敏捷过程。
PS:本文作者赵恩伟埃克斯拥有近五年的敏捷团队管理实践经验，希望大家能分享实现我们敏捷落地所遇到的孔康。
需求管理的本质在于软件开发领域。 我相信，每当我们谈到需求管理时，大多数一线技术人员都会想起需求管理的第一件事，是多少人熬夜编写和提交需求规格书后，再也没有见过的糟糕经历。 我们每次写完都会问这个东西有什么用。
要求规格书是为了使用户和软件开发者双方对该软件的初始规定有共同的理解，并成为整个开发工作的基础。 包括硬件、功能、性能、输入/输出、接口要求、警告信息、安全性、数据和数据库、文档和法规要求等。
当然，许多一线以外的管理员认为本文档仍然有用。 此外，一些人认为，只要拿着这个文档随便拉一个团队，就可以重新开发这个系统。
但实际上需求管理和需求规格的说明并不是相等的关系，需求管理的本质是跟踪和记录用户的需求，将相关信息传递给开发团队，保证最终产品和用户的需求一致。 合格的需求规格书应该能够完全、动态地反映用户的真实需求，但依赖需求规格书完成需求管理的模式注定要失败，除非需求规格书这一载体太重，维护成本非常高，产品需求是静态的。
在现实中，大多数公司不允许开发人员自由开发产品，不赞成产品经理拍脑袋让开发人员实现，他们希望一切都可以记录下来，可以跟踪，因此一般都希望记录需求另一个原因是，不熟悉产品的人可以通过查看这些记录来快速了解产品的上下文并了解情况。
传统模式的需求管理在传统软件开发模式下，需求是一次性获取的，很少更新，所以传统模式下很多开发者不得不编写需求规格书，假装记录固化的需求。 但是，用户的需求往往无法固化。 他们多次提出需求变更，开发团队也多次改写需求规格，最终开发团队放弃需求规格，变成废弃物和有害垃圾。 这样的悲剧在很多传统开发模式的队伍中上演过很多次。
敏捷模式的需求管理敏捷团队的需求管理在哪里？ 下图显示了紧急事件(最广泛使用的敏捷开发模式)的大致流程。
需求管理实际上嵌入到敏捷开发的各个地方，从产品负责人给出产品功能列表(product backlog，PB )到开发人员列出本周期开发计划(sprint backlog，SB )都是需求管理
回顾敏捷宣言，
上图是著名的敏捷宣言，其中应用于需求管理应该是这样，但实际上不需要硬性的需求说明和规格书。 需求是指导生产满足用户需求的软件的中间产品。
由于失望的权衡，大多数敏捷团队会绕过编写繁重的要求规范，采用轻量级的要求管理方法(如功能列表)，直接开发产品，在项目结束后，如果用户或公司要求，他们会一次性集中编写要求规范。
该模型在要求规格书中基本描述了实际软件，可以为后来的人提供参考依据，但实际上在项目结束时大部分团队都很帅气，所以修改了模板后提出。 此时，我们的需求管理没有结果，以后来的人不能提供任何依据。
让我们探讨如何在敏捷团队中更好地管理需求。
需求管理敏捷优化最终目标团队可以在开发过程中自然完成需求记录，在设计和需求发生变化时也能反映出来，无需额外成本就能生成需求说明文件。
特点：
1 .符合开发过程，自然记录
2 .自动生成文档
3 .产品发生变化时自动更新
如何实现符合敏捷开发思维的需求管理不是一件容易的事，而是要根据团队的开发模式和习惯结合具体环境和公司规范进行决策。 介绍我们的落地形态。 我们主要利用Teambition软件和物理看板来平衡团队和公司的要求。
Teambition这个软件我还是很赞的。 对朴素重要而且免费。 不介绍详细情况。 感兴趣的人可以去官网看看。
具体措施如下。
1 .全团队需求管理采用Teambition，待处理，分为本周期、历史。
2 .每次记录都以用户故事的形式记录
3 .使用物理看板进行本周期的详细需求和任务管理，团队在看板上完成用户故事到任务的分割，每天工作站再次在物理看板上更新任务进度。
ps :如果管理员要求查看团队的详细进度，则有两种选择
1 )每天把看板的进度发给他
2 )周期内的任务也更新为teambition，同时也吸纳管理者。
4 .如需最后存档或入库，可直接从teambition导出，如下图所示。
导出的文档如下图所示
这将提供与最终软件相匹配的要求说明，并反映要求的变化。
总结1 .敏捷开发是一种软件开发方法，敏捷是一种思维，这种思维使我们不断
的改进着也推动着周边环境的变迁，所以tzdls不想着如何改进时那么那就不再敏捷了。2.本文实际上给出了一种借助免费软件在开发中自然的记录需求并能在最终时刻自动生成需求说明的方法。