Retrospectiva de estrella de mar (Starfish retrospective)

Autor: Gustavo Veliz Bernaola

Un bien amigo agilista tuvo a bien enviarme un mail sobre una forma de llevar retrospectivas que desconocía. La Starfish retrospective tiene ciertas ventajas frente a la forma “clásica” de llevar retrospectivas, es decir la de solo llevar las cosas como “lo malo” y “lo bueno”.

Las retrospectivas son inmensamente provechosas para cualquier tipo de proyecto sea personal o empresarial.

Algo de reflexión sobre las retrospectivas y su importancia la podemos aprender de la siguiente referencia: dont-forget-to-sharpen-the-saw

Ahora, si ya sabes que es una retrospectiva y estás convencido de su importancia, entremos más en materia.

Una de las ventajas de las retrospectivas es que nos ahorran tiempo al momento de tener un feedback del equipo del trabajo. Pero esta no es su única ventaja, también nos permite ver y exponer problemas o ventajas que de otras maneras serian muy difíciles.

Es en este contexto donde Starfish retrospective entra a tallar, bajo el siguiente esquema:

StarTechnique

Se coloca en una pizarra o donde crean apropiado. Un ejemplo:

starfishRetrospective

Ahora ¿Qué significa cada parte?. Pues me tomó algo de tiempo pero aquí va:

Empezamos por

Start Doing: Aquí van todas aquellas cosas innovadoras o que por cierta curiosidad queremos probar. O tal vez son soluciones comprobadas que notamos que deberíamos usar. Por ejemplo usar una wiki para la comunicación o repositorio interno.

More of: Este paso personalmente considero que será alimentado por el anterior en las siguiente retrospectiva (espero). Es decir que los [Start Doing] se convertirán en [More of]. Esto significa aquellas cosas que estamos usando o haciendo y que queremos que mejoren. Son practicas que creemos que requiere mas refinamiento y que nos gustan mucho por ello hay que darles mas.

Keep Doing : Como secuencia lógica aquello que fue un [More of] llegaría a un nivel de maduración y se convertirá en [Keep Doing]. Es aquello que venimos haciendo y que nos brinda valor. Debemos seguir haciéndolo pero no será preocupación mejorarlo. Está bien como esta.

Less of: En este punto ponemos aquello que tal vez en una retrospectiva fue [Start Doing] pero no nos genero el valor que queriamos. Aquello que intentamos pero no nos dan tanto beneficio como se esperaba. Está bien, démosle como una segunda oportunidad, pero no esta en nuestras prioridades. Tal vez no nos funcione. También puede ser el quitar una parte de una práctica como el reporte de horas mensual o cosas por el estilo, es decir, obligatorias de cumplir pero no nos aportan valor. Y es ahí donde seguimos con el

Stop Doing: En este punto exponemos aquellas practicas que a pesar de ser [Less of] pues podemos eliminarlas. Cuando el equipo ve que no le da valor o simplemente no le gusta una practica puede optar por eliminarla.

Como vemos Starfish retrospective nos permite ver der una manera evolutiva nuestras retrospectivas. Un análisis periódico de nuestros Starfish nos permite ver la evolución del proyecto y la resolución de problemas. Objetivo que era mas difícil de conseguir mediante las retrospectivas tradicionales.

Espero lo apliquen y dejen sus comentarios de como les fue. De manera personal me encantó y me ha dado buenos resultados.

Lugar donde conocí Starfish retrospective: http://www.thekua.com/rant/2006/03/the-retrospective-starfish/

Nota: La retrospectiva de estrella de mar es interesante por que tiene un apartado específico para incentivar probar cosas nuevas e innovar, pero tiene una carencia importante: no hace que el equipo identifique las cosas que están funcionando, con lo que puede quedar una sensación demasiado negativa de que las cosas no van bien. Para solucionarlo, o bien se hace esta pregunta de aspectos positivos al principio de la retrospectiva, o bien se puede alternar con otros formatos de retrospectiva (e.g. «Retrospectiva Pluses y Deltas» ). Por esta misma razón, para iniciar a un equipo en retrospectivas, es recomendable comenzar con «Pluses y Deltas», arreglar los impedimentos ya bien conocidos por el equipo y, tras algunas iteraciones, pasar a otros formatos que ponen una visión más hacia el futuro.

Artículos relacionados

Introducción a la estimación y planificación ágil

Autor: Xavier Quesada Allue

 

Saber estimar y planificar es fundamental a la hora de encarar proyectos donde el producto necesita de un grado importante de creatividad y/o innovación, como por ejemplo los de desarrollo de software. En este artículo, presentamos algunos principios y prácticas introductorias para aprender a estimar y planificar un proyecto ágil.


Una de las características de la gestión de proyectos ágiles es el ser una actividad adaptativa en vez de predictiva. No es extraño, entonces, que los procesos de estimación y planificación en un proyecto ágil sean radicalmente diferentes a los de un proyecto tradicional.

En un proyecto tradicional, el proceso es relativamente lineal: se estima el producto a desarrollar (generalmente haciendo un desglose por etapas); se planifica el desarrollo (con la consecuente transformación de lo que antes eran estimaciones en compromisos); y luego se procede a ejecutar el plan, que por supuesto debe cumplirse al pie de la letra. Cuando las cosas comienzan a atrasarse (y siempre lo hacen) empiezan las complicaciones.

El problema fundamental de la planificación tradicional es que trata al desarrollo de software como una actividad predecible, cuando no lo es. Y este problema fundamental es lo que intenta atacar la estimación y planificación ágil. El desarrollo de software es una actividad de creación y transmutación de conocimiento. Como tal, no puede ser predicha ni estimada en forma precisa. El primer paso hacia la planificación ágil es la aceptación de este concepto.

Pero pocas organizaciones están dispuestas a embarcarse en un proyecto sin tener siquiera una idea aproximada de cuánto va a costar o cuándo va a estar terminado el producto. Si esto fuera aceptado, podríamos dedicarnos directamente a producir sin ningún tipo de estimación o planificación (lo cual tal vez no sería mala idea).

Entonces, cómo encarar la estimación y planificación de algo que no sabemos predecir?

Bueno, empecemos por refinar un poco qué significa no poder predecir el tamaño del producto. En la práctica, cualquier desarrollador senior puede dar una idea del orden de magnitud de un proyecto. Esto nos brinda lo que en inglés se denomina ballpark figure, un número grueso que nos permite ir pensando si es negocio desarrollar el producto o no. Y es lo primero que debe hacerse, ágil o no ágil. Las probabilidades de estar equivocados en un órden de magnitud son realmente bajas (en ese caso, por favor reconsiderar el titulo de «senior» de los desarrolladores). En mi experiencia, los proyectos tradicionales suelen excederse de sus estimaciones originales en numeros que van del 30% al 300%. Esto es lo que intentaremos mejorar con la técnica que explicaremos a continuación.

Las metodologías ágiles implementan muchos conceptos de Lean, el sistema de producción de Toyota. Uno de ellos es small batch sizes, que significa producir valor en lotes pequeños. El desarrollo tradicional, con sus etapas, produce todo el valor (el proyecto) en un solo lote. En todo momento, el 100% del proyecto está siendo procesado y 0% ha sido terminado. Finalmente se llega al «Dia D», el «Big Bang», donde todo el proyecto es entregado de un saque. Los métodos ágiles, por contraste, buscan entregar valor incrementalmente. En el caso del desarrollo de software, esto se consigue agregando funcionalidad en cada iteración y manteniendo siempre el producto funcionando con la funcionalidad que haya sido implementada hasta ese momento.

Objetivos como historias de usuario

Siguiendo esta línea, el primer paso en la estimación y planificación ágil es la creación del product backlog, o sea la definición del proyecto a realizar. Se puede dividir en objetivos expresados como historias de usuario (user stories), cada una aportando valor de negocios incremental e individual. Una historia es un requisito de negocio visto desde el punto de vista de un usuario. Se escriben con el siguiente formato: «Como xxx, quiero hacer yyy con el objetivo de zzz«,  donde, xxx es el tipo de Usuario (quien), yyy es lo que el sistema debe permitir realizar (el qué) y zzz es el beneficio o valor buscado (el por qué).

Ejemplo:
«Como cliente del banco, quiero pedir un préstamo para poder comprar una casa» .

tarjeta-historia-usuario-scrum-backlog

Las condiciones de satisfacción de los objetivos suelen ponerse en forma de criterios de aceptación, pruebas que se realizarán para verificar si el sistema se comporta de la manera esperada. Para ello se puede utilizar la sintaxis de BDD (Behaviour Driven Development) siguiendo el siguiente formato: «Dado aaa, cuando se produzca bbb, entonces ccc«, donde aaa es la situación en la que se encuentra el sistema, bbb es un evento que lo hará cambiar y ccc es el resultado. Esta técnica permite evitar la aparición de errores por malos entendidos y evitar retrabajar (siguiendo los principios Lean). Por ello es recomendable no empezar a desarrollar en una iteración sin antes haber escrito los casos de prueba, especialmente por que es más barato escribir texto y pensar en cómo desambiguar los requisitos que arreglar errores importantes debido a su mal entendimiento.

Pero en la práctica no hace falta usar estos formatos, cualquier sintaxis donde la acción sea clara y el beneficio buscado sea entendido por todos es suficiente. Si no partimos de cero, podemos simplemente tomar los requerimientos en cualquier formato que estén escritos (por ejemplo casos de uso).

Es importante no confundir Criterios de Aceptación de cada objetivo (requisito / historia de usuario) con la Definición de Hecho (DoD) que tienen que cumplir TODOS los requisitos.

Estimación con Planning Poker

