Sin embargo, podemos realizar pequeños pasos para introducirnos en ágil y asomarnos levemente a ver más o menos de que se trata.
Una forma de asomarse al agilismo puede llegar a ser éste desafío que lo tomé prestado de ésta web chilena y permite que los conservadores y cautelosos puedan experimentar sin “dañar nada de su sistema”, similar a un liveCD :) como se calcula la velocidad de un equipo de desarrollo usando Kanban o mejor dicho algo de Kanban.
1. Listar en post-its las tareas de cada uno para las próximas dos semanas
2. Escribir en cada post-it el tiempo que demoraría en hacerse en condiciones óptimas (sin interrupciones)
3. Frente al escritorio de trabajo, crear un panel (que llamaremos Panel Kanban) con 3 columnas: Ítemes que no han partido, ítemes comenzados e Ítemes finalizados
4. En las dos semanas, mover los post-its de una columna a otra a medida que se progresa
5. Al final de las 2 semanas, sumar los numeros de aquellas tareas que estén en la columna “finalizados”
Al dividir la suma de horas “ideales” logradas sobre el total de horas de trabajo de las 2 semanas, habrán medido su velocidad. Ahora tienen una medida de cuanto son capaces de realizar cada 2 semanas, y por ende tienen una guía cerca de cuanto pueden comprometerse para la próxima.
¿Que les parece esta experiencia?
Nosotros aca utilizamos las meeting de mejora continua, que en realidad son meetings donde cuento que es lo que estoy haciendo, que trabas tengo y como pienso resolver las cosas...
ResponderEliminarParticularmente, la idea de los post-it me parece medio choto por tener que escribir un papel (digo siendo informaticos, podriamos hacer algo mejor) pero debe tener su sentido psicologico.
Pienso que hay poca gente experimentada en el ambiente de software como para tener la suficiente experiencia para decidir que poner/sacar en un proceso de desarrollo de software para hacerlo a la medida de los integrantes del equipo y conforme a las directivas de la empresa.
Creo que no existe "La Metodologia" sino las buenas practicas que hacen a un buen producto.
Saludos y buen post
Hola Papa Soler, gracias por comentar.
ResponderEliminarEfectivamente existen multitud de versiones de software que emulan paneles kanban al igual que sucede con los seguimientos de historias de usuario de Scrum. De todas formas se recomienda el panel o pizarra fisica con post-it porque exige una participación más comprometida con el progreso de las tares, items, funcionalidades, historias de usuario, o como les guste llamar. Además permite que cualquier persona que pase por delante de la pizarra curiosee y esté al tanto del proyecto, más alla que la persona no pertenesca al equipo. En los campos de Scrum, donde existe muchos equipos ésto se convierta en una gran ventaja. Existen otras tantas más que son recomendaciones, pero nosotros podemos flexibizarnos y adaptar en la medida que nos convenga, de ésto tambien se trata la agilidad.
Me parece un buen experimento, como dice Soler, nosotros tenemos meetings de mejora para saber en que estamos, pero no nos permite medir la velocidad con que trabajamos. Lo de los post-it es una buena idea porque siempre es conviente que todos los miembros del equipo sepan donde esta parado cada uno (usando una tool muchas veces se olvida de chequearla, je). De cualquier manera pienso que un experimento de dos semanas es un poco corto como para sacar metricas confiables y tomar decisiones basados en ellas.
ResponderEliminarHola elmassi, gracias por comentar.
ResponderEliminarLas prácticas de reuniones diarias son muy útiles para todo el equipo, tal cual como comentas para saber en que andan...La parte díficil es no irse de tiempo. Algunos equipos Scrum llevan cronometros para no pasarse de 10 minutos o 15, segun como lo fijen.
Lo de iterar cada 2 semanas es una recomendación basada años de experiencia. De todas formas es sólo eso, en algunos casos no es un tiempo adecuado. Hay equipos de Scrum que planifican iteraciones de 4 semanas o más. Cuando se adquiere cierta velocidad y se cuenta con mucha gente con un alto seniority algunas empresas hacen iteraciones cortas, hasta de un día. Obviamente para llegar a ésto hay que tener la maquinaria super aceitada, con el server de integración continua a full. De todas formas, entiendo lo que dices y estás completamente en lo cierto, una sola iteración sólo arroja ideas de velocidad, mientras más iteraciones tengamos encima del proyecto la velocidad se va ajustando más a la realidad. Luego con las restrospectivas como herramienta podemos conseguir aceleración para ir más rapido, pero eso ya es otro tema. :)
Buen post. Quiza la idea de la pizarra física además de que cualquiera la puede curiosear, ayuda a que entre todos, incluso los no afectados a la tarea puedan aportar una idea o sugerencia para ayudar a los integrantes del equipo que presenta demoras.
ResponderEliminarHola Orkus, gracias por comentar.
ResponderEliminarExactamente! lo que has dicho es uno de los motivos principales de los paneles Kanban o pilas de sprint implementados en una pizarra física. Tiene otras ventajas cuando se realiza la reunión diaria de scrum, si contamos con la pizarra en la sala, el equipo entero puede discutir las tareas participando y moviendo post-its. Por ejemplo si, un miembro termino con una tarea puede decidir tomar la proxima el, quitandola de la columna TODO. En fin, son pequeñas recomendaciones útiles. Pero tengan en cuenta ésto: En gran medida, no debemos adaptar nuestra empresa a Agil, si no que debemos adaptar agil a nuestra empresa. Ésto es, si no contamos con suficientes desarrolladores senior que conozcan suficiente de TDD (Una tecnica de programación de XP) no la implementemos a la fuerza, porque los resultados van a ser más negativos que positivos.
Para la próxima escribiré un artículo de las prácticas agiles que pueden ir implementandose progresivamente en distintas áreas en un entorno con poca preparación.