为什么敏捷专家应该关心资本化？-CSDN博客

本文链接：https://blog.csdn.net/cpongo4/article/details/89132634

[本文作者并非财务方面的专家。请在财务专业人士的指导下实践本文所述建议。]

在很多公司中，由于对敏捷软件开发的误解和错误报告，导致税负的增加，损益报告的不稳定，并需要对程序员的工时进行人工跟踪。我敢断言，相比于大多数瀑布模型的实施者，Scrum团队创造的生产成本数据更具有可检验性，并且记录得更好，也与已知的客户价值更为密切。更为出色的报表将意味着可观的税负节约并且能激发更大的投资者兴趣。敏捷公司应该对财务报表这一实践进行改良，从而彰显出Scrum的优势。这可能并不容易，但是我做到了。

Scrum的生产实验框架（production experiment framework）与财务报表的原则完全相符。

在对拥有900人的整个软件公司进行Scrum转型期间，我根据这些原则对软件资本化进行了调整，我们让审计师满怀欣喜，更多的去了解了上层的管理，并且提高用以雇佣开发者的内部资金。通过使用Scrum Product Backlog条目得到了更为精准的文档，并对我们的软件工作进行了资本化，从而使我们在税负开支上得到了数百万的节约。

我希望传达给你这些视角和资源，以此来为敏捷资本化创造会计学论据，从而潜在的减少你所在公司的税负开支，增加工程师们的可用资金，也能让你的审计师欢呼雀跃。

软件是资本投资

软件开发是一项针对长远未来的投资。我们预先为工程师的薪水买单，然后（希望）在不久之后的将来通过节约开支或得到收入来获取利润。如果我们投资得明智——将现金（一种类型的资产）转化成软件（另一种类型的资产）——公司的价值将得到提升。税务机构和投资者们是依靠财务报表来理解一个公司的价值的。我们该如何报告开发费用事项呢。

首先，让我们明确资本化（capitalization）和费用化（expensing）。“资本化”的意思是投资费用（有时也称为资本投资或资本费用）需要跨越一个长期资产（a long-term asset）的生命周期才能得到回报的价值。资本化常被用于税务申报和财务报表（比如损益报告）。资本投资成为了公司公开资产的一部分。“费用化”意味着成本即时受到了“影响”，作为“运营费用”在短期内获得了回报或没有价值。一个将所有软件开发进行费用化的公司，将很难澄清它的软件是长期价值的一部分。

某些软件开发项目并不是长期的投资；这取决于该软件是否仍然是一件资产。举个例子，一个软件外包服务商开发和销售定制软件，没有保留对软件持续的拥有权，这种项目将不能进行资本化。（但是采购该软件的公司是可以对其进行资本化的）

当对软件成本进行分类时很容易犯下致命的错误。一些公司错误地将所有软件投资视为运营费用，隐藏其真实的价值。尽管这个错误可以为某些不正当的行为提供机会，但是将软件投资归类为运营费用通常会导致公司承担更多的税负以及公司的价值被低估，从而压低了公司的股价并削弱了公司的借贷能力。

敏捷专家应该理解资本化

如果财务人员对Scrum产品开发处理的不够恰当，那么他们制订的政策将会成为一个隐患，从而削弱公司对Scrum的支持力度。敏捷会让一些财务专家感到困惑。由于其频繁的发布节奏，他们会认定敏捷软件是某种“临时的”存在。

敏捷专家应该学会适度的资本化并传授给他的同仁们。在如何跟踪和报告敏捷项目成本这个问题上存在的误解，会让很多公司多耗费几百万元美金的不当税负。不完善的资本化规则将为敏捷公司带来剧烈波动的收益表，让这些公司看上去显得管理不善。所谓“保守”的瀑布流程难以跟踪设计工作、管理任务与所产生出的功能特性之间的对应关系，但是敏捷方法却可以。然而，会计师们一般都无法理解如何合适地跟踪和汇报敏捷项目中的劳动情况。

当一些公司对软件开发进行资本化时，通常可以节约税负，雇佣更多的开发者并更快速的创造价值。如果他们资本化的工作做得合理，他们将可以对投资者和监督者更负责任地汇报公司的财务状况。对于合理的资本化来说，我们必须准确采集资产创造过程中的劳动成本，并将这些成本合理的归类到“资本化的”或“费用化的”。

Product Backlog条目说明了交付给利益相关者的价值，可以很容易的进行归类。但是瀑布模型——其无穷尽的设计周期和令人困惑的各个阶段（查看下某个RUP的阶段图，你将看到到处都是混乱不堪的景象）——很难跟踪哪些设计工作或项目管理任务导致了哪些功能特性。有人因此就会觉得财务人员和税务机构是会喜欢上敏捷实践的。

但是大部分的财务专家和专业会计师对敏捷实践都没有深刻的理解。比如在会计准则中使用瀑布模型的例子来解释资本化原理，而误用瀑布模型这种语言将导致人们对软件开发的错误归类。除非团队的敏捷传家可以帮助财务部门对敏捷软件开发进行合理的资本化，否则公司将承受过度的税负责任，对工程人员进行变相裁员，以及审计异常发现及随后重新修订报告的风险。

对于敏捷资本化原理的误解将导致显著的裁员。最近，Pat Reed（另一个敏捷企业顾问）和我一起在一家大型的工程公司中和一个经理讨论资本化。该经理告诉我们，他的财务部门可以正常地对瀑布模型开发进行资本化，但是却将敏捷开发视为“运营费用”，因为财务（错误地）认为所有Sprint实际上都是“预备项目阶段”工作。我问道，“这会限制你的人员编制吗？”他承认道，“是的，任何部门选择使用敏捷实践时都期望将人员编制减半”

从积极的一面看，理解资本化的ScrumMaster和敏捷开发主导者可以修正这个问题。因为好的敏捷实践可以使得资本化更具有可验证性，均摊到整段时间上的投资成本通常也可以降低整体的税负，并且有助于利用早期资金来雇佣更多的工程师。以下是ScrumMaster为何具备这个能力的原因：

ScrumMaster是在公司里最能够正确区分某项工作是一项长期投资还是短期费用的人，并且通常都拥有确保这些工作被财务人员和外聘审计师正确归类的关键数据。\
ScrumMaster会推动流程从而调整团队的行为使其与既定目标更加可靠一致。Scrum技术中有一个自适应统计基础，并由实验来进行支持，这在传统的项目管理技术中是没有的。根据我的经验，相对于基于瀑布模型的“实际数字”，审计师可以更加信任基于敏捷的报表。\

作为一个ScrumMaster，如果你想抓住这个机会，劳动分类将可能成为你和公司其他ScrumMaster的职责。必然的，你将可能成为软件资本化、资产折旧、资产减损这些主题的专家。欢迎来到财务的世界！

适当的分类将缔造一个光明的未来

税务机构和投资者使用运营费用和资本费用这些概念来帮助他们做出更好的决策。他们通常希望公司们进行长期投资，这样他们便可以让公司将投资成本均摊到整个时间段，从而略微的抵消部分应税收入，伴随着投资一起挣钱。

软件工作可以提供短期的价值（所有ROI在一年之内）或长期的价值（ROI跨越多年）。举个短期的例子：一个合约型软件公司可能为某个客户创建了一个网站，它在获得报酬后没有保留对该网站的所有权。在这个例子中，我们认为开发成本是一项“运营费用”。

上市公司通常需要向股东和税务机构报告年度和季度的利润。计算利润的公式非常简单：

利润 = 收入 – 费用

举个长期的例子：一个玩具零售商创建了一个网站来出售它的玩具。在创建完这个网站的若干年后，这个很久前完成的工作持续的产生着收入。在这个例子中，我们认为开发是一种“资本费用”，是一项长期的投资。计算总利润时需要追溯到很多年前，得到以下公式：

总利润 = 第一年的收入 + … + 第n年的收入 – 投资费用

股东和税务机构每年都会期待财务报表：我们去年的利润有多少？如果我们有一个长期的软件项目，并且在第一年是没有收益的。如果我们将它视为运营费用，我们可能将出现亏损。而不淡定的股东也许会因此卖掉我们公司的股份！也许我们不需要在这一年支付税负，那真是太好了！但是下一年我们也许没有开发费用，而我们的玩具零售网站却得到了大量的收入，在某些行政辖区将面临全额征税。如果我们这样处理开发计划，将会使我们消极的看待长期投资。

明智的做法是，税务机构和审计小组让我们把系统中的资本费用均摊到整个时间段，这种做法称为“折旧”。大多数的折旧计划会将资本费用均摊到整个软件的预期生命周期上，所以如果我们开发的玩具零售网站预期将被使用5年，我们将在开发后的第一年花费20%的开发成本，然后每年花费20%直到第5年。联系一个会计师以获取关于折旧计划的更多信息，这很大程度上取决于一件资产的预期生命周期。

一项投资可能未必马上可用。由于我们并不是立即从该投资获取收入，我们通常可以延迟折旧直到它开始被使用。会计学将开发之前的这段时间简称为“资本化时期”。（顺便说一句，资本化收益将在折旧开始后继续）如果我们从我们的网站软件上移除功能或彻底地停止使用它（很可能是我们替换了它），不管是在开发之前还是之后，我们“减损”了我们的前期投资，那么我们需要立即将剩余成本进行费用化。

通过对软件开发进行资本化，公司可以取得一定的税负优势：他们通常通过延迟成本从而抵消应税收入，并可以获得更多的利息收入。各部门也将会取得一定的雇佣优势：当一个部门可以延迟软件投资成本时，通常可以将这些被延迟的成本花费在员工薪资上（雇佣更多的人，提供加薪，等等）。

(点击图像放大)

