Ajedrez - antoniomartel.com

Archivos por Etiqueta: DESIC

Scrum en la práctica: Cómo lo usamos en DESIC

La semana pasada publicaba un prezi con una introducción al uso que dábamos a Scrum en DESIC. Esta semana les dejo con el enlace a una segunda presentación en la que concretamos con algo más de detalle cómo usamos Scrum en el trabajo diario en DESIC:

  • Cómo hacemos los tests
  • Cómo planificamos los sprints
  • Cómo ha sido el proceso hasta llegar a la versión de Scrum que utilizamos actualmente y qué nuevas automatizaciones queremos incorporar.
Tienen acceso a la presentación aquí: Scrum en la práctica: Cómo lo usamos en DESIC.
Scrum en la práctica: Cómo lo usamos en DESIC - Antonio Martel

Presentación Cómo usamos Scrum en DESIC (I)

He creado una presentación en prezi que muestra cómo usamos Scrum en DESIC: nuestra particular versión de este marco de trabajo y cómo lo aplicamos. En las últimas diapositivas explico también las que creo que son las principales ventajas que Scrum (o agile si quieres) aporta a los proyectos en general (y a los nuestros en particular).

Puedes acceder a la presentación a pantalla completa haciendo clic en la imagen o en este enlace directamente a prezi: Cómo usamos Scrum en DESIC (I).

Cómo usamos Scrum/Agile en DESIC por Antonio Martel

Cómo usamos Scrum en DESIC

En los blogs sobre software o metodologías varias solemos contar las bondades del framework que usamos o filosofamos sobre el devenir de la industria pero pocas veces contamos qué tal nos va o qué estamos haciendo exactamente en nuestro trabajo diario. De eso va esta entrada, de cómo trabajamos y de qué hacemos para sacar adelante nuestros proyectos.

Trabajo en DESIC, una empresa de desarrollo de software canaria, en la que llevo trabajando en multitud de proyectos desde hace ya más de 10 años. Llevamos unos cuantos intentando ser un poco más ágiles en cada uno de esos proyectos. De unos se aprendió qué debíamos hacer, de otros aprendimos qué no había que hacer y de lo aprendido en todos ellos hemos llegado al estado actual (mejorable aún, eso seguro). Aquí van unas pinceladas sobre cómo trabajamos en DESIC:

Trac para planificar el sprint

No usamos una de esas populares herramientas de gestión de tableros kanban, ni siquiera tenemos un tablero físico con todas esas pegatinas de colores. Usamos Trac en su lugar. Ya sé que no suena tan cool y que tiene una pinta un poco, digamos, vintage, pero nos funciona y la verdad es que lo hace bastante bien.

Cada dos semanas planificamos las tareas a realizar durante las siguientes dos semanas y las introducimos como tickets en el trac para el sprint que vamos a comenzar. Cada vez que alguien resuelve un ticket entra en trac y lo marca como cerrado o lo pasa a un compañero para que continúe con su parte. De un simple vistazo todos vemos el trabajo pendiente que nos queda por acabar y la prioridad que tiene.

Si no hemos podido cerrar muchos tickets en este sprint nos quedamos algo preocupados porque llegaremos al día de demo y no tendremos mucho que enseñar. En cambio si todo ha ido bien y hemos terminado nuestros tickets e incluso comenzamos ya con los de la semana siguiente vamos a estar mucho más contentos (sí, a veces adelantamos lo previsto para el sprint).

Cómo planificamos el sprint

Normalmente tenemos sprints de dos semanas que en alguna ocasión han sido de 3 por vacaciones de parte del equipo de trabajo durante las navidades y en otras de solo una semana. Esto último no funcionó nada bien. Fue muy difícil planificar una demo, la planificación del siguiente sprint, pruebas y todo lo demás en sólo 5 días de trabajo.

Les pongo aquí cómo es el calendario habitual en un uno de nuestros sprints de dos semanas. Está copiado casi literalmente del panel de Google+ donde anunciamos lo que tenemos previsto para los próximos días:

Previsto en el sprint del proyecto para el paso por test, pre-demo y demo:
1. Miércoles de 2ª semana del sprint: 
          a) Test de la batería de tests de 8:00 a 12:00
          b) Pre-demo de 12:00 a 13:30
2. Jueves de 2ª semana del sprint:
          a) Correcciones a bugs/incidencias de 8:00 a 12:00
          b) Subida a demo a las 13:00 (con lo que haya hasta ese momento. No será posible hacer nuevas subidas hasta la demo del día siguiente)
          c) Después de demo correcciones que no hayan podido caber en esta demo y trabajo en siguiente sprint hasta la demo del día siguiente.
3. Viernes de demo
          a) Demo a las 12:00
          b) Planificación del siguiente sprint a las 13:00

