敏捷功能规范

最近，做为敏捷项目的业务分析师，我在这个项目中制作的一个关键文档：功能规范（功能规范（FS））。

在这篇文章中，我将解释一下它到底是什么，以及是如何工作的。

我会提供足够的细节，让大家可以在自己的项目中进行实际的尝试。它不是很完美，但它对我有用！

为了使本文更有意义，在文后可以下载一份功能规范。

功能规范真的可以是敏捷的吗？

考虑到敏捷运动重视工作软件而不是全面的文档，您可能会问：敏捷项目中是否有功能规范的位置？

在极限编程中，需求是直接口头传达给开发人员的，只需在索引卡上潦草地写几条注释作为备忘录。

唯一的文档是代码本身以及附带的自动化验收测试套件。

关于无需求文档这种方法在实践中效果如何的争论很多。无论哪种观点，没有业务分析师，没有文档的方法都不适合一些特定的项目。

这次的项目中，我尝试编写新的功能规范，与以往不同，我想避免功能规范太重的问题。让我们来看看具体的关键特征，希望对您有帮助。

目的和目标

首先要明确的是：这份功能规范的目的是描述指定系统的外部可见行为，要足够详细以便开发团队能够开发系统。

它和一个（HTML）的原型并存，原型为系统的用户界面提供指导。

在我看来，这是一份设计文件（功能设计，而不是技术设计），有些人习惯叫它需求文档。

格式和编写工具

我的功能规范的第一个也是最显著的特点是：它是一个电子表格。过去，我总是用文字描述需求。

这次为什么决定用表格做？

因为我想把系统需求做成用户故事，并完成验收标准。并且创建一个可以在整个项目中轻松更新的活文档。最初考虑使用Mingle这样的敏捷CASE工具，但最终还是选择了更低技术的工具MS Excel。

当对功能规范（FS）的中的内容进行澄清时，用电子表格的好处变得明显——如：出于各种目的新增列特别方便等等。

而且，以前使用文字编写文档时，我会在格式、结构和排版上花很多时间。因为样式糟糕往往让人觉得内容也不怎么样。于是，做文档本身变成了目的，而忘记了真正要完成的需求。

用电子表格就不同了。我不用纠结于每句话的结构和文件样式，也没必要对文件进行格式排版。我可以自由地把内容写出来，让思想流动，专注于内容而非形式。

故事索引

功能规范（FS）中的“摘要”选项卡是包含所有用户故事的列表（在Scrum项目中，这被称为产品积压）。这是我在项目的功能列表（愿望列表）中添加新故事的地方，并且把这些功能详细阐述为更具体的内容（稍后详细介绍）。

“摘要”选项卡上有很多列。大多数列都很容易理解，有一些列的标题有注释提供使用帮助。以下是一些有用的注意事项：

1.故事ID：给每个故事提供一个唯一的ID，使用格式是“Snnn”，例如S001、S002等。“S”前缀非常方便，因为故事可以仅通过其ID来沟通说明，如“张三，我刚看了S078，我有一个问题……”

2.故事名称：故事的一个简单名称，更像用例名称，它比“As A.…I Can…”这样的摘要内容更小更概括。

3.状态：提示该故事在交付生命周期中所处的位置，用颜色编码可以很容易地了解哪些故事已经准备好进行开发、测试、修复等，哪些故事已经撤回。

4.优先级：我给每个故事赋予了MoSCoW优先级，这有助于确定故事的交付顺序，但实际上，决定顺序要复杂得多，我们需要考虑相互依赖性，以及最想尽快向用户展示的故事。

5.开发增量：故事被分配到哪个增量。只有完成估计并计算出适合的开发任务后，故事才会在每个增量开始时被分配到增量。

故事详细信息

“详细信息”选项卡包含了规范的细节。“摘要”选项卡中的每个故事都有展开的完整形式。

我花了很长的时间找到这个完整的形式。

用户故事通常是根据接受标准来定义的，这说明了故事“完成”的意义。但是，糟糕的验收标准和糟糕的要求一样麻烦，我发现了两个陷阱：

1. 模棱两可：没有提供足够的细节

2. 缺乏上下文：没有说明验收标准何时或如何适用

因此，我决定将它们转换成一种格式：用例

不使用以往非结构化的验收标准列表。使用了两列格式

• “何时…”列：说明参与者（用户）的行为

• “然后…”列：表示系统的响应（这也是验收标准）。