El product backlog es, para ser exactos, una lista priorizada y estimada de historias. Por ahora sólo tenemos historias. Falta estimarlas y priorizarlas. El proceso de estimación se puede hacer utilizando una técnica llamada planning poker (póker de planificación). El objetivo del planning poker es obtener una medida de tamaño relativo de todas las historias respecto a sí mismas.

Cartas de planning poker

La teoría es que resulta relativamente fácil decir «A es más grande que B y que C» [no voy a entrar en detalle respecto a cómo efectuar planning poker, dejándolo para otro artículo]. Lo importante de efectuar planning poker sobre todo el backlog (a efectos de la planificación) es que da como resultado que todas las historias han sido estimadas con muy poco esfuerzo. Pero no en días/hombre como se haría tradicionalmente. Planning poker produce estimaciones en una medida arbitraria de tamaño llamada story points o «puntos de historia». Los story points son específicos de cada equipo, no pueden compararse entre diferentes equipos y a veces ni siquiera entre diferentes proyectos del mismo equipo. Lo único que indican es el tamaño relativo que tiene cada funcionalidad del backlog respecto a las demás. Lo importante es que ahora tenemos el tamaño total del proyecto estimado en una unidad llamada story points, y esto nos va a servir de mucho.

Priorización

La etapa de priorización es sencilla y depende exclusivamente del Product Owner. Sabiendo ya el tamaño de las historias, debe priorizarlas por valor de negocio. Notar que también es posible comenzar con la asignación de valor y después aportar el tamaño, en todo caso, la priorización se realiza balanceando el valor respecto al coste y respecto a los riesgos de cada objetivo.

Una manera rápida de empezar a asignar valor a las historias es dividirlas en 3 grupos, según sean imperativas, importantes o cosméticas/prescindibles (de manera que si se llega a una fecha de entrega predeterminada y no se han completado por lo menos hemos aportado el máximo de valor posible). Dentro de cada grupo nos resultará más fácil realizar una ordenación relativa por valor y después asignarlo.

La prioridad puede cambiar todo el tiempo; pero el tamaño en story points debe mantenerse fijo con la estimación original (o sea: como regla general, no reestimar). Si aparecen historias nuevas, deben estimarse utilizando el mismo criterio que se utilizó originalmente.

Ahora bien: todo esto todavía no nos dice nada respecto a cuánto durará o costará el proyecto; pero al menos es un paso más respecto a como estábamos antes, que solo teníamos el ballpark estimate. Si sólo pudiéramos averiguar a cuántos días/hombre o días/equipo equivale un story point, tendríamos nuestra estimación, y luego nuestra planificación.

Duración y proyección a partir de la velocidad del equipo

El último paso, por lo tanto, es calcular la velocidad del equipo completando objetivos a lo largo de las iteraciones. Así pues, la velocidad es la cantidad de story points que se completan por iteración. Calcularla es sencilla: solo hay que sentarse y esperar. En dos -como máximo tres- iteraciones, tendrás una idea bastante clara de cuál es la velocidad del equipo y por lo tanto el tamaño y duración del proyecto. Mientras tanto se puede ir construyendo el burndown chart, cosa que no me animo a traducir (gráfico de quemado?). El burndown chart nos muestra en el eje Y la cantidad total de story points del proyecto, y sobre el eje X las iteraciones. Cada vez que se finaliza una iteración, se completa un punto del gráfico, indicando la velocidad en ese ciclo.

Si teníamos una fecha prefijada en la que queremos terminar el proyecto, esto nos permite calcular la velocidad teórica a la que tendremos que ir para alcanzar esa fecha. El burndown chart permite rápidamente y en todo momento ver dos estadísticas vitales para la planificación: la estimación actual de cuándo va a estar terminado el 100% del proyecto; y la estimación del porcentaje de proyecto que va a estar terminado cuando lleguemos a cierta fecha.

Conclusión

La estimación y planificación ágil permiten así en todo momento saber cuál es la fecha estimada de finalización del proyecto, y en qué iteración estará lista determinada funcionalidad. Un beneficio adicional que nos brinda es que de existir complicaciones severas, que pongan en juego la factibilidad del proyecto, éstas generalmente se ven expuestas bien temprano, permitiendo cancelar el proyecto antes de incurrir en grandes pérdidas. Por esto, sumado al hecho de que el desarrollo iterativo e incremental garantiza que en todo momento se cuenta con el producto listo para ser entregado (por ejemplo software funcionado), está el hecho de que los métodos ágiles disminuyen enormemente los riesgos tradicionales en el desarrollo de proyectos.

Artículos relacionados

Calidad y agilidad – Resultados del cuarto encuentro ágil en Barcelona

En este encuentro se compartieron experiencias sobre los siguientes temas:

  • La manera en que las metodologías ágiles permiten hacer proyectos con un alto nivel de calidad, entendida como (1) la satisfacción de las expectativas del cliente, usuarios finales o consumidores, (2) el comportamiento correcto del producto y (3) la garantía de su mantenibilidad. Todo ello gracias a los principios de Lean (análisis del valor desde la concepción del producto hasta su venta), a que Scrum en sí mismo es un proceso de mejora continua y a que XP (eXtreme Programming) consta de prácticas de ingeniería enfocadas a mantener una alta calidad interna que permite una velocidad de desarrollo sostenible.

Calidad y agilidad

  • Hasta qué punto la calidad es negociable y cómo, gracias a priorizar los objetivos del proyecto por valor, las metodologías ágiles permiten prescindir de requisitos de baja prioridad antes que tener que degradar la calidad.
  • El proceso de Scrum se puede certificar casi directamente en nivel 3 de CMMI y existen empresas certificadas en nivel 5 que al adoptar Scrum han reducido mucho esfuerzo innecesario. La dificultad de certificar CMMI es la falta de conocimiento de los certificadores sobre metodologías ágiles, aunque el SEI está empezando a tener en cuenta estas metodologías.
  • El objetivo de Q/A en metodologías ágiles es evitar que se produzcan errores más que encontrarlos (con lo cual deben formar parte del propio equipo de desarrollo y participar desde la definición de los objetivos del proyecto) así como colaborar en la mejora de los procesos de trabajo para ser más productivos.
A continuación se detallan las ideas que se trataron respecto a estos temas.

 
Conceptos de calidad
El ciclo de mejora continua de Deming (PDCA)
En el ciclo de mejora continua de Deming tiene las siguientes actividades [1]:
  • [Plan] Planificar cómo conseguir unos objetivos.
  • [Do] Ejecutar esta planificación.
  • [Check] Verificar los resultados conseguidos.
  • [Act] Definir acciones correctoras a realizar en el siguiente ciclo para mejorar los resultados.
Las dimensiones de la calidad
Simplificando el modelo de calidad ISO 9126 [3], podríamos considerar que la calidad tiene las siguientes dimensiones:

1-     Cumplimiento de expectativas del Cliente (Product Owner).

Yendo un poco más lejos y utilizando el concepto de Lean de mejorar el proceso de producción de valor (analizar desde la concepción de la idea hasta que alguien la utiliza o paga por ella, cuando se recupera la inversión realizada), más que cumplir con las expectativas del cliente, hay que cumplir con las expectativas del consumidor o usuario final de producto, que es quien va a comprarlo o verse beneficiado en su utilización. Por ello, para no crear un producto que nadie va a comprar o una aplicación que nadie va a utilizar, el cliente debería conocer quién es y qué necesita el consumidor o usuario final, hacer participar a personas representativas, investigar el modelo de negocio (cómo va a ganar dinero) y contar con las ideas y aportaciones del equipo.

2-     Calidad externa, funcionamiento correcto. El producto debe comportarse de la manera esperada, tanto a nivel funcional como no funcional (rendimiento, usabilidad, etc.).

3-     Calidad interna. El producto debe ser mantenible, debe poder evolucionar a un ritmo sostenido.

En el encuentro se añadió, desde una perspectiva ágil, una cuarta dimensión:
4-     Satisfacción del equipo, que esté orgulloso de su trabajo, para mantener su motivación, su compromiso con el proyecto y con la empresa.
 
Agilidad, calidad y mejora continua
Scrum [2] es un proceso que en bloques temporales cortos y fijos (entre 2 y 4 semanas) entrega un incremento de producto final. En cada iteración de Scrum se ejecuta el ciclo de mejora continua de Deming en los siguientes ámbitos:
  • Las expectativas del cliente, a las cuales se va acercando iteración a iteración mediante las siguientes actividades:
    • La planificación al inicio de la iteración, en que el equipo se reúne con el cliente, quien ha expresado su expectativas mediante la lista priorizada de objetivos del proyecto (product backlog). El equipo coge tantos objetivos como se vea capaz de cumplir en la iteración, los refina con preguntas al cliente y hace una primera descomposición en las tareas necesarias para completar cada uno de ellos, creando la definición de hecho y la lista de tareas de la iteración (sprint backlog). [Es importante que el cliente haya preparado las iteraciones para que tengan una meta clara, que no sean un conjunto de objetivos poco cohesionados que produzcan pocas sinergias].
    • La iteración se desarrolla orientada a objetivos, minimizando el “número de objetivos en curso” (WIP, Work In Progress), para tener alguno completado cuando acabe la iteración y no muchos iniciados o a punto de finalizar.
    • La demostración de los resultados completados que el equipo realiza al cliente al final de la iteración. El feedback recibido del cliente permite ir acercándose a sus expectativas mediante ajustes a realizar en siguientes iteraciones, bien por que el equipo no consiguió entender correctamente sus necesidades, bien por que es el cliente quien ahora entiende mejor el producto, bien por que la velocidad de desarrollo no es la esperada o bien por cambios externos al proyecto que obligan a cambiar objetivos. Estos ajustes se incorporan al product backlog y el cliente lo reprioriza.
