Chess - antoniomartel.com

Archivos por Etiqueta: Ágil

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:

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:

Scrum en la serie de TV Silicon Valley y en las tiendas Zara

Scrum, Lean y otros métodos ágiles se están haciendo cada vez más populares. Han pasado de la industria del automóvil al del desarrollo del software y de ahí se está disparando hacia un gran número de sectores diferentes. Hasta en Hollywood se ha interesado por estos nuevos métodos.

Ya se están viendo casos como el del gigante de la moda Zara que usando Lean Manufacturing o Lean Management para producir determinados artículos sólo cuando hay demanda (just in time). Cuando comprueba que una nueva línea de prendas con topos rojos está causando sensación, pone en marcha su maquinaria para fabricar y enviar en solo unos días los nuevos productos a sus tiendas de Shangai o Nueva York.

No tiene que esperar a la próxima temporada de otoño-invierno para diseñar, producir y distribuir los productos que veremos en verano en las tiendas ¡A saber qué estará de moda en ese momento!

También está pasando en la banca. Hablaba hace unos días del caso de ING pero no se está limitando sólo a sus departamentos de informática sino también de oficinas ágiles que intentan adaptarse a las nuevas necesidades de los clientes (ya hablaré de banca ágil en otro post).

Pero quizás la prueba definitiva de la popularidad de lo ágil venga de la mano de la televisión. En la comedia Silicon Valley de la HBO los actores interpretan a programadores recluidos en la casa de un millonario gracias a las páginas web. En varios capítulos pueden verse tableros kanban, gráficas burn-down o de deuda técnica.

En otro capítulo un consejero de la start-up recomienda al dueño usar Scrum pero cuando deciden implantarlo el equipo se queja amargamente y todo acaba con muy malos resultados (ya sabes, es sólo ficción).

Referencias:

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos. Contiene enlaces a sitios web de terceros con políticas de privacidad ajenas que podrás aceptar o no cuando accedas a ellos. 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