前面我们讲了为什么敏捷专家应该关心资本化？ 本文将继续讲忽略敏捷而推荐的会计实践。

会计实践并不完全是由税务与证券法律所指定的。相反，美国财务会计准则委员会（FASB）通过解释这些法律从而制定了“一般公认会计原则”（GAAP）。FASB针对内部使用软件的指南见 [ASC 350-40]( 会计准则编纂)，针对对外出售软件的见[ASC 985-20]，他们的处理方式与本文所讨论的大致相同。国际会计准则委员会（IASB）制定了“国际财务报告准则”（IFRS）。FASB和IASB为如何解释法律提供了指南。他们的建议在敏捷实践流行前就已经制定，展示了如何对使用瀑布模型的项目进行分类工作。

瀑布模型资本化时间线(点击图像放大)

一些被误导的人们盲从FASB和IASB指南，在工程师工时跟踪方面对敏捷项目强行套用瀑布模型的方式，以类似RUP的分析、原型设计、开发、打包以及维护等各个阶段来进行。相反，指南表述为：在开发前的市场分析是需要费用化的，在决策是否投资前的原型设计也是费用化的，而属于长期投资价值的开发应当被资本化，打包上线也应当被资本化，而维护（修复bug）是费用化的。上图绿色部分展示了被资本化的条目。

审计师意识到FASB和IASB指南不能被原封不动地拿来应对新的状况。税务机构和审计师们所追寻的是一种符合法律及其精神的，用途一致的，并且完全透明的方式。我们可以提供他们所有想要的，但是因为敏捷实践比较新，我们必须理解法律及其动机，记录好我们的资本化政策和实践，跟踪项目工作始终，并且完全透明。这非常符合敏捷的原则。

然而，如果你忽视了法律及其动机，没有持续地跟踪工作或清晰地记录进程，你将可能得罪那些税务机构和投资者。不良的审计发现以及提交经过纠正的财务报告结果将导致税务机构和投资者对公司失去信任，以至于遭受更高等级的审查并得到一个更低的股价。

如果你对FASB指南的基本体系感兴趣，并且你又身在美国，可以参考美国税法[26 USC 167] [26 USC 197] [26 USC 179]。事实证明，大多数国家针对这个话题都采用相同的方式。

财务部门无可非议的以自己的方式维持保守。如果你的财务部门不喜欢你做事的方式，他们将可能：

• 强制工程师开始跟踪工时（麻木的进行工时跟踪将降低他们的创造力和生产力），
• 软件开发投资不足（将巨额资金留在账面上），或者
• 对过去的费用进行重新分类（提升了投资者对公司稳定性的质疑）。

在这方面更容易犯下数百万美元的错误。因为绝大多数的公司都犯了资本化错误从而增加了税负，税务机构当然不会抱怨。因为敏捷软件实践对投资者来说晦涩难懂，所以他们也没什么好抱怨的，但是他们应该抱怨。

如果你们当中有一个人对财务、工程和流程这三个领域同时具有不错的理解——就可以很大程度地改善你们的账本底线。鉴于回报如此之高，非常值得雇佣一名顾问来帮助做好这件事。

如何做好：敏捷前沿的财务报表

在FASB和IASB指南被修订并增加明确关于敏捷讨论的例子之前，负责任的敏捷专家必须直接与他们所在公司的财务部门和审计师们一起工作从而打造一个可接受的资本化流程。

首先，当你的公司可能开始资本化工作之前建立好一条清晰一致的自定义界线。ASC 350-40声明成本资本化开始可以在所有“预备项目阶段”完成之后，或者在当管理层确认要为该项目提供资金之后，以及“很可能是项目将要被完成…和已使用时。资本化将从你设计和开发“什么”软件资产转变到“如何”设计和开发之时开始”

在大多数案例中，资本化应该在整个生产团队为第一个sprint整装待命之时启动。你的公司很可能在决定投资组建一个包括设计师、工程师和测试的团队之前就已经完成了初步的市场调研和架构设计。然而，如果一个研究小组启动了一个“突破可行性（feasibility spike）”的sprint来决定应该使用哪种架构或是在这个市场能够创造任何可以提供长期价值之前是否还需要更多的sprint，那么你们很可能还处于“预备项目阶段”，而此时你花费的成本将都是运营费用。

一旦你的公司决定投资一个项目甚至可能已经完成或投入使用，你便可以开始进行资本化工作了。所有至关重要的工作如设计、创建、测试和部署资产都应该被资本化，包括工程师、测试、用户体验设计师、产品管理、项目管理以及ScrumMaster的薪水。