Notar que dentro de la propia iteración hay otro ciclo de Deming: la reunión diaria de sincronización del equipo, que le permite inspeccionar lo que está sucediendo y realizar las adaptaciones necesarias para poder conseguir los objetivos de la iteración, añadiendo o quitando tareas del sprint backlog durante la iteración.
Se puede observar que uno de los principales beneficios de Scrum es la flexibilidad frente a cambios en el contexto, el hecho de poder modificar y repriorizar los objetivos del proyecto iteración a iteración, así como las de tareas para poder conseguir un objetivo (se pueden llegar a cambiar todas las tareas si el planteamiento inicial ya no es aplicable).
  • Los procesos de trabajo del equipo, mediante:
    • La replanificación de las tareas a ejecutar.
    • La retrospectiva de cómo fue su ejecución, qué cree que hay que mantener, mejorar o probar hacer de manera diferente, con lo que se generar objetivos y tareas de ajuste de los procesos a ejecutar en las siguientes iteraciones.
  • La satisfacción del equipo se consigue mediante:
    • El hecho de poder entregar resultados finales de forma regular, de forma que el cliente los pueda utilizar o entregar a los usuarios/consumidores finales.
    • El mejor entendimiento de las expectativas del cliente, que permitirá dar mejores resultados en las siguientes iteraciones.
    • La mejora continua del proceso de trabajo entre el equipo y con terceros, cosa que le permite ser más productivo, reducir re-trabajo y tareas de poco valor.
calidad-lean-scrum-xp 
Agilidad y calidad interna
Es necesario construir el producto con calidad interna para poder tener una velocidad de desarrollo sostenible y crecer de manera iterativa e incremental. Ya desde la segunda iteración se debe construir sobre la parte del producto final ya existente sin poner parches que al final se transformen en “deuda técnica” (Technical Debt). Si la deuda técnica fuese creciendo, al final el coste de ir incrementando la funcionalidad se haría enorme. Para ello, eXtreme Programming utiliza las siguientes prácticas de ingeniería:
  • Estándares de codificación, incluyendo código bien comentado, para facilitar la propiedad colectiva.
  • Pair programming y/o peer review, para conseguir un código más simple, fácil de mantener y revisado por otra persona, con lo que la probabilidad de errores se reduce (arquitectónicos, de diseño o de funcionamiento).
  • Arquitecturas flexibles tanto en interfaz de usuario como en patrones de diseño como en información, de manera que en el futuro se puedan introducir cambios minimizando el impacto sobre el resto del sistema / los objetivos ya completados. Esto no debe implicar preparar la arquitectura o el código para requisitos futuribles (que puede que no lleguen nunca), si no simplemente cubrir cada objetivo conforme se va desarrollando intentando no hacer demasiado en contra de los futuribles.
  • TDD (Test Driven Development) para desde el inicio conseguir un código se puede probar así como su simplicidad. Para ello se escribe primero las pruebas (funcionales, de integración o unitarias) y después se escribe el mínimo código necesario para pasarlas.
  • Refactorización, para simplificar y mejorar el código una vez la prueba ha pasado, con la garantía de que sus pruebas asociadas actuarán como regresión protegiendo de la introducción de errores.
  • Ejecutar pruebas automatizadas en un sistema de integración continua para poder realizar cambios controlados. De esta manera, si algún componente que ya existía deja de funcionar, las pruebas asociadas inmediatamente detectan el fallo tan pronto se integra. Dado que estos errores colaterales no tardan en ser detectados, su corrección es más rápida ya que el desarrollador todavía tiene en mente el código que los produjo.
Es importante contar con métricas para ir evaluando de manera objetiva si cómo se están produciendo las mejoras [8].
 
¿La calidad es negociable?
El cumplimiento de las expectativas del usuario es lo más importante: sin esto el proyecto no puede ser un éxito. Por ello, en metodologías tradicionales, el cliente puede llegar a negociar bajar la calidad funcional e interna con el objeto de cumplir en fechas (ver el concepto del triangulo de hierro). Al cliente no le sirve tener algo perfecto, sino tener lo que necesita a tiempo.
Para no tener qué llegar a bajar la calidad, las metodologías ágiles priorizan los objetivos del proyecto en función del valor que aportan al cliente. De esta manera, para llegar en fechas se prescinde de algún objetivo poco relevante, en lugar de bajar la calidad. Esto también permite que el equipo se sienta orgulloso de la calidad de su trabajo.
 
Reducción de riesgos de calidad y retrabajo
  • Se puede utilizar una iteración (para poner un timeboxing a la no producción de resultados), llamada “iteración cero”,donde hacer la lista priorizada de objetivos del proyecto y pruebas de concepto muy ligeras de:
    • La arquitectura del proyecto, con una prueba extremo a extremo de la introducción/recuperación de información a través de distintas capas y tecnologías.
    • La usabilidad y el diseño e interacción del usuario con la aplicación, mediante wireframes o prototipos de baja fidelidad. Este modelo, un diagrama de procesos y otro de entidad/relación (todos a alto nivel) permiten complementar el modelo de historias de usuario (texto escrito e interpretable) y reducir la incertidumbre sobre las expectativas del cliente (“para el usuario, las pantallas son la aplicación”).
  • Estas pruebas de concepto se irán refinando y adaptando iteración a iteración, según se desarrollen los objetivos por orden de prioridad, por ejemplo construyendo maquetas navegables a partir de los wireframes, como acompañamiento al backlog en la planificación de cada iteración.
 
CMMI vs agilidad
  • CMMI define unos niveles de madurez de una empresa que permiten tener un orden mejora/implantación de procesos. Por ejemplo, si no tienes nada (Nivel 1 de madurez), una de las primeras cosas que deberías hacer es un control de versiones (Nivel 2).
  • Algunas de las principales diferencias entre CMMI y Scrum son que CMMI se orienta a procesos y su institucionalización en la empresa, con la idea de que los procesos serán los que permitirán conseguir los objetivos del cliente y mejorar la predictibilidad de los proyectos, mientras que Scrum se orienta directamente a conseguir los objetivos del cliente en un proyecto mediante el trabajo en equipo, el cual puede mejorar sus procesos según sea el contexto del proyecto.
  • Dado que la base de Scrum es la gestión de proyectos y el trabajo en equipo, CMMI y PMBOK se pueden utilizar para complementar Scrum cuando sea necesario en las áreas que Scrum no aborda por que están fuera de su alcance como, por ejemplo, la gestión de riesgos (que en Scrum son más reducidos por hacer iteraciones cortas con feedback tanto del cliente como del equipo y por limitar la complejidad que cabe en una iteración), la institucionalización en la empresa de los procesos ágiles, la gestión de proveedores, etc.
  • Respecto a la certificación de procesos ágiles, es más fácil certificar ISO que CMMI, ya que ISO certifica lo que dices que haces. El proceso de Scrum se puede certificar casi directamente en nivel 3 de CMMI y existen empresas certificadas en nivel 5 que al adoptar Scrum han reducido mucho esfuerzo innecesario. El problema de certificar CMMI es que los certificadores exijan que se implemente y se registre la ejecución de un proceso de una determinada manera, normalmente siguiendo metodologías tradicionales (en cascada o waterfall). Sin embargo, el propio SEI (que como el PMI está empezando a tener en cuenta la agilidad) lo desmiente [5]: lo importante son los objetivos del proceso, no la manera cómo se implementa (que puede ser ágil) [6].
 
El objetivo de Q/A en metodologías ágiles
  • Evitar que se produzcan errores. Utilizando el pensamiento Lean de evitar el desperdicio como el re-trabajo en búsqueda y corrección de errores, es necesario impedir que aparezcan los errores que se deban a malas interpretaciones. Por ello, las personas que se encargan de las pruebas funcionales deben hacen TDD a nivel de requisitos:
    • Para ayudar a que tanto el cliente como el equipo compartan la misma visión, los testers participan en la toma de objetivos/requisitos (creación/modificación [fuera de la iteración] y detalle del backlog [en la planificación de la iteración]), asociando a cada objetivo sus condiciones de satisfacción, normalmente en forma de pruebas de aceptación (por ejemplo en el reverso de las tarjetas de historias de usuario). De esta manera el equipo y el cliente desambiguan el objetivo, le dan el detalle que consideran necesario e impiden la aparición de errores por falta de entendimiento de los objetivos.
    • Notar que la búsqueda de errores después de la programación sigue siendo necesaria (un programador programa e introduce errores al mismo tiempo). Mediante las prácticas de eXtreme Programming enumeradas anteriormente se puede reducir la tasa de errores por línea de código.
    • Los testers deben estar dentro del propio equipo, para conseguir que el equipo tenga la responsabilidad de entregar objetivos completados (probados) y no sea necesario hacer un trabajo adicional sobre ellos. De esta manera cuando el equipo haga una demostración, el cliente podrá tomar decisiones contando con que puede disponer de los resultados que se le han mostrado.
    • Las pruebas de aceptación por parte del cliente o con usuarios beta sigue siendo necesaria, dado que las pruebas realizadas por el propio equipo (unitarias, funcionales, etc.) no lo pueden cubrir todo. La perspectiva del producto del cliente o del usuario final o consumidor puede ser diferente de la del equipo de desarrollo y llevar a cabo acciones no previstas: pueden esperar un comportamiento del sistema que daban por sobreentendido pero no fue explicitado en su momento, o bien no cayeron en su necesidad cuando se planteó el objetivo y al probar el producto se dan cuenta de algo adicional que es necesario.
    • En ciertos proyectos pueden ser necesarias iteraciones específicas cada vez que se haga una entrega de producto (por ejemplo de la mitad de duración de una iteración de desarrollo) para incluir las últimas modificaciones/errores detectados por el feedback del cliente en la última demostración.
    • Si el proyecto es muy grande y participan varios equipos, puede ser necesario un equipo de integración que recoja el trabajo de todos los equipos y se encargue de que todo funcione correctamente. Para mejorar la comunicación, las personas de este equipo pueden llegar a trabajar la mitad de su tiempo en cada equipo de desarrollo y el resto en el propio equipo de integración, de manera que se asegure que en cada iteración todo el producto funciona.
  • Colaborar en la mejora de los procesos de trabajo, buscar maneras de reducir esfuerzos innecesarios.
 
