嗨,我认为您不能将团队分成两组。
@Guge 涵盖了对这些团体成员的财务和政治影响。
还有更多:
1)速度组不会关心代码的质量。(他们不会为此付费!!)所以他们会产生丑陋的代码。
2)质量组将重写一些代码以更好。速度组将向此代码添加一些新功能,并且代码将再次变得丑陋。
3)速度组即将添加新功能。到未重构的代码。他们不进行重构(他们没有为此付费,因此如果他们这样做,或者他们的工作速度变慢,管理层可能会感到愤怒),因此他们会以低于他们首先重构的速度创建丑陋的^2代码。
4) 没有新功能。意味着没有 $$$ 意味着更低的工资意味着更差的开发人员分配意味着更低的速度和质量。
5) 更好的开发人员会找到一种方法来改变 goup 以提高速度或改变工作:)
5)如果质量组将提高任何子系统速度组可能会拒绝对现有代码实施任何补丁以不减慢速度。
好的 那么如何防止这种情况发生呢?
与您的管理人员交谈,您需要在新功能之间保持平衡。和代码质量。只有好的代码才能引入快速更改或实现新功能。高速。
好的论据是,糟糕的代码或架构演变成丑陋的东西是一种债务。当您不支付时,每月利息会迅速增长。你可以负担得起一个月不付钱,但不能再久了。
您可以随身携带信用卡以进行强调。
也许如果您的团队在截止日期前做太多工作,那么大声说出来总是值得的。但要小心;)
所有程序员都应该重构和编写测试(如果相关)。没有例外。今天稍微重构一下,明天再重构等等。
Fowler “重构” <- 好书借用了信用卡技巧。
PS有像“死亡行军”这样的项目,只推动开发。具有经济意义(因为项目只有在最后期限内以有限的费用取得成功;症状是持续工作数小时而开发量少于所需的时间),我的建议不适用于它