Sunday, 10 December 2017

¿Tienes dependencia de tu proveedor de software?

En algunas ocasiones nos encontramos con clientes que están atados de pies y manos por su proveedor de software. Usan un software que es sistémico para la empresa pero no están contentos con el mantenimiento que el proveedor realiza, los tiempos medios para la corrección de errores y lo tarde y mal que entrega nuevas características del programa. A veces el servicio no es del todo malo pero sí caro pero no pueden pedir ofertas a otros proveedores y estimular la competencia porque ellos son los únicos que conocen el software o quienes tienen contratados a los expertos en esa solución.

Se les suele pedir a estos proveedores que continuamente documenten todo lo que hacen para así asegurarse un traspaso tranquilo y cómodo a otro proveedor si se diera el caso. La empresa probablemente asegure que sí, que todo está bien documentado y esto da cierta tranquilidad al cliente pero ¿pueden estar tranquilos con esta afirmación? ¿basta con documentar el código para evitar la dependencia de proveedores? Probablemente no.

En la empresa proveedora cada vez que llega una nueva andanada de peticiones de documentación, ésta se vuelve como loca a producir documentos pero pueden pasar estas cosas:

  • El proveedor puede ser reticente a documentar las partes más sensibles de su código porque contenga las claves que permitan que su trabaje se copie a otras soluciones.
  • Puede que al proveedor no le interese documentar bien el código para mantener su situación de vendor lock-in (dependencia del proveedor) y que el cliente tenga unos costes inasumibles si intenta cambiar de proveedor.
  • Se producen documentos como si los pagaran al peso pero su principal objetivo no es el de clarificar qué se ha hecho en el código sino poder facturar documentos, enseñarle papeles a un auditor o justificar el trabajo.
  • La documentación no está actualizada porque a medida que se han ido haciendo más y más cambios nadie ha ido actualizando cada diagrama y cada nota de unos documentos que cada mes que pasa se hacen más viejos. Documentar y mantener actualizada una documentación es un trabajo muy costoso que consume mucho tiempo y recursos.
  • La calidad del código es mala y algunas partes del código sólo son entendibles por la persona que lo hizo haciendo muy difícil que nadie pueda escribir un documento que los describa.

¿Podemos quedarnos tranquilos con nuestro código ya documentado? ¿Qué podemos hacer si ya sabemos que documentar no es suficiente?
  • Asegurarte que se usan buenos estándares de programación para que el código sea claro y fácilmente entendible por cualquiera que lo retome.
  • Procurar que todas las personas trabajen en todas las partes y módulos del código (Collective Ownership) evitando que quede en manos de unas pocas personas todo el conocimiento de algunas áreas del código.
  • Seguir el principio KISS (Keep It Simple Stupid) evitando diseños y soluciones demasiado complejas de entender. Ya se sabe que 'lo bueno, si sencillo, dos veces bueno'.
  • Utilizar un buen sistema de control de versiones que te permita mantener la propiedad y el control de todo el código de forma que sea fácilmente transmitible a cualquier nuevo proveedor que llegue con sólo pasarle una url y un usuario y contraseña.
  • Usar APIs de Servicios Web y estándares XML o JSON de forma que puedas extender tu aplicación con las mínimas interferencias con el resto del código de tu producto.
  • Tecnologías como Docker te permitirán aislar tu código del entorno hardware donde están para controlarlo tu mismo evitando hacer peticiones a la empresa que controla el hardware y middleware donde está desplegado tu aplicación.
  • Herramientas de gestión de la configuración como Chef y Puppet te ayudarán a automatizar la configuración de la infraestructura en la que tu software se ejecuta simplificandola drásticamente.

Referencias:

Sunday, 3 December 2017

No te dejes engañar por un diagrama de Gantt y la Falacia de la Planificación

¿Cuántos proyectos conoces que hayan acabado dentro del tiempo y presupuesto estimado sin que haya habido que reducir el alcance del proyecto? Muy pocos ¿no? Yo tampoco conozco muchos casos. Esto pasa en casi todos los sectores, no sólo en la industria del software, pero me temo que nuestra industria tiene una tasa de proyectos fracasados más alta que otras industrias. El estudio realizado para el Informe CHAOS 2015 revela que sólo el 29% de los proyectos TI pudo considerarse un éxito.

Nuestras estimaciones de tiempo y coste de un proyecto se salen de toda escala e incumplimos habitualmente nuestros relucientes diagramas de Gantt hechos al inicio del proyecto ¿A qué se debe esto? Bueno, al menos tiene una explicación científica. Se debe a un sesgo cognitivo que tenemos todas las personas no deprimidas y que hace que caigamos, una y otra vez, por exceso de optimismo en la llamada falacia de la planificación.

