敏捷过程和瀑布过程之间的僵局一直存在 项目管理 几十年的讨论. 软件开发团队在敏捷环境中茁壮成长, 但缺乏管理层的支持是其中之一 敏捷转型的主要障碍. A project manager working in the software industry for any length of time has probably encountered a C-suite that wants them to “do 瀑布.但这在实践中究竟意味着什么呢?

多年来, 研究表明 的使用之间存在正相关关系 敏捷框架 和 项目的成功, 和 it may be tempting for a project manager to believe they just need to sell their corporate officers on 敏捷’s results. 但同样重要的是要了解高层管理人员喜欢什么 瀑布式方法. 如果你了解瀑布公司为高管层提供的财务保障，你就可以制作一份 混合框架 这将弥合两者之间的差距 敏捷实践 和企业瀑布一劳永逸. 这种理解始于《欧博体育app下载》鲜为人知的起源故事.

瀑布方法的模糊起源

大多数从事组织管理的人将“瀑布”一词与下面的图表联系在一起, 来源于“管理大型软件系统的开发，这是温斯顿·W·史密斯撰写的一篇有影响力的学术论文. 罗伊斯博士，1970年. Royce的插图被广泛认为是瀑布式开发的第一个表达.

The crediting of 瀑布 development to Royce’s research is one of the strange ironies of the software industry. 在他的论文中, Royce never uses the word “waterfall” or advocates it as an effective system; he actually presents what would come to be known as 瀑布 as a cautionary tale—an example of a process that is “risky 和 invites failure” because it does not account for the necessary iteration needed among software development stages.

罗伊斯并不孤单:18年后，巴里. Boehm博士(他很快就会成为 美国国防部高级研究计划局)，用了一个非常相似的例子，再次作为一个有问题的例子 软件开发生命周期，并建议迭代开发作为一种有利的替代方案. 在1996年，几乎整个软件行业都赞同一个迭代开发周期，称为 合理统一过程 (RUP), which was itself a synthesis of best practices universally recognized by software engineers.

This raises a big question: 为什么 would anyone in management push back against the use of 敏捷 over 瀑布, a framework that since its inception has been seen by industry experts 和 professionals to be at odds with efficient development practices?

运营成本和. 资本支出:瀑布的财务案例

The reason 瀑布 remains in favor requires a little knowledge about a business function that development teams seldom think about: accounting.

在复式记账法中，有两种费用: 营运开支及资本开支 (通常也称为运营支出和资本支出). 任何费用都会降低公司的净利润, 而是运营费用，比如租金, 工资, 或者保险——降低成本 更多的. 这笔钱已经花了，因此不再记录在账簿上. 资本支出，如房地产, 工厂设备, 或者办公家具——由于一种叫做折旧的会计技术，利润降低的幅度较小, 哪一种方式将费用分摊到几年内. 此外，一旦一项资产被购买，它被认为是公司净资产的一部分.

在2000年到2002年之间——即使是在 敏捷宣言 两起重大的会计丑闻震惊了整个企业界, 首先是这家美国能源公司 安然. 简单地说, 安然 (with the alleged complicity of accounting firm Arthur Andersen) concealed major losses from investors by intentionally mismanaging 营运开支及资本开支. 这是欺诈性夸大利润的更大计划的一部分, 从而提升其股票市场价值, 损失数十亿美元.

此后不久， 类似的丑闻 发生在美国电信公司世界通信公司. 世通还故意将运营费用错误地分类为资本费用，从而掩盖了损失, 2002年国会通过了 萨班斯-奥克斯利法案. 该法案的条款中包括了有关公司高管的新规定, 比如CEO和CFO, 对因缺乏尽职调查而发生的股东损失承担个人责任.

说到软件开发， 资本支出vs运营支出 是一个特别复杂的问题:资本支出在资产负债表上看起来不错, 允许公司报告更好的营业收入和借入更多的资金.不利的一面, 然而, 大写标准是否已经发展并需要文档, 评论, 以及审批——所有这些都会极大地阻碍软件开发过程.

这就是 项目管理 扮演着核心角色. 在这项立法之后, CFOs needed a safety mechanism that they could point to: a management style that could prove they had met the requirements of the 萨班斯-奥克斯利法案. 项目管理学会 有一个解决方案:相位门过程(又称阶段门). This 瀑布 technique uses a series of “gates”—pauses where executive approval would be needed for development to advance. 通过定义一个只包含资本支出合格活动的阶段, 并将其与其他阶段隔离开来, CFOs could prove that they had exercised due diligence when listing an expenditure as a capital expense.

