Autor: diego

¿Cómo elegir una herramienta de gestión de backlog?

  por ,

En este artículo se expone un opción práctica de selección de backlog basada en dos criterios: facilidad de uso y cantidad de información que aportan al proyecto durante la ejecución y después de la misma.

He escogido estos dos criterios, aunque soy consciente que pueden haber muchos otros como el coste, tamaño del equipo, ubicación de las personas, nivel de madurez del equipo u otras.

Gestión de Backlog en Agile

En las metodologías o frameworks ágiles como Scrum no se especifica cómo gestionar un backlog de producto o qué herramienta utilizar. Este aspecto queda a libre elección del equipo que debe elegir cual es la que mejor se adapta a sus necesidades y la que mayor aporta a la mejora de la calidad del producto.

Existen muchas alternativas para gestionar un backlog de producto, por ejemplo usando post-it en tableros físicos, herramientas Kanban como KanbanFlow o Trello o herramientas más complejas como Jira o Redmine. Cada una de ellas tienen un conjunto de ventajas con respecto a las otras desde el punto de vista de los criterios elegidos.

En este artículo nos enfocaremos en estos tres tipos: Post-it con tableros físicos, herramientas software tipo Kanban y herramientas de gestión de desarrollo de software con soporte para Scrum o Kanban.

Gestionar un backlog con post-it

Gestionar un backlog con post-it es muy fácil, totalmente ágil y versátil, se requiere una inversión muy pequeña y requiere poco mantenimiento.

Gestión de backlog con Post-It

Un tablero físico lleno de post-its aunque es fácil de usar, no permite hacer un seguimiento adecuado del histórico del proyecto y la documentación o conocimiento que se puede extraer es muy poca.

En mi opinión, debería ser usado para proyectos de software pequeños, iniciativas cortas o para coordinar iniciativas a alto nivel.

Gestionar un backlog con herramientas Kanban

Las herramientas tipo Kanban son más potentes y son muy utilizadas para gestionar los backlogs. Existen aplicaciones como Trello o KanbanFlow que ofrecen versiones gratuitas que pueden ser suficientes para gestionar un backlog y además ofrecen versiones de pago con funciones avanzadas.

Tablero Kanban

Estas herramientas son bastante fáciles de utilizar y son una gran alternativa a los post-it en formato digital y desde el punto de vista de documentación permiten añadir muchísima más información como descripciones, comentarios, notas, attachments, etc a los items permitiendo enriquecer la información del proyecto.

Las herramientas de Kanban en mi opinión dificultan

Desde mi punto de vista, estas herramientas son adecuadas para proyectos medianos, con pocas personas y donde no se requiera un seguimiento importante de documentación o conocimiento generado por un proyecto.

Gestionar el backlog con una herramienta de gestión de proyectos

Herramientas como Jira o Redmine dan soporte para trabajar con un framework como Scrum o Kanban y ofrecen mayores posibilidades a la hora de gestionar los items del backlog.

Gestión de backlog con Jira
Backlog Jira

Estas herramientas tienen una curva de aprendizaje mayor, aunque al estar pensadas para gestión de desarrollo de software permiten añadir a los items una gran cantidad de información (estados, prioridades, tags, versiones, componentes, sprint, seguidores, etc), permiten colaborar entre diferentes participantes y gestionar diferentes ciclos de desarrollo aportando de esta forma mayor información del desarrollo del producto.

¿Qué herramienta de backlog escoger?

En la siguiente imagen se resume la posición de cada tipo de herramienta según los criterios de facilidad e información que puede obtenerse del backlog de producto (items nuevos y realizados)

Esta valoración está basada en mi experiencia desarrollando productos de software con equipos de diferentes tamaños y con proyectos de diferente alcance.

El criterio de facilidad uso se basa la observación de que tan fácil se adapta el equipo a la herramienta y que tan fácil es definir una metodología de uso de la misma.

El criterio de información se basa en la cantidad de datos que se puede añadir a un ítem para enriquecer su información, la capacidad de colaboración durante la ejecución y la capacidad de recuperación de información a futuro.

Desde mi punto de vista, en el desarrollo de producto, los ítems de backlog representan la historia del producto y de su información puede extraerse mucho conocimiento y a la vez servir de documentación.

En el gráfico, se puede observar que desde el punto de vista de facilidad de uso, los post-it son los más sencillos de utilizar comparado con herramientas de gestión como Jira o RedMine.

Desde el punto de vista de cantidad y calidad de información que se puede añadir y aportar en un ítem de producto se ve como un post-it por su propia característica ofrece poca capacidad de manipular información y sobre todo persistencia, en cambio, herramientas como Jira o Redmine permiten tener ítems de backlog más enriquecidos.

Las herramientas de Kanban están en un punto medio en ambos criterios.

Mi recomendación:

  • Para gestionar tareas personales: Usar una herramienta software kanban
  • Para gestionar iniciativas a alto nivel: Usar una herramienta software kanban
  • Para gestionar proyectos de desarrollo de software pequeños (un mes o dos): Usar Kanban.
  • Para productos de software de largo recorrido: Usar Jira, Redmine o similares

Como veis, no recomiendo los post-it en general para gestionar proyectos de desarrollo de software y sé que los defensores de Agile no estarán de acuerdo conmigo. O por el contrario, puedo decir, usad post-it, si no os importa que se pierdan y la información que contengan no sea valiosa en el futuro del proyecto o para sacar indicadores.

Gestiona de tareas de backlog de producto

  por , ,

En prácticamente todos los sitios en los que he estado he encontrado un denominador común en la gestión de tareas de desarrollo a través de los sistemas de gestión como Jira, Redmine o cualquier otro. Este denominador es una falta de detalle en la gestión de las tareas al margen del framework o metodología de trabajo que utilicen ya sea Scrum, Kanban, o una muy particular..

Me voy a referir a la gestión de tareas en términos generales, aunque en el framework como Scrum estas puedan ser una historia de usuario, una épica, una Tarea, una Incidencia o una tarea Técnica y en otros equipos puedan ser una nueva funcionalidad, mejora, un Error, etc.

En este post quiero comentar algunos de los motivos que he escuchado de porqué no se gestionan correctamente las tareas y os comparto algunas de las razones por las que creo que es importante hacerlo correctamente.