其次，确定应该对整个项目还是仅仅部分进行资本化。在大多数案例中，在“预备项目阶段”以后的整个项目成本都应该被资本化。这个时间点的发生将促使整个工作的相当比例（我认为95%是足够充分的）应该被归类为资本费用。然而，一些常规活动必须被费用化。

如果以下任何一项符合你的情况，你的项目将可能属于混合模式：

• 你的团队正在开发新功能，而当他们在发布产品的时候修复了一些回归bug，
• 你的团队在开发一个国际化版本产品的时候，为产品做多语言的本地化工作，
• 你的团队（不仅仅软件）手动将数据从一种形式转换成另一种形式，
• 你的团队帮助培训其他人使用软件，
• 你的团队参加了部署以外的其他运营活动，比如监控、报表、备份和机器配置，
• 你的团队执行了例行的Sarbanes-Oxley (SOX)或安全审查[15 USC 7211]，
• 你的团队重构了一些与新功能无关的代码（你们很可能本不应该做这些），
• 你的团队为支持个别客户而修改了软件。

以上各条目应当被费用化还是资本化将取决于你的财务部门和会计技术顾问。

如何做好：对混合模式项目的归类

如果你的项目是属于混合模式的，请建立一种方式对劳动进行归类，以确认是营运费用还是资本化费用。如果你们组织具备较强的Scrum实践经验，你大可以放心地通过估点（又称为“故事点数”）对每个团队进行按比例分配。如果每个团队具有不同的点数规模，分配将会更加周全合理。用团队完成的总点数除以该组总共耗费的成本，（包括product owner，ScrumMaster，团队成员以及兼职成员薪水的一定比例）。你便可以得到“每个点的成本”。

在这个例子中，团队在一个四周的Sprint里完成了 63个故事点，其中42个故事点可被资本化。如果整个团队的成本（整个团队的薪水）在这四周里总共是$112,000，则资本费用将是$112,000 × (42 ÷ 63) = $75,000。

如果product owner能够以形式化的故事方式来书写Product Backlog 条目，将会给我们区分资本或运营费用带来更大的便利。我的首选是PBI故事形式，这是由Chris Matts 和 Dan North [North 2006]推崇的一种形式的变体，可以帮助识别大部分的分类工作。它的样子看上去如下：

作为 <利益相关者>，  我可以 <执行某个行为>，  我们公司将因此 <获得业务价值> 验收测试： <验收测试 1>  <验收测试 2>  …

通过这种方式，你可以用具体的值来替代<利益相关者>， <执行某个行为>， <获得业务价值>和<验收测试 …>。利益相关者从来都不是团队的成员，但可以是任何消费该产品的人：某个用户、某个客户、某个系统操作员、某个业务分析师，或者是某个管理员。如果你不是在为团队之外的某些人服务的话，就称不上真正的“用户故事”。<执行某个行为>应该是利益相关者可以做但无法在Product Backlog条目被完成前执行的。<获得业务价值>通常和开发公司所思考的问题相关联：我们为什么要构建这个产品？我们将获得更多的用户吗？用户会为该产品支付更多的钱吗？我们将获得竞争优势或能超越竞争者的产品特性吗？我们将节省运营成本吗？偶尔的情况是，<利益相关者>可能是未来的某个开发者，这将使得团队能更加集中努力从而减少技术债务。无论如何，这样可以确信验收测试能确保未来开发者的利益。

最后，我们还有验收测试。我对团队的忠告是验收测试必须由利益相关者（通常不是开发者）来编写，这样才能验证工作是不是已经完成了，理想情况是在Sprint评审的时候。如果一个验收测试是为团队成员验证而编写的，那事实上这并不是真正的验收测试。

下面是一个例子：

作为系统操作员，  我可以监控系统的当前负载，  公司因此将在负载接近新用户将被拒绝访问的阀值时前添加机器。

验收测试：

通过管理界面，系统操作员可以很容易看到负载。

如果负载在绿色区域时，至少还有50%更多的用户可以加入系统而无需关注。如果负载在黄色区域时，至少还有20%更多的用户可以加入系统而无需关注。

当负载进入红色区域时，可以添加更多的机器从而将负载降回到黄色或绿色区。

该故事是应该被资本化的，因为它添加了以前从来没有的功能，即使它是为公司内的利益相关者服务的。这里面的细微之处通常可能被忽略，通过仔细阅读ASC 350-40将可以看的更加清楚，其中有一个概念的标题是“内部使用软件”。因为大多数云计算和网站开发项目都运行在开发者公司的机器上，它们通常被形容为内部使用软件。

这种格式并不仅仅有助于财务分类，同时对帮助团队理解他们工作的来龙去脉是非常有利的。

怎么跟踪工时？

每当开始进行资本化的时候，某些人通常会建议我们“马上去跟踪程序员的工时”。这是个错误，不仅仅是这样做会破坏我们的敏捷习惯，更甚的是通常这样的衡量是不准确并且不具备可验证性。

