Sunday, 28 June 2015

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:







Sunday, 21 June 2015

El sprint 0 de Scrum y el diseño inicial

Hace poco me preguntaban a través del blog sobre qué es lo que hay antes del primer sprint de Scrum. Al lector le daba la impresión de que todos los textos que leía sobre Scrum empezaban directamente en el desarrollo pero y ¿qué hay de la preparación de los entornos, de los equipos o de la oficina? ¿y del diseño? ¿No hay que pararse a pensar en todo el diseño y la arquitectura de lo que vamos a construir antes de empezar a programar?

Sobre la preparación o el 'antes' de comenzar a programar, hay gente que lo resuelve con el llamado 'sprint número 0' en el que se preparan las herramientas, se instala lo que se necesita, se forma al equipo, etc. Puede ser un sprint más largo (3, 4 semanas o así). Hay algunos detractores a este sprint nº 0 por no ser ágil y estar escondiendo ahí un trabajo que no se está resolviendo en la misma forma que el resto del trabajo. 

Es cierto que puede ser muy cómodo porque le dices al cliente que en 3 semanas estás de vuelta para tener la reunión de preparación del primer sprint y para entonces tú ya tienes casi todo organizado. También he usado esos sprints 0 en mis primeros proyectos pero ahora prefiero resolver esos trabajos también de forma ágil.

Intento que cada una de esas tareas (instalar servidor de despliegue, instalar servidor de demo, crear proyecto y tareas en Trac o Redmine, instalar IDE, etc.) formen parte ya del primer sprint y que tengan, en lo posible, un entregable al final de cada demo.

En esa demo podría mostrarse por ejemplo la herramienta de gestión de proyectos ya instalada en la url definitiva y con la lista de tareas esperando ser asignadas, o arrancar el IDE en esa reunión de demo comprobando que el workspace está bien creado y que el jetty ejecuta correctamente una aplicación 'Hola Mundo'.

Otro punto importante es el diseño inicial de la arquitectura. Si hacemos un gran diseño de toda la arquitectura de la aplicación (big up-front design) antes de comenzar a programar nada estaremos volviendo hacia un diseño en cascada tradicional: primero lo analizamos todo, tres meses después hacemos todo el diseño durante otro par de meses, y por último comenzamos a programarlo todo del tirón hasta acabarlo seis meses más tarde. Si al acabar todo el trabajo se lo enseñas al cliente y te dice: 'eso no es lo que hablamos hace un año...' estamos ante un problema.

Mejor haz el diseño de uno de los módulos de la aplicación o de la nueva funcionalidad, crea las especificaciones y pásalas a desarrollar. Mientras una parte del equipo lo implementa, los analistas pueden ir recogiendo los requisitos para otro nuevo módulo u otras funcionalidades, y así sprint tras sprint.

Habrá sprints en los que no haya nuevas cosas que analizar y otros en los que el desarrollo avanza un poco más rápido de las especificaciones pero normalmente siempre hay algún trabajo listo para comenzar hasta que el product owner dé su visto bueno a los últimos requisitos o estén ya completamente definidos.

Trabajando así, los nuevos módulos o funcionalidades podrían ir pasando a producción o pre-producción cada cierto tiempo por lo que los usuarios pueden ir usándolos sin esperar hasta que la última de las características de la aplicación esté diseñada.

Referencias:

Sunday, 14 June 2015

Gestión práctica de proyectos seleccionado para una promoción de Amazon

Mi libro Gestión práctica de proyectos con Scrum ha sido seleccionado por el equipo KDP en español para participar en la promoción Kindle Flash de amazon.com, amazon.com.mx y amazon.es.

Las promociones Kindle Flash son promociones en las que, durante 24 horas, 3 libros son promocionados por Amazon a un precio especial destacándolos en una newsletter que Amazon envía a todos los suscritos. Desde ahí, los usuarios de Amazon pueden comprar alguno de los libros promocionados con un descuento de hasta el 80%.

Puedes suscribirte a la newsletter en este enlace para Amazon.es si estás en España, o en Amazon.com para otros países. Ahí estará mi libro a sólo 1$ si lo compras desde el enlace de las newsletter entre las 12:00 am hasta las 11:59 pm del 11 de agosto. Además, suscribiéndote a esa newsletter puedes participar en el sorteo de un ebook gratuito.

En este otro enlace puedes ver también los libros Kindle que estarán de promoción hasta las doce de la noche de hoy en Amazon Kindle Flash.