¿A qué me refiero con una falta de detalle en la gestión de tareas? He aquí algunos puntos que suelo ver en una tarea mal gestionada.

  • Asignación incorrecta de tipología (historia, épica, tarea, incidencia)
  • Estados incorrectos de estado.
  • Falta o asignación incorrecta de propietarios.
  • Asignación incorrecta de prioridad.
  • Ausencia total de comentarios
  • Ausencia de criterios de aceptación.
  • Ausencia de imputación de tiempo.

Motivos por los que no se gestionan bien las tareas

Cuando he preguntado a los líderes de IT o a los desarrolladores, encuentro respuestas como las siguientes:

  • No tengo tiempo.
  • No hay procedimientos definidos.
  • No es necesario.
  • Es una pérdida de tiempo
  • No sé cómo hacerlo mejor.

No hay tiempo

Es la excusa más generalizada. Estamos perdidos en el día a día y se considera que no hay hueco para documentar una tarea. Muchos desarrolladores se limitan a cerrar la tarea sin más, si es que llegan a hacerlo, sin añadir un comentario, información de pruebas, etc.

No hay procedimientos definidos

En muchos equipos no se ha creado una cultura de gestión de tareas y es normal que los miembros del equipo no lo hagan por iniciativa propia. A veces se cree que una herramienta lo soluciona todo y no es así. Una herramienta requiere además de su funcionalidad, unas reglas de uso para poder sacar el mejor partido de la misma.

No es necesario.

Muchos desarrolladores ven las gestión de tareas como algo sin sustancia, creen que solo tienen que hacer una acción, ejecutarla y cerrarla sin llegar. El título y la descripción ya lo dicen todo y si está cerrada es porque se ha hecho, ese suele ser su planteamiento.

Es una pérdida de tiempo 

Algunas personas ven el proceso de gestionar las tareas tedioso y una pérdida de tiempo total. Lo ven como algo burocrático y que no merece la pena. Sienten que necesitan dedicar el tiempo a programar, más que a documentar una tarea.

No sé cómo hacerlo mejor

Esta es otra respuesta típica. Todos sabemos que es una tarea y posiblemente hasta sabemos como escribir una historia (El titulo) y su descripción, pero poco sabemos sobre los procesos de gestión de tareas de desarrollo de software y los posibles ciclos de vida.

¿Qué gano cuando una tarea está bien documentada?

Para mi la buena gestión de tareas de desarrollo está alineado con el grado de madurez del equipo y con los procesos de mejora continua. Algunos de mis pensamientos en esta línea son.

Las tareas bien documentadas son una fuente rica de información para el presente y para el futuro

Diego Acosta

Una tarea bien documentada es una herramienta de comunicación excelente entre los peticionarios y los ejecutores.

Diego Acosta

La buena gestión de una tarea nos ayuda a documentar la historia de un producto

Diego Acosta

A continuación listo parte de la información que nos podría brindar una tarea cuando la vemos en el sprint backlog cuando la documentamos bien.

  • Conocer quién o quienes han ejecutado
  • Conocer qué prioridad tiene o tenía cuando se ejecutó.
  • Conocer el objeto o propósito de la tarea de forma clara
  • Conocer el origen, la motivación o el contexto dentro del cual fue solicitada
  • Saber qué decisiones se han tomado sobre la misma durante el proceso de desarrollo
  • Conocer el alcance y cumplimiento
  • Conocer cuales son los criterios de aceptación y sus variaciones si las hubiera.
  • Saber si hubo algún problema y su resolución 
  • Saber si se hubo un cambio el alcance
  • Saber si hay alguna tarea relacionada con mas información 
  • Conocer si forma parte de una tarea más grande
  • Saber si está bloqueada y porqué está bloqueada.
  • etc.

Una tarea bien documentada aporta conocimiento durante el desarrollo y a futuro. Es una inversión para cualquier desarrollo que tenga previsto un roadmap relevante o que forme parte de un producto.

En la gestión de incidencias y problemas es una fuente de información donde puedes encontrar que se ha hecho para solucionarlo, el análisis del problema y todos las posibles soluciones planteadas y cuáles de ellas funcionaron o no. 

Por otro lado, tener un sistema de gestión de tareas bien organizado y trabajado es fuente de indicadores de gestión que pueden ayudar a la mejora continua mediante la medición de ciertos indicadores.

Por ejemplo

  • Número de historias que aportan valor se han terminado
  • Número de incidencias reportadas
  • Tiempo efectivo de desarrollo
  • Número de tareas bloqueadas.
  • Tiempo medio de resolución
  • etc.

Conclusión

Desde mi punto de vista, gestionar una tarea es una labor en la que todos los miembros del equipo deben estar involucrados, desde el Product Owner, Scrum Master y desarrolladores y debe verse como un proceso estandarizado dentro del equipo que debe incorporase mediante ciclos de mejora continua.

Si mejoráis la gestión de las tareas vais a notar un cambio en vuestro día a día y os ayudará a sacar un mejor producto.

Que el teletrabajo no te agobie

  por

En estos días de teletrabajo es importante saber adaptarse a nivel personal y de equipo para evitar agobiarnos. Han pasado casi dos meses desde que estamos en cuarentena y para los que hemos sido afortunados y hemos podido realizar nuestro trabajo desde casa el teletrabajo forma parte de nuestra rutina y por ello es importante saber entenderlo y hacerlo de la mejor manera.

Durante estos días y conversando con algunos colegas de diferentes áreas he llegado a la conclusión de que muchos nos planteamos una cosa en común.

Las jornadas de teletrabajo nos están siendo más intensas y en general más largas

Analizando un poco como transcurre el día a día voy a resaltar algunos aspectos que a mi modo de ver nos hacen sentir que estamos trabajando mucho más. Estos posiblemente pueden encajar principalmente con roles de gestión y de participación activa en definición de proyectos, gestión de equipos, definición de producto, etc. Los puntos más relevantes que quiero resaltar son:

  • Demasiadas reuniones: Cuando el objeto principal de tu trabajo es la organización de equipos y proyectos el calendario está en general a tope de sesiones y hay muy poco tiempo entre una y otra.
  • Pérdida de límites de entrada y salida: Al estar siempre en tu “sitio”, la jornada se puede hacer más larga, entrando más temprano o saliendo más tarde.
  • Sensación de disponibilidad inmediata: Al recibir un mensaje y estar en la rutina de trabajar en casa a veces se mezcla el espacio familiar y el laboral y sentimos que responder cuanto antes es una necesidad. Igualmente, parece que el estar online quiere decir, respuesta inmediata y no es así.