Video del encuentro

 

 
encuentro-calidad-agilidad
El encuentro fue transmitido en directo. La grabación se realizó en dos partes y está disponible en:
 
Agradecer a DoubleYou, agencia de publicidad que utiliza prácticas de Scrum y XP en sus proyectos, la cesión de sus instalaciones, la transmisión en directo del encuentro, los snacks y las bebidas.
Para apuntarse a los próximos encuentros en Barcelona sobre temas ágiles: http://agile-spain.wikidot.com/quedadas-barcelona
 
Para saber más
 

El buen gestor de un equipo ágil

En un equipo ágil, el gestor es un elemento clave. No es sencillo conseguir que el cliente obtenga el mejor resultado posible del proyecto, que el equipo sea hiperproductivo y que a la vez disfrute de su trabajo. De hecho, ser jefe no significa necesariamente ser líder, y el liderazgo estructural simplemente es ejercicio del poder. El liderazgo es más que técnicas, es una forma de pensar, un estilo de vida. Lo detenta aquella persona que consigue que se hagan las cosas, que se cambien, que se mejoren y que se innove.

Si se entiende la cultura de una empresa como el resultado del modelo de gestión que se practica en ella, se puede distinguir entre dos modelos diferentes:
  1. El modelo de gestión tradicional, basado en la autoridad, dirección y control por parte de un superior que planifica/dicta las tareas a hacer y las asigna. Este modelo se acentúa cuando entran en juego competencias de departamentos/áreas diferentes que realmente no acaban trabajando en equipo: cada miembro del proyecto está especializado en tareas concretas dentro de un proceso “en cascada”. Tras realizar su parte, se “pasa la pelota” al experto en la siguiente fase, de manera que es difícil que haya un sentimiento de responsabilidad compartido entre los miembros de este «grupo de trabajo» acerca del resultado del proyecto, se producen esperas, pasos hacia atrás, correcciones por no-cumplimiento y, peor, puede fomentar la competitividad entre las personas del grupo de trabajo.
  2. El modelo que fomenta el trabajo en equipo, especialmente en proyectos complejos y de alto riesgo, donde el alcance se va precisando durante la ejecución del proyecto (proyectos “emergentes”) y/o que necesitan de la creatividad conjunta de los integrantes del equipo, que colaboran estrechamente y comparten la responsabilidad del resultado del proyecto.
Para este segundo modelo, se necesita que el gestor/líder de un equipo ágil piense y se comporte como un facilitador, un líder al servicio del equipo que en Scrum se conoce como Scrum Master, una persona que, además de entender cual es la base por la que funcionan las cosas (el negocio del cliente, la metodología de trabajo, la tecnología) debe tener dotes de trato interpersonal, tanto con el cliente como con el equipo, ser capaz de:
  • Observar, escuchar, preguntar mucho y reparafrasear para entender las necesidades, motivaciones y sentimientos de los otros, ponerse en su lugar antes de dar la propia opinión (si es realmente necesario que la dé). Es decir, evitar juzgar inmediatamente al otro y tener empatía.
  • Negociar, comunicar adecuadamente la información correcta en el momento correcto, adaptándola a las necesidades de la audiencia.
  • Enfocar al equipo, orientarlo para avanzar y cumplir con las expectativas del cliente, a la vez que cuidar la calidad del producto, sin dictar cómo hacerlo.
  • Motivar al equipo.
Esta manera alternativa de concebir el trabajo en equipo lleva utilizándose desde hace varios años en miles de proyectos en empresas donde la competitividad de mercado, la innovación, la calidad y la productividad son fundamentales, desde startups a grandes empresas como Toyota, Google, etc.
 
A continuación se enumeran las cualidades que debe tener y los comportamientos a evitar por parte de un buen gestor de equipo.
 

Confía en el equipo y lo potencia
  • No actúa como un jefe de proyecto tradicional que dirige los resultados del proyecto (esto es responsabilidad del cliente). No impone su autoridad ni exige que el equipo le siga. No controla a su equipo planificando sus tareas, decidiendo en qué tareas debe trabajar cada persona y cómo deber de hacer su trabajo, no guía el proyecto con sus decisiones ni hace microgestión, no hace que el equipo se sienta cuestionado ni lo desautoriza. En cambio, asume que el equipo es el experto y así se lo hace saber, ellos son quienes conocen la mejor manera de realizar su trabajo y quienes tienen la responsabilidad de llevar a buen término el proyecto.
  • Ayuda al equipo a autoorganizarse para conseguir los objetivos del proyecto; a comunicarse, a compartir ideas, a colaborar y a ir mejorando su forma de trabajar para ser más productivo, flexible y adaptativo a cambios en las necesidades del cliente. No da respuestas, si no que guía al equipo con preguntas para que descubra por sí mismo una solución y aprenda. Facilita que el equipo tome decisiones consensuadas (sostenibles en el tiempo), que encuentre las mejores soluciones posibles mediante la sinergia de enfoques, conocimientos y experiencias, a partir de los cuales combinar diferentes opciones. Para ello fomenta la colaboración entre los miembros del equipo en los procesos de decisión y con el cliente, especialmente en las reuniones de planificación de la iteración (Sprint), en las demostraciones de los resultados de cada iteración y en las retrospectivas (Si además se consideran las reuniones de sincronización diaria, se puede ver que Scrum implementa 3 veces el círculo de Deming).
Actúa como un sirviente de su equipo, de manera que avance y no se quede bloqueado
  • Ayuda a que su equipo avance, no se quede bloqueado, se mantenga focalizado en su trabajo, elimine ineficiencias y maximice su productividad. Para ello quita de en medio los impedimentos que el equipo no puede resolver por sí mismo (o que no son su principal objetivo) y, lo que es mejor, es capaz de intuirlos y anticipar la necesidad de mitigación de riesgos. Cuando es necesario, busca recursos para que el equipo vaya aprendiendo cómo solucionar sus déficits (formación, soporte experto, etc.).
  • Protege a su equipo de interrupciones externas para que pueda cumplir con el compromiso de objetivos que adquirió al inicio de la iteración.

Promueve la confianza y la comunicación entre los miembros del equipo
  • Promueve las conversaciones sinceras, la compartición de información y la comunicación frecuente entre los miembros del equipo. Aporta seguridad y confianza para que tengan lugar.
  • Mantiene un ambiente constructivo para converger en los conflictos e impide actitudes recriminatorias, atacantes y/o acusadoras dentro y desde fuera del equipo. Para ello ayuda a escuchar, a ponerse en el lugar de los otros, a entender sus razones, a consensuar el problema, a que se propongan soluciones alternativas, respetando las opiniones de todos, a evaluarlas y a llegar a conclusiones y acuerdos, siempre bajo el principio de ganar-ganar.
  • Crea un sentido de comunidad e identidad del equipo en el proyecto. Fomenta que unos aprendan de otros y que establezcan vínculos.
Promueve la confianza entre el cliente y el equipo
Tolera errores y no busca culpables, sino mejorar el proceso de trabajo
  • Cuando se produce un error no busca personas culpables. No acusa ni recrimina, para que el equipo no se desmotive y hasta acabe paralizándose. Asume que es el contexto quien provoca los errores, por lo que con visión constructiva ayuda al equipo a descubrir, mediante un análisis causal, qué partes del proceso de trabajo, de interrelaciones y de colaboración, tanto intraequipo como con terceros, deben ser mejoradas para que el error no se repita.
  • Es capaz de aceptar imperfecciones (desde su punto de vista) en el trabajo de los miembros del equipo y hacer que el equipo encuentre el camino para ir mejorando. Incluso puede dejar que el equipo se equivoque para que pueda aprender a partir de la reflexión sobre la equivocación.
  • Cuando se produce un problema, lo primero que debe pensar el gestor de un equipo ágil es que la responsabilidad es suya, no de otros, debe preguntarse qué debería haber hecho o estar haciendo para que este problema no esté sucediendo, cómo podría haberse anticipado.
  • El gestor de un equipo ágil es humilde, tienen capacidad de autocrítica, sabe que siempre hay cosas sobre las que aprender y se esfuerza en ello, acepta las observaciones de los demás y asume sus errores como oportunidades de mejora.
Practica con el ejemplo
  • El gestor de un equipo ágil da ejemplo, especialmente en la forma de interrelacionarse con los demás.
  • No habla de «yo», sino de «nosotros». Por ejemplo, no dice «quiero esto», sino «necesitaríamos esto».
  • No eleva el tono de voz ni grita, sino que habla calmado, sin excitarse, tiene buen humor y sonríe.

El Scrum Master ofrece su comportamiento como ejemplo

Para saber más

Modelos mentales:

Planificación ágil de proyectos dependientes

Para planificar un proyecto desde la óptica ágil y crear la primera versión del backlog (lista de objetivos priorizados) se pueden utilizar los siguientes criterios de priorización:

  • El valor para el cliente de cada objetivo o requisito de alto nivel.
  • El esfuerzo estimado de desarrollo de los objetivos, proporcionado por el equipo.
  • El riesgo asociado a cada objetivo (madurez de requisitos, riesgos tecnológicos, personas que participan, en línea con los factores de complejidad de los proyectos).
