Concrete Logo
Hamburger button

Los seis papeles en un equipo ágil

  • Blog
  • 18 de Junho de 2019
Share

Ya dejamos claro en varios momentos en este Blog que sólo trabajamos con métodos ágiles aquí en Concrete Solutions. Esto es porque creemos que el proceso de desarrollo de Waterfall es un proceso superado que nunca debería haber sido aplicado en software. Este proceso tiene el problema de asumir una realidad estática en la que las personas omniscientes prevean el futuro. ¿Usted cree que saber el problema a resolver y la solución para antes de comenzar a creará su producto finalmente?

Este post tiene por objetivo explicar un poco de cómo funcionan los equipos ágiles, destacando la responsabilidad y la importancia de cada papel dentro de ellos.

Antes de eso, debemos resaltar que estamos analizando los equipos ágiles que funcionan para el desarrollo de productos digitales. Cada producto también tiene sus peculiaridades y funciones específicas que pueden interferir en esa estructura de equipo. Aquí, nuestra intención es mostrar un equipo básico, con el que desarrollamos la mayor parte de nuestros productos.

También tenemos algunos conceptos que debemos explicar antes de entrar en los papeles. El trabajo en métodos ágiles se divide en “sprints”, períodos de tiempo predefinidos, que siguen un “backlog”, lista organizada y priorizada de lo que hay que hacer. El backlog se define en la planificación, que precede a todo sprint, y revisado al final de ella, en lo que llamamos “review”. Diariamente, el equipo tiene reuniones rápidas (de no más de quince minutos) llamadas “dailys”, en las que los participantes presentan lo que cada uno resolvió entre un día y otro, eliminan las tareas y asumen nuevas responsabilidades.

Dicho esto, vamos a los papeles:

1. Product Owner (PO) o Dueño del Producto

El PO es el CEO del producto. Es el responsable de la definición de cuál va a ser el producto, considerando las funcionalidades que tendrá. Debe tener una visión general de todos los sprints y administrar el backlog de acuerdo con esa visión, priorizando las tareas. Es el product owner quien dice al equipo lo que tiene que hacer, y cuándo.


2. Scrum Master (SM)

El Scrum Master es el “coach” ágil del equipo. Se asegura de que todas las prácticas ágiles sean seguidas, es decir, garantizar que la diaria sea realizada, cuidar del tiempo del sprint, etc. También es función del SM proteger al equipo, asegurando que no se comprometa con más de lo que puede desarrollar y gestionar las expectativas de los stakeholders del producto. También es el scrum master quien resuelve problemas de relación entre el equipo y los impedimentos externos que puedan obstaculizar el desarrollo del producto.

3. User Experience (UX), Diseñador o Diseñador de Experiencia de Uso

UX es quien define la usabilidad del producto. Es el puente entre el desarrollo y el usuario final, el que va a usar el producto. Es decir, al UX cabe decidir el diseño y el flujo que la información debe seguir. Es él quien define cuántas pantallas, lo que tendrá en cada pantalla, donde queda cada enlace, etc.


4. Equipo de Desarrollo

Es quien realmente hace el producto. Puede ser formada por una o hasta siete personas, que no tienen funciones predefinidas. El equipo es auto gestionado y auto organizado, es decir, los propios miembros eligen quién será el responsable de determinada tarea y cobran la realización de ella. En este punto, es importante resaltar que el equipo debe tener todos los perfiles necesarios para la ejecución del trabajo. No sirve, por ejemplo, tener cuatro personas para back-end y ninguna de front-end.

5. Growth Hacker o Marketing del producto

La persona cedida normalmente por el marketing de la empresa, el growth hacker es responsable de traer tracción para el producto durante la fase de validación. Este papel es responsable de hacer que la gente sepa que el producto existe y involucrar a esas personas para que ellas usen durante el desarrollo, ya que es a través de la retroalimentación de esas personas que el equipo valida hipótesis y sigue o cambia de dirección. La diferencia entre el crecimiento del crecimiento y el marketing tradicional es que el primero tiene énfasis en el uso de herramientas más analíticas, ya que su objetivo es validar hipótesis que influyen en el desarrollo del producto, y tiene un presupuesto más limitado. Por eso, desarrolla campañas enfocadas en grupos de usuarios específicos.

6. Devops

Es el responsable de codificar la infraestructura en la que será montado el producto. A diferencia del papel de infraestructura tradicional, Devops crea una documentación viva del entorno, que puede reutilizarse.

Antes de terminar, es importante observar que todos estos papeles son interconectados y parte de un equipo. Si no tenemos el PO, el equipo puede desarrollar un producto equivocado y todo el presupuesto se gastará en ingeniería. La frase que resume este punto es “no importa cuán bueno sea su equipo si usted no da algo relevante para él hacer”. Sin el PO, el equipo va a desarrollar un montón de códigos desconexos de la realidad, que puede no convertirse en un producto efectivamente “entregable”, mucho menos un producto exitoso.

La falta de un scrum master puede comprometer el tiempo en que se crea el producto. El equipo puede tomar más tareas de lo que efectivamente puede ejecutar, y no desarrollar en el tiempo adecuado, mientras que los stakeholders pueden tener sus expectativas frustradas. Va a faltar cadencia en el desarrollo del producto. Sin el equipo de desarrollo, no tiene producto. Sin UX, no tenemos garantía de que el producto va a ser “usable”, es decir, que el usuario podrá utilizar lo que está creando. Sin el Devops, no habrá una manera replicable, automática y documentada para la creación de ambiente para el desarrollo, control de calidad y producción, mientras que sin el creador de crecimiento nadie sabrá que su producto existe y usted no va a poder validar sus hipótesis, ni generar el trazado y el compromiso.

Al final, puede ser hasta que el producto salga, pero no aquel producto que usted quisiera construir y ni en la velocidad que usted esperaba. Además, es muy probable que su presupuesto termine mucho antes de su producto.

¿Estas de acuerdo con la estructura que describimos? ¿La utilizas en tu empresa? ¿Tienes dudas en cuanto a algún papel?

¡Deja tu comentario!