Estos aspectos mencionados pueden generar efectos en tu mente y tu cuerpo que hay que controlar como por ejemplo:

  • Ansiedad: Este probablemente es el más perjudicial. Esa sensación de se me ha ido el día y no he avanzado puede llevarnos a irritación, a trabajar más horas o a estresarnos.
  • Cansancio mental: No parar para organizarnos, reenfocar o simplemente cambiar de actividad puede llevarnos a tener fatiga mental y con ello pérdida de foco y desconcentración.
  • Dolores e irritación de garganta: En este nuevo modelo donde muchas cosas se resuelven vía conferencia y donde prácticamente no hay descanso entre una y otra es normal que la garganta se recienta y más cuando no se tienen buenos hábitos de control vocal.
  • Cansancio muscular: El estar sentado o “quieto” dependiendo del espacio de trabajo hace que el cuerpo se entumezca, máxime si no hay mucho tiempo entre una reunión y la siguiente.

Para evitar que el teletrabajo nos agobie, nos consuma nuestro día y nuestra vida reseño algunos puntos importantes que deberían ser tenidos en cuenta por cada persona del equipo. Desde mi punto de vista, todos tenemos que implicarnos para hacernos los días más llevaderos.

  • Agenda tus espacios de trabajo individual cada día: Una agenda vacía parece que se interpreta como disponibilidad inmediata para una reunión de última hora. Para evitar esto, y sobretodo para poder organizar y sacar tu trabajo, reserva al menos una hora de trabajo individual y hazlo respetar.
  • Respeta las agendas casi llenas: En algunas ocasiones he visto ocupar la única media hora libre de mi agenda para una reunión. Creo que es una falta de respeto ocupar el único espacio libre de una persona que ya tiene su agenda llena. En un escenario, para mi ideal, una persona no debería estar con reuniones más allá de un 60% o 70% del día. En caso de ser inevitable, tener la amabilidad de hablar con la persona sería lo mínimo.
  • Respetar las horas ocupadas: cuando sepas que alguno de tus compañeros se reserva horas para trabajo individual, respeta esos espacios u otros que veas ocupados en el calendario. En caso de ser inevitable, al menos ten la delicadeza de avisar a tu compañero (a) de la situación.
  • Si no te contestan inmediatamente, no llames salvo que sea urgente: Hay muchos casos en los que alguien escribe en un chat, manda un e-mail y luego te llama a ver si has visto el mensaje del chat. Esto no tiene sentido si no es algo urgente y en todo caso, si es una urgencia el orden debería ser el contrario, llamada, e-mail, chat haciendo explícita la urgencia. El hecho de que estemos en casa no quiere decir que estemos disponibles 100% para la persona que escribe. Somos un equipo y tenemos que trabajar con varias personas al tiempo.
  • Respeta el horario laboral: El respeto por el horario de entrada y salida es principalmente personal, depende de cada uno poner freno a la cantidad de horas que se dedican. Aunque en estos momentos la situación sea complicada, hay que saber cuándo parar y cuando hay que meter el hombro, sin que esto se convierta en una rutina.
  • Usa manos libres o cascos en las conferencias y llamadas: El uso de cascos te permite levantarte y estirar brazos y piernas, si es necesario. Nadie ha establecido un protocolo de reunión en el cual todos tengan que estar sentados al frente del ordenador sin apartarse de él.
  • Termina las reuniones 10 minutos antes de la siguiente: Cuando haces reuniones presenciales, necesariamente debes terminar una para desplazarte a la siguiente y sueles salir 5 o 10 minutos antes, lo que te permite despejarte un poco. Porque no hacerlo en teletrabajo?.
  • Mantén agua a tu lado: El agua ayudará a aclarar tu garganta y a evitar la resequedad. Si prevés una reunión larga donde tengas que intervenir mucho tiempo, lo mejor es que te aprovisiones de agua para tomar durante la misma.
  • Cambia de espacio durante el día: Hoy en día es muy normal tener un ordenador portátil para trabajar. Aprovecha que lo tienes para cambiar durante el día, si te es posible, el espacio donde trabajas, al menos durante algún rato. Esto ayudará a despejar la mente. Igualmente, puedes, durante un espacio de tiempo usar el móvil o una tablet para responder e-mails desde la comodidad de un sofá o similar, esto dará descanso a tu mente.
  • No pierdas el contacto con tus colegas: El teletrabajo te aísla físicamente de las personas y te limita a un espacio reducido, si a esto le sumas el confinamiento puedes llegar a sentirte demasiado aislado. Saca algunos momentos para hablar con la gente en espacios que no sean una reunión de trabajo, como lo podrías haber hecho en la oficina, tomando un café o mientras vas por un pasillo. Somos personas y necesitamos de las relaciones sociales.
  • Has ejercicio al terminar tu jornada: Aunque esto es algo que deberíamos hacer siempre, en la situación que estamos actualmente, es mucho más importante estirar el cuerpo y relajar la mente. Saca al menos 30 minutos al día para hacer alguna actividad física.

Poco a poco nuestro día a día en teletrabajo debe adaptarse para encontrar un buen balance entre la ejecución de nuestra responsabilidad laboral y nuestra vida personal donde nos encontremos a gusto en esos dos escenarios. Si ponemos en práctica algunos de estos puntos seguro vamos a pasarlo mucho mejor.

Scrum con Jira – Relación entre Épicas, Historias y Tareas Técnicas.

  por ,

Como se comentó en un post anterior, Jira permite trabajar con Épicas, Historias y Tareas en el backlog. En este post se explicará la relación entre las mismas. Para entenderlo mejor, he elaborado el siguiente gráfico.

scrum-épicas-historias-tareas-tecnicas