En el caso de planificar varios proyectos dependientes, puede ser necesario añadir nuevos criterios como, por ejemplo:
  • Las dependencias e integraciones entre los proyectos, para asegurar que se traten de manera simultánea y en el momento adecuado.
  • El riesgo asociado a estas dependencias e integraciones.
Estos últimos criterios pueden obligar a repriorizar algunos objetivos de los proyectos.
 
En esta planificación inicial, para facilitar la colaboración de los participantes en los diferentes proyectos (clientes / product owners, equipos y scrum masters / facilitadores), se puede utilizar tarjetas de historia de usuario pegadas sobre una pizarra blanca o pared.
 
tarjeta-historia-usuario-scrum-backlog

 
 
A continuación se detalla el proceso de creación conjunta del backlog de varios proyectos.

  1. Crear las tarjetas con los objetivos de cada proyecto, escribiendo el valor, estimación de esfuerzo y riesgo iniciales de cada objetivo.
  2. Elaborar el backlog de cada proyecto, ordenando las tarjetas teniendo en cuenta las dependencias entre objetivos y utilizando los criterios de priorización anteriores.
  3. Pegar las tarjetas de cada proyecto en la pizarra, encajando el esfuerzo de los objetivos en la capacidad de las iteraciones.
  4. Identificar las dependencias entre objetivos de diferentes proyectos y realizar los movimientos de tarjetas y recálculos de esfuerzo necesarios.

planificacion-proyectos-dependientes-scrum

 
En este ejemplo los objetivos o requisitos de alto nivel de cada proyecto aparecen clasificados por áreas (módulos o paquetes funcionales de un proyecto) que se desarrollan incrementalmente en diferentes momentos e iteraciones.

 

Artículos relacionados

Creación de product backlog – Resultados del tercer encuentro ágil en Barcelona

 

En este encuentro se compartieron experiencias sobre los siguientes temas:
  • Principios de Lean Software Development, a modo de ayuda cuando Scrum no proporciona una solución directa a un problema.
  • Cómo gestionar historias de usuario que comparten implementación, haciendo énfasis en no perder el foco de que toda historia de usuario debería proporcionar algún valor al cliente.
  • Empezar por las historias de usuario más claras y que aportan más valor, y así en el futuro evitar modificar código de requisitos actuales dudosos.
  • La “generalización” del producto puede ser peligrosa para el negocio, no hay que olvidarse de obtener resultados a corto-medio plazo para el negocio
  • Cómo poner las pruebas de concepto en el product backlog, siempre sin perder de vista que el tiempo para estas pruebas debe estar acotado (timebox) y que debe poder medirse el progreso de la prueba.
  • El backlog como iceberg, en el cual los primeros objetivos son más pequeños, están más detallados, y los últimos son meros recordatorios de grandes objetivos a conseguir.
A continuación se detallan las ideas que se trataron respecto a estos temas.

 
Principios de Lean Software Development
La reunión comenzó haciendo una enumeración de los principios de Lean Software Development, de manera que sirviesen como ayuda por si se trataba algún problema para el que Scrum o XP no tuviesen una solución directa:
  • Respetar a las personas, por que el equipo es quien conoce cómo mejorar el proceso en que trabaja.
  • Eliminar los desperdicios que se producen en el proceso, todo aquello que no produce valor añadido en el producto.
  • Aplazar el compromiso, retardar las decisiones hasta que se disponga de toda la información o no se pueda esperar más.
  • Crear conocimiento, tener feedback regular con el cliente para alinearse con sus expectativas.
  • Hacer entregas rápidas, para permitir que el cliente pueda aprovechar antes los beneficios que le aporta el proyecto.
  • Desarrollar con calidad interna, de manera que el producto pueda ir creciendo con una velocidad sostenida.
  • Optimizar la totalidad del proceso, mejorar el proceso de creación del producto, desde la idea hasta su entrega.
Cómo gestionar historias de usuario que comparten implementación
En ocasiones hay historias de usuario que comparten una misma implementación. Lo más conveniente es formular toda historia de usuario de manera que aporte un valor al cliente (por ejemplo, cuantificable en dinero que el cliente podrá recuperar a partir de sus usuarios). No deberían existir historias de usuario de implementación del estilo “crear un motor de indexación”.
Dado que la primera historia de usuario siempre tendrá un esfuerzo mayor de implementación, puede ser conveniente hacer lo siguiente:
  • Explicar al cliente esta situación. De esta manera puede tomar una mejor decisión de qué historia de usuario le interesa que se implemente antes (puede llegar el caso de que el cliente vaya retardando la segundo historia de usuario y que al final ésta no se implemente nunca).
  • Ver qué orden de implementación de las dos historias de usuario es el que necesitará de un menor esfuerzo global.
Empezar por las historias de usuario más claras y que aportan más valor
Siguiendo el principio de Lean “aplazar el compromiso”, ante la duda de si en el futuro será necesario un requisito o una parte de arquitectura, lo mejor es sólo implementar lo que se necesite en el momento actual y utilizar técnicas como patrones de diseño para que en el futuro no cueste crecer encima (“Desarrollar con calidad interna”). Estas primeras necesidades deberían estar claras para el cliente, dado que deberían ser las que le aporten más valor en el momento actual.
Se consiguen varios beneficios de no implementar lo que no está claro (que sea necesario para el producto o cómo debe funcionar):
  • Se consiguen completar antes los requisitos que sí están claros (“Hacer entregas rápidas”).
  • Cuando llegue el momento de incorporar los requisitos que en su día fueron dudosos (y puesto que la idea original puede haber cambiado), las modificaciones/refactorizaciones a realizar pueden ser menores que si se tuviesen que hacer sobre un código implementado a partir de requisitos no claros. En un caso extremo, puede ser que el cliente no necesite nunca esos requisitos.
La “generalización” del producto puede ser peligrosa para el negocio
Si el cliente o el equipo dedica demasiado tiempo en generalizar el producto y las historias de usuario para que la solución cubra el máximo número de futuras posibilidades del producto (posibilidades que quizás acabarán cambiando o que nunca llegarán), se corre el peligro de desviarse de obtener resultados a corto-medio plazo para el negocio.
Cómo poner las pruebas de concepto en el product backlog
Es conveniente que todos los objetivos del proyecto aparezcan en el product backlog, incluidas las pruebas de concepto (spikes) que sean necesarias:
  • Si es posible, es mejor ser transparente con el cliente y que entienda el sentido y necesidad de realizar pruebas de concepto.
  • Es más sencillo utilizar una única herramienta (el product backlog) para tener la visión de todos los objetivos en que está trabajando la fuerza productiva (el equipo).
Las pruebas de concepto deben estar acotadas en el tiempo (tareas con timebox) para ayudar a tomar decisiones, especialmente si no se están consiguiendo resultados de las pruebas. Para ver si se va por buen camino, se pueden utilizar diferentes técnicas:
  • Hacer que el timebox sea pequeño (siempre menor que una iteración), pero suficiente para poder obtener un resultado y tomar una decisión. Si al final resulta insuficiente, se puede volver a utilizar otro timebox.
  • Definir la estrategia de la prueba de concepto, dividiéndola en tareas que al completarlas permitan saber si se está progresando.
  • Hacer varias pruebas de concepto para reducir riesgos. Por ejemplo, en el caso de una aplicación web, se pueden hacer públicas variantes de una misma funcionalidad (o diferentes funcionalidades) para diferentes usuarios, de manera que se obtenga feedack directo y real de su aceptación.
El backlog como iceberg
Se explicó la metáfora del backlog como iceberg:
  • En las primeras iteraciones, en que aparecen las historias de usuario más prioritarias, estas historias de usuario son más pequeñas y detalladas.
  • Conforme las entregas son más lejanas, los objetivos se redactan como grandes temas que actúan a modo de recordatorio (“épicas”).
Para apuntarse a los próximos encuentros en Barcelona sobre temas ágiles: http://agile-spain.wikidot.com/quedadas-barcelona
Agradecer a DoubleYou, agencia de publicidad que utiliza prácticas de Scrum y XP en sus proyectos, la cesión de sus instalaciones, los snacks y las bebidas.

Artículos relacionados

 

Ingeniería Ágil – Resultados del segundo encuentro ágil en Barcelona

 

En este encuentro participaron 11 personas que explicaron sus experiencias, los beneficios y dificultades que habían encontrado en los siguientes temas:
  • Integración continua con pruebas automatizadas y TDD.
  • Deuda técnica vs perfeccionismo.
  • Integración continua en entornos multiequipo.
  • Aprovechamiento de los nightly builds para métricas de calidad y pruebas de stress.
  • El valor aportado al cliente mediante prácticas de ingeniería ágiles.
Otros resultados del encuentro:
  • Se identificaron nuevos temas del “track” de ingeniería para próximos encuentros: herramientas, frameworks, resistencia a la introducción de metodologías ágiles, pair programming, automatización de los tests de aceptación y documentación automática.
  • Se propusieron los siguientes workshops:
    • Aplicación práctica de TDD
    • Integración continua con Maven 2
    • Integración continua con Hudson

Para obtener más valor de próximos encuentros, se propusieron las siguientes técnicas:

  • Exposiciones de experiencias reales, en que los asistentes realicen preguntas y proporcionen consejos.
  • Talleres alrededor de un objetivo ficticio, preparado con anterioridad para obtener el máximo de la sesión.
A continuación se detallan las ideas que se trataron respecto a estos temas.
 

 
Pruebas unitarias
 
Las pruebas unitarias son uno de los principales protagonistas del desarrollo ágil:
  • Las pruebas unitarias son claves para realizar cambios con seguridad (cuando se introducen nuevas funcionalidades, se hacen refactorings, etc.), por el hecho de disponer de una malla de pruebas automatizadas que avisa cuando algo se rompe.
  • Las pruebas unitarias sirven como documentación técnica del uso del código.
