archivo

Archivos Mensuales: noviembre 2012

Esto de la gestión visual del flujo de trabajo, los daily scrum, los sprints, las retrospectivas, la programación por pares, etc… son vistos por muchos como un juego y no les culpo, yo también lo veía así cuando los árboles del enfoque clásico y su infinidad de problemas me impedían ver el bosque.

Y si quienes tienen que aplicarlas lo ven como un juego difícilmente van a funcionar. Este es uno de los principales problemas que tiene la aplicación de prácticas de estrategias o metodologías ágiles en los proyectos de desarrollo de software.

Quienes están acostumbrados a trabajar con enfoques clásicos con una orientación a producir entregables formales (sirvan o no) y a tener el proyecto clasificado en etapas diferenciadas y especializadas les va a resultar complicado ver esas prácticas como algo serio:

1) Durante años se les ha grabado a fuego que ingeniería de software es lo que ellos hacen (o que la forma de trabajar correcta es esa) y que cualquier cosa que salga de ahí no lo es.

2) También, durante años, se les ha dado el mensaje que el éxito en los proyectos de desarrollo de software está en los procesos y no en las personas. Por tanto, un enfoque en el que lo importante son precisamente las personas y su interacción y en donde las necesidades del producto predominan sobre el proceso, choca, porque se está abriendo la puerta a procesos abiertos en los que las prácticas, estrategias y herramientas se eligen en función de lo que el proyecto requiere (que no es incompatible con intentar armonizar un núcleo reducido de las mismas en diferentes proyectos) y porque no se van a trabajar con especificaciones cerradas sino que van a estar abiertas con el objeto de proporcionar al producto un mayor valor a través del feedback del área usuaria.

Sin embargo, si se echa un poco la vista atrás y vemos los resultados obtenidos en los proyectos en los que se ha trabajado con enfoques clásicos nos daremos cuenta de manera sencilla que algo falla porque el desgaste personal, el esfuerzo real y la inversión realizada en los proyectos no se corresponde con los resultados obtenidos. Sin embargo pese a esa evidencia muchos, muchísimos, siguen sin explorar otras alternativas, en unos casos porque piensan que el desarrollo de software es así, en otros porque no terminan de considerar tan negativos esos resultados y otros muchos que pese a que están convencidos de que esta dinámica de trabajo falla no consiguen sacar tiempo (o tener voluntad) para estudiar o formarse en otros enfoques de desarrollo de software.

También está el caso de quien quiere pero que no encuentra la oportunidad de poner en marcha estas estrategias, en estas situaciones digo lo de siempre, la agilidad es cuestión de actitud y eso está por encima de las circunstancias en las que tengas que trabajar en el proyecto. Lo mejor es tener la posibilidad de poder experimentar (con cabeza, siempre con cabeza y pensando en lo mejor para el proyecto) pero no siempre vamos a tener la oportunidad de ser nosotros quiénes elijan las condiciones en las que se va a realizar el proyecto.

También está el caso de quien quiere pero no se atreve, entiendo el temor, pero es importante darse cuenta de que los cambios deben hacerse de manera paulatina y que, por tanto, no se trata de introducir numerosas prácticas nuevas sino de ir haciéndolo poco a poco, hasta llegar a entenderlas bien. El primer paso lógico es la adopción de un enfoque iterativo incremental y empezar a crecer a partir de ahí.

En el artículo de ayer veíamos la necesidad de tener bien definidas las historias de usuario que van a formar parte de la pila de sprint, en el de hoy veremos una posible estrategia para conseguir esto.

¿Qué hacemos entonces? Mientras se trabaja en un sprint hay que estar preparando el siguiente, si trasladamos esto a una línea de producción, mientras las máquinas y sus operarios trabajan es necesario que alguien vaya a comprar y preparar las materias primas, de lo contrario se interrumpe el proceso.

¿Quién hace eso? Posibilidades hay muchas. Hay bibliografía que recomienda reservar entre un 5% y un 10% de la capacidad del equipo del sprint a realizar estas tareas o lo que es lo mismo, el equipo de sprint considera en cada iteración que tiene entre un 5 y un 10% de capacidad menos para asumir tareas. Estos límites pueden fluctuar en función del momento del proyecto en el que no encontremos a la vez que podrían sobrepasarse en el caso de que fuera necesario (y se tuviera en cuenta en la definición de la capacidad asumible en el sprint).

¿Mi opinión? Como siempre, os advierto que no hay soluciones únicas. Es fundamental que las tareas con mayor prioridad de cara al siguiente sprint estén lo suficientemente detalladas para que se pueda hacer una buena estimación y se pueda comenzar a trabajar con el objetivo de que la línea de producción pueda funcionar fluida y podamos cumplir los compromisos.

