Ajedrez - antoniomartel.com

Archivos por Etiqueta: gestión de proyectos

Mi libro hoy en la promoción Kindle Flash de Amazon

Mi libro Gestión práctica de proyectos con Scrum ha sido incluido entre los tres libros promocionados hoy por Amazon en su selección Kindle Flash.

Junto a mi libro están también de promoción:

  • Mi alma gemela de Caroline March que fue II Premio Digital en los premios HQÑ.
  • El barón rampante de Italo Calvino.

Si aún no lo has leído, anímate a comprarlo. Con esta promoción estará durante todo el día con un descuento del 80%.

Haciendo clic en la portada tienes el enlace a la oferta de hoy en Kindle Flash de Amazon.com:

(Actualización: Parece que esto de ser promocionados por Amazon funciona. Hoy a las 6:15 de la mañana ya había vendido 30 libros! Espero que no los devuelvan todos…)

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

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:

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:

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:

Suscríbete