Sin embargo:
  • La integración es un problema complicado, que no se resuelve únicamente con pruebas unitarias. Para ello existen frameworks específicos:
    • Para solucionar la relación con la base de datos: DBUnit, MockObjects, etc.
    • Inyección de dependencias, Aspect Oriented Programming como Spring. La comunidad Open Source está dirigiendo sus pasos hacia esta filosofía, que permite desacoplar y probar de manera independiente componentes y permite no escribir el código de servicios transversales (como requisitos no funcionales) dentro del código de negocio (por ejemplo, no escribir el try/match/rollback, realizar pruebas sin servidor de aplicaciones, no necesitar un pool de conexiones, utilizar URL rewritting, limpiar diariamente una tabla, etc.).
  • Las pruebas unitarias están lejos del “negocio”, pierden un poco de vista el objetivo al que están sirviendo.
 
Pruebas funcionales

 

  • La automatización de pruebas funcionales y de aceptación es más compleja, aunque cada vez existen mejores herramientas: Fitnesse, HTTPUnit, Jmeter, etc.
  • El cliente debería participar en su definición.
 
TDD
 
Se distinguieron los siguientes enfoques para el desarrollo guiado por pruebas:
  • TDD en pruebas de aceptación. Los casos de pruebas de aceptación se escriben en el momento de crear una historia de usuario y quedan ligados a ella. Estas condiciones permiten:
    • Verificar que la historia ha sido completada.
    • Mueven el rol del experto en pruebas funcionales al inicio del proceso, evitando que aparezcan errores (al clarificar el objetivo de la historia), en lugar de sólo dedicarse a buscarlos.
  • TDD en pruebas unitarias.
    • Siguiendo XP y TDD, primero se deben escribir las pruebas. Sin embargo, es difícil pensar en abstracto, hacer arquitectura y diseño durante la elaboración de casos de prueba para unas clases que todavía no existen. De cualquier manera, existe buena literatura al respecto, mencionándose a la autora Lisa Crispin.
    • Hay que asumir el esfuerzo de cambiar el código y pruebas ya existentes, así como refactorizar.
Cómo solucionar la deuda técnica

 

  • Ante preguntas del tipo ¿Qué hacer cuando la deuda técnica acumulada es grande, cuando hay necesidad de hacer grandes refactorings o el número de bugs acumulados es alto? se plantearon diferentes respuestas:
    • Explicar al cliente los problemas existentes y crear historias específicas para resolverlos, de manera que la decisión de qué problemas arreglar y cuando hacerlo sea suya.
    • Solucionar los problemas dentro de historias que den valor al cliente, arreglando la parte de deuda técnica afectada.
Deuda técnica vs perfeccionismo
 
Una tarea puede dilatarse por condicionantes propias de la condición humana:
  • Cuando una persona crea algo, se siente responsable y puede querer un resultado perfecto.
  • Las personas buscan no sólo realizar tareas, sino su satisfacción personal. Esto puede llevar, por ejemplo, a “dispersión técnica” (entendida como utilización de técnicas innecesarias o sobredimensionadas que no aportan valor y que incluso pueden llegar a complicar en exceso el producto).
Dilatar el tiempo de un proyecto de esta forma es encarecerlo. El tiempo dedicado a hacer una tarea no pertenece al desarrollador, si no a quien le paga, que es su empleador y, en última instancia, el cliente. Por ello, puede ser conveniente tener siempre algo de deuda técnica: “no tienes que tener el mejor producto”.
 
 
Integración continua

 

  • Integración en un entorno multiequipo.
    • La integración continua minimiza la necesidad de disponer de diferentes ramas para grupos de programadores, pero siguen siendo necesarias en caso de que estos grupos trabajen en proyectos u objetivos de negocio bastante desacoplados que pueden subir a producción en momentos diferentes. En ese caso, cada equipo puede trabajar en su propia rama (con integración continua) y, cuando se decide que el trabajo de un equipo debe formar  parte de una entrega, integrar manualmente hacia una rama central (donde ya no debería haber marcha atrás). Cualquier arreglo de bug en esta versión ya va directamente desde el desarrollador hacia esta rama.
    • Perforce gestiona mejor las “marchas atrás” que Subversión.
  • Aprovechar los nightly builds para realizar tareas que serían demasiado costosas en cada commit:
    • Métricas de calidad, por ejemplo con Checkstyle y Simian reports (como detector de “copy & paste”s).
    • Pruebas de stress.
  • Se resaltan las cualidades de Maven 2 como herramienta de integración continua.
 
El valor aportado al cliente mediante prácticas de ingeniería ágiles
 
Resultó especialmente interesante el análisis de estas prácticas no sólo a nivel de ingeniería, sino también considerando su impacto en la gestión del proyecto y, especialmente, en el valor que aportan al cliente.
  • ¿Por qué conviene al cliente que el equipo trabaje de manera ágil, utilizando integración continua con pruebas automatizadas?
  • ¿Le interesa un esfuerzo/coste superior en las primeras iteraciones del proyecto que se verá compensado en el medio plazo?
  • ¿Qué cobertura y profundidad hay que aplicar con automatización de pruebas?.
La respuesta fue: DEPENDE. Depende del grado de calidad que quiera el cliente (de cómo él defina lo que entiende que es calidad), del producto, del proyecto, del conocimiento de los requisitos que tenga el cliente, de tener una estrategia empresarial orientada a calidad (cosa que puede repercutir en tener unos precios más altos que la competencia), etc.
De cualquier manera, se subraya los beneficios de aplicar estas técnicas:
  • Mayor flexibilidad frente a cambios: disponer de una malla de tests que avisa cuando algo se rompe.
  • Y, en definitiva, mayor calidad respecto a:
    • Expectativas del cliente.
    • Minimización de errores.
    • Mantenimiento del sistema.
Temas y metodología a seguir en próximos encuentros
 
Se identificaron los siguientes temas para el “track” sobre ingeniería ágil:
  • Herramientas de soporte al desarrollo ágil, frameworks y plataformas.
  • Resistencia a la introducción de metodologías ágiles
  • Pair programming
  • Automatización de los tests de aceptación
  • Documentación automática
Se propusieron los siguientes workshops:
  • Aplicación práctica de TDD
  • Integración continua con Maven 2
  • Integración continua con Hudson
Para obtener más valor de próximos encuentros, se propusieron las siguientes técnicas:
  • Exposiciones de experiencias reales, en que los asistentes realicen preguntas y proporcionen consejos.
  • Talleres alrededor de un objetivo ficticio, preparado con anterioridad para obtener el máximo de la sesión.
Para apuntarse a los próximos encuentros en Barcelona sobre los temas y workshops anteriores: http://agile-spain.wikidot.com/quedadas-barcelona.
 
Agradecer a DoubleYou, agencia de publicidad que utiliza prácticas de Scrum y XP en sus proyectos, la cesión de sus instalaciones, los snacks y las bebidas.

 

 

Iniciativas resultado del primer encuentro ágil en Barcelona

Resumen

El punto principal que se trató en el encuentro fue por qué no son más conocidas las metodologías ágiles:

  • Cambio cultural y de valores. Respeto y reconocimiento a quien es válido. Las metodologías ágiles “aplanan” la jerarquía de la empresa.
  • Factorías de software jerárquicas.
  • La universidad enseña waterfall.
  • La mayor parte de los recursos están en inglés.
  • Poco conocimiento de metodologías en general en las empresas, y menos si son “nuevas”.
 Iniciativas propuestas para dar a conocer las metodologías ágiles:
 
  • Hacer un evento a nivel nacional con casos de éxito de empresas españolas.
  • Divulgar las metodologías ágiles en clientes y quien toma las decisiones en las empresas, explicando los beneficios y casos de éxito.
  • Crear un directorio de empresas ágiles españolas.
  • Crear contenidos en español donde explicar cómo trabajar con metodologías ágiles, problemas y soluciones.
  • Hacer talleres donde aprender y practicar técnicas ágiles.
  • Fomentar la formación en metodologías ágiles en la universidad.
  • Directorio de herramientas de gestión y de desarrollo.
 

 

Los participantes

 

14 personas que aplican metodologías ágiles en desarrollo de software y consultoría desde hace 6 meses a 2 años, con resultados positivos.

 Algunos de los participantes:

 
Por qué no son más conocidas las metodologías ágiles

 

  • Cambio cultural y de valores.
    • Respeto y reconocimiento a quien es válido, premiar al competente.
    • Las metodologías ágiles “aplanan” la jerarquía de la empresa. Hay mandos que no están dispuestos a que sus equipos tengan más responsabilidad y autoridad, que les digan qué y cómo se hacen las cosas.
  • Factorías de software jerárquicas.
  • La universidad enseña waterfall.
    • La enseñanza universitaria está basada en “waterfall”, ya que es un proceso con las mismas fases que otras disciplinas de ingeniería entienden (pero asumiendo que los requisitos iniciales son conocidos, por ejemplo, en la construcción de un edificio).
    • Da la sensación de que las metodologías ágiles no son formales (sin embargo, tanto XP como Scrum definen procesos, que ayudan a certificarse en CMMi 3).
  • La mayor parte de los recursos están en inglés (libros, revistas, artículos en Internet), cosa que no predispone a algunas personas.
  • Poco conocimiento de metodologías en general en las empresas, y menos si son “nuevas”. También hay que tener en cuenta que la adopción de una metodología de manera más o menos general tarda años.

 

Otros temas tratados 

 