Por tanto no debemos quedarnos cortos a la hora de dedicar esfuerzo a esta actividad (que suele recibir el nombre de refinamiento de la pila de producto). Es posible que para conseguir ese objetivo tengamos que poner un cierto colchón de seguridad por si el proceso de definición es más complejo de lo que parecía (algo que es, por otro lado, bastante frecuente), desde mi punto de vista es mejor que no se llegue a ese tope y corramos el riesgo de “tirar” capacidad (algo que no tiene por qué ser así porque ese tiempo extra lo podría dedicar a echar una mano en el sprint en curso ya que siempre hay tareas que hacer y nunca está de más contar con ayuda extra) que poner en riesgo los compromisos del sprint o lo que es lo mismo, perder más tiempo por bloqueos en el proceso de desarrollo motivados por no tener todos los “ingredientes” necesarios para trabajar.

Con esto estoy diciendo que quien realice esa tarea (que podría ser siempre el mismo o no) es parte del equipo, es decir, sufrirá o se beneficiará de la calidad de su trabajo, de esta manera evitamos antipatrones del tipo “arrojar al otro lado del muro”. Esto implicará que parte de su dedicación (prevista y cuantificada en cada iteración) tiene que estar en el sprint y ser tenida en cuenta la hora de definir los compromisos.

Por tanto, estoy de acuerdo con lo que indica la bibliografía pero no tanto en los porcentajes que expresa porque me parecen demasiado optimistas sobre todo para proyectos que empiezan.

Otro aspecto que resulta complicado de entender cuando se comienza a trabajar con prácticas basadas en Scrum es cómo se va poder realizar una estimación con calidad en la reunión de definición de la pila de sprint sobre historias de usuario que están descritas a muy alto nivel.

Es más fácil de entender en contextos donde el equipo tiene un conocimiento importante del producto y tecnología sobre la que se desarrolla y las tareas se basan en evoluciones de componentes o pantallas ya desarrolladas. Sin embargo, en los primeros sprints o en situaciones donde se incorpora funcionalidad adicional a las ya existentes (nuevos módulos) se necesita tener una definición más detallada de las historias de usuario.

Si el equipo de proyecto se compromete a tener terminadas (listas para un hipotético paso a producción) las tareas definidas en la pila de sprint al final del mismo, es fundamental que acierte en las estimaciones y para hacerlo resulta importante tener lo suficientemente desarrollada la historia de usuario antes de empezar a trabajar con la misma, de lo contrario se tendrá que invertir tiempo de sprint en hacer ese trabajo y lo mismo resulta que lo que quiere el product owner es más complejo de lo previsto (se pierde tiempo en perfilar la historia de usuario y el exceso de complejidad sobre lo previsto se come capacidad del equipo en el sprint), lo que hará que probablemente no se puedan cumplir con los objetivos definidos.

Si de manera recurrente se incumplen los objetivos perdemos confianza en el esquema de trabajo y la predecibilidad que estamos buscando dentro del contexto del sprint. Esto quiere decir que algo falla y en este caso es que las historias de usuario no están lo suficientemente definidas al comienzo del sprint. Es importante hacer una diferenciación entre consultar detalles al product owner algo que resulta del todo razonable y otra hacer un análisis más en detalle en pleno sprint.

En el artículo de mañana veremos una posible solución a este problema.

Cuando se comienza a trabajar con prácticas basadas en Scrum, uno de los aspectos que más llama la atención a los desarrolladores es cómo se va a tener una pila de producto si todavía no se ha comenzado a analizar el mismo, es decir, si todavía no se sabe muy bien qué se va a hacer y el product owner no lo tiene muy claro, ¿cómo vamos a poder definir tareas?.

Esto hace que una de tus primeras impresiones sea que las prácticas de Scrum solo son válidas en contextos relacionados con el mantenimiento de sistemas de información o en procesos de desarrollo en los que ya se ha comenzado a trabajar con el producto.

Pues no, estas prácticas podrían ser válidas también para aplicaciones que se inician desde cero (otra cosa es que sea la mejor solución en todos los casos) pero requieren, como es lógico, una fase inicial de contextualización del sistema de información que permita a grandes rasgos obtener una primera visión de las expectativas del usuario, de lo que va a ser el producto y se defina la arquitectura y tecnología del sistema.

No se trata de una análisis en detalle y/o completo (ni se quiere, ni se pretende), sino de delimitar el sistema para determinar la mejor forma de abordar su desarrollo. Solo se entraría en más detalle en aquellas tareas que se consideren más prioritarias teniendo en cuenta la capacidad de trabajo (velocidad) absorbible en cada sprint, por lo que como mucho nos deberíamos centrar en lo que sería el primer sprint y tal vez el siguiente (abordar más de entrada significaría retrasar el inicio de las iteraciones corriendo el riesgo, además, de que se trabaje en balde porque puede haber aspectos que varíen una vez que el product owner empiece a analizar de manera tangible las ideas abstractas que tenía en la cabeza).