Épicas, Historias y Tareas Técnicas

Como puede verse, una Épica puede ser descompuesta en múltiples Historias de usuario y a su vez, estas historias de usuario se descomponen en tareas técnicas.

Épica

Una Épica puede ser vista como una historia de usuario de alta complejidad (petición de negocio de alto nivel y complejidad, no clara). Para elaborarla se puede requerir un esfuerzo muy grande y no puede ser cubierta en un Sprint. Una épica debido a su gran tamaño es difícil de estimar y de acometer, así que podemos aplicar aquí el principio “divide y vencerás” y descomponerla en historias. Implementar una épica suele llevar dos o más sprints.

Ejemplos de Épicas.

  • Como usuario quiero poder registrarme y tener una cuenta de usuario para poder acceder a mi información de usuario y de los servicios que uso.
  • Como usuario quiero un servicio de “lista de deseos” para poder guardar los artículos que me gustan.

Historia de Usuario

Una historia de usuario representa una necesidad de negocio que puede ser implementada en un sprint y aporta valor al producto. Al final del Sprint la historia añade una nueva funcionalidad o característica al producto y puede ser candidata para pasar a producción.

En el backlog pueden haber historias de usuario sueltas o historias de usuario asociadas a épicas, ambas deben poderse terminar en un sprint, si no pueden terminarse en un sprint, deben ser descompuestas en historias de usuario más pequeñas.

Un patrón típico de definición de historias de usuario es el siguiente (1).

“Como [un] [tipo de usuario] [quiero, puedo, necesito, etc] para  [alguna razón].”

La redacción de la historia en esta forma permite identificar rápidamente para “quien” es esa funcionalidad y cual es el objetivo que se persigue o que gana ese usuario. Es un formato que facilita la comunicación del equipo entero y es fácil de entender por negocio.

Ejemplos

  • Como [Usuario Anónimo] quiero [poder registrarme en el portal] para [crear una cuenta.]
  • Como [Usuario Registrado] quiero [poder iniciar sesión en el portal] para [poder acceder a la información de mis servicios contratados]

No hay una barita mágica ni para redactar historias de usuario, ni para partir épicas en historias de usuario, ni para identificar épicas. Con el tiempo se va ganando destreza identificando épicas, dividiendo épicas en historias y redactando las historias.

Tareas Técnicas

Las tareas técnicas son la  descomposición de una historia de usuarios en tareas más manejables que  deben ser implementadas para poder implementar la historia durante el sprint. Lo normal es que durante la reunión de sprint planning se hayan identificado estas tareas técnicas. Las tareas técnicas deben ser generadas por el equipo de desarrollo.

Partir una historia en tareas técnicas ayuda a dimensionar mejor el esfuerzo de la historia en puntos.

Aunque no es obligatorio dividir una historia de usuario en tareas técnicas en Jira, puede ser una buena práctica si se quiere llevar un mejor control del desarrollo de la historia o si para implementar una historia se requiere la intervención de varios miembros del equipo.

Ejemplo, en la historia

Como [Usuario Anónimo] quiero [poder registrarme en el portal] para [crear una cuenta.]

Podemos identificar las siguientes tareas técnicas.

  • Implementar formulario básico para capturar los datos.
  • Implementar backend para recibir los datos e implementar la lógica de funcionamiento.
  • Maquetar formulario según diseño previsto.
  • Diseñar  plan de pruebas
  • Ejecutar plan de pruebas.

Las tareas técnicas no se redactan como historias al estar orientadas a ejecutar acciones y al igual que en las historias o épicas no hay una fórmula para crearlas y dependerá del equipo, del grado de madurez del mismo, de la historia, y de los participantes.

Una guía que suelo usar es que dependiendo del tamaño de la historia  se debe descomponer en tareas técnicas, esto ayuda no sólo al desarrollador, sino al líder de IT, al Scrum Master y al PO a ver los avances. Otro elemento que nos puede ayudar a detectar las tareas técnicas son los criterios de aceptación.

Cómo se ven las tareas técnicas en Jira?

Las relación entre tareas técnicas y épicas se ve claramente en la vista del sprint activo dentro de una pizarra de Scrum.

Historias y tareas técnicas en Jira

Historias y Tareas Técnicas

Las tareas técnicas se muestran debajo de la historia y se pueden mover a la columna correspondiente dependiendo del estado. Una vez las tareas técnicas están terminadas, Jira sugiere cerrar la historia.

Esta vista puede verse como la representación virtual de la pizarra de scrum física muy utilizada en diferentes equipos y es muy útil para ver el estado del Sprint.

 

Scrum con Jira, De Épicas, Historias y Tareas

  por

Una de las principales labores a realizar cuando gestionamos desarrollos usando Scrum es la gestión del backlog. En este post veremos cómo se usa Jira para este propósito.

Que es un Backlog

Según la definición de scrum.org

Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product (Product Backlog – scrum.org)

Es una lista ordenada de todas las cosas que podría necesitarse en el producto y la única fuente de requerimientos para cualquier cambio a ser realizado al producto

En la práctica un Backlog contiene todo lo que puede o podría ser necesario para desarrollar un producto y además tareas que de una manera u otra impacta al equipo de desarrollo. Aunque el backlog debe ser mantenido y priorizado por el Product Owner (PO), no necesariamente es el único involucrado en la entrada de items, el equipo de desarrollo puede realizar entradas para reflejar necesidades detectadas, incidencias a resolver en otros sprints, etc. El ordenamiento y priorización de los Items es realizado de manera constante por el PO y los elementos superiores del mismo son los candidatos a incluir en el siguiente sprint y deben estar más refinados que el resto.

En el backlog podemos encontrar:

  • Épicas: Peticiones sobre el producto de alta complejidad que suelen ser descompuestas en Historias de usuario. Por ejemplo, el desarrollo de un módulo X con más de una funcionalidad.
  • Historias de Usuario: Petición sobre el producto cuyo desarrollo puede encajarse en un sprint. Si no puede hacerse en un sprint debe descomponerse.
  • Tareas: Tareas asociadas al producto que no necesariamente son historias de usuario, pero que requieren ser realizadas dentro del marco del desarrollo del producto. Por ejemplo, instalación de un software, documentación, despliegues, nuevas instalaciones, etc.
  • Incidencias: Incidencias detectadas en el producto que deben ser priorizadas para su resolución dentro de un ciclo de vida de producto.

