敏捷过程和瀑布过程之间的僵局一直存在 项目管理 几十年的讨论. 软件开发团队在敏捷环境中茁壮成长, 但缺乏管理层的支持是其中之一 敏捷转型的主要障碍. 在软件行业工作了一段时间的项目经理可能会遇到希望他们“使用瀑布法”的高管.但这在实践中究竟意味着什么呢?

多年来, 研究表明 的使用之间存在正相关关系 敏捷框架 和 项目的成功, 对于项目经理来说，他们可能很容易相信他们只需要向公司官员推销敏捷的结果. 但同样重要的是要了解高层管理人员喜欢什么 瀑布式方法. 如果你了解瀑布公司为高管层提供的财务保障，你就可以制作一份 混合框架 这将弥合两者之间的差距 敏捷实践 和企业瀑布一劳永逸. 这种理解始于《欧博体育app下载》鲜为人知的起源故事.

瀑布方法的模糊起源

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

将瀑布开发归功于Royce的研究是软件行业的一个奇怪的讽刺. 在他的论文中, 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)，它本身是软件工程师普遍认可的最佳实践的综合.

这就提出了一个大问题:为什么管理层会反对使用敏捷方法而不是瀑布方法, 从一开始就被行业专家和专业人士视为与高效开发实践不一致的框架?

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

瀑布仍然受欢迎的原因需要一些关于开发团队很少考虑的业务功能的知识:会计.

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

在2000年到2002年之间——即使是在 敏捷宣言 两起重大的会计丑闻震惊了整个企业界, 首先是这家美国能源公司 安然. 简单地说, 安然(据称与安达信会计师事务所合谋)故意对运营费用和资本费用管理不当，从而向投资者隐瞒了重大损失. 这是欺诈性夸大利润的更大计划的一部分, 从而提升其股票市场价值, 损失数十亿美元.

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

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

这就是 项目管理 扮演着核心角色. 在这项立法之后, 首席财务官需要一种他们可以指出的安全机制:一种可以证明他们符合《欧博体育app下载》(萨班斯-奥克斯利法案)要求的管理风格. 项目管理学会 有一个解决方案:相位门过程(又称阶段门). 这种瀑布式技术使用了一系列的“闸门”——暂停，在这些地方需要执行人员的批准才能推进开发. 通过定义一个只包含资本支出合格活动的阶段, 并将其与其他阶段隔离开来, 首席财务官可以证明他们在将一项支出列为资本支出时进行了尽职调查.

快进到现在, 20年来，phase-gate管理一直是上市公司开发项目的实际标准，stage -gate International估计 《欧博体育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 萨班斯-奥克斯利法案.

好消息是，您需要做的所有事情都可以在实际开发过程之外进行，以确保项目将通过审计. 如果你能向高层保证他们的需求会得到满足, 他们应该接受一种混合方法，即在计划阶段通过瀑布方法处理财务问题，而在敏捷框架中进行开发。

穿越瀑布

如果一个项目经理了解他们的CFO想要什么，并且能够向他们保证由阶段门框架提供的操作监督, 没有理由在开发中使用瀑布而不是敏捷. 在处理阶段门管理的需求时，要理解它的目的是财务和法律上的，并不一定会影响团队的开发工作. 以下是如何开始:

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

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

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

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

理解的重要性

您的项目控制办公室(或, 如果你没有的话, 你的财务主管)可以帮助你了解公司的门槛 物质——财务差异重要到足以被记录下来的那一点:购买一盒笔可能被认为是无关紧要的, 但为团队购买新电脑却不是. 非物质变成物质的那条线因公司而异. 了解公司的门槛, 并做相应的记录, 会让你更喜欢做会计决策的人吗.

分享 your domain knowledge with your counterpart in finance; for example, 理解的概念 交换用户故事 就如何处理这种做法达成共识，将避免出现不当行为. 向他们保证，如果互换产生的任何额外费用可能超过实质性门槛, 你将把它升级，这样它就可以被适当地记录下来.

讲金融语言

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

最重要的是, 如果您提供项目预算报告或更新, 确保你的行项目标题和描述与你第一次批准预算时使用的完全一致. 如果批准的预算指的是“Epic: Authentication UI,，那么你就应该在你的报告中写上这句话——而不是“史诗登录屏幕”或其他任何变体. 忽略这个建议，你肯定会在整个公司的财务部门制造摩擦和挫折.

价值交付

如果你符合上述财务要求，恭喜你! 你满足了高管层“瀑布式”的需求.“资本性开支已妥善入账, 该过程的任何部分都不需要对代码的实际编写方式或更新的交付方式进行任何更改. 你在计划中做出的任何妥协都为你在其他部门和高管层赢得了盟友. 这个过程也让您更好地了解您的团队如何与组织的其他部分合作, 而不是孤立地工作——或者更糟, 与本该站在你这边的人唱反调.

An 敏捷纯粹主义者 可以把这些财务问题看作是“合同谈判”.“然而，把你的财务同事当作内部业务客户也是合理的. 满足他们在金融方面的需求只是客户协作的另一种形式. 在敏捷中，客户对价值交付的感知总是获胜的.