Ryu*_*Ryu 20 testing agile scrum process code-freeze
我很好奇社区是否认为在我们停止开发的情况下使用"Code Freeze"一词是可以接受的,除了测试和修复bug.
发展情况
我们刚刚完成了我们的第三次也是最后一次冲刺,之后将进行"代码冻结"和2周的Q/A测试.这是一个很大的发布,一些组件开发超越了所有3个sprint.从历史上看,即使我们将其称为"代码冻结",我们仍然会提交代码来修复错误.
问题
每一个版本我都会尝试并纠正我的经理和同事,我们应该将其称为"功能冻结",因为很明显我们会在我们开始大量测试后立即找到错误并提交代码来修复它们.但是他们仍然坚持称其为"Code Freeze".有时我们仍然知道错误并声明"代码冻结".
维基百科的定义在这里似乎与我一致
分析
我怀疑将这些情况称为"代码冻结"是某种故意的双重思考,为利益相关者提供虚假的信心.或者我们假装处于"Code Freeze"状态,因为根据Scrum的说法,在每个sprint之后我们都应该有一个可发送的软件,这是我们对Scrum的期望.所以我们必须把它称之为Scrum所期望的而不是它真正的本质.
结论
我在分析这个吗？我只是发现忽视情况的现实是不健康的,应该放弃它,称之为不是或者解决根本问题.还有其他人有过与Code Freezes类似的经历吗？
Sho*_*og9 18
我在分析这个吗？
是.
我们可能会.实际上,在冻结之后进行任何代码更改之前,您应该三思而后行.错误应该通过一些严重性测试,如果修复程序需要对代码库进行潜在危险的更改或者使已完成的测试无效,则更多.如果你不这样做那个,那么是的,你只是在欺骗自己.
但是,如果你不想修复任何错误,那么冻结代码有点毫无意义:只需构建并运送它.
最重要的是,重要的是你们都明白标签的含义,而不是标签本身.一个大快乐的Humpty-Dumpty ......
Chr*_*ons 12
我们使用术语"功能完成".所有功能都是编码和功能,但我们正在进入测试通过,以确认没有错误.如果有错误,我们会找到它们,修复它们并重新测试.在我们对结果感到满意后,我们就是"代码完成".