Este fenómemo, el de la falacia de la planificación, es debido a que los seres humanos tendemos a subestimar cuanto nos va a llevar terminar una tarea. Somos demasiado optimistas y siempre pensamos que vamos a tardar mucho menos de lo que finalmente nos va a llevar terminarla.

Lovallo y Kahneman, los autores de esta teoría, realizaron un estudio en el que preguntaron a 87 estudiantes de una universidad cuánto tiempo creían ellos que necesitarían para terminar su proyecto de fin de carrera. De media estos estudiantes estimaron que tardarían 34 días en finalizarlo el proyecto pero sólo el 30% de ellos fueron capaces de hacerlo en ese tiempo. La media real empleada en terminar sus tesis fue de 55.5 días, un 63% más de lo estimado.

Este exceso de optimismo es provocado en parte por la llamada ceguera de ausencia (absence blindness) que nos dice que por muy bien que planifiquemos nuestro proyecto nos será muy difícil planificar los imprevistos porque son eso, imprevistos, y no los conocemos de antemano. Planificamos todo lo relacionado con las especificaciones del proyecto pero olvidamos calcular los tiempos para las vacaciones, bajas por enfermedad, paternidad, maternidad, reuniones, otras tareas que causan overhead, dependencias de otros proyectos, requisitos que no están bien definidos y un larguísimo etcétera. Como dice Forrest Gump en su película, shit happens (esas cosas pasan).

Todo esto nos lleva además a tener en cuenta la Ley de Hofstadter: "Todo proyecto lleva siempre más tiempo del previsto incluso si se tiene en cuenta la propia Ley de Hofstadter". Y si esto ocurre y nuestro proyecto se alarga más de lo previsto, probablemente caigamos todavía en más costes de lo que supone terminar más tarde. Como no llegamos a la fecha del fin del proyecto la presión nos llevará a meter a más gente dentro del proyecto para terminaar a tiempo haciendo que tengamos que contabilizar gastos extra directos como el salario de estas nuevas personas pero también indirectos de los cuáles no siempre somos conscientes.

Al incluir más personas olvidamos que necesitarán formación en el proyecto y que cometerán más errores al ser nuevos, errores que habrá que dedicar un tiempo a corregir. Se estima que un nuevo perfil en un proyecto tarda unos tres meses en ser totalmente productivo. Por otro lado, alguien que ya estaba trabajando en el proyecto tendrá que parar lo que estaba haciendo para enseñar a los nuevos. Como ya nos decía Brooks en los 70: "Añadir más gente a un proyecto retrasado, hará que se retrase aún más".

Pero la presión aún nos hará incurrir en más costes en el proyecto. Las prisas nos harán bajar la calidad del producto que producimos, aparecerán más errores que también necesitarán tiempo para ser corregidos, o nos saltaríamos las pruebas del software con lo que saldrá a producción con bugs que nos harán perder la confianza y credibilidad con nuestro cliente. Y queremos que nos contrate de nuevo ¿no?


¿Qué podemos hacer para evitar esto?

En primer lugar debemos hacer un esfuerzo para tener en cuenta el máximo número posible de imprevistos que puedan surgir calculando así un tiempo extra para esos inconvenientes del día a día y aquellos otros que puedan ser aún más imprevisibles.

Podemos también intentar apoyarnos en las estadísticas de proyectos similares al nuestro. Si comprobamos cuanto tardaron probablemente nos llevemos una sorpresa si lo comparamos con lo que nosotros hemos previsto inicialmente.

Por último, sería bueno apoyarnos también en pruebas empíricas y no en estimaciones predictivas y medir la velocidad del equipo para calcular cuantas tarjetas podemos consumir en cada sprint. Así sabremos calcular un poco mejor qué podremos tener terminado en determinadas fechas. Los equipos de trabajo no son siempre iguales y si nos basamos en la cantidad de puntos o historias de usuario que nuestro equipo ha podido hacer durante los últimos sprints, podremos calcular algo mejor la cantidad de tiempo que nos llevará hacer otras funcionalidades similares en las próximas semanas o meses.


Otros artículos que pueden ser de tu interés:

Referencias:








Sunday, 19 November 2017

Cómo ser ágiles en proyectos para la administración pública o a precio cerrado

La mayor parte de mi vida profesional, como muchos otros, la he vivido trabajando en proyectos a precio cerrado (fixed price) en concreto trabajando para administraciones públicas en las que el alcance del proyecto venía prefijado de antemano en pliegos de condiciones administrativas y claúsulas técnicas.