Aquí tienes también los accesos al libro en los tres Amazon donde puedes comprarlo (si no quieres esperar al descuento del 11 de agosto):

Amazon.com
Amazon.es
Amazon.com.mx

Sunday, 7 June 2015

Historia de los proyectos software en tres sencillos actos

En los inicios de la informática comenzaron a aparecer las empresas especializadas en el desarrollo de software que ayudaban a resolver aquellos primeros proyectos TI que, por aquella época, parecían de ciencia ficción.

Desde entonces han habido empresas de todo tipo que empezaron a evolucionar según la corriente de los tiempos y el tamaño de sus proyectos: De empresas de garaje a Blue Chips pasando por consultoras de todos los tamaños para volver de nuevo a las empresas de garaje (ahora llamadas startups).

Todas estas décadas de aprendizaje en esta nueva ingeniería, la del desarrollo de software, no han sido fáciles. Muchas empresas quedaron por el camino ante cambios tan rápidos: La ingeniería del software es la ingeniería con mayor tasa de proyectos fallidos de entre todas las ingenierías.

Un estudio de 2012 indica que el 45% de los proyectos IT grandes exceden el presupuesto, un 7% excede el plazo y el 56% termina entregando menos valor del que se pretendía. Un porcentaje elevado de ellos va tan mal que su resultado amenaza incluso la propia existencia de la compañía.

La historia de lo sucedido en todos esos años probablemente pueda resumirse en tres sencillos actos:

Primer acto: Hacemos todo lo que el cliente solicita

Los cambios aparecen. Se necesitan modificar cosas. Lo que se construyó de una manera resulta no ser la mejor y es necesario rehacer parte del trabajo. Lamentablemente, en la mayoría de las ocasiones, el contrato está cerrado y se va a cobrar el mismo importe que se presupuestó inicialmente. La empresa debe continuar trabajando hasta que todo esté terminado, incurriendo en sobrecostes que en la mayoría de las ocasiones no estaban previstos. El desánimo cunde. El proyecto se alarga y alarga devorando horas y horas del equipo de trabajo que intenta terminarlo a tiempo.

 Segundo acto: No admitimos cambiar ni una coma

Nos enfadamos. Los sobrecostes llegan a ser tan altos en algunos proyectos que se comen cualquier margen comercial.

Las empresas de software han aprendido la lección y no pueden permitir esto. Colocan como jefe de proyecto a un duro negociador que no admite cambios. Cualquier modificación debe ser firmada por el cliente por triplicado y registrada en un acta formal. Las reuniones de análisis se convierten en algo similar a esto: 'En el acta de reunión del 3 de junio se dijo que ... corroborado luego en el acta del 9 de agosto por lo que ahora no puede cambiarse'.

Pero los cambios ocurren, el mercado, las leyes o los decretos cambian y los errores de juicio se cometen. Nadie puede estar 100% seguro de que lo que dijo 2 años antes, al inicio del proyecto, sea válido ahora.

Tercer acto: Agilidad

El cliente puede llamarte y decir:
  • 'Sabes qué? He estado pensando y puede quedar mejor sí...'
  • 'Después de que pusimos en producción la versión 14 hemos visto que no está usando nadie la feature C. Mejor saltamos también D y comenzamos a trabajar en E y F'
  • 'Hemos enseñado la aplicación en las sesiones de formación y todos nos preguntan que porqué no hay una exportación a Excel. Mejor comenzamos por ahí en el siguiente sprint en lugar de cambiar los logos y los iconos del menú'
Para esto tienes que estar en contacto continuo con el cliente. No puedes encerrarte año y medio con los tomos de análisis de requisitos, de casos de uso y las especificaciones de diseño y dejarle ver al cliente el resultado cuando hayas implementado hasta el último caso de uso (se necesite ya o no).

Este tercer acto no es tan sencillo como parece:

  • Es necesaria la confianza mutua entre ambas partes. 
  • Es necesario que el dueño del producto o representante del cliente conozca bien su negocio, tome decisiones acertadas (o corrija el rumbo con destreza cuando no ha podido ser así).
  • Es también muy importante que el jefe del proyecto en la empresa contratada sepa asesorar al cliente y darle apoyo en cuestiones técnicas y no tan técnicas. Probablemente no conozca el negocio del cliente pero seguro que tiene alguna experiencia útil en lo que salió bien (o no tan bien) en productos similares en los que ha trabajado.

Referencias: