Ajedrez - antoniomartel.com

Archivos por Etiqueta: Agile

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:
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

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

Metodologías ágiles explicadas

Les dejo al final de la página un vídeo que explica las diferencias entre una metodología en cascada y otra ágil para la planificación de un viaje de miles de kilómetros hasta Portland, Oregon.

Dos equipos de trabajo reciben las mismas especificaciones para un proyecto: Viajar de la costa este hasta Portland en la costa oeste de Estados Unidos.

El equipo que trabaja en cascada planifica todo el viaje con antelación. Forman varios equipos distintos, cada uno especializado en un aspecto distinto del viaje: mecánica, avituallamiento, mapas, etc. Deciden cuál es el presupuesto que necesitarán, cuántos kilómetros recorrerán cada día, el sitio exacto dónde pararán a por gasolina, a por comida o a revisiones en el taller.

En cambio, el equipo ágil forma un único equipo en el que entre todos tienen el conocimiento suficiente para tomar decisiones sobre mecánica, rutas del viaje o meteorología. Establecen una serie de metas en el camino y toman las decisiones según lo aprendido en lo que ya llevan recorrido. Puede que decidan cambiar la ruta planeada por que la carretera estaba en mal estado o la velocidad con la que se preveía circular resultó no ser la prevista.

El presupuesto y la ruta ágil han ido adaptándose a lo que el cliente necesita y a las necesidades reales del proyecto, las que se conocen justo en el momento en que pasan. Esto puede permitir superar las expectativas del cliente o reducir el presupuesto al adaptarse a las cosas a medida que suceden.

Aquí les dejo el enlace a la página del vídeo: Agile Methodology by Common Craft.

La importancia de saber hacia dónde se va

A veces, cuando empezamos un nuevo proyecto no transmitimos o no nos transmiten correctamente la idea de lo que se va a desarrollar. Sí, sabemos las especificaciones técnicas y conocemos los requisitos pero no sabemos el porqué ni para qué se necesita esa nueva funcionalidad o ese nuevo sistema.

Sucede como cuando hay niebla en la carretera, no vemos bien hacia donde vamos por lo que tendemos a reducir la velocidad. No vamos tan rápido como si hubiese una clara visión del objetivo.

Si nos piden que desarrollemos un nuevo servicio web que acepta y envía un complejo lenguaje con información de residuos lo construiremos tal y como nos dijeron y ya está ¿Funcionó? ¿Sirvió para algo? ¿Se está usando? Ni idea, nadie sabe muy bien.

En cambio, si en la reunión de arranque del proyecto, alguien explica al equipo de trabajo que con ese servicio web se pretende conseguir que todas las comunidades autónomas intercambien información sobre lo que se hace con los residuos y hacia dónde los llevan los gestores. Sabiendo que con software como ese se puede evitar que baterías de coche usadas terminen vertidas en una playa de Senegal por el mercado ilegal de residuos tendremos un idea mucha más clara del objetivo.

Saber esto desde el principio va a ayudar al programador a entender mejor los requisitos, identificar si alguno es incorrecto o a proponer incluso mejoras ahora que sabe para qué sirve. Además de todo eso puede que esté más contento. Sabe que lo que está haciendo es útil, que sirve para algo y que es importante que no tenga errores (quizás esto sea más efectivo para la calidad del software final que las pruebas unitarias).

Referencias:

La banca también es ágil

Comentaba la semana pasada que la agilidad no está siendo usada solo por los proyecto software sino que también la aplican tiendas de moda como Zara o bancos como ING para su departamento de IT.

Pero ING no es el único banco que utiliza Scrum y otros métodos ágiles en su gestión. También lo hace el banco BBVA Compass, filial americana del BBVA. Su director de informática cuenta sobre los métodos ágiles:

«Los rigurosos y repetitivos procesos de desarrollo de agile nos permiten reaccionar más rápidamente ante los problemas que surgen sin que los plazos y los clientes se vean perjudicados».

«Crear un entorno agile es mucho más que poner en práctica una nueva forma de gestionar proyectos»


«Estamos cambiando nuestra mentalidad, nuestra cultura».

La señora Huesman, directora de la oficina de gestión de carteras del BBVA Compass afirma también que en apenas seis semanas de aplicar la agilidad ya habían evitado retrasos y sobrecostes al identificar los problemas mucho antes que con la metodología en cascada.
Aquí, en España, también lo usa directamente el tan denostado Bankia que empieza a hacer cosas de manera diferente con sus oficinas ágiles (esperemos que sea así siempre). Estas oficinas están especializadas en operaciones y transacciones básicas que comercializan productos sencillos dejando para sus oficinas convencionales cercanas el asesoramiento y los productos complejos.
Las llamadas oficinas ágiles de Bankia son antiguas sucursales reformadas para darles una nueva imagen y que cuentan también con un horario más amplio, hasta las seis de la tarde de forma ininterrumpida.
En Bankia fueron ágiles también en la apertura de estas oficinas. No abrieron todas las sucursales al mismo tiempo sino que en 2013 crearon la primera oficina ágil en Alcalá de Henares (Madrid) como proyecto piloto. Su éxito permitió que otras veinte oficinas más se abrieran ese mismo año. En 2014, la entidad contaba ya con 120 oficinas ágiles a la que se espera que se unan otras 20 nuevas oficinas durante este año.
Según Bankia, la productividad de estas oficinas ha tenido un incremento de «dos dígitos altos» durante el último año dejando el tiempo medio de espera en 3:31 minutos y el de atención en 4:53. Esto supone, según el director de banca particular de Bankia, que desde que los clientes entran hasta que terminaron sus gestiones, han pasado menos de diez minutos.
Parece que incluso sectores tan tradicionales como la banca se apuntan a esto de la agilidad. Está empezando a dejar de ser sólo cosa de informáticos.

Referencias:

Suscríbete