“我们正在运行敏捷开发，所以没有什么需要审计”，这是审计员们在审核运行敏捷开发的客户时，经常听到的一句话。对于一个植根于计划驱动型方法论的职业，从验证软件开发到记录审计工作文件，敏捷方法都构成了一个独特而复杂的难题。1
针对文档的案例
敏捷软件开发宣言由 17 位自称为“组织型无政府主义者”于 2001 年在犹他州的一个滑雪度假胜地起草，其中的前两条价值观（见图1）似乎与一般审计概念存在冲突，因为内部控制设计和验证总是取决于流程和程序文件。此外，Scrum 作为一种深受欢迎的迭代敏捷软件开发方法学，提倡自组织、跨职能团队，对于习惯于为降低不当行为或欺诈的风险而明确划分职责分工的规定岗位和职责的审计员而言，审计过程变得非常具有挑战性。
回顾于1970年首次提出的瀑布模型的开端，有助于了解敏捷开发和 Scrum 的演化过程，并识别对审计的相关影响。虽然瀑布模型定义了大型软件系统开发管理的不同阶段，但也认识到了迭代的必要性。2 快速跨越30年，这一认识对敏捷开发和Scrum的倡导者则会非常理想，因为对他们而言，每两周一次的冲刺（sprint）都会让工作的软件的DEMO演示为结束。从梗概结构着手，并继承每一次连续冲刺的更多功能，Scrum 团队力求通过不断处理产品积压工作，“满足” 新出现的各种需求。
瀑布模型提倡在整个开发生命周期内保持重 要文档。部分文档的确有助于避免误解已经达成一致的事项。然而，正是需求分析阶段对重要文档的维护，反而产生了更多文档，形式多为寻求计划差异审批的变更请求。根本而言，敏捷软件开发宣言并未大大降低对文档的重视程度，反而是更加重视可用的软件。敏捷开发侧重于创建够用就行的文档来启动和维持跨职能团队成员之间的开放式对话。创建够用就行而非全面的文档的前提是，在项目开始之初，所有需要知晓的一切都尚未知晓。大量意料之外的结果随时可能出现，例如客户会而且经常会变更他们对功能的想法，即便软件的代码已经完成（所开发功能的 64% 从未或很少会被用到）。3 因此，在项目之初过度创建文档并用其作为下游活动的基准，这似乎有悖常理。
虽然敏捷开发的文档较短，实际上却可以给项目婴儿期可能尚不清晰的不确定性带来更大的透明度。根据 House of Scrum 创始人 Jens Østergaard 的观点，与已知不确定性相关的风险会在每次连续冲刺（sprint）时逐渐消失，而在瀑布模型中，全面的初始规范文档可能会产生虚假的安全感，只会在项目进入测试和上线阶段（图 2）时，随着潜藏的复杂性在下游的显现而被替代。4 从审计角度来看，审计员如果过早寻找证据，很可能审核的材料到当需求进一步清晰之后会被覆盖掉。
从故事叙述到故事测试
这并不是为了阻止审计员在软件开发早期进行干预。事实上，未被利用的机会常常隐藏在用于在敏捷开发中描述规范的用户故事中。图 3 描述了用户故事的模板。
应对更改的关键方法之一是鼓励主动对用户要求尚未完成部分进行更新，而不是因循既定计划。详见 图 1 中列出的第四价值观）；在敏捷开发中，这称为每个冲刺（sprint）阶段用户故事的产品积压工作疏理。用户故事代表了客户的心声，所以开发团队的明智选择是确保他们最大程度地适应。
Scrum 团队是如何知道他们已经交付了一个用户故事的？在每个用户故事的背后，是一套有助于阐明为了交付故事而需要满足的具体条件的验收标准。验收标准识别也可以将较大的故事分解成更小、更容易消化的部分，以便开发人员考虑。用户故事通常遵循一组 (INVEST) 属性即独立、可协商、对用户或客户有价值、可估算、小并且可以测试。
行为驱动开发 (BDD) 是一种发现并测试软件应该做什么的手段。“一个故事的行为，简而言之便是其验收标准；如果系统满足所有验收标准，则表示其行为正确。”5 自动化测试工具能够让团队以情景描述作为验收标准；通过使用代码添加步骤定义，情景可变为自动测试。情景的形式详见 图 4 所示。
下面以开发一个超过$1,000美元采购申请应用程序来说明（图 5）。
如何能确认Scrum团队在其用户故事中交付了这一点？图 6 展示了一个可供考虑的情景。
情景可促使利益相关者澄清到底什么是他们需要的，并有助于减轻镀金风险，因为那只是添加不增值的功能。因此，审计员可以在早期介入软件开发过程，但不是审核全面的前期文档，而是参与到用户故事策划中。
每个故事都有机会准备被滥用的情景，这种情景的验证性质是负面的，即覆盖不遵循计划的情景。图 7 描述了五种滥用情景的预期应用行为。图 8 阐述了这些情景的传统内部控制目标。
| |
事实证明，对于拟提出的支出请求是否被正确记录至适当的总账账户，并无控制。审计员有机会阐明有必要增加另外 的确保交易诚信的其他职责。通过在冲刺（sprint）期间而非在之后加入Scrum团队，审计员可以为财务人员增加一个故事，从而提供一个如 图 9 所示的第二审核层。
如果开发方法为瀑布模型，审计员获得初始需求（即企业买家正确完成总账账户的采购功能代码编写）的批准后便会感到满意，即便在现实中，这个流程并不能执行。除了参与用户故事开发外，审计员还需要改变他们开展审计的方式。
一份规范应该做点什么。6 因此，在审计敏捷开发时，审计员可以采用更加恰当的方式要求可执行规范的系统日志，而非期待一本活页夹装订的书面规范。以下问题可以帮助审计员进一步了解规范：
- 自动测试结果在哪里？
- 如果测试失败会发生什么？
- 测试覆盖范围是什么？
- 自动测试更新的频率是多久？
好消息是，敏捷开发和Scrum的产物与审计员依赖于内部控制系统证据的传统审计的产物没有太大区别。用户故事反映了用户的叙述，而验收标准则反映了确保交易处理准确性、完整性和有效性的应用程序控制。考虑更加完整的不同角色和情景（通过用户故事和验收标准阐述）的审计员能够 为Scrum团队做出重大贡献。
审计员还可以挑战项目结束时的测试是确保所要求的质量的唯一途径的现行思维模式。人们普遍认为，漏洞发现得越晚，修复的成本就越大。7 同样，如果故事的验收标准是作为行为驱动开发的一部分而制定的，则开发人员可以采用测试驱动开发（TDD）在编写代码前编写测试。对采用测试驱动开发的三个微软敏捷开发团队和一个IBM敏捷开发团队的研究表明，产品预发布缺陷密度分别下降了40%和90%。8 此外，当与触发测试的连续集成（CI）服务器结合时，每次新代码变更进行签入时，就会激发测试。与独立下游测试阶段相反，测试已成为编码的组成或伴随部分。因此，单元和功能错误的较早识别可以降低后续修复成本，释放测试者的时间，使其能够增值做探索性和端到端交易测试。
重叠的角色
本文中提及的敏捷软件开发宣言的其他价值观强调客户合作高于合同谈判（见图 1中的第三个价值观）。瀑布模型重点强调不同阶段和移交，可比作一场接力赛，9 而Scrum则源于一场球赛的重新开球，球员们都低着头聚在一起，试图获得对球的控制权。当应用于软件开发时，Scrum 方法着重于通过合作来重叠不同的阶段。
这对审计影响有多大？强调合作以获得可持续产品设计，是作为问题解决手段的设计思维出现背后的一项准则。通过考虑用户故事中的滥用情景，审计员可以在Scrum团队中扮演一个重要的角色，积极参与到合作中。
扩大被审计人员范围是审计员可以作出的另一项有用调整。正如前面所提到的那样，只要产品拥有者推动着用户故事的产品积压工作，便是确保合规性和安全性需求得以满足的一项关键来源。通过确保在Scrum团队中广泛代表利益相关者，审计员可以作出重要贡献。Scrum 团队的构成在确保所有参与者对项目的期望保持一致方面起着重要作用。
然而，仅因为Scrum团队是跨职能并不意味着团队中的任何人都可以访问所有开发、测试/交付准备和生产环境。审计目标要求职责分工与开发目标维护代码整体性并不相互排斥，职责分工（SoD）是要达到限制环境或配置访问，任何个人均不能规避或破解现行的内部控制系统。开发目标维护代码整体性要确保有效代码变更不因疏忽而被覆盖，或因与未经过测试或未与现有接口充分集成的代码竞争而被稀释。
通过强调客户合作高于合同谈判，很容易被误导，认为敏捷开发的流程高于结果。根据对来自三个不同组织的团队（一个团队采用瀑布模型，一个采用敏捷开发，另一个两个方法都采用）的采访显示，采用瀑布模型的组织更强调预防控制的产品或结果，而采用敏捷开发的组织则倾向于检测 性和纠正性控制的流程。10 通过敏捷开发对以可用软件为结果的基础性关注人们可以反驳道：在Scrum中，测试驱动开发、连续集成和自动化单元和验收测试等控制实践真正侧重于结果，而瀑布模型则侧重于正式的批准，真正出于对流程的强调。图 10 阐述了敏捷开发和Scrum中基于流程和基于结果的不同类型。
至于敏捷开发的控制是否比瀑布模型更具检测性或纠正性，具体标注控制是属于预防性或检测性也尚属灰色区域。因为作为一个项目从实际应用角度说，瀑布模型的测试阶段属于预防性，即通过在测试环境中暴露出代码错误，可以降低在实用中出现代码错误的可能性。但从开发角度来看，测试属于检测性，因为它能够揭示出开发阶段的代码中的错误。同样地，通过在编写代码前迫使开发者测试失败，Scrum 和极端编程中的测试驱动开发能够检测出错误，所有使其能够防止最终生产阶段产生错误。相同的论点可以扩展至自动化单元和验收测试；当在开发和准备环境中侦测错误时，他们能够真正预防实际使用中出现错误。将敏捷开发控制描述为检测性比预防性更强，会错失深入挖掘真实内容的机会。
控制就绪性是一种功能
一个企业的控制就绪程度不仅取决于所采用的实践（软件开发中采用的是瀑布模型，还是敏捷开发）还取决于每个企业独有的环境。管理层在控制软件开发的过程中采用的由上而 下，还是自下而上的方法，在是否最终采用瀑布模型、敏捷开发、亦或二者的结合上具有很大区别。实际上，审计员可以审核敏捷团队践行敏捷开发的彻底程度。
审计员长期以来一直依靠验证流程的运行有效性，寄希望于一个控制良好的流程会产生正面的结果，如验证批准证据。流程控制的问题在于，他们对促进正面结果而言可能是必要的，但还绝对不够。考虑 图 9 中显示的提交采购申请审批的用户故事。
当审计员在对发票进行抽样审核时，他们可能会发现都匹配已审批的申请。他们能够找到 100% 双向匹配，而无例外。似乎所有采购均事先做出了批准。但他们还是从系统审计时间戳中发现，对一组特定的采购员而言，申请几乎总是在发票开具后短期内创建，有时候仅仅在几分钟内。事实证明，对于这组采购员，因为计划支出高度不稳定，很多在前期进行预测，只有在收到发票时才能创建申请，而非在收到发票前创建。
这具有说明性审计结果对将申请审批作为精确控制支出的手段产生了怀疑，因为审批是发生在收到服务之后，而非在服务提供之前，而且通常作为证据以应付审计。审计员必须积极地确保审计保持作为有效的错误或欺诈保障措施，而不是为了审计而审计的形式化手段。11 敏捷开发强调可用的软件，侧重于结果，因而为审计员提供了相应调整方法的机会。在敏捷开发和Scrum圈子中存在一个广为流传的观察，即Standish Group在2002年和2010年进行的软件项目研究显示，敏捷开发成功率比瀑布模型要高三倍。12 但是审计员们指出，Standish Group的同一份研究中还显示，敏捷开发和瀑布模型项目都有50/50的机率被质疑。
作为轻量级框架，敏捷开发和 Scrum 的原则并非大而全。他们不解决风险管理、产品策略以及其他包括支持和维持产品投放、持续强化和维护等大量活动的领域。在审计敏捷开发时，重要的是审计员需要认识到，采用Scrum或敏捷开发的企业并非在空跑——其实还有流程方面的产物和步骤，以及从结果方面跟踪测试覆盖率和自动测试结果的衡量指标。或许更重要的是，审计员最好需要观察到，与其前任瀑布模型一样，敏捷开发并非解决弥合软件合规性和安全性这个老大难的有效解决办法。
尾注
1 本文使用了多个对理解而言非常关键的敏捷开发术语。冲刺（sprint）是指具体工作必须在其范围内完成并准备好可供审核的一段时间。燃尽图是指剩余工作与时间的图形表示。产品列表是指包含产品内所需的所有功能的简短描述的优先功能列表。
2 Royce, W.; 《管理大型软件系统开发》, 西部电子展览和 会议（WesCon）技术论文，1970 年 8 月 25-28 日，美国加利福利亚洛杉矶
3 Johnson, J.; Standish Group 在 XP2002 上汇报的研究
4 Ostergaard, J.; “为何Scrum如此之难”，2009年8月 20日，http://www.slideshare.net/marakana99/jens-stergaard-on-why-scrum-is-so-hard-2416688
5 North, D.; “行为驱动开发介绍”， 《更好的软件》， 2006年3月，http://dannorth.net/introducing-bdd/
6 同上。
7 Beohm, B.; V. Basili; “软件缺陷削减前十列表”，《电脑》，第34卷第1期，2001年1月， p. 135-137
8 Nagappan, N.; E. Maximilien; T. Bhat; L. Williams; “通过测试驱动型开发实现质量改进：四个工业团队的结果和经验”，《实验软件工程》，第13卷第3期，2008年6 月
9 Takeuchi, H.; I. Nonaka; “新产品开发博弈”，《哈佛商业评论》，64，第1期， 1986年1月-2月
10 Cram, W. A.; M. K. Brohman; “控制信息系统开发：针对不断演变领域的一种全新类型学”， 《信息系统杂志》， 23 (2)， 2013， p. 137-154
11 Power, M.; 《审计学会：验证的例行公事》，英国牛津大学出版社，1997年
12 CHAOS 宣言，The Standish Group，2012年
Chong Ee，CISA，CGEIT，是位于美国加利福利亚洲旧金山的云通讯公司 Twilio的资深财务系统经理。Ee 专注于优化财务云应用程序的使用和集成。近期，他为 Trulia 实施了 NetSuite 和其他软件作为服务解决方案，以支持该公司从创业阶段到IPO、再到上市公司的增长。在此之前，Ee 具有在大审计公司、财富五百强公司和创业公司的各种合规、审计和顾问岗位上从业13年的经验。Ee 是一位经过认证的 NetSuite ERP 顾问和 NetSuite 管理员。