En este encuentro se utilizó un diagrama de prácticas ágiles para priorizarlas considerando su aplicación en el desarrollo de producto en su punto inicial (por ejemplo, en una startup).

La priorización de las prácticas difiere del caso tratado en el encuentro anterior, en que se evaluaron el uso de estas prácticas en el caso de un proyecto “corto”, de 3 meses, y sin evolución posterior. Los factores que más condicionan esta diferencia de priorización son la duración del proyecto y, por consiguiente, el grado de responsabilidad del equipo sobre su calidad técnica (la facilidad de mantenimiento/crecimiento del producto a posteriori).

Hacer clic en la imagen para ampliarla

A continuación se muestran las principales diferencias en la priorización de prácticas:

 

• Demo cada 2 semanas y cliente siempre disponible. Pasan a ser un Must. el éxito en desarrollo de producto depende del enfoque en proporcionar valor al usuario / consumidor final por parte de todos (tanto del cliente como del equipo, al cual se está pagado con stock options). Es por eso que la métrica de proyecto de valor entregado por unidad de tiempo también pasa a ser un Must. Por el contrario, en un proyecto corto, su éxito suele depender más de la visión del cliente. Él tiene que saber qué quiere obtener en ese espacio de tiempo, por que no hay mucho margen para una gran innovación o cambios radicales (eso no quita que existan proyectos cortos en que el equipo tiene que aportar mucho en definición de producto, incluso más que el cliente).
• Historias de usuario. Pasa a ser un Must. Es muy importante tener foco en el valor aportado al usuario final o consumidor. Como se ha comentado anteriormente, en el caso del desarrollo de producto hay mucho más interés en este valor que en un proyecto de 3 meses. Asimismo este valor será de gran ayuda para priorizar el Product Backlog.
• Modelo de Dominio. Pasa a ser un Must. Es un mapa conceptual que permite tener un vocabulario común entre las personas de negocio y el equipo de desarrollo, por lo que debe estar claro y bien definido. Se elabora en la iteración 0 para dar soporte a la primera release y se va refinando cada iteración. En el caso de un proyecto corto donde sólo se utilizaba durante 3 meses era un Have por que podría bastar con el esquema de base de datos.
• La gestión de cambios de requisitos deja de ser un Have, dado que no hay que negociar desviaciones con un cliente externo. El control de los resultados del proyecto, del valor proporcionado, es una responsabilidad interna en la empresa, con lo que todos los cambios, modificaciones y adiciones de funcionalidad se entienden como necesarios.
• Move people around y propiedad colectiva del código. Pasan a ser un Must. En la construcción de producto hay que asegurar el collective ownership y no perder conocimiento si en algún momento desaparece algún miembro del equipo. En un proyecto corto esto era menos perjudicial, dado que es inferior la probabilidad de que marche alguien con un conocimiento exclusivo y muy grande del producto.
• Paso sostenido 40 horas a la semana. A corto plazo es un Have en una startup donde para aumentar su implicación el equipo incluso está pagado con stock options, con lo que puede “apretar” más para sacar la primera release. A medio/largo plazo debería ser un Must.
• Hoja de cálculo o aplicación para seguimiento del Sprint. Deja de ser un must si se utiliza un Tablero de Tareas.
• Los spikes (también llamados “balas trazadoras” o pruebas de concepto), aún sin aportar valor de negocio, son de especial importancia en el desarrollo de producto, dado que permiten desechar o validar soluciones tecnológicas (por ejemplo averiguar si un Framework va a mejorar la velocidad de desarrollo o si va a llevar a un callejón sin salida por que no soluciona una problemática), así como obtener una estimación del coste de un desarrollo masivo de aspectos concretos del producto. Es importante que un spike se realice dentro de un timebox, para forzar la toma de decisiones.
• El refactoring sin miedo pasa a ser refactoring sin piedad, dado que el equipo se juega poder construir de manera sostenida en el futuro.
• Peer reviews. Pasan a ser un Must. Dado que la empresa va a tener que vivir de este producto durante varios años y es muy posible que en siguientes iteraciones el código lo tengan que ver otras personas (en parte debido a las prácticas de Move people around y propiedad colectiva del código).
• Gestión de defectos. Pasa a ser un Must. Posiblemente ya no sea suficiente o posible resolver los defectos ASAP para olvidarse de ellos, por lo que es importante disponer de un soporte electrónico adecuado para gestionar  defectos y obtener estadísticas que permitan averiguar qué está sucediendo.
• Pruebas de rendimiento. Pasan a ser un Must.
• Métricas de proceso. Pasan de no ser especialmente relevantes en un proyecto corto a ser un have en desarrollo de producto.
• Programación en parejas. Es conveniente ir realizando esta práctica aunque sea de manera ocasional, planificando un número de horas por iteración o escoger para ello historias de usuario concretas. 

 

Otras observaciones:

• En el caso de desarrollo de producto en un entorno competitivo, es especialmente importante construir con calidad interna para tener “cintura” a la hora de hacer cambios y conseguir un paso sostenible.
• Los casos de prueba de aceptación sirven como checklist de completitud de las historias de usuario, aunque no deben de servir como excusa ni “descarga” para decir “he probado lo que había escrito, si no funciona es por que no estaban todos los tests identificados”.
• Los casos de prueba de aceptación también actúan como TDD. El hecho de escribirlos y pensar en cómo se probará una funcionalidad, cómo debe comportarse el sistema (o BDD, Behaviour Driven Development),  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.
• La estimación siempre debe ser realizada por el equipo que vaya a ejecutar el proyecto. De esta manera será más realista, por tener en cuenta sus diferentes conocimientos, experiencias, fortalezas y debilidades. Recordar que como característica básica de los métodos ágiles, la estimación y planificación ágil permitirá calcular el ROI en función del tiempo y del gasto, así como saber qué cabe en cada release.

 

Artículos relacionados

• Priorización de prácticas ágiles en un proyecto corto – IX y X encuentros ágiles en 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.

Nota del system administrator de ProyectosAgiles.org:

Si estás viendo este artículo a través del RSS de ProyectosAgiles.org, asegúrate de estar accediendo a través de la siguiente URL: /wordpress/rss.xml

Se ha detectado que (por razones históricas) también se está accediendo desde: http: //www.proyectosagiles.org/taxonomy/term/11/0/feed, que sólo muestra un conjunto muy reducido de artículos.

• planificación_proyecto