Ajedrez - antoniomartel.com

Archivos por Etiqueta: Agile

Trello, la gráfica burndown y Google Calendar

Probablemente sea siempre mejor un tablero físico, en una pizarra o pared de corcho, que un tablero Kanban virtual en la pantalla de nuestro ordenador pero es indudable que llevar este seguimiento en nuestro PC o portátil también tiene sus ventajas: mantener estadísticas automatizadas, guardar el historial de nuestro progreso y los cambios que hemos hecho almacenando los datos en la nube para que nosotros o nuestro cliente podamos ver el estado del proyecto desde su casa u oficina.

Hay muchos de estos tableros virtuales como KanbanFlow, Rally, Jira + Greenhopper o Pomodoro Daisuki, con más o menos ventajas o más o menos costosas pero hoy quería comentar sólo sobre una en partícular: Trello, del conocido blogger Joel Spolsky, un aplicación web gratuita para llevar los tableros Kanban de nuestros proyectos.

Utilizo Trello con cierta frecuencia por un par de proyectos, uno profesional y otro personal para el aprendizaje de idiomas. Permite llevar adelante cualquier tipo de proyecto, no sirve sólo para proyectos de desarrollo de software. Al crear un nuevo tablero aparecerán las tres columnas habituales (To Do, Doing y Done) pero aquí son tratadas como simples listas y a las que puedes cambiarle el nombre a lo que mejor se ajuste a tu proyecto, por ejemplo: Pendiente, En desarrollo, Revisado, Pre-explotación y Producción.
Una vez creadas las listas para tu proyecto comenzarás a crear las tareas que van en ellas priorizándolas o cambiándola de columna con solo mover una encima de la otra o arrastrándolas a las columnas de al lado. También puedes invitar a otros usuarios de Gmail a formar parte del proyecto y asignarles tareas directamente. Estos usuarios serán notificados por email cada vez que alguien escriba un comentario a la tarea o la cambie de estado. Hay más funcionalidades interesantes para las tarjetas con tareas: añadir comentarios, imágenes o archivos adjuntos para cada tarea, mantener una checklist de comprobaciones con cada una de ellas o etiquetarlas individualmente con un color y nombre diferente por tipo de tarea. 
Puedes incluso ponerles una fecha de finalización a cada tarjeta colocada en el tablero, cambiando de color según se acerca la fatídica fecha. También, si activas la extensión para el calendario de Google, todas estas fechas aparecerán automáticamente en tu agenda para que las tengas siempre presentes (para activar esta función en tu calendario de Google echa un ojo a esta página de ayuda de Trello)
Pero lo que más me atrajo de Trello (además de ser gratuito) no son solo sus propias funcionalidades sino la posibilidad de mantener una gráfica burndown de forma automática con una aplicación externa: Burndown for Trello. Se trata de una web que, conectándose a la API proporcionada por Trello obtiene todos los datos y estadísticas de este tablero a medida que mueves las tarjetas de columna calculándote automáticamente esta gráfica:
y estas estadísticas:
Se muestran el total de tarjetas, cuantas quedan por hacer, qué porcentaje del total se ha hecho, cuantas horas estimadas quedan de trabajo por delante, en cuantos días se calcula que se hará todo el trabajo y en qué fecha, también estimada, estará completado el trabajo si seguimos avanzando a este ritmo ¡Espero que te sea útil!

Si te ha gustado este post, puedes encontrar más contenidos que expliquen Scrum de forma práctica y desde su base en mi libro en Amazon Curso práctico de Scrum: Algo más que teoría.

Libro en Amazon: Curso práctico de Scrum: Algo más que teoría
Libro en Amazon: Curso práctico de Scrum – Algo mas que teoría

Estadísticas de uso de Scrum (2014)

Hace algo más de un año, en abril de 2013, publicaba una serie de gráficas y estadísticas sobre el uso de Scrum en los portales de empleo y sus búsquedas en Internet en general. Para hacerlo comencé por la demanda de profesionales que pudieran tener metodologías o técnicas como Scrum, Kanban o TDD. Contabilicé en primer lugar el número de veces que aparecían términos como estos en portales de empleo españoles, británicos y alemanes. Estos fueron los resultados que obtuve en 2013:

Comparativa 2013 de portales de empleo para Scrum, Agile, Kanban, Lean, TDD o PMP

He vuelto a buscar este año las palabras Scrum, Agile, Kanban, Lean, TDD, PMP, RUP y Waterfall en los portales de empleo Infojobs.net de España, Monster.co.uk del Reino Unido y el Monster.de de Alemania obteniendo los siguientes porcentajes de variación:

Comparativa 2014 de portales de empleo para Scrum, Agile, Kanban, Lean, TDD o PMP

Los términos ‘ágiles’ como Scrum, Agile, Kanban o TDD tienen una importante subida entre los anuncios de demanda de empleo de los tres países. Habría que destacar que mientras que en España la demanda de empleos que requieren de conocimientos en Scrum sube un 35%, en el Reino Unido sólo sube un 8% pero en Alemania baja incluso un 20%. Esto quizás se deba a que son mercados más maduros en los que términos como Scrum y Kanban están siendo sustituidos por otros más genéricos como Agile, que sube un 170% en Alemania mientras que Kanban baja un 19% en Inglaterra y un 9% en Alemania.

He buscado también el uso de estas palabras en todo Internet con la ayuda de Google Trends. Aquí tienen la gráfica de las búsquedas realizadas en Google por ciudadanos de todo el mundo para los términos ‘scrum -espn -rugby’ (para eliminar los resultados del deporte), ‘pmp’ y ‘agile’. Esta es la gráfica:

Incluyo también la gráfica en la que se muestra de qué países provienen las visitas del término Scrum. Es asombroso comprobar cómo una gran parte de las búsquedas proceden de los países del norte de Europa y de otros importantes países en la producción de software como la India o Argentina.

