En potencia todo, salvo el papel en blanco (y seguro que conocemos casos donde se han realizado estimaciones con un nivel de conocimiento del trabajo a realizar que se aproxima muy mucho a ese papel en blanco), es estimable, sin embargo, lo que queremos son estimaciones que se ajusten lo máximo posible a la realidad y para ello se requiere que cada historia de usuario esté lo suficientemente desarrollada como para conseguirlo.

Vuelvo a insistir en lo que comenté en el artículo de ayer, suficientemente desarrollada no es lo mismo que absolutamente detallada y/o llena de formalismos, sino que se adapte a lo que el proyecto (y su contexto actual) necesite.

Otra cosa es que nos equivoquemos en la estimación, cosa que sucederá sobre todo en los primeros sprints y/o hasta que se tenga dominada la tecnología y entorno sobre el que se va a desarrollar.

¿Para que sirven entonces las reuniones de planificación de sprint? Para terminar de perfilar el sprint. ¿No se hacen todas las actividades necesarias para poder estimar? La base son las historias de usuario y aunque puedas invitar al product owner a participar y aclarar dudas con él, cuando el proyecto se encuentra en una fase inicial o se incorporan funcionalidades con una cierta complejidad, no da tiempo en una reunión de planificación de sprint a tener lo suficientemente claro el alcance de la tarea por lo que la estimación corre más riesgos a lo que hay que sumar las consultas que de forma más que probable habrá que hacerle al product owner durante el sprint y que podrían bloquear determinados trabajos si no se han resuelto antes de que esas tareas se lleven a cabo.

Aplicando prácticas de Scrum y si me apuráis, por puro sentido común, tenemos que tener como objetivo que el resultado de cada sprint sea una versión entregable y por tanto, que se pueda pasar a producción.

Es muy importante desarrollar con intención para reducir el número de iteraciones (o dicho de otra forma para ganar en cantidad de trabajo efectivo por unidad de tiempo o lo que es lo mismo para ganar en productividad), para ello debemos minimizar (siendo el objetivo máximo eliminar), el número de componentes (funcionalidades) defectuosas que llegan al final del sprint (y por extensión a producción).

Para ello cada historia de usuario debe estar completamente terminada. ¿Qué es eso? Desde luego no es programar las tareas en que se descompone la historia y hacer cuatro pruebas, sino de tener la certeza de que efectivamente funciona, lo que implica una buena batería de testing y la verificación de que efectivamente cumple con las expectativas del usuario.

Una primera aproximación a esto último son las medidas para verificar la misma que aparecen en la historia de usuario, en las cuales tenemos que minimizar las ambigüedades para poder dar por bueno o rechazar la misma, ya que no debería haber medias tintas.

Estas medidas pueden estar implícitas en la propia descripción de la historia o separadas en un apartado diferente de la misma.

Otra cosa es que después, el product owner o por extensión los usuarios, se den cuenta de que la especificación realizada no satisface sus expectativas, en este caso el problema está en la especificación y para solucionarlo se requerirá evolucionar (modificar) esa funcionalidad en uno de los siguientes sprints.

Los presupuestos fijos en los proyectos sobre una base de funcionalidades que hay que desarrollar (y que son o pueden ser innegociables) dan lugar a fuertes desviaciones en las previsiones iniciales que se pueden ver reducidas o acentuadas en función del conocimiento del negocio, tecnología y de las personas (componentes de los stakeholders) que van a participar en el proyecto y de la materialización o no de los riesgos previstos e imprevistos.

Cuanto mayor sea la incertidumbre más probabilidad hay de que las estimaciones sean erróneas. Por tanto, cuanto más cerca estemos del inicio del proyecto, más probabilidad de error habrá.

Mike Cohn lo cuantifica de la siguiente manera (traducción libre): “Durante la fase de estimación de la viabilidad de un proyecto la estimación realizada se sitúa entre el 60% y el 160%”.

