archivo

Archivo de la etiqueta: velocidad

La gestión de la capacidad, velocidad o carga de trabajo del equipo resulta esencial. Uno de los factores que más influyen en la pérdida de control es precisamente el intento de cumplir agendas imposibles.

Con mucho esfuerzo, siempre y cuando, exista posibilidad material de cumplir unos plazos, se pueden llegar a ofrecer unos resultados, pero, ¿a costa de qué?, ¿a costa de quién? Del producto y del equipo, ya que probablemente el sistema resultante tenga funcionalidades que no estén bien rematadas, tenga incorrecciones funcionales, numerosos bugs y la factura técnica sea francamente mejorable, a lo que hay que añadir el desgaste de las personas debido a la presión y al overtime.

Esto impacta en la entrega pero también en lo que queda de proyecto porque será necesario dedicar esfuerzo a “barrer” o “pulir” lo que fue mal mientras se está trabajando en lo nuevo.

Si no se ha reajustado la capacidad de trabajo asumible por el equipo, seguirá desbordado y lo más probable es que no cumpla con la mayoría de los compromisos y los que cumpla presenten deficiencias similares a los de la anterior entrega y se sigan acumulando flecos pendientes. Como una bola de nieve esto irá a más y más durante el transcurso del proyecto y si además se acumulan modificaciones funcionales serias sobre elementos ya desarrollados o hay cambios sensibles en el contexto del proyecto, se volverá absolutamente inmanejable.

Incluso con la intención de ajustar el trabajo a la capacidad del equipo podemos caer en la situación descrita si nos equivocamos a la hora de hacer ese ajuste, si bien, es posible a corto/medio plazo volver a una situación más equilibrada ya que gracias a este enfoque tendremos en cuenta ese esfuerzo de más que vamos a necesitar en cada iteración para lograr ese objetivo.

Se entiende que un equipo de proyecto irá incrementando la velocidad de desarrollo (volumen de trabajo que se puede afrontar en una iteración) hasta alcanzar una cierta estabilidad tras una serie de sprints (cambios en el equipo de proyecto ya sea de personas, en número, etc… afectarán a la velocidad, también cambios drásticos relacionados con el contexto de trabajo: tecnologías, entornos, metodologías, etc…).

Es bastante razonable que eso sea así salvo que la deuda técnica ofrezca cada vez una mayor resistencia.

Todo esto es teoría, si bien es la situación que se puede dar con mayor probabilidad.

Pero, ¿cómo medimos objetivamente el incremento de velocidad? Es decir, notaremos que el equipo puede afrontar una mayor cantidad de trabajo porque estimarán en menos tiempo el desarrollo o modificación de las pantallas, de la realización de informes, etc…, ¿pero cuánto realmente es esa mejora?, ¿en qué lo medimos?, ¿vale la pena el esfuerzo necesario para medirlo?.

Ahí estriba la dificultad porque lo ideal sería traducir los esfuerzos necesarios a una únidad genérica común, lo que en algunas metodologías se denominan puntos función, puntos por caso de uso, puntos por historia de usuario, etc… Esa traducción tiene un alto componente de subjetividad y se requerirá tiempo de perfeccionamiento conseguir una traducción con una cierta fiabilidad a esa unidad genérica común.

¿Invertimos esfuerzo en ello? Depende de en la fase en la que nos encontremos en la implantación de estrategias de desarrollo ágiles, si todavía no se tiene madurez (y para que exista se requiere tiempo) es mejor esperar a que se tenga una cierta estabilidad en la aplicación de estas dinámicas de trabajo de manera que el equipo tenga ya asimilados ciertos automatismos, una vez hecho eso, puede ser interesante empezar a medir.

No obstante, una cosa es medir en base a unidades genéricas y otra que no se haga un seguimiento de la velocidad en el sprint ya que resulta importante conocer (y eso se puede hacer con un esfuerzo mínimo) si el número de días de trabajo estimado para terminar los trabajos es congruente con la fecha de finalización del sprint por si fuera necesario (o posible) tomar alguna medida que permita reconducir desviaciones y/o gestionar las expectativas.

No rematar las tareas y arrastrar deficiencias en el producto constituyen una resistencia importante al proceso de desarrollo, afectando a la velocidad del equipo de desarrolladores y lo más importante, afectando al nivel de satisfacción de los usuarios.

Por ese motivo es fundamental que se tengan en cuenta en el proceso de desarrollo, ya sea dentro de la línea principal y/o como parte de un segundo equipo dedicado exclusivamente a resolver estos problemas, en base a las prioridades que se establezcan para las mismas.

Sobre este tema Mary Poppendieck realiza la siguiente reflexión: “La única forma de prevenir que se nos escapen defectos en el futuro es examinar los que se producen en el presente, metódicamente encontrar sus causas y, uno a uno, eliminarlos”.

El ritmo de desarrollo es muy importante, ya que condiciona la capacidad de adaptación al cambio del producto, ya sea provocado por el entorno o por las necesidades del usuario, por ese motivo, reducir la probabilidad de que se produzcan contingencias que afecten al funcionamiento continuo de la “maquinaria” resulta esencial.

Lo deseable es que el equipo coja velocidad de crucero desde el primer sprint, sin embargo es algo que resulta muy complicado salvo en aquellos proyectos en los que el equipo esté habituado a trabajar junto y/o con una orientación a sprint, esté perfectamente habituado a la tecnología de desarrollo y en donde las historias de usuario sean de calidad y fácilmente asimilables por los desarrolladores.

Lo más normal es que el equipo pueda asumir menos carga de trabajo al principio y la vaya aumentando conforme los factores anteriores se van asentando, hasta llegar a esa velocidad de crucero, que, ¿por qué no?, podría ir mejorando con el paso del tiempo.

Trabajar con agendas puede implicar un nivel de exigencia alto al equipo desde el primer sprint, un nivel de exigencia que se sitúa por encima de lo que el equipo puede dar en ese momento. Desde mi experiencia os puedo asegurar que no es positivo porque no asegura el adecuado cumplimiento de los compromisos (que esté programada una funcionalidad no es cumplir el compromiso, cumplirlo es que funcione y esté en disposición de pasarse a producción si así se considerase oportuno) y porque el equipo empieza a desgastarse desde muy pronto y eso afecta negativamente a los trabajos teniendo en cuenta que todavía queda mucho proyecto por delante.

¿Qué hacemos? Si se puede intentar adaptar la agenda a lo que el equipo puede dar e incrementar si se puede el equipo o la dedicación de las personas que ya participan en él (si hay personas que puedan incorporarse al equipo en donde su saldo de participación neto: lo que aporta menos lo que el equipo tiene que invertir para conseguir esos resultados es positivo o puede serlo a muy corto plazo y hay trabajo por delante que lo justifique).

Por tanto, es conveniente dejar que el equipo vaya adquiriendo paulatinamente esa velocidad de crucero, no hay que olvidar que tienen que cumplir unos compromisos, que ponen mucho en juego y que por tanto, ellos de manera responsable deben autogestionar la capacidad de trabajo que pueden asumir en cada momento.

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.