Ajedrez - antoniomartel.com

Archivos por Etiqueta: Agile

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.

El tamaño del Equipo de Desarrollo

Lo que nos indica la guía de Scrum como mejor tamaño del Equipo de Desarrollo (no el Equipo de Trabajo, sólo el Equipo de Desarrollo, es decir, sin contar con Scrum Master y Product Owner) es de tres miembros cuando menos y nueve como tamaño máximo.

La idea es tener un equipo lo suficientemente pequeño para ser ágil pero que puedan entregar al final de cada Sprint una cantidad de trabajo que merezca la pena como para ponerlo en producción. En cambio no se quiere que tenga un tamaño tan grande, mayor de 9, que haga que se multipliquen las interacciones en el equipo y que haga difícil la coordinación entre ellos.

¿Para un Equipo de Desarrollo de sólo una o dos personas merece la pena Scrum? Estaríamos añadiendo un overhead o sobrecarga de reuniones y ceremonias que podría dificultar la normal marcha del trabajo haciendo perder tiempo al equipo. En mi caso personal, para equipos de estos tamaños aún así he intentando ser ágil siguiendo sólo cuatro principios básicos de Scrum para obtener el máximo de sus ventajas sin sobrecargar de reuniones que podrían ser inútiles al ser tan pequeños. Por ejemplo, mantener la reunión diaria, la reunión de demo, el Sprint y las Pilas de Producto y de Sprint.

En cambio, yendo hacia el lado contrario, tener 10, 11, 12 o más miembros en un Equipo de Desarrollo podría requerir demasiada coordinación y demasiadas reuniones para ponerse de acuerdo entre todos. Si se van a auto-organizar ese tamaño va a llevar demasiada complejidad como para repartirse tareas y coordinarse sin que haya un seguimiento estricto de qué hace cada uno o las dependencias entre el trabajo entre unos y otros y qué tiene que estar listo primero para que el otro pueda avanzar.

El Dueño del Producto y el Scrum Master no cuentan como miembros del equipo de desarrollo a menos que también estén trabajando en la lista de cosas pendientes a acabar dentro del Sprint. En ese caso sí son contados como miembros del Equipo de Desarrollo sumando una o dos personas más según sea el caso.

Hay estrategias para el escalado de Scrum (estrategias para cuando el proyecto es tan grande que un sólo equipo no puede con todo) como DAD (Disciplined Agile Delivery) que no son tan estrictos con los tamaños de los equipos y no prescriben unos tamaños límites mínimo o máximo tan cerrados como estos.

SI QUIERES CONTRATAR MIS SERVICIOS PUEDES ENCONTRARME EN:

Tel: +34 690317539
Skype: antoniomartel
admin@antoniomartel.com

Haz clic en la imagen para obtener tu copia del libro gratis

Conéctate

facebook twitter google linkedin rss youtube