度量源代码更改的风险？

Question

我的经理要求我为定义的任务编写工作时间估计和源代码更改的风险评估。

虽然第一个问题对我来说没有问题，而且网络上有很多资源，但我不能把我的头转到后一个。

我已经要求更清楚地描述风险评估，并得到了这样的答案:需要“由于更改而引起的后续代码更改”和“整个软件的潜在稳定性损失”的风险应该被说明。

我如何处理这个任务(经验规则，关于风险评估的文件，.)？

Answer 1

你的经理不想知道风险的数字。

经理通常想知道你不会把软件搞砸。

这两个风险区域相当于“你知道你需要知道的一切吗？”还有“你还会打破什么吗？”

你可能应该对风险进行定性分析。

列出你有的问题--神秘的领域--可能需要跟进的事情，或者你可能会因为不明白而分手的事情。

“数字”是1.0。您将有后续的更改(总是有后续的变化)，您将引入新的以前未知的错误(除非您有一个非常好的测试规程，这听起来不太可能从情况和问题)。

理想情况下，你了解整个问题，不需要跟进。这是真的吗？你能给出什么证据来证明你什么都懂？如果你有证据，提出它并声称没有后续的风险。如果你没有证据证明你了解整个问题，那就列出你不明白的事情。这就是风险所在。

理想情况下，你不会破坏其他任何东西。这是真的吗？有什么证据可以证明你的零钱是孤立的，而且你不会破坏任何其他东西？再说一遍，列出那些可能会破裂的事情；这就是风险。

请注意，只有在您完成所有更改之后，才能获得完美的知识。只有在您更改代码之后，您才会知道您是否知道所有的事情，并且没有破坏任何其他东西。

展望未知的未来，你只能猜测，如果你知道一切，不会破坏任何东西。

因此，有一定程度的收益递减。您可以提供一些证据，说明您了解更改并且不会破坏任何内容，但您不能完全确定您的分析，除非实际进行实际的代码更改。

Answer 2

最好的起点是一些具体的例子。选择应用程序中的几个区域，并计算出该领域出现问题的成本和发生这种情况的可能性。

例如，如果您对登录过程进行了更改，成本可能是：

1. 用户无法登录。
2. 任何能够进入的人。
3. 用户登录，但不能访问正确的功能-即他们有错误的角色。

然后评估每一种情况的可能性：

1. 不太可能-你会很快在测试中发现这一点的。
2. 不太可能--再一次，这是(或应该)容易理解的。
3. 更有可能的是--取决于您的应用程序有多复杂，发现某个人可以访问他们不应该或不应该访问的东西是很难发现的。

因此，对“后续代码更改”的需求和前两项的“潜在稳定性损失”都很低(但仍将存在)，而第三项则更高。

一旦您对一些高风险和低风险区域执行了此操作，您就可以将任何内容分配到这些区域之一。

Answer 3

虽然我觉得“风险评估”是一个糟糕的指标，但如果给开发人员，特别是将要工作的开发人员，情况就更糟了。您的经理还不如让您自己做自己的验收测试和自己的代码评审。

如果有正确的方法对某项任务或特性进行风险分析，我将通过以下几项措施来进行：

1. 特征涉及多少个独立的组件或功能点？
2. 受影响的特性或组件是否有清晰完整的设计文档或技术规范？
3. 自动化单元测试是否包含了受影响的特性或组件？
4. 还有哪些其他衡量技术债务的措施正在扼杀这个系统，而这些措施可能会有问题？

也许，如果你能用数字来解释这类事情，并在某种BS论坛上制定它们，以确定风险的比率，那么你的经理可能会对此感到满意。像我所描述的公式，虽然大部分没有意义，但就像管理色情。