El pasado 27 de Septiembre se llevó a cabo la reunión mensual de la comunidad Agile Perú, siempre es grato ver rostros conocidos pero sobre todo ver como cada vez nuevas personas se interesan por la comunidad, agilismo y por el aporte que los distintos miembros realizan a los temas tratados en cada sesión.
En esta oportunidad continuamos usando el formato Open Space, con el que buscamos conversar y compartir conocimientos y distintas experiencias relacionadas a los temas propuestos.
Los temas que se trataron fueron:
- Interacción UX-Dev en equipos ágiles
- P.O.W.E.R. Start
- DevOps como cultura
- ¿Quién impulsa a los integrantes de un equipo?
- Documentación necesaria para QA
Interacción UX-Dev en equipos ágiles
En este caso se trataron dos preguntas puntuales, para las que surgieron distintos aportes, todos muy bien valorados y que puedo resumir en lo siguiente:
1. ¿El equipo de desarrollo ha tenido la necesidad de recursos por parte del equipo VD (Visual Design) pero por distintos motivos no estaban listos?
Se mencionó que en este caso es importante tener en cuenta que actualmente para llegar a un recurso (pantalla, asset, etc) se pasa por todo un proceso de user research, user interviews, luego de las cuales se pueden plasmar wireframes y prototipos que finalmente serán diseñados.
Con todo ese proceso de por medio, el tiempo que puede tomar obtener un recurso puede ser extenso; por lo que se plantea que previo a la construcción del producto exista un tiempo apropiado en el que se pueda realizar la “etapa UX” en donde al menos se puedan obtener los recursos necesarios para 2 o 3 Sprints de desarrollo.
2. ¿En algún proyecto en el que hayan participado, el equipo UX propone funcionalidades que en ese momento no son factibles técnicamente?
Aquí la solución parece ser bastante simple: Comunicación, es importante que se fomente una constante interacción entre el equipo técnico y equipo UX; es recomendable tener conversaciones acerca de la factibilidad técnica de los prototipos a ser diseñados y así no llevarse “sorpresas” mientras se construye el producto.
P.O.W.E.R. Start
Posiblemente muchos de nosotros hemos tenido reuniones que parecen no tener propósito, donde los resultados no son los esperados, o en donde simplemente se acuerdan más reuniones; a cuantos nos ha pasado que hemos facilitado una planning o una sesión de retrospectiva en las cuales podemos percibir la frustración de los asistentes al no encontrar el sentido de la reunión; esto puede ser mucho más común de lo que nos imaginamos.
El expositor nos presentó la técnica POWER Start que puede ser usada para planificar tus reuniones de manera que se mantenga el foco y se obtengan los resultados esperados.
POWER es el acróstico para:
Purpose (¿Por qué es esta reunión necesaria?)
Outcomes (¿Qué queremos lograr? ¿Dónde está el valor de la reunión?)
What’s in it for them (¿Por qué los convocados les debería importar y asistir a la reunión?)
Engagement (¿Cómo aseguramos que todos estén enganchados en la reunión?)
Roles and responsibilities (¿Quién hace qué?)
Realizamos una sesión grupal de 3 personas en donde conversamos acerca de alguna reunión complicada en la que vayamos a participar o que debamos facilitar y seguimos la guía de Reuniones Poderosas basada en POWER Start, técnica con la que logramos identificar cada uno de los puntos “Power” para lograr una reunión exitosa, en donde los asistentes se sientan satisfechos con el resultado obtenido.
DevOps como cultura
En este punto se trató acerca del entendimiento de DevOps como una cultura en la organización, cultura en donde se trata de conseguir una alineación entre el negocio y TI, incrementar la colaboración entre desarrollo y operaciones.
En esta cultura DevOps es importante lograr conformar equipos multidisciplinarios (Desarrolladores, testers, QA, operaciones) en el que el objetivo sea claro; desarrollar software que aporte valor al usuario final.
Un pensamiento compartido en la conversación fue que DevOps es una cultura de conversación, interacción y comunicación; en donde se presenta el respeto entre las personas, el conocimiento compartido y no existen súper héroes; el apoyo entre miembros del equipo es constante. Teniendo en cuenta estos puntos se puede superar cualquier barrera y se obtendrán grandes beneficios a nivel de personas, equipos y organización.
¿Quién impulsa a los integrantes de un equipo?
En base a este tema se originó un debate muy interesante, en donde se habló de psicología, ética, entre otros.
El expositor planteó la pregunta acerca del perfil o características adecuadas para quien tenga la gran responsabilidad de guiar a los miembros de un equipo. ¿Con qué ética el Scrum Master puede cumplir con esto? ¿No debería el equipo u organización apoyarse en un psicólogo o sociólogo?
Existen Scrum Master, Agile Coaches, Líderes de Proyecto, personas en general; con “habilidades blandas” bastante desarrolladas en base a la experiencia y sin haber llevado estudios de psicología, con lo cual pueden guiar el crecimiento continuo del equipo, pero también hay que tener claro que pueden existir momentos en que cualquier de los perfiles previamente mencionados podría necesitar el apoyo de un psicólogo o sociólogo para resolver problemas puntuales relacionados al equipo.
Un comentario que destaco es “Un Scrum Master no debe dar nada por sentado, debe estar en constante aprendizaje, capacitación, interacciones humanas; para poder tener las mejores herramientas que lo ayuden a impulsar al equipo y a las personas que lo conforman”
El expositor nos comparte un artículo sobre el tema.
Documentación necesaria para QA
La expositora nos planteó el escenario proveedor-cliente, en donde el proveedor cuenta con perfiles QC/QA como parte del equipo de desarrollo; en este escenario al finalizar con un incremento de producto (incluyendo las pruebas internas); el producto debe pasar por una etapa de pruebas/certificación por parte del equipo QC/QA del cliente.
Y ahí es donde surge la pregunta ¿Qué documentación le debemos proporcionar al equipo QC/QA del cliente?
Se sugirió el uso de Behavior-Driven Development (BDD) en donde se utiliza un lenguaje común para unir a la parte técnica y de negocio, en donde las pruebas de aceptación se escriben como historias de usuario y los criterios de aceptación son escenarios.
Si bien existen muchas alternativas (Casos de Uso, Diagramas, etc.), una opinión compartida respecto a este tema, es que la historia de usuario, es una herramienta para fomentar lo más importante, que es la comunicación e interacción entre los miembros del equipo a fin de despejar cualquier duda existente.
Además, de ser posible, estos perfiles QC/QA podrían participar desde etapas tempranas de la construcción del producto.
Como siempre el aporte de estas sesiones son de gran valor.
Comunidad, Comunicación, Colaboración, Compartir conocimiento.
Autor: Ibrahim López