Cambios de tarea
Los cambios de tarea son muy malos para la productividad. No importa quién hable de ello, está claro que cambiar a alguien de tarea es un gasto de tiempo que, a pesar de todo, siempre ocurre en los desarrollos de software.Recuerdo que en el libro Peopleware, hay un capítulo que habla de la enorme cantidad de tiempo desperdiciada cambiando de tarea. Hace poco (y es por eso que estoy escribiendo) leí una entrada en el blog JoelOnSoftware tratando sobre lo mismo. Pero como Joel decia: no siempre se pueden evitar los cambios de tarea.
Así que, cambiar de una tarea a otra porque aparece algún problema urgente, una petición de cliente o algo similar parece inevitable... y el impacto en productividad muy alto pero... ¿hay alguna manera de minimizarlo?
Si eres un programador trabajando en cierto código y te ves forzado a cambiar a otra cosa, ¿cómo lo harías? Normamente habrá unos cuantos ficheros en los que estás trabajando, y muy probablemente todavía no hayas acabado. Entonces, ¿qué haces con el trabajo que todavía no está terminado? Probablemente estés usando algún tipo de control de versiones, pero hacer un commit o una protección (un checkin) de código a medio acabar no parece muy buena idea. ¿Qué hacer entonces? Probablemente acabarás copiando los ficheros a otro directorio, y preparando el área de trabajo para la siguiente tarea.
La imagen muestra la situación. Incluso teniendo un control de versiones, el programador acaba copiando ficheros manualmente. No tiene muy buena pinta. Además, todos esos cambios se quedan fuera del control de versiones y... ¿por cuánto tiempo?
¿Qué puede ocurrir con esos cambios si se quedan fuera del control de versiones? ¿Pueden perderse? ¿Qué pasa si se tarda más en volver a la tarea de lo esperado? ¿Y si se rompe el ordenador del programador? :-)
La mayoría de los controles de versiones fuerzan a seguir un modelo como el ilustrado en la imagen. Vale, no todos ellos, y por eso estoy escribiendo sobre el tema...
¿No sería mejor que el control de versiones ayudara a gestionar los cambios de tarea?Se puede hacer mediante el patrón de rama por tarea. Creas una rama cada vez que tienes que trabajar en algo, sea lo que sea, desde un pequeño cambio hasta una tarea de varias semanas de trabajo. Entonces, teniendo tu propia rama, puedes proteger tus cambios (quiero decir hacer checkin en el control de versiones) tantas veces como necesites.
Se guardarán los cambios intermedios, todo el trabajo del desarrollador se almacena en el servidor (puedes incluso evitar los backups de las máquinas de los desarrolladores, ahorrando dinero), así que nunca más te pasará eso de sí, creo que el código bueno estaba en tu ordenador.
Y además ayuda a cambiar de tarea: haces check in de todo, enviándolo a la rama asociada a la tarea, y símplemente te mueves a la nueva. Nada de copiar ficheros a mano, nada de riesgos extra, nada de tiempo perdido. Símplemente usar la herramienta.
Entonces, si es tan fácil... ¿por qué no es lo que hace todo el mundo? ¡¡Límites!! La mayoría de los controles de versiones tienen graves problemas trabajando con ramas, por eso no puedes plantearte usar rama por tarea, y cambiar de tarea es un dolor. Y por eso hemos diseñado Plastic SCM para que trabaje perfectamente con ramas. Puedes seguir la estrategia que hemos propuesto con nuestra herramienta... ¡¡y verás la diferencia!! :-P
0 comentarios:
Publicar un comentario