search
top

Las responsabilidades de los roles en DAD (Disciplined Agile Delivery) Parte (2/2)

– Post escrito por María Morales (@MaMoralesMC) y Noemí Navarro (@nnsanchez92).

La semana pasada explicamos los roles primarios en DAD, ya adelantamos que además hay roles secundarios para ayudar a escalar la agilidad. En este post vamos a hablar de estos roles secundarios y además la transición de pasar de los roles tradicionales a los roles de DAD. Así que vamos con ello…

Roles secundarios en DAD

Para seguir la misma estructura del post anterior os dejamos una imagen ilustrativa y a continuación explicamos cada uno de ellos.

Roles secundarios en DaD

Roles secundarios en DaD

 

  • Specialist: cuando escalamos la agilidad, es probable que se requieran especialistas, por ejemplo, en equipos muy grandes uno o más analistas de negocio pueden unirse al equipo para ayudar a explorar al PO las necesidades de lo que se está desarrollando.

 

  • Independent Tester: como suponemos que sabréis, la mayoría de las pruebas las hacen los propios desarrolladores (sobre todo las pruebas unitarias, aunque alguna vez hemos hablado de técnicas como el ping pong testing, pair testing o #MobTesting para que esto no ocurra). Alguno equipos de DAD son apoyados por un equipo de pruebas independiente que trabaja en paralelo validando su trabajo.

 

  • Domain Expert: El Product Owner representa a los Stakeholders, como ya hemos visto, pero pueden no ser expertos en un tema en concreto como para realizar buenas Historias de Usuarios por ejemplo, para ello, este traerá una persona con el rol de Domain Expert para trabajar con el equipo, por ejemplo, un experto en impuestos para explicar los detalles de una necesidad o un ejecutivo de patrocinio para explicar la visión del proyecto.

 

  • Technical Expert: a veces el equipo de desarrollo puede necesitar ayuda de expertos técnicos, en temas como por ejemplo configuración de scripts, administrador de BBDD, un experto en experiencia de usuario… Los expertos técnicos son contratados temporalmente para ayudar al equipo a superar algún problema técnico y transmitir así esos conocimientos a uno o más desarrolladores del equipo.

 

  • Integrator: si las personas de un equipo están organizados en subequipos, estos suelen ser responsables de uno o más subsistemas. Cuanto mayor sea el equipo más grande y complicado es lo que se está desarrollando por lo que es posible que en estas situaciones necesitemos una o más personas dedicadas a ayudar a integrar el sistema completo. En equipos pequeños el rol primario Architecture Owner será el que ejerza el rol de Integrator. Los Integrators a menudo trabajan estrechamente con el equipo Independent Tester, si lo hay, para realizar pruebas de integración del sistema regularmente durante todo el proyecto.  Normalmente, este papel de integrador sólo se necesita a escala para soluciones técnicas complejas.

¿Cómo encajan los roles tradicionales en DAD?

Aunque nos gusta nombrar cada vez menos los roles tradiciones nos parece interesante enseñaros una transición que hace Scott Ambler en el libro hacia los roles de DAD que hemos visto en esta serie de posts.  Ya que para una persona que haya trabajado con agilidad a pesar de las diferencias le resultará más fácil entender la transición que una persona que venga de un equipo que utilizaba el ciclo de vida en cascada para gestionarse.

En color verde representamos las relación más probable, y en color azul las otras opciones que se pueden dar.

De los roles tradicionales a los roles en DAD

De los roles tradicionales a los roles en DAD

Terminando…

En estos  posts, hemos querido hablarte más en concreto sobre los roles en DAD, ya que últimamente el tema de los equipos. El peopleware está siendo muy importante (aunque debería haber sido desde siempre).

Además, os adelantamos, que para el año que viene, 233 Grados de TI está preparando un curso con el mismísimo Scott Ambler autor de varios libros importantes sobre DAD ¡ya os iremos contando más!

María Morales

María Morales

Practitioner at 233 Grados de TI
Interesada y apasionada en todo aquello que tenga relación con metodologías ágiles y calidad software, gestión de proyectos, modelos de procesos, DevOps y sobre todo en gestión de equipos.

Actualmente, colabora activamente con la Empresa y Comunidad 233, dando formación y mentoring ágil además de organizando eventos, charlas e iniciativas para difundir el conocimiento sobre Ingeniería del Software.

Profesionalmente dedicada al mentoring ágil en 233 Grados de TI, calidad software, testing ágil, a la implantación en importantes organizaciones de Scrum, agilidad, DevOps, Product Owner, peopleware, automatización de pruebas web y móviles con BDD, Calabash.

Certificada por la Scrum Manager como Scrum Manager con credenciales de profesora, entre otras certificaciones, como por ejemplo en GIT y GitHub.
María Morales

Dejar una respuesta

Tu dirección de correo electrónico no será publicada.

top