TIP: Es importante hacer mantenimiento al backlog cada cierto tiempo debido a que pueden generarse items duplicados, obsoletos por tiempo o por descarte de negocio, tareas no priorizadas adecuadamente, etc.

Vista de Backlog y  Épicas en Jira.

La siguiente imagen muestra un ejemplo de backlog en Jira donde se hace uso de Epicas, historias, tareas e incidencias.

Backlog - Jira, Epicas e historias

Vista de Backlog en Jira

Al entrar en el modo de visualización  “Trabajo Pendiente” se puede ver el sprint activo y el backlog. Seleccionando la opción “Épicas”, podemos desplegar la lista de las mismas, editarlas o ver el resumen de la épica desglosada como se muestra en la figura. Una épica como cualquier tarea en Jira tiene asignado un número.

El modo de visualización de épicas es de gran ayuda a la hora de gestionar el backlog dado que permite crear y editar las historias de las mismas. Al asociar una historia a una épica, se añade una “etiqueta” con el nombre de la épica como puede verse con la historia “unificar librería” y las tareas 5 y 10. En esta vista también podemos asignar versiones a las historias o tareas como puede verse en la tarea “111” que está asignada a la versión 3.4.8.

Se puede observar también tres tipos de items (ver números en la figura)

  1. Historia de usuario.
  2. Tarea
  3. Incidencia

En Jira, se pueden asignar puntos de historia a las Historias de Usuario y a las Tareas.

TIP: Para una mejor organización y visualización de las historias es aconsejable asignar diferentes colores a las épicas

Edición de una épica

Para editar la épica, haga click en el color de la misma, como muestra la siguiente figura. Puede cambiar el nombre (El que se muestra en la columna de épicas), ver la tarea en Jira para documentarla o ver estado de la misma o cerrarla con la opción “Marcar como Listo”

cambiar de nombre a una épica

Opciones de épica

Las épicas deben ser cerradas tan pronto sean implementadas las historias de usuarios o tareas asociadas. Es aconsejable disminuir el número de épicas abiertas y procurar cerrar las que llevan mucho tiempo.

TIP:  Hay que hacer revisión del estado de las épicas y cerrarlas cuando estén completadas.

En mi caso, si  el equipo de desarrollo además lleva incidencias, problemas y evolutivos  he optado por tener dos épicas activas. Aunque no son épicas en si misma, nos ayudan a filtrar de una manera más rápida las tareas en la pizarra de Scrum que si usáramos

  • Mejora Continua: Para tareas, historias o épicas técnicas (no solicitadas por el product owner) que pueden mejorar el producto en si mismo
  • O&M (Operación & Mantenimiento): Para tareas que pueden estar asociadas a problemas, peticiones de servicio y demás.

Cómo clasificar un Item como Épica, Historia y Tarea

Este punto puede ser controversial, yo voy a dar mi opinión de como clasificarlas y en que situaciones. El criterio final dependerá del Scrum Master, el equipo y la forma como se gestione el ciclo de vida producto.

Épica

  • Petición de negocio de alta complejidad que no puede desarrollarse en un sprint del equipo y debe ser descompuesta en historias. (Ejm, un módulo para gestión de usuarios)
  • Petición de servicio de alta complejidad que no puede encajarse en un sprint del equipo y debe ser descompuesta en historias. (Ejm, Instalar, configurar y desplegar un nuevo site con nuestro producto)
  • Necesidad de IT compleja que no puede ser resuelta en un sprint (Ejm. Módulo de monitorización de servicios del producto, Refactorización por cambio de arquitectura).

Historias.

  • Una petición del PO y añade valor al producto.
  • Una necesidad de IT que ha sido “negociada” con el PO y añade valor al producto desde el punto de vista de IT. (Ejm, optimización).
  • Una petición de servicio estandar de mediana complejidad que tiene que ser descompuesta en tareas para su gestión.

Tareas

  • Si es una petición de negocio, que no añade valor al producto y que debe hacer alguien del equipo, pero se debe hacer para otro propósito (Ejm, sacar un informe, analizar comportamientos)
  • Si es una tarea pura de IT que involucra a miembros del equipo y que no añade valor al producto de manera directa. (Ejm. Generar, probar y desplegar una release, generar documentación)
  • Si es una petición de negocio de un tamaño tan pequeño que no puede descomponerse en subtareas o no merece la pena. (Ejm, Cambiar un enlace de un menú).
  • Si es una petición de servicio estandar de corta duración que atiende el equipo. (Ejm, Cambiar la maquetación de unos mails)

Como regla general,  principalmente en las “Historias de Usuario” cuidamos el formato de escritura usando la estructura “Como <cliente> quiero/necesito <algo> para <lograr algo>”, con su respectiva descripción y criterios de aceptación.

Conclusión.

Jira da soporte a la gestión de Épicas, Historias y Tareas en el backlog y en los sprint backlog, de su uso adecuado depende en gran medida la eficacia en la gestión y la organización del equipo.  En un post futuro hablaré sobre la gestión del sprint backlog en Jira.

Scrum con Jira – Primeros pasos

  por ,

Actualizado, 19/11/2017

Scrum es un framework muy usado actualmente por equipos de desarrollo de software que cae dentro de las prácticas Agiles. Scrum introduce varios conceptos que ayudan a organizar la forma de trabajo, roles, artefactos, eventos y reglas.

Scrum define los lineamientos para trabajar pero no define el cómo implantarlo y es en este punto donde comienzan a surgir dudas a la hora de organizar la información. ¿Cómo hacemos  y gestionamos el backlog?, ¿Cómo gestionamos los sprint con nuestra herramienta de gestión de proyectos?, usamos un excel, etc.
En este post y en otros posteriores os voy a compartir mi experiencia de uso de Jira para gestionar proyectos con Scrum, entre ellos, cómo configurar el proyecto, cómo trabajar con los sprint, cómo crear las épicas, etc. Para ello vamos asumir que nuestro proyecto ya tiene un backlog construido y que tenemos proyectados algunos sprint y vamos a iniciar el desarrollo del mismo.

