几个星期前，我曾经答应某人在博客上发表关于估算非功能性需求的独特挑战的文章。
首先，我们应该知道所谓非功能性需求是指对整个系统状态的一种需求，而不是系统的某个特定功能。非功能性需求通常包括性能，准确性，可维护性，互通性以及便携性等等。
（在这里顺带说一句，如果你对如何用用户故事的形式表达非功能性需求的话可以看这里：http://blog.mountaingoatsoftware.com/non-functional-requirements-as-user-stories。）
估算非功能性需求的挑战是它包含两项成本。第一个是初始维护成本。第二个是持续维护成本。
让我们来看看下面这个例子来说明这两个成本。假设一个团队正在开发一个新产品，而且对该产品有性能方面的需求。在第一个Sprint中，团队可能会考虑到性能的问题，但是由于还没有足够的代码，他们并没有办法去做性能测试。在几个Sprint以后，比如说Sprint 5，团队觉得已经有足够的代码，并且决定从这个Sprint开始做性能测试。
还记得我们提到过的初始维护成本吗？在这个例子中，就是指团队在Sprint 5开始做的性能测试的工作。虽然，性能测试比不会比大多数的其他用户故事多花很多时间。于是，团队在估算的时候给性能测试预留了几个用户故事点数或者理想人日。
接下来，我继续看这个例子。假设团队真的在Sprint 5中进行了性能测试，并且根据测试的结果进行了调优。在第六个Sprint的时候，团队还需要继续增加新功能，这就是刚刚提到的第二个成本—持续维护成本。一旦团队在项目开始中开始关注非功能性的需求（就像例子中的团队在Sprint 5中做的那样），他们就必须在项目中接下来的日子里一直维护下去。我把这项成本看作是一种税。性能测试（或者说持续维护非功能性需求）给团队带来了额外的负担（也就是税）。而且这种负担或者说税必须一直的持续下去。
有些时候，团队和Product Owner会确定每个Sprint都需要承担这种税。在这个例子中，就意味着每次他们要添加一个功能，他们都必须要给新功能甚至是整个系统做性能测试。有时候，团队和PO可能会同意每隔几个Sprint才承担一次。毕竟，有时候团队会说新加入的功能并不会给系统的性能带来什么影响，而且我们并不会在这个Sprint后发布。我们可以把每个月的进行性能测试想象成销售税或在VAT。把每隔几个月进行一次测试的想象成季度税，例如在美国的独立承包商所付的税。
我们到底应该如何估算非功能性需求呢？答案很简单，把上面提到的两项成本分开估算。像估算其他用户故事或者待办事列表项目一样估算初始维护成本。团队和Product Owner需要一起估计什么时候开始进行测试，因为在第五个Sprint开始做性能测试和在第二十开始做是不同的。然后，团队和Product Owner要协商持续维护的频率，是每个Sprint都要做还是每N个Sprint做一次？然后团队可以估算需要的工作量，然后分配相应的时间。比如说，团队和Product Owner决定每4个Sprint做一次性能测试，团队估算出每4个Sprint大概需要6个用户故事点来做性能测试。也就是说，大约每个Sprint要1.5个故事点。如果团队的速率是30的话，1.5个故事点可以看作成是5%的税。当然，对于第一次团队的估算可能不大准确。不过值得庆幸的是，团队在几个Sprint之后可以清楚的知道他们在性能测试上具体花了多少时间，然后根据统计来修改他们对持续维护成本的估算。
原文地址：http://blog.mountaingoatsoftware.com/estimating-non-functional-requirements
作者:Mike Cohn
