¿Qué prácticas agile debemos aplicar en los proyectos?

Muchas empresas y startups del ámbito tecnológico se encuentran en el mismo dilema. ¿Qué prácticas ágile deben priorizar su aplicación? No existe una respuesta única puesto que todo depende de múltiples circumstancias. En este post intentaremos analizar una situación bastante común y exponer qué prácticas ágile deberían ser aplicadas para maximizar el rendimiento del equipo.

Estamos hablando de una startup o empresa de base tecnológica que dispone de producto propio y hace proyectos para clientes. Es una situación bastante común y que requiere cierta flexibidad en función de cada caso. Para entender un poco mejor la situación se trata de producto propio cuando la base de su negocio se basa en la comercialización de dicho producto. En la mayor parte de los casos nos referimos a software pero también aplica a otros proyectos tecnológicos.

El producto propio cuenta con la característica de que su evolución no termina nunca. Estos productos deberán irse adaptando al mercado y sus aplicaciones se verán forzadas a mejorar y innovar. Los proyectos de clientes basados en el producto propio cuentan con una menor evolución posterior, esto es tarea de la propia empresa ir incorporando nuevas soluciones a un proyecto existente. Aún así, salvo algunos casos, existe menor evolución posterior.

Estas son las características de un proyecto  para tener en cuenta a la hora de priorizar las prácticas agile:

• Tipo de proyecto en función de su evolución posterior o si se trata de desarrollo de producto.
• Esfuerzo a realizar, complejidad y número de personas implicadas.
• Conocimiento de la tecnología y del tipo de negocio por parte del equipo.
• Conocimiento del proceso de trabajo.
• Conocimiento entre los miembros del equipo, ¿han trabajado antes juntos?
• Aspectos a mejorar dentro del proyecto: calidad, tiempos de entrega, productividad...

En este post nos centraremos en tres puntos importantes en la priorización de prácticas agile: tipos de entrega, requisitos y documentación, desarrollo personalizado o de producto.

Tipos de entrega

Para las entregas de producto es ideal realizar demos periódicas (cada X sprints) al equipo y explicar las novedades al cliente final. Debemos centrar estas entregas en proporcionar valor al usuario final, de modo que la métrica a tener presente sería el valor entregado por puntos del poker plan. En este otro post explicamos cómo utilizar el poker plan cómo una herramienta de planifación.

Para las entregas en proyectos cortos y de poca evolución posterior el éxito dependerá de la visión del cliente. Del valor aportado para el cliente. Normalmente estos proyectos van muy ajustados en el tiempo, de modo que existe poco margen para la innovación o cambios radicales a medio desarrollo.

En el equipo de desarrollo es muy importante mantener siempre la propiedad colectiva del código. Debemos evitar encasillar determinadas tareas a una persona porqué el hizo la primera parte del proyecto o producto. Para ello el equipo debe trabajar en crear las dinámicas suficientes para compartir el conocimiento sobre todas las partes.

A veces determinados proyectos con clientes repiten ciertas acciones que requieren un desarrollo personalizado. En estos casos el product owner debe analizar cómo mejorar la solución, aportando valor al cliente y evitando estos desarrollos personalizados y repetitivos. Cuando se aplican estos cambios de debe mantener siempre la visión del producto, mejorar su aplicación y no corromperla en el futuro.

Definición de requisitos y documentación de la solución

En los proyectos para clientes con poca evolución posterior la definición de requisitos es muy importante, puesto que es necesario saber muy bien en qué consiste para poder realizar el presupuesto. Del mismo modo los requisitos deben enlazar con las expectativas esperadas por el cliente. De no ser así es probable que se generen situaciones tensas y con alteraciones en la solución.

En el caso de producto propio estos requisitos y la gestión de cambios pasa a ser más libiano. Por un lado no existe la necesidad de negociar las posibles desviaciones con un cliente externo. Por el otro lado es responsabilidad interna de la empresa maximizar el valor aportado por el producto, de modo que se entienden en esta linea todos los cambios, modificaciones y adiciones de funcionalidades.

En este sentido son muy útiles las historias de usuario para la descripción de estas funcionalidades. De este modo se da la libertad y autonomía al equipo para escoger cómo es la mejor manera de aplicar la solución. Las historias de usuario nos ayudan a centrar el desarrollo en aportar valor al producto y los criterios de validación nos ayudan a aceptar la evolución del producto. En este post puedes ver como definir los requisitos con historias de usuario.

Haciendo referencia a la documentación del proyecto es mucho más importante la en productos de largo recorrido que en proyectos de clientes de poca evolución posterior. El problema de la documentación es que una documentación desactualizada es como no tenerla.

Desarrollo personalizado o de producto

Normalmente no se tratan igual los proyectos de clientes que el desarrollo de producto. Aunque los niveles de calidad para su aceptación son los mismos existen ciertas diferencias en las prácticas agile utilizadas.

En el desarrollo de producto propio debemos priorizar:

• Propiedad colectiva del código
• Unit testing
• Refactors
• Pull requests
• Gestión de bugs
• Pruebas de rendimiento
• Pair programming
• Integración continua

En el desarrollo de proyectos de clientes con poca evolución posterior deberíamos priorizar:

• Propiedad colectiva del código
• Integración continua
• En proyectos de más de 2 meses de dedicación
• Unit testing
• Gestión de bugs

Otro punto importante es detectar cuando una funcionalidad personalizada para un cliente debe pasar a formar parte del producto. En Please Networks usamos las llamada regla del 3:

Cuando una funcionalidad personalizada de cliente se repite 3 veces se hace una abstracción y se convierte en parte del producto.

Si quieres leer más sobre este tema recomendamos la lectura de estos dos artículos de la web Proyectos Agiles:

• Priorización de prácticas ágiles en desarrollo de producto
• Priorización de prácticas ágiles en un proyecto corto

Te ha gustado el post? No olvides en suscribirte en nuestra newsletter! Ayúdanos a dar a conocer Scrumízate y comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!