Ajedrez - antoniomartel.com

Archivos por Etiqueta: Agile

Error nº 14: Objetivos del Sprint inalcanzables

Lo que cabe dentro de un Sprint y lo que no es algo que decide el Equipo de Trabajo. Ellos son quienes mejor pueden calcular hasta dónde pueden llegar en esas semanas que dura el Sprint porque son ellos quienes saben hacer el trabajo. Si se les obliga a aceptar un alcance mínimo para entregar en ese tiempo lo que podríamos estar haciendo es forzarles a que disminuyan la calidad.

En todo proyecto hay siempre tres variables que están ligadas unas a otras. Es el llamado triángulo de hierro. Estas variables son:

  • Alcance: El conjunto de funcionalidades o tareas a realizar.
  • Coste: El presupuesto o el número de personas empleadas para desarrollar esas funcionalidades.
  • Tiempo: Lo que durará el proyecto.

 

Triángulo de Hierro en el desarrollo del software

Esto es, si tienes un alcance muy grande tendrás un proyecto muy grande con un coste alto y que durará bastante tiempo. Si por ejemplo, en un proyecto empleas a pocas personas para el mismo alcance tendrás un proyecto que se alargará en el tiempo. Estas variables están interconectadas por lo que si intentas reducir alguna de estas variables manteniendo fijas las otras será la calidad la que se resienta.

Si en cambio, como dice el título de este apartado, alguien externo al proyecto obliga a aceptar un alcance muy elevado en sólo un Sprint, estaremos ampliando el alcance pero dejando inmutables el coste (número de desarrolladores) y el tiempo. Con esto sólo conseguiremos que no lleguemos a cumplir el objetivo del Sprint o que lo hagamos con unos niveles de calidad inaceptables.

No pasará nada en un principio, todo irá aparentemente bien aparte del estrés para poder cumplir el Sprint, pero si la calidad ha bajado esto se terminará notando. Lo hará más adelante en forma de bugs o incidencias que irán apareciendo o de funcionalidades que no están bien pensadas o resultas y que son usables. Funcionalidades poco prácticas o incómodas de usar por los usuarios y que requieren más clics de los necesarios.

Si tenemos un objetivo del Sprint demasiado ambicioso, que ha sido impuesto desde fuera y que es inasumible corremos el riesgo de emplear el doble de trabajo que si lo hubiésemos repartido mejor entre más Sprints. Veamos por qué:

  • Los programadores tendrán que hacer multitarea para intentar acometer el alto número de tareas que tienen en ese Sprint. Lamentablemente nunca tenemos en cuenta la bajada de productividad que la multitarea supone.
  • Tendremos que dedicar tiempo a la corrección de bugs. No habrá tiempo ni para pensar y todas las tareas se acometerán a toda prisa: No hay tests, no se hacen pruebas, no se revisa la aplicación una vez está todo integrado y no hay tiempo de comprobar que todas las funcionalidades pedidas realmente se han hecho.
  • Debido a esto último, muchos bugs aparecerán más tarde, cuando se hagan las pruebas de aceptación por el cliente o cuando se ponga en uso la aplicación. Puede que algunos aparezcan meses o años después de entregado el código ¿Quién se acuerda ahora de por qué el código se hizo así? ¿Para qué eran esas funcionalidades? Se tardará mucho más tiempo en resolver esos bugs que si se hubiesen corregido en el mismo Sprint cuando se tenía aún fresco en la memoria el trabajo hecho. Se sobresaturó el trabajo en el Sprint y no quedó tiempo para hacer buen código y revisarlo después (o a la vez que se escribe). En el futuro pagaremos más por cada bug detectado, es mejor pagar la deuda técnica ahora que hacerlo luego con muchos más intereses.

Interrupciones urgentes que no nos dejan avanzar en el proyecto

A veces tenemos que manejar un montón de interrupciones para resolver problemas de mantenimiento, corrección de errores o soporte que hacen que no lleguemos al objetivo del Sprint porque nos llega una cantidad grande de tareas que no estaban planificadas al inicio del Sprint.

Lo primero que tendremos que hacer es verificar si esas interrupciones urgentes son en realidad tan urgentes como nos las pintan o nos hemos dejado llevar por el alarmismo de haber encontrado un error en producción.

Lo segundo que debemos hacer es ver cuál es la razón principal por la que tenemos tantas interrupciones y de forma tan constante ¿Se deben a la mala calidad del software? ¿Quizás debido a las constantes interrupciones? Quizás debamos dedicar algunos sprints a resolver la deuda técnica que hemos ido dejando atrás o a dar más estabilidad a las partes del software que más problemas están dando.

También hay otras cosas que podemos hacer:

Tener sprints cortos