En este tipo de proyectos tienes que presentar una propuesta económica, de recursos y de tiempo a la administración pública que valorará cuál es la mejor de las ofertas presentadas, normalmente la de presupuesto económico más bajo, decidiendo luego qué proveedor será el adjudicatario. Por tanto, desde antes de iniciar el proyecto, tendrás que estudiar las condiciones y el alcance fijados en los pliegos y hacer una arriesgada estimación de cada una de las tareas o módulos que se requiere desarrollar y lanzar tu oferta.

¿Se puede ser ágil en proyectos en los que el costo, el alcance y a veces la fecha de entrega están cerrados desde el inicio? Yo pienso que sí, veamos cómo.

¿Qué hacer con el coste?

Este es el lado más arriesgado de este triángulo de hierro. Hemos hecho una estimación basada en lo que ponía en los pliegos de contratación pero estos contienen en la mayor parte de las ocasiones una descripción genérica de las tareas a realizar que luego se concretará a medida que se avanza en el proyecto o se analiza con las partes interesadas. Más que una oferta hemos hecho una apuesta que no sabemos si nos saldrá bien.

Tendremos que confiar en haber hecho una buena estimación. Por naturaleza todos tendemos a ser demasiado optimistas teniendo en cuenta sólo los escenarios en los que todo marcha bien. Sólo cuando usamos estimaciones tipo PERT en la que se nos obliga a ponernos también en el peor caso nos paramos a pensar en esos grandes imprevistos que siempre pueden pasar (como se dice en inglés, shit happens). A partir de aquí nos basaremos en las mejoras de eficacia que proporciona la agilidad.

En Scrum y otros frameworks iremos entregando cada poco tiempo una parte del alcance prometido lo que permitirá ir enseñando nuestros trabajo, haciendo correcciones y aprendiendo de lo que ya hemos hecho. En los proyectos en cascada también hay fases: Análisis, Diseño, Construcción y Testeo pero al final de las primeras sólo entregamos unos documentos sobre lo que se va a construir. Sería como analizar, diseñar un nuevo prototipo de móvil y esperar a construir 10.000 unidades para luego comenzar a venderlo y ver si le gusta a los usuarios que lo han comprado o no.

Incluir los tests y planes de aseguramiento de la calidad en cada sprint nos permitirá construir bien desde el inicio y con menos costes. Es mucho más fácil corregir los problemas de cobertura de un móvil cuando se está desarrollando y diseñando la antena en los primeros modelos que cuando ésta ya ha llegado a la línea de ensamblaje para la producción en masa.

¿Qué hacer con el alcance?

A medida que avanza el proyecto es habitual que el cliente se dé cuenta de que necesita cosas que no están incluidas en el contrato inicial. Elaboró los pliegos con el conocimiento que tenía en ese momento pero según se adquiere más experiencia en el proyecto y se va usando la aplicación (recordemos que la vamos entregando poco a poco para que la comiencen a utilizar) se va dando cuenta de que hay partes sin las que el software sería mucho menos provechoso.

En los proyectos ágiles en los que he trabajado admito modificaciones negociadas al alcance. Si se quieren incluir cinco informes nuevos a la aplicación que la harían mucho más útil deberemos acordar qué otras tareas de igual o similar estimación quitamos del alcance del proyecto. Normalmente está tan interesado en incluir las nuevas funcionalidades que no le importa sacar del proyecto otras tareas que ahora no ve tan importantes o que incluso considera que no deben hacerse.

Para la negociación habré presentado al cliente desde el arranque del proyecto una estimación de cada una de las funcionalidades a entregar de forma que sabe cuánto valen para él cada uno de estos puntos si decide quitarlos del alcance. Esta estimación fue realizada al inicio del proyecto y puede que ahora sepamos que hay cosas que son mucho más costosas de realizar de lo que estimamos al inicio, sin embargo, no cambio esta estimación inicial para que el cliente no se sienta engañado. Normalmente las estimaciones que ahora son más costosas son compensadas con otras que ahora sabemos que no lo son tanto y que también quiere que quitemos del proyecto. En cualquier caso, si hemos conseguido que el cliente esté satisfecho con el trabajo que le hemos ido entregando poco a poco y además está contento por las nuevas funcionalidades que va a conseguir, la negociación no debería ser muy dura.

¿Que hacer con el tiempo?

A veces, además de tener un importe económico y un alcance fijos tenemos que cumplir también con unas fechas de entregas inalterables que nos obligarían a aumentar las horas extras, los tiempos dedicados durante el fin de semana y el número de desarrolladores implicados en el proyecto aumentando considerablemente nuestro coste del proyecto.

