在sql中将日期转换_在敏捷转换过程中将软件资本化

在sql中将日期转换

客户想知道如何最好地计算他们的软件大小写。 当使用瀑布时，他们采用了“标准”方法。

他们不再拥有所有瀑布项目。 他们已经开始使用敏捷方法。 而且，项目看起来都不一样。 处于中间位置意味着他们在对大写字母进行推理时遇到麻烦。

为什么要大写？

资本化可以帮助公司将其投资从纯粹的支出类别转换为公司可以折旧的投资。

（我不是财务人员。如果您需要资本化，请与您的财务人员谈谈。我不提供财务或法律建议。我只是在讨论资本化与支出的观念，以及公司如何使用这些观念。一篇很棒的介绍文章， 软件开发成本大写 。）

大写对于内部工作尤为重要。

如果您在IT部门工作，您可能已经看到了内部退款。 那是因为该公司试图确定可以将多少工作资本化，以及必须多少支出。

如果公司拥有资产，则可以对其进行折旧 。 公司不能折旧费用。 您和我可能会认为这是在组织内流动资金，但是折旧在税收上有很大的不同。 公司（以及您和我）希望尽量减少我们的税收。

敏捷工作的资本化

让我为您介绍一个由5人组成的敏捷团队的例子。 假设每个人都在一个项目（如果愿意，可以是产品）上一起工作。 假设该团队的每周运行费为$ 2500。

大写规则说您不能大写计划工作。 您只能大写价值创造工作。

因此，让我们假设团队在团队工作的40个小时中总共花费了4个小时进行计划，回顾，演示以及所有非创造时间。 （我会在价值创造中加入演示功能，但我不确定会计师如何对反馈循环进行分类。而且，使用4个小时可以简化数学。）

4小时是40小时的10％。 这意味着团队要花费90％的时间来创建资本资产。 如果团队的运行价格为2500美元，那么90％的时间价值2777美元和几分钱。 我不知道是否允许会计师凑足2800美元，但我打算这样做。

结果：该团队可以每周一次将90％的工作资本化。

这是有趣的事情。 因为这是成本会计，所以转移到较短的周期时间没有会计价值。

但是，团队减少周期时间越多，团队创造的价值就越独特。 这有助于整体销售和支持。 （有关更多详细信息，请参见最低产品结果 。）

但是，如果您没有敏捷项目，会发生什么？

某些人如何看待软件项目

让我们首先讨论一些人如何看待软件项目。

当我以前与公司会计师一起工作时，他们认为软件项目遵循着一个串行项目的可爱轨迹：

• 我们首先获得了所有要求。
• 然后，我们分析了它们并创建了体系结构。
• 然后，我们进行了设计，编码，集成和测试。
• 而且，一切都正常。

是的，对。 我没看过 我总是使用递增的生命周期来管理风险。

几年前，我在一个客户身上向他展示了串行生命周期实际上是如何工作的：

我解释说，备选方案1很常见，在这里，我们不断获得需求，直到我们几乎“完成”编码为止。

备选方案2是您将更多需求方式集成到集成中，然后由于无法忍受更多更改而不得不削减Test的原因，因此您必须交付该死的东西。

并且，备选方案3是您尝试在整个项目过程中容纳所有反馈的地方。

（对于串行生命周期，还有更多的反模式，但是我不再赘述。这三种选择就足够了。）

在这三种情况下，我都问一个问题：如果我们不停止计划和重新计划，什么时候可以资本化？

一些更有创造力的会计师对我笑着说：“一旦开始设计，我们就可以从那里开始资本化。”

我问：“即使我们完成了90％的工作？ ”

一位会计师实际上ca不休。 “你打赌。”

循环时间长会伤害组织。 较长的周期时间不会损害大写。

资本化的一些替代方法

因此，我的客户正试图弄清楚该怎么做。 如果某些项目使用敏捷方法而某些使用瀑布方法，那么他们如何管理资本？

我建议了以下可能性：

1. 测量周期时间 。 团队每次发布功能时，他们都可以测量周期时间，并将其用作可以利用软件的平均时间。
2. 确保人们从事一个和只有一个项目。 现在，您可以测量项目的运行速度 。 您知道什么时候进行哪些活动。 您可以计算总运行率中的多少是费用，多少是资本。
3. 缩短项目，以便您知道可以每季度甚至每月发布一些内容。 然后，即使您“伪造”了大写数字，也可以显示可折旧资产。

我对大写字母的担心是，高大写字母并不意味着您会更频繁地发布广告。 而且，在我的太多客户中，如果团队开始编码，即使团队仍在重新计划，会计师也会把所有工作都当作大写。

您可能需要考虑大写。 我有一个建议：您如何使资本化的想法对您有用，从而创造较小的价值块并更频繁地释放它们？

（如果您对此有任何想法，请发表评论。谢谢。）

翻译自: https://www.javacodegeeks.com/2020/02/capitalizing-software-during-an-agile-transformation.html

在sql中将日期转换