Chess - antoniomartel.com

Archivos de Autor: antoniomartel

Meteduras de pata, confianza y política CYA

Los errores en un proyecto software son algo habitual, algo con lo que lidiar cada día. Se calcula que una aplicación web tiene una media de 4 errores por cada punto de función (contando 1 punto de función como unas 50-55 líneas aproximadamente de código Java).

Recuerdo incluso haber leído en mis tiempos de Universidad que, en la construcción de cierto sistema operativo, por cada 3 bugs corregidos se introducían 2 nuevos. Quizás una aplicación web no tenga la complejidad de ese sistema operativo pero no me resultaría extraño si alguien me dijera que en ese caso la relación fuese de 3 a 1.

Los errores al programar no son los únicos fallos que puede cometer un equipo de desarrollo. Pueden haberse entendido mal las especificaciones. Pueden haber olvidado copiar un archivo en un despliegue o no haber concretado lo suficiente un requerimiento. Oportunidades para equivocarse hay muchas.

Si ante cada error afeamos la conducta al que lo cometió e insistimos en encontrar al culpable para señalarlo con el dedo sólo vamos a conseguir que el equipo de trabajo esté más preocupado de salvar su pellejo que de hacer su trabajo lo mejor que sabe. Se tenderá a argumentar y argumentar en la documentación para justificar el porqué de las decisiones y dejar claro quién fue el que tomó la decisión.

En inglés hay un término llamado ‘CYA (cover your ass)‘ para indicar cuando se están tomando acciones sólo para protegerse las espaldas. Se dice también que cuando no tienes que emplear una mano en tapar tus vergüenzas puedes contar con las dos manos para trabajar mejor.

Si logramos en nuestros equipos una cultura ‘No need to CYA‘ podremos trabajar más tranquilos y ocuparnos sólo en entregar nuestro trabajo. Si alguien comete un error, bueno, quizás la próxima vez sea uno mismo quién lo cometa. Se asume, se explica, se toman las acciones necesarias para corregirlo y se avanza a la siguiente tarea. Es más rápido y más efectivo que estar buscando al culpable entre acusaciones cruzadas.

Referencias:

Estadísticas de uso de Scrum (2015)

Este es el tercer año ya que publico estas estadísticas sobre el uso de Scrum. En 2013 se podía ver que términos como Scrum, Agile o Kanban estaban en pleno auge. Había muchos resultados en los portales de empleo o en las búsquedas de Google.

En 2014 prácticas concretas como Scrum o Kanban tenían aún en España una fuerte subida con respecto al año anterior. En cambio, en países del norte de Europa como Alemania o Reino Unido la subida no era tan grande o incluso bajaban. Términos más genéricos como Agile mantenían y aumentaban mucho su presencia en las redes. Veamos ahora 2015.

Para España (infojobs.net) se ve una fuerte subida de Scrum y Lean (esta última cada vez tiene más peso en el mundo Ágil). También se aprecia un aumento importante de puestos de trabajo que solicitan PMP. Un 33% nada menos. Sigue sonando fuerte la certificación de pmi.org.

Estas subidas tan altas podrían deberse en parte a que existe un número mayor de ofertas de trabajo en general en el mercado español. Por esto los resultados podrían ser más positivos al haber más demanda de empleo en general.

En el Reino Unido (monster.co.uk) hay una bajada muy fuerte de todos las palabras clave. Parece que el número de ofertas puede haber bajado al haber una mayor deslocalización de puestos de operaciones IT hacia Asia. Puede también que monster.co.uk haya sufrida una fuerte competencia de otros sitios web de empleo o LinkedIn y ya no sea tan popular en UK.

En Alemania me ha sorprendido sobre todo el alto número de puestos de trabajo que solicitan PMP que sube un 265%. PMP no es requerido solo para puestos IT sino también para la industria de la automoción. Diría que PMP tiene un gran futuro en Alemania.

También se puede comprobar en la tabla la importante subida que tiene Lean en Alemania al igual que sucede en España. Es curioso también que en Alemania han comenzado a declinar en su idioma la palabra agile. Si sólo se busca por ella aparece la mitad de resultados. Buscando por otras combinaciones (agile or agiler or agiles or agil or agilen) hay más de mil ofertas de empleo que buscan a alguien ‘ágil’.

Aquí ahora la comparativa entre Scrum, Agile y PMP de todos los años con Google Trends:

Scrum y PMP están empatados en número de búsquedas en Internet. PMP ha moderado su caída de los últimos años y el interés por Scrum parece aumentar en lo que llevamos de este año 2015. Las búsquedas en Internet por la palabra Agile siguen aumentando y suman ya casi tanto como las búsquedas por Scrum y PMP juntas.

Por si es de interés aquí tienes esta misma comparativa del uso de Scrum para los años 2013 y 2014:

Scrum en ING Holanda

ING Holanda había comprobado mediante proyectos piloto que el rendimiento de su departamento IT era, competitivamente hablando, muy desfavorable. Existía una cultura de la burocracia en la organización y, desde el resto de departamentos, había una clara insatisfacción con los servicios que proporcionaba.

El responsable de canales digitales de ING decidió tomar cartas en el asunto poniéndose como meta conseguir el doble del valor que se estaba obteniendo por cada euro que se destinaba a IT. Pidió consejo a un gran número de colegas sobre qué podía hacerse para mejorar el rendimiento de este departamento. La mayoría de ellos apuntaron a Scrum como posible solución. Inmediatamente se reunió con colaboradores de Capgemini para estudiar la adopción de Scrum en ING y en el departamento de IT específicamente.

Los primeros proyectos pilotos con Scrum comenzaron en 2011. El ciclo de vida para esos proyectos se redujo de los 3-6 meses a 6-9 semanas. Inicialmente se usaron puntos de función (FP) para medir la productividad. El ratio euro/FP y la calidad, expresada en defectos/FP, se mantuvieron pero los equipos Scrum habían realizado importantes trabajos de mantenimiento y mejora en el código.

No solo la innovación y la satisfacción del empleado subieron drásticamente sino que también lo hizo la mejora de las habilidades técnicas y la colaboración entre los miembros del equipo de trabajo. Desde los departamentos de negocio de ING comenzó también a aumentar la confianza en el departamento IT a medida que se iba entregando con éxito nuevo software que además era usable.

La reducción de costes en la entrega de software estaba en un rango de entre el 30 y el 50%. El número de incidencias técnicas reportadas se había reducido, en algunos casos, incluso por encima del 30%. La cantidad de releases puestas en producción se aumentó gradualmente para reducir los ciclos y para aumentar el aprendizaje (cuanto antes se ponía en producción antes se aprendía qué era bueno y qué no o como mejorar el producto).

Para septiembre de 2012 el número de equipos Scrum en ING había pasado de 45 a 75. Se esperaba que para diciembre de 2012 todos los equipos de trabajo en ING Holanda hubiesen adoptado Scrum en sus proyectos.

¿Y tú? ¿Pensando en adoptar Scrum en tus proyectos? Quizás te interese continuar leyendo aquí
Jornada sobre cómo «Adoptar Scrum y sobrevivir al intento…», aquí Implementar Scrum y cómo sobrevivir para contarlo o en mi libro Gestión práctica de proyectos con Scrum.
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

Scrum en ING Direct

Si son clientes de ING Direct probablemente se hayan dado cuenta que desde hace algún tiempo tienen una nueva web desde la que realizar sus gestiones con el banco. Algunos ya lo sospechábamos pero en esta entrevista a Enrique Ávila, director general del tecnología de ING Direct en España, se confirma: están usando Scrum/Agile para su desarrollo.

Empezaron con un desarrollo pequeño, con las funcionalidades básicas para hacer el 80 o 90 por ciento de las operaciones y dejando otras funcionalidades más específicas para más adelante. Tampoco la lanzaron de una sola vez al mercado obligando a todo el mundo a usar la nueva web sino que la proponían desde el portal de siempre para que la fueran usando los usuarios más avanzados (y probablemente tampoco a todos al mismo tiempo).

Con estos usuarios fueron probando que todo funcionaba bien y corrigiendo o adaptando lo que necesitasen cambiar. Desde entonces han ido incorporando cada poco tiempo más y más funcionalidades según las necesidades del cliente, tanto que ya casi no es necesario visitar la antigua web.

En el vídeo se comenta la adopción de Scrum por ING y cómo era el desarrollo, con equipos Scrum pequeños y multidisciplinares con todas las capacidades para entender al cliente y entregar productos construidos en ciclos muy cortos. A partir del feedback del cliente vuelven a repetir los ciclos de manera más refinada y aproximándose cada vez más a lo que el cliente necesita.