Sobre esa afirmación se podría pensar que todos los proyectos están abocados al desastre. Tal vez quien piense eso no anda muy mal descaminado, sobre todo si el proyecto se realiza en un contexto de inflexibilidad en el que las distintas partes no se centran en el problema: que es desarrollar un producto software de la mayor calidad posible teniendo en cuenta los recursos disponibles.

¿Qué es ese contexto de inflexibilidad? Este es el presupuesto y esto es lo que hay que hacer, no hay posibilidad de negociación ni voluntad de analizar las causas que han dado lugar a esa situación.

Es importante que tengamos en cuenta lo que nos dice el Manifiesto Ágil al respecto: “Se valora la colaboración con el cliente, por encima de la negociación contractual”, a lo que habría que añadir también que “Se valora la colaboración con el proveedor, por encima de la negociación contractual”.

Y es que las causas hay que analizarlas con el objeto de determinar cuál o cuáles han sido los orígenes de esta situación porque en base a eso hay que dialogar y negociar. Generalmente los problemas de ese diálogo o de esa negociación lo tenemos también como consecuencia de una situación de inflexibilidad y la negativa a reconocer errores por parte del cliente y del proveedor.

Dado que el desarrollo de software es evolutivo soy de la opinión de que el presupuesto en un proyecto debe evolucionar de la misma manera que lo hace el software teniendo siempre presente el cliente y el proveedor el coste de cada actuación. Sobre esta materia recomiendo leer la serie de artículos sobre Contratación ágil que escribí hace un tiempo.

Todas las medidas que supongan un obstáculo a la comunicación entre los componentes de un equipo de trabajo o entre equipos de trabajo diferentes suponen una resistencia importante al proyecto de desarrollo de software.

Se pueden establecer ciertas reglas orientadas a conseguir un mayor orden y una comunicación más eficiente pero es necesario evitar todas aquellas que creen entre personas y equipos que den lugar a que la comunicación sea mayoritariamente asíncrona (cuando no prácticamente inexistente) provocando un distanciamiento entre los equipos (no se trata de un hecho físico ya que pueden estar distanciados equipos que incluso trabajan en la misma sala), la aparición de antipatrones como: “Arrojar al otro lado del muro y que las funcionalidades se desarrollen o las decisiones se tomen sin contar con toda la información disponible lo que dará lugar a unos mayores costes debido al más que probable incremento del número de iteraciones necesarias para tener el producto.

A veces la comunicación se deteriora por conflictos entre personas o entre equipos que provocan que como medida de autodefensa se pongan como un escudo que dificulta o impide la comunicación. Por el bien del proyecto y de las personas que participan en él este tipo de situaciones hay que atajarlas cuanto antes y no dejarlas ir porque cuando se entra en enfrentamientos personales los mismos no terminan por arte de magia cuando acaba el proyecto.

También los gestores cuando no tienen una visión global tienen mucha que ver con el aislamiento de los equipos de trabajo.

Frederick Brooks en su libro “The Mythical Man Month” comenta lo siguiente: “Entonces, ¿cómo se comunicarán los equipos unos con otros? De tantas formas como sea posible”.

No hay mejor formar de gestionar las expectativas del área funcional o del cliente que evitando las sorpresas. Es como jugar a las cartas conociendo las del resto de jugadores y eso debería ser un proyecto de desarrollo de software, un conjunto de personas, equipos y organizaciones que trabajan con respecto a los demás de forma transparente (y esto es perfectamente compatible con los intereses particulares o de empresa que puedan existir).

En los proyectos en los que trabajo tengo como objetivo minimizar las sorpresas, gestionando de esta forma las expectativas del área usuaria desde el mismo momento en que puede haber un cambio en las mismas. Casi nunca gusta que acortes alcances pero te aseguro que es mucho mejor negociar en esas circunstancias que cuando, sin margen de reacción, no cumples los compromisos con el usuario.