Si hemos sido ágiles en el proyecto y hemos ido poniendo en producción cada poco tiempo lo que hemos ido desarrollando, el cliente podrá tener ya en uso el día de la fecha de entrega un porcentaje alto de lo que se necesita entregar. Si además hemos priorizado correctamente, desarrollando en primer lugar aquellas funcionalidades que más valor aportan, sólo quedarán fuera aquellas de menor importancia por lo que normalmente pueden entregarse en una segunda fase sin que se altere demasiado el valor del sistema.

Si hubiésemos realizado un desarrollo en cascada y estuviésemos retrasados, en la fecha de entrega no tendríamos nada que subir a producción a pesar de que podríamos tener un 80% del trabajo realizado. Durante las últimas semanas del proyecto tendríamos que abusar de las horas extras y del estrés para entregar ese 20% que nos falta pero probablemente sólo consigamos que sufra la calidad del software que entregamos y que se se ignore la fase de tests del desarrollo apareciendo un montón de bugs después de la entrega.

Sunday, 12 November 2017

Cómo ser ágiles en proyectos de mantenimiento

Son habituales en la industria ciertos proyectos, denominados de mantenimiento, en los que el trabajo consiste no en desarrollar nuevas funcionalidades al producto sino en realizar correcciones a bugs o las tareas mínimas para lograr que el sistema esté activo y dando servicio las 24 horas.

Pero a veces la carga de trabajo es tan alta, o la organización del equipo no es todo lo eficiente que debería ser, que no hay tiempo para corregir estos problemas de raíz y en lugar de corregir el código que produce los bugs ponemos parches que dan una patada hacia adelante a los problemas. Tampoco tenemos tiempo para refactorizar el código y aumentarle su calidad de forma que el número de errores tan alto que se come todo el tiempo de desarrollo. El problema llega a ser tan preocupante que, incluso cuando nuestro contrato incluye tareas de mantenimiento evolutivo, la corrección de bugs nos consume todo el tiempo disponible evitando que añadamos más valor a nuestro producto.

Si intentamos usar Scrum para poner orden en esto probablemente no nos vaya a funcionar porque semana tras semana nuevas tareas de corrección de bugs nos asaltan de forma urgente en nuestra planificación del sprint impidiendo que lleguemos nunca a cumplirlo. Retomar el trabajo días después hace que tardemos aún más debido a los cambios de contexto y porque nos vemos asaltados de nuevo por más bugs urgentes. Las planificaciones de los sprints no serán nada fiables, el análisis hecho para las nuevas funcionalidades caducará o habrá que revisarlo y ningún sprint se cumple.

Yo utilizaría Kanban en lugar de Scrum en una primera fase de estos proyectos. El uso de Kanban conlleva un menor cambio cultural en el equipo de trabajo y en los clientes y una menor sobrecarga de reuniones pero sobre todo permite una mayor agilidad para dar entrada a tareas urgentes en medio de la carga de trabajo de la semana.

En este Kanban utilizaría tres códigos de tarjetas de colores: Rojo para las tareas de corrección de bugs, amarillo para las tareas que corrigen deficiencias técnicas y code smells en nuestro código y que están haciendo que el código sea difícilmente mantenible o están produciendo bugs de forma continuada. Por último utilizaría el color verde para las tarjetas que implican el desarrollo de nuevas funcionalidades.

Tampoco separaría el equipo en dos partes, uno para corregir bugs y otro para desarrollar nuevas funcionalidades. Hacer eso está reconocido como una mala práctica debido a que los equipos dedicados a los nuevos desarrollos no aprenden lo que pasa cuando se introducen errores y por otro lado se castiga a los equipos de mantenimiento a que sólo arreglan desaguisados y con prisas y tampoco crean nada nuevo que aporte valor y reconocimiento al equipo.

En un principio nuestro Kanban estará lleno de tarjetas de color rojo pero si logramos introducir nuevas tarjetas de color amarillo y subirles la prioridad a aquellas que solucionan un número alto de bugs, en un periodo prudente de tiempo deberíamos conseguir bajar el número de bugs que se están produciendo obteniendo tiempo así para añadir al Kanban más tarjetas amarillas o incluso verdes.

Con el paso del tiempo, nuestro tablero Kanban deberá mostrar un reportorio más amplio de colores en el que finalmente, con suerte, predominará el color verde. Para esto sirven los tableros visuales Kanban, para dar visibilidad a lo que está sucediendo en nuestros proyectos.

