bta*_*bta 21
我不认为这与Scrum和项目管理理念有很大关系.
无论项目是否使用Scrum,许多项目经理都不喜欢开发人员花时间处理代码重构或重组等"不必要"的事情,而这些事情并未直接推进其中一项突出的功能需求.这不是"正常开发产生结果的工作",而是"防止结果延迟的工作".鉴于Sprint通常使用的时间通常很短,因此通常很难看到这种好处,而且几乎无法量化.
保持代码可维护性需要成为刻录列表中的项目(如果使用Scrum).它与新开发同样重要.虽然它可能看起来不像"用户可见",但忽略它会增加您的技术债务.当技术债务累积到足以导致您的代码缺乏可维护性减缓开发时,新功能开发的延迟将在客户身上显现.
这完全是管理/哲学的问题.不要将重构和可维护性增强视为不会影响客户的"额外"工作,而应将其视为时间投资,以防止客户明显的延迟(以及潜在的错误).开发人员有时可以比管理者更清楚地看到这些好处; 如果您的经理不理解忽视可维护性的缺点,您可能想要抓住其他几位开发人员并与您的经理聊天.
我认为有一个公平的案例可以用于技术债务重构,其中维护代码的努力/成本影响高于或甚至高于重构它以提高质量或更好/更好地工作的成本 - 特别是贷款它具有更高的可维护性.
例如:如果软件是如此有问题,你正在失去客户或金钱,你会迅速采取行动解决它......有些人可能认为这是它自己的业务要求,但它通常不会放在前面和中心位于中小型大小的开发项目,而不是专注于创建应用程序的技术性,而不是应用程序的质量对底线的影响.