La confianza es fundamental en el desarrollo de software y más en proyectos con la intensidad que requieren los enfoques iterativos incrementales, por ese motivo es absolutamente necesario gestionar las expectativas, modularlas a la realidad del proyecto.

Ocultar el estado real del proyecto o de un sprint no sirve para nada porque al final, más pronto o más tarde se termina descubriendo el pastel, tal vez todo salga a la luz después de haber terminado los trabajos, pero esa huida hacia adelante termina pasando factura si quieres volver a seguir trabajando con ese cliente.

Una de las claves para sacar adelante cualquier trabajo (y un proyecto no es más que un tipo de trabajo más), con su complejidad y sus características inherentes, es dividirlo en una serie de tareas que sean manejables: divide y vencerás.

El enfoque clásico o predictivo supuso el primer avance en ese sentido, si bien lo que hizo fue darle formalidad a lo que carecía de ella porque la división en tareas más simples en el desarrollo de software existe desde sus mismos inicios.

Esa división en procesos, actividades y tareas la podemos ver en Métrica v3, en versiones anteriores, en cualquier otra metodología basada en enfoques clásicos o en las propias definiciones genéricas de esa estrategia.

El inconveniente que se plantea es que divide en partes las actividades pero no el producto. Sobre esa aproximación inicial surgieron nuevas estrategias que tenían como objetivo descomponer el producto en partes y sobre cada una de ellas realizar una división de las actividades. Esto dio lugar a enfoques de tipo teórico como los desarrollos en espiral o más tangibles como los desarrollos iterativos incrementales.

Con este tipo de estrategias se puso en primer plano los conceptos de feedback y retrospectiva: conocimiento adquirido como consecuencia de la experiencia sobre versiones reales del producto (ya sea en producción o no) y la mejora continua de las prácticas y enfoque del proyecto.

El siguiente paso fue hacer que la descomposición del producto fuera en trozos más pequeños definiéndose para ello sprints de duración fija o variable pero que en cualquier caso iban a ser de corta duración. En este contexto el feedback y la retrospectiva ganan en intensidad, se realizan cada poco tiempo y el producto está preparado para adaptarse al cambio.

En esta evolución se ha pasado de la especificación del producto a su visión: se tiene una colección de tareas a realizar que se va modificando conforme avanza el proyecto y solo se estudian en detalle cuando se está preparando la siguiente iteración.

La tentación, muchas veces motivada por las circunstancias, es obviar la mejora de la factura técnica del producto, para centrarnos en corregir errores y en incrementar las funcionalidades.

El usuario siente la calidad del software con lo que ve: cumplimiento de sus expectativas de funcionamiento y buen rendimiento y disponibilidad, por eso pondrá resistencia a invertir tiempo en reducir la deuda técnica.

No debemos olvidar que desarrollamos para el usuario y él es quien tiene la última palabra, lo cual no quita que le expongamos la ventaja que tiene la realización de este tipo de tareas, como una inversión que permita no solo incrementar la capacidad de trabajo que puede abordar el equipo, sino además, reducir la posibilidad de efectos colaterales que provoquen errores cuando y donde menos los esperamos.

De serie, un desarrollador debe tener en cuenta estas prácticas y tenerlo en cuenta a la hora de definir su velocidad. El tiempo que se puede dedicar a esto puede ser prácticamente ilimitado porque todo es susceptible de ser mejorado, por ese motivo, ese tiempo de más sobre las buenas prácticas de programación cotidiana es el que se tiene que discutir con el cliente.

Comenta Mary Poppendieck: “La refactorización continua no es opcional. Si se elige no refactorizar se elige no pagar la deuda técnica que con el tiempo demostrará que la posibilidad de fracaso aumenta”.

La clave es mantener la deuda técnica bajo control y esto requiere un esfuerzo desde la programación de base como de las tareas adicionales de refactorización, de acuerdo siempre con las necesidades de quién paga, el cual debe estar siempre informado de las consecuencias que tiene realizar desarrollos sobre un software de baja calidad.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 3.200 seguidores