Jira

Jira es una de las herramlogoientas de gestión de proyectos ágiles más usadas por equipos de desarrollo que ofrece todo el soporte para gestionar, planificar, liberar, hacer seguimiento y hacer reporting y ofrece el soporte Agile bajo dos esquemas Scrum y Kanban con su funcionalidad de “Pizarra” o Board , en el caso que nos ocupa trabajaremos con Scrum.

Objetivo del post

El  objetivo  es cubrir la siguiente necesidad.

Tengo un backlog, he hecho la sprint sprint planning y quiero arrancar mi primer sprint”

Los pasos que vamos a tratar en este post son son los siguientes.

  1. Crear una pizarra Scrum
  2. Crear las historias de usuario
  3. Crear el primer sprint.
  4. Asignar las historias de usuario al Sprint.
  5. Activar el sprint

Se asume que usted ya tiene un proyecto creado en Jira

Crear la pizarra Scrum

Para crear la pizarra simplemente vaya al proyecto que quiere gestionar con Scrum y busque la opción “Pizarra” como se muestra en la figura.

Menú Pizarra en Jira

Opción de menú “pizarra” en Jira

Haga clic en la opción “Pizarra”, Aparecerá un menú desplegable, seleccione la opción “Crear Pizarra” y nos mostrará un dialogo donde podemos elegir el tipo de pizarra que queremos. y seleccionaremos la opción “Crear una pizarra de Scrum”.

Crear pizarra Scrum en Jira

Crear pizarra Scrum en Jira

La pizarra puede ser creada de un proyecto existente o de un filtro existente de tareas. Para nuestro caso, seleccionaremos la opción “Pizarra de un proyecto existente”.

Selección de proyecto o filtro

Selección de proyecto o filtro

Posteriormente, seleccione el proyecto y escriba el nombre de la pizarra.

nombre de pizarra y proyecto

Escriba el nombre de la pizarra y seleccione el proyecto

Esto nos crea una vista de pizarra Scrum donde podemos ver en la barra lateral unos íconos de arriba a abajo desde donde apunta la flecha roja que son el backlog, la vista de sprint backlog, los informes, los componentes y las incidencias. Principalmente interactuaremos con los dos primeros.

El Backlog

Menú lateral Jira

Menú lateral Jira

La vista de backlog (Trabajo pendiente)  nos permite ver las historias de usuario del sprint activo, sprints siguientes e interactuar con las tareas del backlog. Esta vista nos permite rápidamente gestionar  la creación y edición de historias de usuario, la asignación de puntos de historia, etc.

TIP!!!:Una cosa importante de cara a gestionar las tareas con Scrum en Jira es que las tareas deben ser creadas del tipo historia de usuario y deben tener previamente asignados los puntos de historia, una vez incorporados a un sprint y activado este ya no es posible cambiar el valor de los puntos de historia.

En la vista de backlog además podemos crear los sprint, organizar las tareas del backlog y asignarlas al sprint (arrastrando las tareas) lo que hace muy sencillo priorizar las historias y armar un sprint backlog. La siguiente imagen nos muestra la vista de trabajo pendiente o backlog.

Una historia puede crearse dentro de un sprint no activo o en el backlog (Create Issue), o crearse en el backlog  para luego arrastrarla y soltarla en un sprint.

TIP: Puedes tener tantos sprint como quieras, aunque no es recomendable tener más de dos y uno de ellos activo.

Una vez tenga el sprint completo, puede activar o iniciar el sprint “Iniciar Sprint” donde podrás fijar la fecha de inicio y fin del mismo. También puede cambiar el nombre del sprint haciendo click sobre el nombre del mismo.

Backlog

Trabajos Pendientes – Backlog

En la parte superior aparecen los filtros rápidos, los cuales pueden ser configurados dentro de la configuración de la pizarra que veremos en post posteriores.

Si tenemos los Sprint activos, hacemos click en el ícono boton-sprint-pizarra-scrum-jira, esta vista nos facilita ver y gestionar las historias de usuario y las tareas técnicas asociadas a las historias de usuario.

El Sprint Activo

La siguiente figura muestra la vista de un sprint activo, en ella podemos observar las columnas que representan los estados en los que se encuentran las tareas de cada historia de usuario. Para cambiar de estado simplemente se arrastran de una columna a otra.

Sprint Activo

Sprint Activo

Esta vista “sustituye” a nivel software lo que sería la pizarra scrum donde están las historias de usuario y las tareas en los estados en los que se encuentran. Es de gran utilidad aunque he de reconocer que no es fácil acostumbrarse visualmente a ella, la vista que se muestra en la figura agrupando las tareas por historia es la que al final me ha parecido más cómoda.

Espero que este post le sirva para dar el primer para crear la pizarra, crear las tareas del backlog, los sprint, asignar las historias de usuario a los sprint y a activar el sprint. En un siguiente post vamos a ver como crear las tareas técnicas y las épicas.

Un comentario

Simbiosis tecnología – Sociedad

  por

EOI, Escuela de Organización IndustrialEste post forma parte de las actividades de formación del MBA Executive de la  Escuela de Organización Industrial en el ámbito de la materia Entorno Social que dirige el profesor Ricardo H.Ontalba.

El objetivo de este post es mostrar de una forma sencilla la relación de convivencia que hay entre la tecnología social (redes sociales, web2.0) y la evolución de la sociedad. Los dos forman una simbiosis donde ambos lados ganan  y evolucionan constantemente.

La tecnología como ente facilitador y la sociedad como ente asimilador y de manera inversa, la sociedad consumidora de dichas soluciones crea nuevos retos tecnológicos para satisfacer o facilitar la creación de enlaces en esta nueva sociedad donde todos estamos conectados.

Como se muestra en la gráfica, el hombre y la sociedad crea constantemente necesidades y retos que son resueltos por la tecnología y a su vez, la tecnología crea nuevas herramientas y soluciones que transforman la forma en que vivimos, nos comunicamos y pensamos.

