A raíz de la charla de “Buenas prácticas de programación” han surgido preguntas y discusiones algunas relacionadas con la programación y otras sobre metodologías de programación, seguimiento y control de resultados y objetivos.
Aquí os dejo una de ellas, de Alejandro:
“…En la jornada planteabas ciertas prácticas muy interesantes como revisar código propio antiguo, código y soluciones de diferentes personas (gracias por el listado de blogs), mantenerse al día de nuevas técnicas, pair programming, reiterar múltiples veces en el particionado y simplificado del código… Coincidirás conmigo en que estos “hábitos” no son lo que consideramos actividades productivas al uso, y en caso de tenerlos integrados en nuestro día a día será lo primero que sacrificaremos ante una situación de apremio (restauración de BDD, problema grave de seguridad…)
En este extraño sector en el que nos movemos parece que el apremio es una constante invariable por lo que entiendo que la mayoría de profesionales no ejercitamos dichas actividades de forma regular no tanto por desconocimiento sino por priorización (una mala priorización, quizá). Comprendo por lo tanto que es nuestro deber el reservar tiempo para algo que en realidad es una inversión de futuro y presente… y aquí llegamos a lo que es un quebradero de cabeza para mí: encontrar la justa medida.
Sé que es algo no extrapolable entre diferentes empresas, proyectos, orientaciones, personas… pero me gustaría tener una referencia de cuánto tiempo como media dedicas como jefe de proyecto a esas tareas diferentes a “Producir y punto” y cuánto entiendes que deberían dedicar tus programadores.”
Abrimos la veda, a la caza de fallos que nos hagan mejorar en este punto.
Frank Torres
2 Comentario para el post
Iñaki Elcoro
mayo 20th, 2010Veo tres temas diferentes en esta pregunta:
1- Tiempo invertido en autoformación
2- Contexto en el que invertir dicho tiempo
3- Reacción ante situaciones de apremio
Comenzando por el primero punto, podremos invertir tiempo en autoformación una vez hayamos creado una conciencia adecuada en nuestro entorno que nos permita hacerlo. Esto es lo más difícil y es un trabajo arduo y no hay receta mágica para ello. Sin embargo desde mi punto de vista, este puede ser el proceso:
Al principio, puede que debamos sacrificar algo de tiempo personal, pausas en los cafes, algún rato libre, con el fin de autoformarmos. Pero si lo hacemos buscando mejoras aplicables a nuestro contexto actual de trabajo, posteriormente podremos ir demostrando a nuestro entorno que la autoformación es una inversión, la cuál nos ha permitido llegar a la meta establecida, mejor de lo que estaba previsto.
Debemos sacarlo a la luz en cada oportunidad que se nos de, para al final, poder tener argumentos para proponer un tiempo X de nuestra jornada que podamos dedicar a este proceso. Respecto a esto, un planteamiento inicial suele ser no más de una hora semanal, y posiblemente posteriormente, podramos ir aumentado hasta incluso 1 hora diaria.
Vamos con el segundo punto, el contexto, que es también muy importante. En un proyecto que esta mal estimado o que tiene problemas, es muy peligroso tratar de aplicar nuevas técnicas que no se dominan. Tendremos que buscar el proyecto, (contexto) apropiado, como pueden ser proyectos a más largo plazo, o que esten correctamente estimados (aunque esto es más dificil), donde podemos experimentar y probar nuevas técnicas. Una vez probadas y asimiladas aquellas técnicas que funcionan, podremos aplicarlas en proyectos mas apretados, ya que descubriremos que en la práctica somos más productivos utilizandolas.
Todo esto esta muy bien, pero que pasa cuando ocurre un problema grave y debemos solucionarlo inmediatamente? Puede y es probable que todas estas buenas prácticas nos retrasen. Sin embargo no debemos perder de vista el plan, que se mencionaba en la charla, ante una situación de apremio: contener-mitigar-solucionar
Para las dos primeras fases del plan, contener y mitigar, nos olvidaremos de todas aquellas prácticas que pueden retrasarnos y trataremos de aplicar la solución inmediata más sencilla y eficaz aplicable en el momento.
Aquí es donde viene el error, no debemos creer que hemos terminado, todavía nos queda solucionar, ya que no querremos arrastrar esta solución de contingencia durante el resto del proyecto, ¿no?.
Una vez mitigado el problema, debemos crear una nueva tarea en nuestra planificación para solucionar de forma definitiva y correcta el problema. Dicha tarea la priorizaremos según la importancia que pueda tener dentro del contexto del desarrollo, es más, es posible que si la solución anterior es suficientemente buena nunca llegue a tener la prioridad suficiente para ejecutarse, aunque bajo mi experiencia pocas veces es así.
Espero haber ayudado.
Frank Torres
mayo 24th, 2010En respuesta a la pregunta de Alejandro, es la dinámica de planificación que llevamos la que nos permite dedicar algo de tiempo a la formación, al pair-programming y ese grupo de tareas no directamente relacionadas con la producción.
Nunca planificamos los sprints al 100%, sino que solemos dejarlos a un 85%, aunque la capacidad de trabajo de las personas sea el 100%. Eso nos permite, dada la falta de equipos de testeo, como tienen otras empresas, probar las tareas antes de pasarlas a completed, dedicar tiempo de otro programador para hacer pair-programming cuando hay un atasco en la programación de algún componente o necesitamos mejorar el rendimiento, o, en el mejor de los casos, terminar antes el sprint y tener algo de tiempo para mirar las novedades tecnológicas de programación o las tendencias del mercado.
La auto-formación tenemos dos formas de realizarla: algunas veces son las propias personas las que proponen qué es lo que se quieren mirar, otras veces somos nosotros los que proponemos qué mirar, dando pistas de para qué podríamos utilizarlo en el futuro para motivar.
Otras veces – la mayoría – la empresa planifica cursos de formación interna, que encajamos entre sprint y sprint o en medio de un sprint cuando no hay más remedio. Si tenemos que encajarlo en medio de algún sprint, siempre nos apoyaremos en ese pequeño margen de tiempo que no hemos planificado al 100% y en un pequeño sobre-esfuerzo que aplicamos al retomar el sprint para realizar las entregas a tiempo.
Hemos comprobado que las planificaciones al 100% de la carga nunca se cumplen, porque está ese grupo de tareas no directamente productivas que pueden surgir en cualquier momento, pero que son necesarias porque, aunque no están relacionadas directamente con la productividad, hacen que la productividad aumente y ese 85% sea aprovechado al máximo, generando código con menos errores, componentes reutilizables y soluciones efectivas y seguras.
Luego las decisiones de cómo interrumpir nuestros sprints, si merece la pena o no y por cuánto tiempo, es importante. Es lo que comenta Iñaki en el post anterior (contener-mitigar-solucionar). Otras veces que hay que ignorar. Son decisiones que vienen de haber visto muchos casos y ver qué consecuencias tiene tomar una decisión u otra.
A todo esto, como mismo comentamos en la charla, hemos llegado en base a nuestra experiencia. Los cursos y la documentación de metodologías ayudan mucho, pero probar una y otra vez es lo que hace que determinada metodología encaje en la estructura de nuestra empresa. Lo que vale para una, rara vez vale para otra. Probar, corregir fallos y volver a intentarlo es lo que hace que las técnicas de planificación y seguimiento sean eficaces.
Enviar comentarios