En esta planificación que pueden ver ahí, hay algunas cosas que son particulares a nuestra forma de trabajar:

  • Tenemos una pre-demo el miércoles antes de terminar el sprint. Se estableció así porque en las primeras demo de los viernes fallaban muchas cosas o no nos habíamos entendido bien. Se muestra sólo al Scrum Master lo que han hecho durante esas casi dos semanas que puede ya ir viendo cómo de bien o mal va a quedar el sprint. Esto sirve también de ensayo para lo que vamos a ver el viernes en la reunión de demo real.
  • El último día del sprint, el viernes de la segunda semana tenemos una demo ante todo el equipo de trabajo, en la que no siempre está el Product Owner, nuestro cliente. Trabajamos en un entorno distribuido por lo que no podemos estar en las mismas oficinas que nuestro cliente cada dos semanas. La misma aplicación que hemos visto en demo la enviamos al product owner para que pueda comprobar el trabajo hecho en ese sprint y que valide o no el resultado.
  • En clientes más recientes, que han adoptado la agilidad desde hace mucho, hacemos una demo por Skype y se le explica lo realizado en esas semanas. Al final hay una retrospectiva en el que nos cuenta su impresión de lo que hemos hecho y lo que le ha gustado o no y puede mejorarse. Es una demo ensayada y probada para intentar que todo quede casi cronometrado en una hora de duración.

Cómo informamos al cliente

Cada vez que termina un sprint enviamos al cliente un informe de estado con las tareas y tickets de trac que hemos cerrado en esas dos semanas. Así pueden saber qué se pudo completar de lo previsto. Del mismo modo enviamos también qué tickets tenemos previsto cerrar durante las próximas dos semanas. Si todo ha ido bien deberá ser muy parecido a lo que digamos en el siguiente informe de estado que hemos podido finalizar.
Estos correos van con copia a la cuenta de correo de todo el grupo de trabajo y en él le indicamos al cliente también la URL donde podrá probar la versión de la aplicación que acabamos de desplegar y que revisamos en nuestra demo interna del viernes. En el correo van también las instrucciones sobre cómo probar los cambios realizados o dónde pueden encontrarlos.
En todo momento los clientes tienen acceso al entorno de demo para hacer sus pruebas, indicarnos qué va mal o decirnos qué cambios quiere sobre lo que está probando. Este entorno ha resultado ser muy útil porque nos permite mostrar muy rápidamente cada cambio aunque no esté finalizado sin tener que esperar a despliegues programados en pre-explotación o en producción.
Puedes ver más sobre las herramientas que usamos en esta otra entrada: Google+ como herramienta de gestión de proyectos.

Ponencia sobre GUIRRE en las Jornadas del proyecto Resiless

Femepa ha tenido a bien invitar un año más a DESIC a dar, el pasado jueves, una ponencia sobre el sistema de información GUIRRE que hemos venido diseñando y evolucionando en los últimos años para la Viceconsejería de Medio Ambiente del Gobierno de Canarias.

GUIRRE es el acrónimo para el Sistema de Información de Residuos de Canarias y en su ponencia, mi compañero Aridany Ramírez, jefe de proyecto para los desarrollos en esta aplicación, ha explicado los avances realizados en el último año:

  • La posibilidad para gestores y productores de residuos de presentar documentos de control y seguimiento (DCS) a través de la sede (habilitado cuando se apruebe la normativa que admite este medio como presentación oficial).
  • La pantalla de avisos en GUIRRE que permite al técnico de medio ambiente saber si se acaba de entregar un DCS para un residuo en el que el gestor no está autorizado o si el centro que la ha presentado tiene su autorización en vigor. 
  • La aplicación que lee la bandeja de correos electrónicos donde los gestores de residuos, además de la presentación oficial, envían el documento en formato electrónico. Esta aplicación lee estos correos, los interpreta y guarda en la base de datos de GUIRRE indicando al usuario si el documento es correcto, si ya lo ha presentado anteriormente o si se ha equivocado y ha enviado una notificación de traslado (NT) en lugar de un DCS.
Al final del año ya el gestor ha dicho a la Consejería a través de los DCS qué ha hecho con los residuos, a quién se los recogió, quién los transportó y a qué centro los entregó. Con toda esta información recibida a través de los DCS que ha ido entregando a lo largo del año, un gestor de residuos podrá generar un borrador de la memoria que deben entregar cada anualmente. . 
A través de una nueva opción, los gestores se traen todos los datos que GUIRRE tiene de ellos y los importan en la memoria anual de forma similar a como lo hace la declaración de la renta. Si está de acuerdo con lo allí presentado o quiere añadir algo más, sólo tiene que completar el resto y pulsar el botón tramitar (esto puede ser importante para gestores que llegan a presentar memorias de más de 300 páginas).
También intervinieron en estas jornadas Carlota Cruz, directora de la fundación Canarias Recicla y Juan Carlos Betancor, secretario general de Femepa.

Y por último, les dejo la presentación en prezi que utilizó Aridany Ramírez para su ponencia: Gestión de Residuos – Sistema de Información de Residuos de Canarias y algunas fotos del evento:

Suscríbete

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Más información
Privacidad