Los individuos y las organizaciones vivimos hoy en una sociedad en la que necesitamos dotarnos de una identidad digital, una identidad para formar parte de una cibersociedad o cibercultura que transciende la vida cotidiana y las paredes de cemento y ladrillo para trasladarse a la red. Para ello contamos con  herramientas tecnológicas de información y comunicación que facilitan nuestra actividad social en la red (tecnologías sociales ) entre las que triunfan las redes sociales, los sistemas de microbloggin, los blogs, wikies y toda una serie de  proyectos abiertos y colaborativos que potencian nuestra ciberactividad.

Cada día estamos más cautivos de la tecnología y con ella, cada día estamos más informados y conectados. En el bus, el tren, el trabajo, con dispositivos de diferentes tipos como móviles, ordenadores, tablet, portátiles, etc. Desarrollamos nuevas formas de actuar, comunicar y expresar. Las tecnologías sociales generan constantemente mitosis y mutaciones en la forma como nos socializamos con impactos positivos y negativos.

Estamos llenos de inquietudes y necesidades, entre las que podemos resaltar las siguientes.

  • Queremos y necesitamos ser más ecológicos y responsables socialmente.
  • Queremos y necesitamos estar todo el tiempo conectados
  • Queremos absorber y compartir el conocimiento
  • Participamos, creamos o dejamos cibercurturas constantemente
  • Somos la punta de lanza de una nueva forma de vida digital
  • Nuestros niños son nativos digitales

La necesidad de un cambio ecologísta ha generado una enorme ola de productos y acciones que tienen como objetivo “Salvar al planeta”. Alimentos ecológicos, vinos ecológicos, coches eléctricos, cambios en el alumbrado público por bombillas de led que permiten ahorrar hasta un 40% en costes y de paso disminuir las emisiones, campañas de ahorro de energía como la propuesta en estos días por www.horadelplaneta.es, etc.

Por otro lado, nuestra generación está viviendo un cambio importante en la forma en que nos organizamos. Hoy nuestro pensamiento se traslada constantemente a la red, a través de ciberculturas, cibergrupos, cibersectas, ciberconexiones etc.Los sistemas de comunicación personales como el correo electrónico es algo completamente cotidiano, los sistemas de mensajería instantánea están al día y ya vienen de serie. A ellos se les suma desde hace algunos años las redes que han surgido como una evolución natural denominada web2.0 pero que ha supuesto un cambio en los paradigmas de la comunicación e interacción social que aumenta la capacidad de impacto de los mensajes al permitir llegar a un colectivo más amplio y global.

Hoy suplantamos muchas de las comunicaciones e intereacciones personales por un conjunto de servicios ofrecidos por las redes que ya no solo nos permiten llegar a una persona con multitud de contenidos (texto, audio, video), sino que nos  transmitir el conocimiento o información a un colectivo o grupo si lo deseo. Estas herramientas sociales permiten crear rápidamente mundos, movimientos o redes virtuales  alrededor de un tema, una ideología o un simple tag o concepto haciendo que los interesados en dicha información puedan recibirla y retransmitirla rápidamente.

Nuestros hijos ya forman parte innata de esta nueva forma de vida, son los denominados “Nativos Digitales”, muchos con menos de un año ya tienen una cuenta de correo electrónico, nacen y están en contacto directo con la tecnología 10 minutos después de nacer sino antes con las cámaras digitales y la subida de fotos a Internet y aún no lo saben. A los 6 o 7 años ya tienen perfiles en redes sociales, o quieren hablar con sus amigos vía messenger, muchos ya no quieren ir al parque porque han quedado en el chat. A los 10 o 12 años tendrán su móvil, es decir, están construyendo su identidad digital desde muy pequeños y nosotros les ayudaremos.

A nuestra generación (>30 años) nos podrá costar un poco más crear nuestra identidad digital, muchos somos reacios a estar en la red o en algunas redes. No entendemos los nuevos idiomas digitales nacidos con la mensajería y los SMS, algunos no asimilamos  la rapidez con la que se mueven las redes y como se generan las ciberturbas [2]. Muchos no somos capaces de tener una mecánica de uso y nos movemos o nos dejamos mover como un barco a la deriva, pero muchos podremos alinearnos con este cambio social y tecnológico y no naufragaremos en el intento.

Estos grandes movimientos a través de las redes sociales han sido logrados con ayuda de las tecnologías de comunicación en todos sus estilos. Si hoy necesitamos organizar una reunión hacemos uso del movil, los SMS, el correo, facebook, de otra forma sería mucho más complicado. Estos sistemas de amplio alcance y su evolución son los que a la postre permiten generar de una manera más acelerada los cambios sociales que hoy vivimos. Entre dichos cambios tecnológicos tenemos:

  • Aumento de conectividad – movilidad
  • Aumento de conectividad – redes sociales – Aplicaciones
  • Aumento de conectividad – dispositivos

Se han resaltado estas tres líneas principales: movilidad, redes sociales (aplicaciones) y dispositivos y en las tres líneas se ha mencionado “aumento de conectividad” como elemento común. Esto refleja el punto central de evolución en estas tres grandes líneas, mejorar la forma en la que estamos conectados. Este es el punto primordial que para mí, es el núcleo de la simbiosis entre la sociedad o los cambios sociales y la tecnología o los cambios tecnológicos. Somos seres sociales y como tales, necesitamos estar en contacto (conectados) de manera física o virtual.

Desde el punto de vista de las redes de comunicaciones, hemos pasado de sistemas de comunicación “cable dependientes” a sistemas sin hilos. En casa es normal usar redes inalámbricas. Al salir a la calle, es común hoy en día usar las redes de tercera y cuarta generación que nos proporcionan cada día mayor velocidad para el intercambio de contenidos enriquecidos como fotos y videos. Atrás van quedando los días de GPRS u otras tecnologías de baja velocidad para transportar datos. Las redes de nueva generación nos permitirán incluso realizar comunicaciones de voz y video usando canales de datos directamente (Ejm llamadas de voz sobre ip, video conferencias ip, skype) cambiando de esta forma la forma de usar las redes.