Otros temas que se trataron o hubo interés en tratar en futuros encuentros

  • Cómo hacer participar al cliente en el proyecto. El cliente quiere resultados y no le importa tanto la metodología, por lo que a veces es difícil involucrarlo en el desarrollo (sin embargo, las metodologías ágiles necesitan de su tiempo y participación regular, cambiando el paradigma de cerrar el alcance, coste y tiempo al inicio del proyecto, para dejar abierto el alcance).

  • Cómo hacer testing en metodologías ágiles y, especialmente, en outsourcing.

  • Cómo definir el business case y la visión de producto según metodologías ágiles dado que, por ejemplo, el business case es anterior al proceso de Scrum y queda fuera de su alcance.

  • Cómo aplicar los principios de la agilidad en “operaciones”, gestión de sistemas y Data Centers. Existe un vacío en esta área y podría definirse alguna metodología ágil siguiendo sus valores.

 

Iniciativas para dar a conocer las metodologías ágiles

 

  • Hacer un evento a nivel nacional con casos de éxito de empresas españolas.

    • En este momento participarían: Telefónica I+D (quien cedería sus instalaciones) y DoubleYou.
    • Otros (a contactar): Rally Software, Códice Software, Juan Palacio, Proyectalis, Jorge Fernández (Agile Business Intelligence), …
    • Key Note: Se propone a Ángel Medinilla y algún speaker internacional.

  • Divulgar las metodologías ágiles en clientes y en quien toma las decisiones en las empresas (CEOs, CIOs, mandos medios, jefes de proyecto, etc.), explicando los beneficios y casos de éxito.

  • Crear un directorio de empresas ágiles españolas.

  • Crear contenidos en español donde explicar cómo trabajar con metodologías ágiles, problemas y soluciones.

  • Hacer talleres donde aprender y practicar técnicas ágiles como, por ejemplo, coding do jo’s: una empresa lo patrocina cediendo una sala de reuniones. Se define algo que hacer y en qué lenguaje. A partir de aquí una persona toma el rol de cliente y los demás, haciedo programación por pares y TDD en iteraciones van dando forma al producto. Estas reuniones están muy bien para dar a conocer estas prácticas, para dar a conocer cómo se trabaja con ciertas metodologías ágiles (para gente que no tenga mucha experiencia) o para aprender un nuevo lenguaje o framework (para aquellos que no lo conozcan aunque tengan experiencia con metodologías ágiles).

  • Fomentar la formación en metodologías ágiles en la universidad.

  • Crear un directorio de herramientas de gestión y de desarrollo (se podría utilizar el drigg para poner comentarios y puntuarlas).

 

Próximos encuentros ágiles en España:

 

 

 

Técnicas ágiles y CMMi nivel 2 en un proyecto de Banca

Introducción

Recientemente en Biko obtuvimos la certificación CMMI nivel 2. Tras un periodo de estudio de los procesos convenientes para el funcionamiento de la organización, estos fueron validados y aprobados mediante el SCAMPI.

Este nivel de la metodología formal se centra en determinadas áreas, como planificación, gestión de requisitos, métricas, y verificación y validación.

En Biko, CMMI ha servido para uniformizar criterios importantes sobre la gestión de los  proyectos, que dada la heterogeneidad de los múltiples proyectos desarrollados en la organización, ha sido un hito muy importante.

Pero CMMI en su nivel 2 no especifica nada sobre las metodologías de desarrollo o gestión del equipo, ni del proceso concreto de creación de software. Es por eso por lo que hemos ido un paso más allá, y hemos buscado técnicas para el mejor control del desarrollo.

Las metodologías ágiles de desarrollo van hacia otro objetivo que las metodologías formales. Se centran “en los individuos y sus interacciones más que en procesos y herramientas”. Algunas de las más importantes son las basadas en el concepto de “Lean development”, u otras más concretas como pueden ser “Scrum” y “XP”.

Nuestra idea era empezar a experimentar con los desarrollos con metodologías ágiles, en concreto con Scrum, para poder mejorar la eficiencia del equipo. En este artículo presentamos la primera aproximación que realizamos, nuestra implementación y conclusiones.

 

Escenario

Tras un proyecto desarrollado con algunos problemas para un cliente de Banca, se nos plantea hacer un segundo desarrollo. Es entonces cuando buscamos la solución que mejor pueda solucionar los problemas encontrados anteriormente.

Los problemas a los que intentamos dar solución:

  • Pérdida de control del proyecto por los desarrolladores. Conocen parte del proyecto, pero a veces repetimos soluciones diferentes para el mismo problema.
  • Se intentó entregar por iteraciones, pero estas nunca quedaban definidas, y pronto se perdió el control exacto de las funcionalidades incluidas en cada entrega.
  • Las peticiones de cambio generadas por un cliente muy pendiente del desarrollo del proyecto, eran muy numerosas. La gestión de requisitos mediante una hoja Excel no ayudaba demasiado.
  • El cliente quedó medianamente satisfecho con el producto final, pero éste quedó con carencias importantes. Además, la etapa de desarrollo fue muy dura tanto para el equipo como para el cliente.

Organización y Gestión

Para el segundo proyecto nos planteamos utilizar metodologías ágiles, para mejorar la eficiencia del equipo. ¿Por qué? Estos son algunos de los puntos que tomamos en cuenta como punto de partida, donde las metodologías ágiles podían ayudarnos más:

Como primera experiencia nos basamos en Scrum. Pero no la implementamos al 100%, realmente la adaptamos. Así que “no decimos que usamos Scrum”. Pero, ¿por qué lo modificamos?

  • El alcance ya estaba definido con el cliente. Los contratos a precio cerrado no son el mejor encaje para las metodologías ágiles.
  • Requeríamos un análisis previo, para la validación por el cliente, una fase inicial donde estudiásemos la globalidad del proyecto. En ese momento nos pareció la mejor solución para evitar los continuos cambios que se habían sucedido anteriormente. Cerrar el alcance en el inicio de una manera más clara no es un concepto demasiado ágil, pero las presiones por las desviaciones en proyectos anteriores nos hicieron pensar que podía ser útil.

Como este proyecto era la continuación tecnológica de uno anterior, minimizábamos el riesgo, y podíamos extrapolar mejor las conclusiones de la implantación.

  • Proyecto tecnológicamente conocido: El primer proyecto fue el que estableció las bases tecnológicas, y salvó los escollos más importantes en esta área. Teníamos mucho trabajo por hacer, para mejorar la plataforma creada, pero consistía en refactorizar elementos.
  • Cliente recurrente: conocíamos cómo trabaja, y podíamos adaptar nuestra manera de desarrollar para su satisfacción.

El equipo

El equipo, visto desde el prisma de sus roles tradicionales ha sido: dos desarrolladores, un diseñador, y un analista funcional y un jefe de proyecto. Realmente el equipo que trabajó bajo las premisas de gestión ágil de dedicación a tiempo completa al proyecto fueron todos excepto la gente de diseño, puesto que trabajaron en momentos más puntuales.

Los perfiles eran bastante distintos en cuanto a experiencia, conjugando dos personas con un año escaso, con otras de casi 10 años en el desarrollo de software. La autogestión del equipo fue un hecho desde el primer momento, teníamos claro qué tareas se debían realizar, y cada persona era autónoma para decidir cuáles realizar, compartiéndolo con el equipo o discutiéndolo. Las reuniones diarias y de planificación de iteración (Sprin) eran una asignación de tareas por acuerdo.

Desarrollo

La idea inicial era utilizar Scrum para el desarrollo del proyecto. Sin embargo, echando la vista  atrás no podemos decir que lo hayamos utilizado, puesto que hemos hecho modificaciones importantes, y no hemos aplicado todas sus técnicas.

Antes de empezar el ciclo de iteraciones hicimos una fase cero del proyecto:

  • Arranque del proyecto: Preparación del catálogo de requisitos (Product Backlog).
  • Fase 0: Análisis funcional, y diseño de la interfaz y su arquitectura. Esta fase fue requerida por el cliente para su validación.
  • Fase N, Iteraciones semanales: Trabajo definido por el equipo. Cierre con demostraciones de la versión y puesta en desarrollo para el cliente.

Nuestro grado de avance y situación lo llevamos simultáneamente en una herramienta de gestión de proyectos (JIRA) y en una pizarra blanca:

image005(1)

  • La pizarra proporciona una inmediatez del trabajo efectuado/restante que da una sensación de control del proyecto muy importante. Es un mapa del site que se puede ver con solo girar la cabeza, y ¡no hay que hacer un solo click! Scrum recomienda un tablero de tareas con “post-it”, pero creemos que esto es igual de útil.
  • JIRA nos proporciona soporte para asociar a las tareas documentación, partes de horas, comentarios de los desarrolladores, enlaces al código de Subversion…, a costa de un mayor gasto de gestión, pero que, una vez habituados a la herramienta, es muy escaso. Además también nos proporciona el EDT (Estructura de Desglose de Tareas) actualizado, basándonos en las tareas cerradas/abiertas y sus estimaciones.

    También sustituimos la gestión de cambios de requisitos, pasando del “Excel” a la gestión de tareas identificadas como “Nuevos Requisitos” en JIRA.

Por tanto, teníamos la información duplicada, en la pizarra y en JIRA, pero el coste de mantener ambos no es elevado. La pizarra proporciona inmediatez en la visión del proyecto, y JIRA nos proporciona trazabilidad con el código.

Por cada iteración definíamos qué trabajo íbamos a realizar para entregar (Sprint Backlog) como resultado de esa semana (Sprint).

Cada 15 días, además, realizábamos una reunión de seguimiento con las personas no directamente implicadas: gerente y diseñador. Estas reuniones se hacían de manera bastante informal, pero eran una práctica acordada en el desarrollo de CMMI. Daban más visibilidad del desarrollo a las partes implicadas.

Conclusiones

