软件开发中的估算、速度与技术债务解析
1. 估算与速度的合理运用
在软件开发项目里,对工作项的估算以及团队开发速度的衡量至关重要。不过,在实际操作中,这些环节常常出现问题。
假设有团队 A 和团队 B 负责相同的产品待办事项(PBI)。即便两个团队每个冲刺实际完成的工作量相近,但团队 B 的速度可能是团队 A 的十倍。团队 A 一旦察觉到这种比较可能带来的不利影响,成员就可能会采取不正当手段来提高速度数值,比如改变估算 PBI 的规模标准,把原本评估为 5 的工作项,重新评估为 500,这就是所谓的“点数膨胀”。这种行为毫无意义,只是为了迎合不合理的衡量体系。
即使团队采用相同的单位来估算 PBI,如果奖励机制倾向于更高的数值,那么必然会出现点数膨胀的情况。更糟糕的是,有些团队为了追求更高、更理想的速度,会偷工减料,这会导致技术债务不断增加。
我们应该依据速度对准确规划的辅助程度以及对团队内部改进的帮助来评判其价值。任何其他不当的使用方式都可能引发不良行为。
估算工作适用于组合层面的项目、产品待办事项和任务。对于 PBI 的估算,有故事点和理想天数等重要概念,常用的估算技术是规划扑克。速度以范围形式表示比单一数值更有帮助,对于新团队的速度预测也有一些方法。但在实际应用中,速度常常被误用。
2. 技术债务的定义与类型
技术债务这一概念最早由 Ward Cunningham 在 1992 年提出。他将首次发布代码比作负债,适度的债务在能及时通过重写偿还的情况下可以加速开发,但如果债务得不到偿还,就会带来危险。每一分钟花在不太正确的代码上,都相当于在为这笔债务支付利息,整个工程组织可能会因未整合的实现所
超级会员免费看
订阅专栏 解锁全文
16

被折叠的 条评论
为什么被折叠?