Es en este momento, en el que el equipo realiza sobre todo tareas de mantenimiento evolutivo, cuando podríamos volver a pensar en utilizar Scrum para nuestro proyecto bajando un poco el factor de dedicación para solventar aquellas tareas urgentes que nos llegan ahora con menor asiduidad.



Sunday, 5 November 2017

Error nº 9: Apretar demasiado en el objetivo del sprint

Es el equipo el que decide qué funcionalidades caben en un Sprint y cuáles no. Los miembros del Equipo de Desarrollo son los que mejor saben cómo se hace el trabajo y los que por tanto mejor pueden calcular si en el sprint caben seis u ocho historias de usuario o lo hacen a 10.

Si viene presión de fuera para que metan más cosas en el Sprint y que se comprometan a entregar más trabajo cuando realmente no lo ven factible, esto sólo puede hacer que se acumule el resentimiento o la desconfianza o que se fomente la baja calidad del trabajo para poder entregar a tiempo. Se sabe que cuanto más ridículos son los plazos de entrega más tiempo y dinero se malgastan en intentar conseguirlos.

Cuando se planea la cantidad de trabajo que podemos hacer, se planea un tiempo para las pruebas que necesitamos hacer y asegurarnos de que el trabajo es fiable. Se planifica también una cantidad de tiempo razonable para pensar y estructurar el desarrollo. Si falta tiempo para hacer estas cosas, la calidad del trabajo se resentirá y, más adelante, en próximos sprints o después de finalizado el proyecto, pagaremos esta deuda que hemos dejado atrás con intereses de demora convertidos en bugs que nos asaltarán en los momentos más inoportunos y que reducirán el nivel de satisfacción de nuestros usuarios.

Otra cosa es que el Equipo de Trabajo se sienta retado a conseguir más cosas dentro del Sprint y que se sientan con ánimo de conseguir mucho en poco tiempo. Si conseguimos un ambiente así, en el que los desarrolladores se comprometen por sí sólos al máximo alcanzable por ellos, habremos conseguido un gran objetivo y tendremos un gran equipo.

Sunday, 29 October 2017

Error nº 8: El Scrum Master reparte las tareas

Se trata de que los equipos de trabajo sean auto-organizados y se repartan ellos mismos las tareas. Ellos son quienes mejor saben cómo hacer el trabajo y cómo mejor repartírselo entre ellos. Si dejamos que el Scrum Master o el jefe de proyecto reparta el trabajo probablemente no quede balanceado entre todos los miembros del equipo quedando más peso en unos que en otros o se hayan asignado tareas a alguien que no tiene ahora las habilidades técnicas para resolverlo igual que algún otro.

Si dejamos que ellos mismos, los miembros del Equipo de Trabajo, se repartan las tareas a realizar, el trabajo quedará más repartido y ellos tendrán un sentimiento de reparto más justo. Se trata de que levanten la mano y digan ‘Esa tarea la hago yo’ o ‘Creo que quién mejor puede hacerla es Carolina’ a lo que Carolina puede responder ‘Quizás sí, pero ya tengo asignadas las tareas 14 y 16 ¿Qué tal si la hace Fernando? Ya lo hizo una vez y puede ir ganando más experiencia con eso’.

Sunday, 8 October 2017

Error nº 7: Reuniones diarias de Scrum demasiado largas

Esto suele suceder cuando las reuniones de la Daily Scrum se utilizan para resolver los problemas y las dudas que se están teniendo en el trabajo diario. Esta es una reunión que debe mantenerse muy corta y en la que sólo deberemos comentar lo que hicimos ayer, lo que se hará hoy y qué problemas nos estamos encontrando o vamos a necesitar solución.

Es en este último punto cuando todo el mundo tiene una posible solución y la comenta en la reunión por lo que ésta se alarga y alarga con los comentarios sobre un problema que quizás sólo atañe a una o dos personas y a que a las otras no afecta directamente por lo que se aburren y pierden un tiempo en el que podrían estar ya desarrollando.

Aquí el Scrum Master debería mantener bajo control estas reuniones para que no se vayan de tiempo y hagan perder el tiempo a todo el mundo. Siempre que una discusión sobre un problema comience, deberá emplazar esta discusión para otro momento en el que sólo intervengan las personas involucradas y quizás algún tercero que no está en la reunión diaria pero cuya opinión pueda ser importante.

Es esencial también que no olvidemos tener esa otra reunión para resolver el problema ¿Para qué si no se avisó de que había un problema? Si no puede resolverse durante la reunión diaria debe atenderse en algún otro momento del día o días posteriores para ponerle solución.