Pero la agilidad no es nueva en ese banco. ING Holanda ya la había puesto en práctica con excelentes resultados. Aquí tienen parte de la historia:

Amir Arooni, un CIO de ING Holanda, decidió que por razones de competitividad, las entregas de los servicios IT de su departamento necesitaban mejoras sustanciales. Los métodos de trabajo y los proyectos en cascada ya no estaban siendo viables y necesitaban un cambio urgente.

Se creó un pequeño proyecto piloto para medir el rendimiento real del departamento. Era un proyecto estimado en 1500 días/hombre (casi un año para un equipo de 5 personas) pero se tardó 11 meses en terminar a pesar de estar involucradas 47 personas y 25 departamentos.

Las entregas eran percibidas como inseguras por la poca fiabilidad de las fechas de finalización y había una alto nivel de burocracia debajo de todo el proceso formal que estaban usando. La forma tradicional de gestionar proyectos basándose en el presupuesto y en el tiempo estaban retrasando enormemente las entregas que estaban lastrando la competitividad del banco.

Amir envió una petición a un gran número de sus colegas pidiéndoles ayuda para tratar con esta situación. Una gran mayoría de ellos apuntó a Scrum como la solución por lo que Amir decidió contactar con Capgemini Holanda para valorar las posibilidades de adoptar Scrum en ING y en su departamento específicamente.

Lo que sucedió en ING después de implementar Scrum lo termino de contar en este otra entrada del blog. Sigue el link: Scrum en ING Holanda.

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

Céntrate en lo importante. Es ahí donde se marca la diferencia

Nos pasa a todos en todas partes. Nos devanamos los sesos pensando en cada pequeño detalle y, mientras, las cosas quedan sin hacer. En nutrición se discute y se discute sobre si el brócoli tiene más antioxidantes que la lechuga o si las lentejas tienen o no más hierro que las espinacas, en lugar de dedicar nuestro tiempo y esfuerzos en tener una dieta rica y variada en general sin preocuparnos de que en ella esté el alimento perfecto.

Lo mismo pasaría a los estudiantes de alfarería que mencionaba hace algunas semanas en este blog. Pueden discutir y discutir durante semanas sobre cuál es la mejor técnica de todas para hacer el jarrón perfecto pero solo harán buenos jarrones cuando se hayan cansado de practicar haciendo un jarrón tras otro.

Me pasa a mí también, que puedo quedarme horas pensando si el post es lo suficientemente bueno o no o si ya he revisado bastante o aún quedan faltas de ortografía. Me pasaba también al publicar el libro. Pasaba mucho tiempo decidiendo si usaba esta portada o la otra, si incluyo este capítulo o no, si es mejor Arial que Times New Roman ¡Publica! Otros libros se están vendiendo mientras tanto.

La fuente de letras no va a conseguirme muchos lectores más y, en cuanto a la portada, realmente no sabía cuál de ellas iba a funcionar mejor. Sólo sé cuál de ellas me parece un poco más bonita que la otra. Nunca lo sabría hasta que no la expusiera al público, mientras, sólo voy a darle vueltas hasta auto-convencerme de que una opción es mejor que la otra y que no me voy a equivocar. Esto nos puede llevar a la parálisis del perfeccionismo y a un excesivo miedo a equivocarse.

¿Y en el software? Claro, también nos pasa. Horas y horas para decidir si usamos este patrón de diseño o el otro. Cada uno tendrá sus ventajas e inconvenientes. Una vez comparados los dos, apostamos por uno después de haber sopesado los pros y los contras y continuamos con el trabajo. Sólo después de unos meses sabremos si era la mejor solución o no (en realidad tampoco podremos estar seguros porque solemos tender a dar más peso a los aspectos negativos de las decisiones que tomamos en lugar de a los positivos).

Haz cien jarrones, corrige 100 bugs, escribe 100 clases, haz 100 entregas. Sólo eso te hará saber qué es lo mejor para el proyecto. Entrégalo y que los usuarios vean mediante su uso qué es lo más práctico.

De cada 100 clases habrán 5, 10 o 15 errores. Todos, sin excepciones, cometemos fallos, es inevitable pero de la tolerancia a errores y de la tranquilidad del equipo para probar lo que cree que es mejor o, como se diría en inglés, no need for C.Y.A, hablaremos en otro post.