Los gringos le dicen crunch time a esa fase dentro de los proyectos en la cual el equipo de desarrollo ingresa a un estado de sobre-dedicación, trabajando hasta tarde, incluso los fines de semana. Muchos de los que desarrollamos software sabemos, al menos intuitivamente, que esto esto es altamente contraproducente (no me refiero solamente a la salud, estado de ánimo y motivación del equipo) y mientras más tiempo dure, peor.
Lo que no había encontrado hasta ahora era una explicación lo suficientemente documentada como para convencer a un escéptico (léase project manager). La idea básica es que la calidad del código disminuye drásticamente como consecuencia de aplicar esta "práctica".
Aquí tienen un resumen de lo que significa el crunch time y como decir NO:
The Crunch Mode Paradox: Turning Superstars Average
Y esta es la fundamentación detallada de por qué se debe evitar a toda costa:
Why Crunch Mode Doesn't Work: 6 Lessons
2 comentarios:
Que buenos artículos! muy buena referencia para poder sustentar... que inicie la campaña "Digan NO al Crunch Time!", por una mejor calidad de software (y mejor calidad de vida).
Te he referenciado:
http://lshimokawa.blogspot.com/2008/04/digan-no-al-crunch-time.html
Desde luego yo también estoy totalmente en contra de esta práctica, por dos razones:
1-Es contraproducente para mí personalmente (salud...)
2-Es contraproducente para el cliente: mi trabajo será de menor calidad, será más fácil que aparezcan bugs en un futuro próximo, más difícil de mantener por otros, más difícil de modificar ante nuevas funcionalidades o cambio de requisitos...
Además, suele ser causado porque otra gente ha hecho mal su trabajo antes (toma de requisitos, análisis y diseño) con lo cual ya de por sí la calidad del software entregado será menor.
Sin embargo, favorece a los intermediarios: se aseguran que tendrán más horas de trabajo que facturar y se hacen más difíciles de reemplazar. Y mientras se pague por horas...
Publicar un comentario