需求跟踪和落地的敏捷实践

前言

敏捷开发已经有着超过20年的历史，国内也热起来有五年了，理论和方法学的文章网上数不胜数，但真正深入解决问题的却少之又少，全靠团队自己琢磨，比如下面我们要讨论的如何解决敏捷化开发和需求跟踪和记录的问题。这篇文章我们主要讨论需求管理是如何在敏捷团队中落地，也就是如何才能不损害团队敏捷流程的前提下更好的完成需求的跟踪和记录。
PS:本文作者，zhaoenweiex，拥有近5年的敏捷团队管理实践经验,希望能够将我们的实现敏捷落地遇到的坑坑坎坎分享给大家。

需求管理的实质

在软件开发领域，每当我们谈起需求管理我们到底在谈什么，相信大部分一线的技术人员谈起需求管理的想起的第一件事就是多少个通宵编写需求规格说明书以及上交完之后再也没看过的不堪回首的经历。每次我们写完了之后问这东西到底有什么用。
需求规格说明书，为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解， 使之成为整个开发工作的基础。包含硬件、功能、性能、输入输出、接口需求、警示信息、保密安全、数据与数据库、文档和法规的要求等等。
当然不少非一线管理者都会认为这个文档还是有用的，甚至不乏有人认为拿着这个文档随便拉个团队就能把这个系统再开发出来。
但实际上需求管理与需求规格说明绝不是相等的关系，需求管理的实质是跟踪并记录用户的需求，并将相关的信息传递给开发团队并保证最终产品与用户需求一致。一个合格的需求规格说明书应该能完整和动态的反映用户的真是需求，但由于需求规格说明书这个载体过于沉重，维护代价极高，除非是产品的需求是静态的否则依赖需求规格说明来完成需求管理的模式是注定要失败的。

现实要求

大部分公司并不会容许开发人员自由的开发产品，也不赞成产品经理拍拍脑袋就让开发人员实现，希望一切都有记录与可追踪，因此一般都希望将需求记录下来。这么做还有一个原因，一个不熟悉产品的人可以通过查看这些记录迅速的了解产品的脉络和掌握情况。

传统模式的需求管理

在传统软件开发模式下，需求是一次性获取并几乎不再更新的，因此传统模式下广大开发者不得不编写需求规格说明书来假装记录固化的需求。但大多数情况下用户的需求是无法固化的，他们会一次次的提出需求变更，开发团队也就一次次的改写需求规格上，最终开发团队放弃需求规格，使之成为废料甚至是有害的垃圾。这样的悲剧在诸多传统开发模式的团队中已经上演了无数次。

敏捷模式的需求管理

敏捷团队的需求管理在哪里

下面这幅图描述了Scrum(一种应用最广的敏捷开发模式)的大体流程。

需求管理实际上嵌入到敏捷开发的每一处，从产品负责人给出产品功能列表（product backlog，PB）到开发人员列出本周期开发计划(sprint backlog,SB)都是需求管理的重要组成部分。

回顾一下敏捷宣言

上面这幅图就是著名的敏捷宣言，其中应用到需求管理就应该是这样，其实不需要硬性的需求说明或规格说明书，需求是用来指导我们生产满足用户需要的软件，是一个中间产品。

令人失望的折衷

因此绝大多数的敏捷团队都是绕过沉重的需求规格说明书的编写，采用轻量级的需求管理方法，比如功能列表，直接开发产品，再项目进入尾声后，若用户或公司要求则一次性的集中力量编写需求规格说明书。
这种模式下需求规格说明书基本描述了实际软件，能够为后来人提供参考依据，但实际上由于已经项目尾声大部分团队就是装装样子，改改模板交了了事。这时我们的需求管理就没有结果，也无法未后来人提供任何依据。
下面我们来讨论一下如何在敏捷团队进行更好的需求管理。

需求管理的敏捷优化

最终目标

团队在开发过程中自然而然的完成了需求的记录，而且在设计或需求变化的时候能够即使的反映，在不需要付出任何额外代价的前提下就能生成需求说明文档。
特征：
1.符合开发过程，自然记录
2.自动生成文档
3.当产品变化时自动更新

如何落地

要想实现符合敏捷开发思维的需求管理并不是一件容易的事，需要根据团队的开发模式和习惯结合具体环境和公司规范来确定，下面就介绍一下我们的落地形式。我们是主要借助于Teambition软件和物理看板来平衡团队和公司要求的。
Teambition这款软件我还是很推崇的，很接地气关键还免费，细节我就不介绍了，有兴趣的去官网看看吧。
下面是具体措施：
1.采用Teambition用于团队的整体需求管理，划分为待处理，本周期，历史。

2.每条记录都采用用户故事的形式记录

3.采用物理看板进行本周期详细需求和任务管理，团队在看板上完成用户故事到任务的拆分，每日站会则再物理看板上更新任务进度。

ps：要是有管理者要求查看团队细致的进展有两个选择
1）每天把看板进度发给他
2）将周期内的任务也更新到teambition上同时把管理者也拉进去。
4.再最后需要存档或入库时，直接从teambition中导出即可，如下图。

导出的文档如下图所示

这样我们就有了一份跟最终软件一致的需求说明，甚至还能反映出需求的变化。

总结

1.敏捷开发是一种软件开发方法，而敏捷则是一种思维，这种思维促使我们不断的改进着也推动着周边环境的变迁，所以当你不想着如何改进时那么那就不再敏捷了。
2.本文实际上给出了一种借助免费软件在开发中自然的记录需求并能在最终时刻自动生成需求说明的方法。