Si te ha gustado este post, puedes encontrar más contenidos que expliquen Scrum de forma práctica y desde su base en mi libro en Amazon Curso práctico de Scrum: Algo más que teoría.

Libro en Amazon: Curso práctico de Scrum: Algo más que teoría
Libro en Amazon: Curso práctico de Scrum – Algo mas que teoría

Libro Gestión práctica de proyectos con Scrum

Estoy terminando de escribir un libro sobre la gestión ágil de proyectos software usando Scrum. Se trata de un ebook en el que trato de explicar, de la forma más amena que me ha sido posible, la gestión de proyectos desde un punto de vista práctico evitando toda teoría y terminología que pudiera sonar rara a un novato que se acerca por primera vez a Scrum.

Dentro de un par de semanas lo publicaré en Amazon. Espero que les sea de interés. De momento les dejo un adelanto del contenido (clic en la imagen para ver el Prezi)

Libro Gestión práctica de proyectos con Scrum

Scrumdamentalismo

Scrum y técnicas ágiles
llevan solo unos años siendo populares en España y ya se está hablando de Post-Agile o lo que vendrá después de la
moda de las técnicas ágiles ¡Si no hemos tenido tiempo de aprender Scrum y ya
lo están reemplazando! En realidad el
movimiento Post-Agile no pretende ser algo que sustituya a Scrum a Kanban o a
otras técnicas llamadas ‘ágiles’ sino que más bien intentan que no se pierda la filosofía que hay detrás.
He visto a muchos
profesionales preocupados por seguir todas y cada una de las reglas que se
definen en Scrum, usando pomposos nombres para sus reuniones y un montón de
tarjetas de colores para todo tipo de tareas posibles. Dicen cosas como ‘¿Qué no actualizas la gráfica burndown a diario?
Entonces tú no estás haciendo Scrum’
, ‘¿No
mantienes una Reunión de Retrospectiva después de cada demo? Eso no es Scrum’.

En algunos casos es
una especie de fundamentalismo del Scrum que afecta a los profesionales TI y
que a veces nos lleva a convertirnos en pequeños talibanes de nuestro lenguaje
de programación favorito o de la metodología que esté de moda en ese momento. En otros
casos es algo así con una enfermedad, Scrumbutphobia, como la denomina Henrik
Kniberg, conocida también como Scrumdamentalismo, y que se define como el miedo
a seguir mal Scrum.
Hay un concepto
divertido, que proviene de las artes marciales, en las que a las fases del
aprendizaje se las llama Shu Ha Ri. Este concepto explica que cuando se está
aprendiendo un arte marcial, y esto puede aplicarse a muchos otros campos, se
pasa por estas tres etapas. La primera, Shu,
en la que los aprendices sólo se siguen las reglas que les han enseñado. La
segunda, Ha, en la que aprenden a
adaptarlas para que les funcione mejor en sus condiciones particulares. La
última, Ri, cuando ya se conocen y
dominan las técnicas simplemente se ‘ignoran’
las reglas. Uno de los síntomas de los que padecen, o hemos padecido, la fobia
a hacer mal el Scrum, es la de estar atascados en Shu, la primera fase del aprendizaje.
«¡Que le den a las reglas! Las reglas son buenas al inicio, luego rómpelas cuando lo necesites»
Si tu meta es
entregar productos de calidad que sean verdaderamente útiles al cliente y no
tener que acudir continuamente al contrato a verificar si estás obligado a
hacer esa tarea. Si te olvidas un poco de porcentajes, de complejos procesos y de tanta herramienta para centrarte en
si estás mostrando periódicamente demos que funcionan (con algún error que otro) en lugar de powerpoints y barras de progreso, entonces creo que vas por buen
camino. No te preocupes si no cumples todas y cada una de las reglas de Scrum.

Asfaltar el camino

Quizás porque los proyectos en los que trabajo actualmente no son muy grandes o quizás por simple deformación profesional pero veo que mi trabajo es cada vez menos parecido al de un jefe de proyecto tradicional y más cercano al de un facilitador del trabajo.

Por supuesto que sigo teniendo responsabilidades en el control del coste económico y en la gestión del equipo pero no entiendo esto como la parte más importante de mi trabajo. Suena polémico pero intento explicarme.

En un rol de gestor de proyectos tradicional el jefe de proyecto debía redactar las especificaciones del proyecto, calcular el costo, gestionar el equipo de trabajo, asignarle las tareas y hacer un seguimiento de cada tarea asignada. El equipo de trabajo trabaja para el jefe de proyecto que velará porque se estén cumpliendo los objetivos dentro del coste presupuestado.

En mi caso, en cambio, el 70% de mi trabajo se resume en reunirme cada día durante 15 minutos con los distintos equipos de trabajo para preguntarles qué hicieron ayer, qué se va a hacer hoy y si tienen algún problema que no les permita avanzar. Me anoto en esas reuniones qué tengo que hacer yo para solucionarlo y me paso el resto del día intentando dar una solución a esos problemas (pidiendo información al cliente, revisando una entrega o reclamando una copia de la base de datos)

Como verán, mi trabajo trata de facilitar las cosas al equipo de trabajo asfaltando el camino para que pueda ir más rápido. Trato de conseguir que puedan hacer cada tarea en el menor tiempo posible en lugar de sólo asignar la tarea y medir si el tiempo empleado es mayor del estimado.

Como he mencionado en alguna ocasión, si nos contratan para llevar una carga del punto A al punto B de poco nos servirá saber cuántos pasos hemos dado ya con la carga. ¿No sería más útil ver si estamos en el camino más corto hacia B o en el que menos dificultades hay?

Suscríbete