按小时的财务监管减慢了软件开发的速度。软件开发是创造性的工作，为了跟踪工时而打断工作将阻碍创造性进程。如果我们对工程师强制实施按小时的跟踪，我们将把开发者们从一个正在思考利益相关者、利益相关者行为、验收测试以及代码的“禅悟状态（Zen state）”中拉回来，并推入一个自觉回顾上一小时工作内容的状态。

所以，为了避免这种破坏，公司通常充其量只是在周末通过简单的询问工程师来填写时间卡。到了这个时候，他们完成的工作都已经遗忘在过去的迷雾里。根据我的经验，他们的周报是很不准确的。

当我们保持较高生产力的时候，审计师将在对会计实践的支持中提供可靠的透明性。我所遇到的那些审计师都承认按小时跟踪是存在问题的。我向他们建议根据故事点来按比例分配实际成本，这将会提供最可靠的透明性。一开始，他们只是较为谨慎地同意了。

按照这种方式，我可以断言“估计的工作量”将与实际的工作时间高度关联，这个断言是站得住脚的。Scrum框架被设计用来帮助团队追求估计点数和实际时间的高度关联。Scrum提供了比瀑布模型更好的预测精度，而团队信奉Scrum原则并开始检查他们的估计点数与产出，试图确保他们的sprint预测能大致上符合sprint结果。

当他们看到效果时，审计师们马上成为了这种方法的狂热支持者。当我们跟踪PBI，估计点数和竣工时间（sprint结束时间）时，我们可以精确地知道哪个团队进行了这项工作，我们通常拥有一个按日的任务燃尽图，并且有一个按比例的成本分配。我们报告的PBI被很好的记录下来并且很容易被理解（感谢故事的形式）。当审计师们采访团队成员时，团队成员所讲述的内容与高管们所讲述的是一致的。这是一个审计师们的梦想：经理和高管们报告的综合数据可以被个别贡献者的陈述所验证。

在向敏捷的过渡中发生了什么？

如果你打算着手从瀑布模型过渡到Scrum，这将是一个考虑改变财务报表的绝好机会。在软件开发中，敏捷方法与瀑布模型是截然不同的，并且它被证明可以在财务报表方法上带来显著的改善。

首先，你可以创建一个几乎防弹（译者注：原文是nearly bulletproof，很安全的意思）的体系来跟踪工程成本以消除对于跟踪实际工时的需求。审计师和财务人员一开始会对这种新的方式保持警惕，然而当他们意识到每个人——从开发到ScrumMaster到Product Owner到经理到财务人员——都在持续并深入地议论着公司的这种工作方式时，他们将会欣喜万分。

你将会发现过渡到一个更加精确及更负责任的资本化方式后将显著的提升可资本化的工作总量。你的财务部门应该会期望较高的资本化率，因为软件开发工作通常是一个未来长期性的投资。不管怎样，对财务部门和审计师们来说，这是一个可以看到的意味着剧变的红色信号。

我们必须正面地说明这些问题，向他们解释敏捷软件实践促使这个复杂的方式可行。对于瀑布模型的团队来说，很难可靠地跟踪设计工作或项目管理任务产生了那些功能特性，而敏捷方法将自然地通过sprint backlog来揭示这些信息。因此，举个例子，在过去你们公司也许会将所有的投资决策设计工作集中在“预备项目阶段”，但这样做已不合时宜。

此外，因为敏捷实践每个月都会创建可发布的软件，他们可以用独立的功能特性来关联基础设施开发工作，使得它们可以被资本化。某些瀑布模型的公司觉得基础设施工作距离用户功能太远，没有紧密的关联性，所以应该被费用化。

不管你是什么样的情况，请完全坦率地对待你的财务和审计师们。如果你希望显著的增加你的资本化率，请将这些信息与你的财务和审计师们分享，讨论下什么将可能发生。最后，显式地将它联系到公司向敏捷的过渡中。你的评论可能会出现在一份公司股东的报告中，你将会受到大家的欢迎，你是个真正值得骄傲的敏捷专家。

总结

如果你看到了这里，你可能是一个企业敏捷专家；敏捷思想中的好点子不应该仅仅只影响工程，同样应该福泽财务和其他部门。来加入我们吧！

既然你了解了更多关于敏捷资本化的内容，你的公司将有机会更负责任地向股东和税务机构报告公司的活动了。这将需要很多的协商、计划和流程改进才能够实现。不管怎样，你的工程小组将能够雇佣更多的工程师；你的公司将能够显著的减轻税负责任；你的公司的财务报表将更加稳定。这些改进所带来的价值将高达数百万。