摘要： 在评估代码库的风险时，这不是单个的魔术数字，也不是简单的像是“通过/不通过”交通信号灯。风险是多维和多变的，对于不同的组织，风险的衡量方法也有所不同。 你可能已经知道代码中高风险或“不良”部分的位置——它们是你经常更改的代码部分，在这里和那里进行了一些小调整，以修复一些看起来无害的小问题，但通常代表着不良设计之上的要素分层。这就是为什么更改现有代码是在应用程序中引入缺陷的主要原因。 但是我们也知道变化是不变的。你永远不会完全实现所有功能或第一次都无法正确执行，但是与此同时，当你在现有代码上分层时，对每个用例和场景的了解就会丢失，复杂性会增加，并且代码的风险也会越来越大。这些变化为将环境应用于风险提供了关键条件。 与了解风险本身同样重要的是，了解如何应对风险——如何确定补救措施的优先级，以实现“可接受的风险水平”，同时最大程度地降低对团队速度的影响。不过，这篇文章仅着眼于：如何评估代码更改的风险以及如何有效地确定优先级和减轻风险。 阅读全文

摘要： 当目标确实是更准确地投放市场时，敏捷通常会误售给高级管理人员，以此来缩短产品上市时间。然而，我们没有告诉任何人的小秘密是，这实际上是有代价的…… 阅读全文