使用折旧和未使用折旧的利润与亏损对比

该图描述了利润和亏损（损益表）是如何受折旧所影响的。这些数字的展示单位是“千美元”。作为软件项目的一个典型性，主要成本（开发成本）发生在项目开始：2012年花费了200万美元和2013年花费了200万美元。在2014年及以后，成本是20万美元一年，主要是花费在向软件增加功能特性的成本。该项目在2014年被部署之前始终没有盈利或带来成本节约，直到该时间点之后才开始带来每年120万的收入。

如果项目成本没有被折旧，而是马上被费用化了，蓝色的线条讲述了损益的故事：在开始的两年存在巨大亏损，而在接下来的几年内出现了巨大的盈利。

当成本被折旧时，绿色的线条讲述了一个截然不同的损益故事。从损益表中可以看到在软件被投入使用之前没有成本花费。当软件就位投入使用时，我们通过一个五年的时间窗口对成本进行折旧以计算我们的利润

为什么这很重要？政府通常只对总数为正数金额的利润进行征税，所以很难通过负数金额来减少未来每年的应税利润（除非你通过折旧来进行调整）。

财务人员通常会因为将所有软件费用视为运营费用而造成过度花费，并声称这是某种程度的保守行为。而事实上并不是这样，如果你正在进行一项长期投资，将软件投资划分到短期费用一类将使你的公司看上去很不稳定——这对你的股东来说是很不负责任的。这将带来更高的税负义务，这也是对你公司的不负责任，同时违背了你们国家对于希望你们进行长期投资的原本目的。

一家具有高额利润的公司能够抵消一个产品开发部门的生产损耗。这样可以避免税负问题，但是却无法避免糟糕的计划。根据我的经验，高管们会把注意力放在部门的利润和亏损上，并据此来决定人员的编制。我们中间谁没见过大型软件问题中关于人事雇佣和解雇的兴衰循环？在某种程度上，人员编制的波动的可能原因是由于未能适当的将软件识别为一项投资。

最后，如果敏捷软件项目被费用化而瀑布模型项目却没有，这本质上相当于对任何长期在企业中采用敏捷实践的方式判了死刑。如果瀑布模型项目可以雇佣更多的员工，而敏捷项目却不可以，你认为经理们还会选择推动哪种方法论？

忽略敏捷而推荐的会计实践

会计实践并不完全是由税务与证券法律所指定的。相反，美国财务会计准则委员会（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，团队成员以及兼职成员薪水的一定比例）。你便可以得到“每个点的成本”。\

\ ID \	\ 描述 \	\ 估点 \	\ 是否资本化 \
\ 1 \	\ 添加国际化语言功能 \	\ 8 \	\ Y \
\ 2 \	\ 在英文版本中修复回归bug \	\ 5 \	\ N \
\ 3 \	\ 对西班牙，法国，德国进行本地化 \	\ 13 \	\ N \
\ 4 \	\ 为公司高级客户定制软件 \	\ 3 \	\ N \
\ 5 \	\ 以更好的图形化，信息流来重构网站 \	\ 13 \	\ Y \
\ 6 \	\ 修复在Mac OS上一直存在的“导出”无效的bug \	\ 8 \	\ Y \
\ 7 \	\ 实现导入功能 \	\ 13 \	\ Y \

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

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

作为 \u0026lt;利益相关者\u0026gt;，
\我可以 \u0026lt;执行某个行为\u0026gt;，
\我们公司将因此 \u0026lt;获得业务价值\u0026gt;

验收测试：

\u0026lt;验收测试 1\u0026gt;\
\u0026lt;验收测试 2\u0026gt;\
…\

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

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

下面是一个例子：

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

验收测试：

通过管理界面，系统操作员可以很容易看到负载。\
如果负载在绿色区域时，至少还有50%更多的用户可以加入系统而无需关注。如果负载在黄色区域时，至少还有20%更多的用户可以加入系统而无需关注。\
当负载进入红色区域时，可以添加更多的机器从而将负载降回到黄色或绿色区。\

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

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

怎么跟踪工时？

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

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

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

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

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

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

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

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

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

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

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

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

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

总结

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

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

为了敏捷和上善之道，我一直是你卑微的仆人。（译者注：原文是For agility and the greater good, I remain your humble servant. 作者幽默的一种表达，表示将始终为敏捷事业而服务）

关于作者

Daniel R Greening, 博士是Senex Rex的总经理，Senex Rexa 是一家面向美国和欧洲的管理咨询公司。他设计和实现的资本化策略为Citrix Online所使用，并且为很多公司提供过该主题的相关顾问。 Dan 引领企业进行可持续的敏捷转型。他目前在他的客户之一——某家大型的软件公司担任Product Owner，并为该客户提供国际化的敏捷指导。Dan 曾在Citrix Online 和 Overstock.com 领导过所有工程流程的转变。你可以通过dan@senexrex.com联系到他。