En el artículo de ayer analicé el tratamiento de las incidencias en un enfoque iterativo incremental cuando las mismas se han detectado en el entorno de producción y se está trabajando en un sprint. En este voy a analizar el tratamiento de las incidencias que aparecen como consecuencias del trabajo que se está realizando en la iteración.

Estas incidencias pueden tener una doble naturaleza: ser resultado de actividades de la iteración (se desarrolla un componente o una pantalla y no funciona bien, se producen efectos colaterales, etc…) o bien ser el resultado de descubrir bugs no relacionados directamente con el sprint y que se han detectando haciendo tareas de testing sobre elementos del sprint.

Como en el caso anterior, resulta complicado dar una receta (no hay tallas únicas).

Mi opinión es que si las incidencias son sobre tareas de la iteración se deben corregir en la iteración, siguiendo el objetivo de que el producto resultante del sprint debería estar en disposición de ser entregado (pasarse a producción), de lo contrario no estamos terminando adecuadamente las historias de usuario y estamos huyendo hacia adelante empujando estas incidencias a futuras iteraciones.

Si las incidencias son externas a la iteración tenemos que evaluar el contexto en el que nos encontramos, es decir, ¿la resolución de la incidencia es sencilla y no impacta en el sprint?, se abordaría sin más, en caso contrario, ¿hay una línea de trabajo dedicada a resolver incidencias? Si la respuesta es afirmativa se crearía una entrada en la pila de tareas pendientes de ese equipo, ¿no existe esa línea?, ¿es crítica? el equipo tendrá que decidir (consultando al product owner) si la trata en la iteración, lo normal es que así sea, lo cual provocará probablemente que alguna tarea de las previstas para el sprint no se lleve a cabo (de ahí la necesidad de informar al responsable funcional).

En un enfoque iterativo incremental hay diversas formas de gestionar las incidencias. Vamos a considerar dos tipos de incidencias y las analizamos por separado: las que se producen sobre la aplicación en el entorno de producción y las que aparecen en la iteración en la que estamos trabajando.

En este artículo vamos a analizar el primer caso, en el artículo de mañana, el segundo.

En función de la criticidad e impacto de cada incidencia se puede decidir incluirlas en la pila de producto para ser tratadas en iteraciones sucesivas o bien trabajar con ellas dentro de este ciclo. En este segundo caso puede impactar sobre los objetivos del sprint porque las historias de usuario y tareas sobre las que se trabaja están adaptadas a la capacidad (velocidad) del equipo de trabajo y esas tareas de más implican que el equipo debe incrementar la velocidad para cumplir los objetivos, a veces se podrá (pero cuidado con la calidad de los resultados) y otras no será suficiente e implicará que alguno de los hitos de la iteración no se puedan ejecutar, salvo que se decida prolongar la duración del sprint.

No estoy hablando de metodologías concretas sino de un enfoque iterativo incremental y que cada cual lo gestione cómo crea que conviene mejor al proyecto y es mejor. Con respecto a retrasar la fecha de finalización del sprint yo no soy partidario, aunque en determinadas situaciones puede ser la mejor opción (no tenemos que encorsetarnos, nos debemos a los proyectos no a las metodologías).

Si se decide trabajar con incidencias dentro de este ciclo existe la posibilidad de tener una persona (o un conjunto de ellas) que se dediquen a corregir las mismas, “fuera” del equipo de personas que trabajan en el sprint. Lo pongo entre comillas porque perfectamente pueden ir rotándose con personal del equipo “principal” o ser parte de hecho de ese equipo principal pero no computarse su esfuerzo en la capacidad del equipo de trabajo (la rotación podría ser incluso dentro del mismo sprint).

El resultado del trabajo de estas personas podría sincronizarse con el sprint, conformar un sprint independiente o simplemente empaquetar incidencias corregidas y decidir el mejor momento para pasar a producción (sin sincronizarse con el sprint o adoptar un enfoque iterativo).

Estas personas podrían ayudar al equipo de desarrollo del sprint en caso de que no entrase suficiente carga de trabajo como consecuencia de incidencias.

No ayuda nada obviar el contexto en que se realiza el proyecto bien puede ser por falta de experiencia o por el contrario por pensar que se tiene la solución para derribar todas las puertas (martillo de oro) lo primero se cura con el tiempo (una vez que te recuperas de las caídas que has tenido y si realmente haces retrospección de tus actuaciones y decisiones) de lo segundo también, si bien, resulta algo más complicado ya que supone bajar de las nubes en la que estemos instalados… y es que se está tan bien allí arriba.

Jim McCarthy realizó la siguiente reflexión: “Decir que quieres algo implica que estás dispuesto a cambiar para conseguirlo. De lo contrario, realmente no lo quieres”.

Me parece interesante ya que representa el cambio de actitud necesario cuando con la actual no consigues nada (o incluso empeoras la situación) y por extensión la necesidad de adaptarte al cambio porque no siempre te va a caer todo en las manos (por mucho que pienses que sabes colocarte bien).