Este ha sido un proyecto de introducción de novedades en gestión del equipo de desarrollo de software. Estamos aplicando por ejemplo en otros proyectos una aproximación mucho más estricta de Scrum. Pero he aquí algunas conclusiones que podemos extraer:

  • Las iteraciones semanales son demasiado cortas. Este proyecto era de duración reducida, pero unas iteraciones tan cortas introducen mucho “ruido” del cliente demasiado cerca de la siguiente finalización de la iteración.
  • No aceptar cambios en el plan de iteración (solo corrección de “bugs” de la iteración anterior, para lo que se deja un tiempo) es una gran idea. Puedes controlar cómo funcionas respecto a tu planificación.
  • El equipo controla todas las partes del desarrollo. Las reuniones diarias de 10’ son puestas como ejemplo y destacadas por los integrantes del equipo como una maravillosa práctica. Los perfiles de menos experiencia se benefician en gran medida de las reuniones diarias, donde se les resuelve el 90% de sus problemas. Nunca se bloquean en un trabajo más de 8 horas sin que el equipo lo sepa. Todo el equipo involucrado ha destacado la utilidad de las reuniones diarias, especialmente la gente con menos experiencia.
  • El problema de un proyecto con horas cerradas sigue pendiente. Tienes unas horas de una estimación inicial al inicio de proyecto, que engloban a todas las funcionalidades, y realmente no ves y estimas adecuadamente las tareas hasta el principio de cada iteración.
  • La primera iteración o fase 0, es muy interesante, porque proporciona una base común para el trabajo posterior. En este caso no teníamos problema para la solución técnica, pero si no hubiese estado hecha en un proyecto anterior, posiblemente la hubiésemos planteado aquí. De esta manera podemos establecer una base de cómo realizar las cosas, útil especialmente trabajando con desarrolladores más inexpertos.

 

Artículos relacionados

 

Métricas ágiles y cuadro de mandos integral para Scrum

La métrica más importante en un proyecto ágil como Scrum es el valor que se está dando al cliente. Mediante esta métrica, el cliente puede conocer la velocidad con que retorna su inversión y saber cuándo ya no es necesario seguir con el proyecto, por que los beneficios pendientes de obtener ya no compensan sus costes.

Sin embargo, cuando se mide a una persona o a un equipo de una determinada manera, sus acciones pueden desviarse en exceso hacia ese objetivo y descuidar otros aspectos también importantes como, por ejemplo, la calidad, los costes, los riesgos, la sostenibilidad de la velocidad con que obtienen objetivos, etc. Por ello, puede ser necesario utilizar un conjunto de métricas de diferentes aspectos relacionados, creando de esta manera un cuadro de mandos integral ágil (agile balanced scorecard).

graficos-progreso-scrum

 
Selección y uso de las métricas
Respecto al valor aportado al proyecto, es recomendable que esté basado en un único indicador económico clave con el que el cliente pueda medir todos los objetivos del proyecto, de forma que permita guiar la toma de decisiones y la forma de invertir en el proyecto.
Para el resto del cuadro de mandos se debe escoger el mínimo número de métricas que permita tomar decisiones sobre los resultados del proyecto y las necesidades del cliente (tras un análisis causal de los problemas que están mostrando, siempre recordando que el uso de una métrica puede condicionar la actuación de las personas). Se debe minimizar tanto el coste e impacto que se añade al trabajo ordinario del equipo (hay que ir registrando lo que sucede, cosa que puede incluso desvirtuar la métrica) como su coste de recolección, proceso y presentación. Por todo esto, cuando un problema específico esté resuelto, hay que plantear si tiene sentido seguir recogiendo las métricas asociadas.
Es conveniente mostrar en el cuadro de mandos los objetivos de la iteración, entrega, proyecto, programa u organización, según sea el ámbito del cuadro de mandos (mostrar la velocidad con que se consiguen los objetivos del proyecto o guiar e informar sobre la estrategia de la organización y su cumplimiento).
En los equipos ágiles es común que las métricas surjan ante una necesidad del equipo, como una forma de mejorarse. Por ejemplo la velocidad del equipo puede ser una herramienta para que el equipo planifique y tome compromisos, e incluso para cuantificar una mejora.
Será fundamental presentar las tendencias de las métricas a lo largo del tiempo (los valores en un momento dado pueden deberse a situaciones puntuales), con diferentes niveles de agregación en función de las necesidades: diario, iteración, etc.
 
Métricas ágiles del cuadro de mandos
La mayoría de las métricas más importantes derivan de las herramientas propias de Scrum (la lista de requisitos priorizada, la lista de tareas de la iteración y los gráficos de trabajo pendiente), por lo que el momento natural para actualizar este cuadro de mandos es tras la retrospectiva de la iteración.
Notar que en una gestión ágil de proyectos carece de sentido utilizar algunas de las métricas más utilizadas en proyectos tradicionales o en cascada, como por ejemplo:
  • El porcentaje de completitud de un objetivo o requisito: en un proyecto ágil, para poder determinar cuando se completa un requisito o entrega se utiliza concepto de esfuerzo pendiente, así como qué objetivos están completados o cuáles no (al cliente no le interesan los que están en curso ya que no puede hacer uso de ellos)
  • Los diagramas de Gantt: no aportan más información que la que aportan las herramientas propias de Scrum.
Las métricas de uso más común se muestran en negrita. Las que no aparecen en negrita se muestran como ejemplos de métricas que se pueden utilizar de manera más temporal para analizar problemas concretos.
Métricas de productividad y efectividad de la entrega
  • Velocidad con que se completan objetivos/requisitos en cada iteración. Idealmente debería aumentar con respecto al tiempo (productividad). También permite ir extrapolando la fecha de finalización del proyecto en función de cuando se vaya a completar todo su alcance.
  • Tiempo de entrega de un requisito tras su petición o Lead Time (responsividad a necesidades del cliente, Time to Market, tiempo de servicio), en función de la criticidad de la petición (urgente, etc.) y cumplimiento de los Acuerdos de Nivel de Servicio (ANS / SLA).
  • Urgencias y prioridad/valor de los requisitos completados, para comprobar si existe desalineamiento con los objetivos del proyecto y/o la estrategia de la organización.
Métricas de resultados del proyecto
  • Velocidad con que se aporta valor al negocio (desde el punto de vista del cliente).
  • Valor acumulado.
  • Requisitos completados en la iteración.
  • Próximos requisitos a desarrollar.
  • Cambios incorporados y requisitos añadidos sobre el alcance inicial del proyecto.
  • Número de requisitos completados respecto al total de requisitos (métrica que también permite observar cambios de alcance).
  • Días de trabajo ideales pendientes (métrica que permite proyectar la fecha de finalización del proyecto).
  • Desviación de resultados de proyecto respecto a planificación inicial.
Métricas de situación financiera
  • Retorno de Inversión (ROI) pendiente, el valor pendiente respecto al coste pendiente, para saber cuándo finalizar el proyecto (ver la cláusula de finalización anticipada del contrato en el artículo Un contrato ágil para Scrum).
  • Presupuesto disponible y/o presupuesto gastado.
  • Desviación financiera respecto a la planificación inicial.
Métricas de calidad
Expectativas:
  • Satisfacción del cliente / usuario, respecto a los resultados del proyecto y a la colaboración con el equipo.
  • Ambiente en el equipo
Calidad funcional:
  • Incidencias (defectos encontrados por el cliente o usuarios del producto), por estado y por criticidad.
  • Errores (defectos detectados internamente, bugs), por estado y por criticidad.
  • Cobertura de las pruebas.
  • Trazabilidad.
Mantenibilidad:
  • Días de deuda técnica.
  • % de código en SCM (e.g. GIT), motor CI (e.g. Jenkins),  herramienta de control de calidad de código (Sonar).
    • Separando las partes «nuevas / refactorizadas» del monolito.
  • Cumplimiento de estándares de codificación, normativas, regulaciones, etc.
  • Comentarios en el código.
  • Complejidad ciclomática del producto.
  • Tamaño de las operaciones.
  • Calidad de la documentación (existencia y cobertura de la documentación funcional, técnica, de pruebas, de implantación, operativa, etc.).
Métricas de riesgos, impedimentos, proceso y mejora continua
  • Riesgos (severidad y mitigaciones) e impedimentos: considerando las dependencias o sinergias con otros equipos o proyectos, la implicación del cliente, los problemas tecnológicos, el resultado de las retrospectivas, etc.
  • Lecciones aprendidas.
  • Actividades de mejora a planificar (comunicaciones, formaciones, soporte, herramientas, etc.).
  • Uso de prácticas específicas: número de integraciones, tiempo de refactorización, de TDD, revisiones expertas, etc.
  • Situaciones anómalas: sobreesfuerzo, requisitos no completados, terminaciones anormales de iteración, interrupciones, sospechas de mala aplicación del proceso (por ejemplo, si el cliente se muestra sorprendido en la demostración de la iteración), etc.
  • % de personas que no intervienen en las reuniones diarias de sincronización.
 
Conclusiones sobre el estado del proyecto
Este apartado debe contener un resumen con las métricas más importantes y las relaciones entre ellas, así como las lecciones aprendidas y próximas acciones de mejora (tras un análisis causal de problemas como, por ejemplo, el que se realiza en una retrospectiva), de manera que el cliente pueda tomar decisiones informadas y dirigir los resultados del proyecto.
Hay que recordar que muchos de los problemas detectados y disfuncionalidades de la organización ya estaban ahí antes de utilizar una gestión ágil de proyectos como Scrum, no son el resultado de aplicarla. La transparencia que proporciona Scrum los hace más visibles, lo cual ayuda a priorizar y tomar decisiones (de manera conjunta con las personas implicadas para consensuar la mejor solución). Para ello es necesario disponer del máximo apoyo de la Dirección para alinear comportamientos, recursos y resultados con la estratégia de la organización.
 
Más información