如果，我对一个动作有多个接受标准，会把它们都放在不同的行中，这样就可以单独跟踪它们。

下面是一个“登录”故事的例子：

注意事项：

• “当…然后…”：这部分内容实际上是用例。

• “流程”列：标识用例的主要流程和替代流。

如，流程7a是分支主流程步骤7的第1个备选流程，流程7b是分支相同步骤的第2个备选流程。

过去，我用很多时间考虑用例中的确切语言和细节，确保对所有参与者和实体使用了一致术语；

这次，我只是尽可能快、尽可能清楚地写下了我希望系统做什么。有些标准可能很高（如“系统显示登录页面”），另一些则可能很具体（例如“用户ID的最大长度为16个字符”）。

如果有需要说明的细节，就加入。如果不需要或我相信开发人员没有太多指导的情况下也能做好时，就排除在外。

我还花时间来记录了用例是更新内容，当需要修改或扩展现有系统功能时，我同步会更新记录到现有用例（小心标记更改前后的内容）。

如何使用FS

之所以说功能规范（FS）敏捷，主要和我如何（何时）使用它有关。

一个关键点是：我“及时的”写了多功能规范（FS）。

我所在项目使用的是增量开发过程——每个增量3周时间，所以3周的任何时间里，我都会详细阐述下一个增量中的故事。

更准确地说，我详细阐述了足够多的故事，以确保下一次增量开始时，进行增量规划会议，有足够的空间，明确确切的范围。

故事是按优先顺序阐述的，当开发努力完成增量时，基于对整个系统的理解，故事不断被重新排序。

增量结束后，我们让用户使用系统（一种软UAT）对产品进行反馈。这也会导致一些调整，这些调整被添加到后面的增量中，作为新的故事，与所有其他故事一起被优先考虑。

前面说过，我还开发了和功能规范并行的HTML原型，它主要用于说明功能规范中的概念，为开发人员提供外观指导。

在这个项目中，我很幸运，可以随时接触到业务人员。因此，我每周举办两次研讨会，让我们了解最新的故事。

使用笔记本电脑和投影仪，我会把HTML原型放在大屏幕上让所有人都看到一些视觉效果，把功能规范（FS）放在笔记本电脑屏幕上，做为原型细节说明可以参考。

我会解释验收标准，在会议上达成一致（或酌情修改），然后在功能规范（FS）的“业务约定”栏中插入今天的日期，设计在这里确认。

用户甚至不需要阅读规范。

共享活文件

功能规范（FS）是一个共享的活文档，开发人员用它来开发增量N时，我正在为增量N+1添加故事。开发团队发现细节中的漏洞时，我会直接修改增量N中的故事。

文件放在一个共享的网络空间里，每个人都可以轻松访问它。

为了简单，我们没有用MS Excel的“共享”功能，因为这个功能同时只能有一个人可以编辑它。如果，你的团队人员大约有6个人，可以考虑Excel的共享

如果项目团队超过6人，可以寻找更方便、有效的共享工具在线编辑这个文档。

测试

电子表格不仅仅被我们作为CASE工具使用，还把它用作了测试工具！

测试人员（我和另一个人）直接将用例做为测试脚本使用，如果您查看“详细信息”选项卡上的N到R列，会发现电子表格还捕获了测试结果以及发现的任何缺陷。

这是个很好的低保真解决方案，虽然有一定的局限，但它最大的优势是：开发人员能够准确地看到哪里测试失败，在什么样的上下文中失败，而不必切换引用其它多个文档。

跟踪和进度监控

了解敏捷性，就会知道：项目中燃尽图在追踪进度方面非常流行。

我的功能规范（FS）中，有一个单独的选项卡显示每个迭代的燃尽图。我的图表就是燃尽图，因为它们跟踪完成的工作，而不是剩余的工作，原理是一样的。

消耗图表是根据“汇总”表K栏中输入的日期自动计算的。

注意，它们只显示开发完成，而不是测试完成。

回顾

本文开头说过，这个功能规范（FS）不是敏捷分析师的万能宝典。以下，是关于它在我的项目中，能顺利推进项目进展，取得成功的一些思考：

1.每个人都喜欢低技术的方法和不被工具奴役

2.业务用户不喜欢阅读和签署文档

3.业务分析师喜欢语言和术语自由！

4.没有关于要求不明确的投诉

改善思考：

1.解决方案无法很好地扩展（超过6人左右的团队）

2.随着文档的增长，在文档中查找要修复/测试的突出缺陷变得有点棘手。