Del lado de las redes sociales y las aplicaciones la evolución es constante. No sólo en el ámbito de las tecnologías web, sino en las aplicaciones de escritorio y en dispositivos móviles. Hoy no es raro que una aplicación se conecte a internet para descargar plantillas, clip arts, etc. Si vamos al plano de las redes sociales, éstas poseen clientes que funcionan en la web, el pc y dispositivos móviles. Las redes sociales evolucionan constantemente ofreciendo nuevas posibilidades de desarrollo de aplicaciones, mejorar la forma de uso, facilitar la comunicación y para la creación rápida de nuevos servicios y para mejorar el seguimiento de grupos o colectivos.

Sin quererlo cada día nos vamos introduciendo más y más en el mundo digital movidos por la sociedad,y necesitamos construir nuestra identidad digital, nuestra identidad en la red. Es curioso como hace algunos años al darnos de alta en un sistema de correo electrónico como yahoo, hotmail y google muchos no prestábamos atención al nombre de usuario que registrabamos, hoy creo que somos más cuidadosos, buscamos tener el mismo nombre de usuario en todos los sistemas, queremos tener nuestro propio domino en internet y reservamos nuestro espacio en redes aunque no intereactuemos con ellas, porque no sabemos si la usaremos en un futuro y queremos que no ocupen nuestro nombre. Este es el principio de nuestra identidad digital (como o quienes somos en la red) . Esta identidad se complementa con que escribimos o hacemos en la red.

A esta necesidad social de identidad digital, la complementa el echo de tenerlo todo más fácil pues cada día los dispositivos ya vienen más preparados para interactuar con ella en el mundo digital. los dispositivos ya viene preparado para esta sociedad interconectada.

Desde el punto de vista empresarial, éstas tienen en las redes sociales una masa importante de clientes potenciales y de puntos de distribución de información que les permitan identificar nuevos nichos de mercado, afinar e identificar de target. Las tecnologías sociales ofrecen nuevos soportes para modificar sus estrategias de márketing y nuevas formas de interacción con el cliente.

Las redes nos permiten llegar al cliente fácilmente, conocerle, escucharle. Y en esta misma medida nuestro cliente está a un clic de nuestra competencia,  por ello es tan importante no hacer oidos sordos a lo que se habla en la red  de nuestras empresas.

En este punto, quiero dejar abierto un tema que para mi es importante y me plantea una duda : Las empresas están perdiendo su entidad adquirida en la red a nombre propio para migrar a una identidad digital  basada en redes sociales?, Con este no me refiero a que no es necesaria una presencia en las redes, sino,  a la una transformación de la identidad digital que pasa de una identidad estilo web1.0 y dominio .com a una estilo web2.0 basada en una comunidad. Hoy es más común escuchar… siguenos en facebook.com/algo, que visita nuestra web en algo.com. ¿No es esto una forma de perder identidad y marca?.

Como podemos observar, son muchos los ejemplos en los cuales la tecnología y la sociedad van de la mano, aquí solo he tocado aspectos relativos a las tecnologías de redes y la sociedad con ideas muy generales. Creo que el tema más importe es que todos debemos pensar en cómo queremos que sea nuestra identidad digital que en el futuro nos marcará como nuestro pasado judicial o nuestro historial laboral. Lo que hagamos en la red, se puede quedar en la red y de ahí estar al alcance de todos. La tecnología nos permite hacer uso de estos mecanismos de comunicación, hagamos buen uso de ellos y creo que un punto importante es no olvidar que aunque seamos alguien en el ciber espacio, necesitamos mantener nuestros vínculos personales vivos, nuestros amigos y familiares y aún no está inventado un mecanismo que transmita el calor de un abrazo y la ternura de una mirada.

Hagamos cibermovimientos, participemos activamente si lo deseamos, pero ante todo, seamos persona de carne y hueso, sociales en persona y conectados en la red.

Algunas referencias:

No hay comentarios

Como instalar el módulo sqlite para php 5.1.2 en Centos

  por

En un Centos que tiene instalado php 5.1.2 me vi necesitado de instalar una aplicación que requería sqlite. PHP había si compilado sin soporte sqlite y sólo disponía de pdo_sqlite. Al ejecutar la aplicación en los logs salía un error que indicaba lo siguiente.
PHP
PHP Fatal error: Call to undefined function sqlite_open()

Para instalar el módulo php sqlite hay que descargarselo y compilarlo.

Descargar el código que corresponda a la versión de php instalada en nuestro caso la versión 5.1.6

wget wget http://museum.php.net/php5/php-5.1.2.tar.gz
tar -zxvf php-5.1.2.tar.gz
cd php-5.1.2
cd ext
./configure
make
sudo make install

Si no está instalado el compilardor hay que  instalarlo y las librerías de desarrollo de php.

sudo yum install gcc
sudo yum php-devel.x86_64


Al ejecutar make install, se muestra un texto como este.

Installing shared extensions: /usr/lib64/php/modules/
Installing header files: /usr/include/php/

En modules apareció un nuevo módulo llamado sqlite.so.

Los siguientes pasos fueron:

  • crear un nuevo fichero en /etc/php.d/ llamado sqlite.ini con la cadena “extension=sqlite.so”
  • Reiniciar apache

Se que esta no es la versión más reciente de php, pero en este caso estaba limitado a la versión que tiene el servidor. Espero que a alguien le sirvan estas instrucciones. Esta solución está basada en las instrucciones de instalación de sqlite de php.

Etiquetado   
No hay comentarios

En la Conferencia 6 meses en el espacio de la EOI

  por

Hoy se realizó en EOI Escuela de Organización Industrial la conferencia 6 meses en el espacio impartida por el astronauta Miguel López Alegría.

imageEn poco más de una hora Miguel nos habló de su experiencia en la Estación Espacial de la que fue comandante y nos mostró aspectos relacionados con el despegue, estadía y regreso de los vuelos, los experimentos, vivencias. Durante una entrevista comentó de la importancia del trabajo en equipo, capacidad de integración, conocimiento, humildad y capacidad de liderazgo que se requieren como astronauta.

Como empleado de EOI y para mi como padre de Oscar Mauricio ha sido un verdadero honor haber tenido la oportunidad de conocerle personalmente. Oscar estaba muy emocionado y mucho más por sus aspiraciones de ser astronauta.

Tan pronto tengamos el video de la conferencia y la entrevista lo pondré en este post, por ahora comparto con ustedes una foto de mi hijo con Miguel López.