快进到现在, 和 phase-gate management has been the de facto st和ard for development projects at public companies for 20 years—Stage-Gate International estimates that 《欧博体育app下载》1000强中有80%的企业使用了一些变体 这个框架的. 对于敏捷开发人员或项目经理来说，这似乎令人困惑. 难道你的CFO不知道敏捷的好处吗? 他们可能会，也可能不会, 但不管怎样, 项目经理要记住的最重要的事情是:他们不在乎.

当首席财务官想让你“做瀑布”时,“这并不是基于瀑布法是交付软件最有效的方式这一信念. 程序员是否使用RUP对他们来说并不重要， Scrum、XP、Crystal、FDD、DSDM、 看板, or any other development technique or management framework; what they care about is capitalizing the project without violating the terms of the 萨班斯-奥克斯利法案.

The good news is that everything you need to do to assure the CFO that the project will pass an audit takes place outside of the actual development process. 如果你能向高层保证他们的需求会得到满足, they should be amenable to a hybrid methodology in which financial concerns are h和led via 瀑布 in the planning stage 和 development is done in an 敏捷 framework:

穿越瀑布

If a project manager underst和s what their CFO wants 和 can assure them of the operational oversight provided by a phase-gate framework, 没有理由在开发中使用瀑布而不是敏捷. Just approach the requirements of phase-gate management with the underst和ing that its purpose is financial 和 legal 和 does not have to impact your team’s development work. 以下是如何开始:

把预算看作是迭代的，直到它不是

每年，公司预算中都会分配一笔固定的资金用于资本支出. 其中一小部分分配给软件开发项目, 商业领袖们也会为他们的项目争取最大的利润. 这一谈判过程通常在财政年度的头两三个月进行.

谈判是 极 迭代,所以 项目预算 在整个过程中不断波动. 通过向您的业务发起人提供可调整的估计来授权他们. 这里的目标是建立一个预算信封, 因此，针对多种突发事件的广泛选择将非常有帮助. 例如, 除了基线估计之外, 如果满足节省成本的条件，您可以提供更便宜的选择, 比如通过手动输入进行数据迁移, 如果包含额外功能，也可以选择更昂贵的选项, 就像一个移动应用程序. This will help your business sponsor adjust their budget request as treasury committee negotiations get underway.

这些估计数需要在预算谈判之前提供, 因为一旦财政委员会批准了今年的项目, 没有回头路. 在阶段门系统中，门3是项目获得财务批准的地方. 预算的灵活性是存在的，但只存在于流程的前端，也就是在这个闸门出现之前.

理解的重要性

您的项目控制办公室(或, 如果你没有的话, 你的财务主管)可以帮助你了解公司的门槛 物质—the point at which financial variation is important enough to be recorded: The purchase of a box of pens may be considered immaterial, 但为团队购买新电脑却不是. 非物质变成物质的那条线因公司而异. 了解公司的门槛, 并做相应的记录, 会让你更喜欢做会计决策的人吗.

分享 your domain knowledge with your counterpart in finance; for example, 理解的概念 交换用户故事 就如何处理这种做法达成共识，将避免出现不当行为. Assure them that if any additional expense from a swap threatens to exceed the 物质 threshold, 你将把它升级，这样它就可以被适当地记录下来.

讲金融语言

如果你还不熟悉 每周状态报告 风险日志，大家要熟悉. 阅读它们. 爱他们. 定期准确填写. 把它们送给你的 项目管理办公室 他们也会反过来爱你.

最重要的是, 如果您提供项目预算报告或更新, make sure your line item titles 和 descriptions exactly match the ones you used when the budget was first approved. 如果批准的预算指的是“Epic: Authentication UI,，那么你就应该在你的报告中写上这句话——而不是“史诗登录屏幕”或其他任何变体. Ignore this advice 和 you are guaranteed to create friction 和 frustration across the entire financial arm of the organization.

价值交付

如果你符合上述财务要求，恭喜你! 你满足了高管层“瀑布式”的需求.“资本性开支已妥善入账, 和 no part of the process has required any change in how code is actually written or how updates are delivered. Any compromises you’ve had to make in planning have gained you allies in other departments 和 the C-suite. The process has also given you a better underst和ing of how your team can work with other parts of the organization, 而不是孤立地工作——或者更糟, 与本该站在你这边的人唱反调.

An 敏捷纯粹主义者 可以把这些财务问题看作是“合同谈判”.” However, it’s just as valid to think of your financial colleagues as internal business customers. 满足他们在金融方面的需求只是客户协作的另一种形式. 在敏捷中，客户对价值交付的感知总是获胜的.