Con esta solución mantendremos las tareas ya programadas en la planificación del Sprint. Al tener sprints de una o dos semanas de duración podremos incluir la tarea no planificada como prioritaria en la lista de cosas a hacer en el siguiente Sprint. Si el Sprint tiene una semana de duración tardaremos una media aproximada tres días laborales en comenzar a acometer la tarea urgente.

Esto funcionaría en un mundo ideal pero no todas las tareas pueden esperar varios días para ser solucionadas. El servicio entero podría depender de ella.

Factor de dedicación bajo

Si sabemos que con frecuencia nos llegarán tareas inesperadas que debemos resolver con mucha rapidez podemos bajar el factor de dedicación durante el Sprint para dar ‘hueco’ a la resolución de estos problemas.


Sabiendo que en cada Sprint el equipo tiene capacidad para resolver 10 puntos de historias programadas podríamos comprometernos a entregar solo 7 para que el equipo tenga tiempo de resolver las incidencias urgentes. De este modo no fallaremos un Sprint tras otro en entregar lo prometido.

En mi opinión esta solución puede ser útil en ciertos proyectos pero puede crear otro problema. Me explico: Habitualmente el factor de dedicación es del 75%, si lo bajamos para poder dedicar un 30% del tiempo del equipo a las tareas urgentes deberíamos aplicar un factor de dedicación del 40-50%. Sobre este 40% aplicamos Scrum pero ¿Cómo se está gestionando el resto del tiempo del equipo? ¿Qué sabemos sobre esa pila de tareas que estamos resolviendo Sprint tras Sprint?

Evitemos crear equipos sólo para dar soporte

Eso sería un anti-patrón a evitar en todo tipo de proyectos. Si creamos equipos que se dedican sólo a resolver bugs o errores encontrados en producción dejaremos al resto de equipos con las manos libres para centrarse en su trabajo sin interrupciones para llegar al final del Sprint pero esto puede hacer que cada vez aumente más el número de errores encontrados.


Los equipos necesitan hacerse responsables del trabajo que entregan y si no ven lo que se causa entregando código defectuoso porque otro equipo especializado se encarga de ello, estaremos fomentando que aparezcan más y más errores. Si ellos mismos tienen que corregir sus propios errores, terminarán dándose cuenta de lo importante que es la calidad para evitar desaguisados y de lo que tienen que hacer para construir software más robusto que evite tanto error.

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

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.

El Scrum Master y el Equipo de Desarrollo

El trabajo del Scrum Master no es el de jefe de proyectos ni es sólo el de servir de ayuda al Product Owner (que tampoco es el jefe de proyectos). En el trabajo diario del Scrum Master también debe ofrecer servicios de ayuda al Equipo de Desarrollo además de al Product Owner.

El más importante quizás sea el de eliminar impedimentos para el progreso del Equipo, es decir, ayudar en lo que el equipo necesite para tener su trabajo preparado y no tener que estar esperando por nada. Si por ejemplo se necesita solicitar una exportación de la base de datos antes de realizar algún trabajo, será trabajo del Scrum Master realizar estas gestiones para que el Equipo de Desarrollo lo tenga preparado a tiempo y no tenga que quedarse esperando a que esto se resuelva.

Otro de los puntos importantes en los que debe trabajar el Scrum Master es en el de guiar al Equipo de Desarrollo en ser autoorganizado y multifuncional. Los equipos de desarrollo normalmente esperan que alguien les asigne las tareas y a encargarse sólo de aquellas tareas que pone el título de su contrato. El Scrum Master debe intentar cambiar este paradigma haciendo que cambie esta mentalidad para que el Equipo de Desarrollo sepa elegir sus propias tareas (de acuerdo por supuesto a la priorización hecha por el Product Owner) y a encargarse de todas las tareas sin derivarlas a otros departamentos porque ellos son los especialistas (departamentos de administradores de bases de datos o de analistas para que ellos hagan el análisis o un import o export de bases de datos).

Entre los trabajos del Scrum Master también está el de organizar los eventos o reuniones de Scrum para facilitar que éstas sucedan. Deberá organizar la reunión diaria, la reunión de demo, la reunión de retrospectiva, procurar que todos asistan y que sea del máximo provecho para todos los interesados.

También deberá servir al Equipo de Desarrollo para ayudarlo a crear productos de alto valor que no quiere decir que tengan un nivel de calidad alto, que se da por supuesto, sino a que el Equipo de Desarrollo esté centrado en producir funcionalidades y características que le aporten el máximo valor o utilidad al producto que se está construyendo.

Por último, y no menos importante, el Scrum Master deberá guiar al Equipo de Desarrollo cuando éste no ha trabajado nunca con Scrum para ayudarles en su adopción y en que sea completamente entendido por todo el equipo.

Suscríbete