– Post escrito por María Morales (@MaMoralesMC) y Noemí Navarro (@nnsanchez92).
Siguiendo con los posts sobre Mob Programming:
- Mob Programming: un único ordenador para todo el equipo (más allá del pair programming)
- #MobProgramming: caso de estudio y experiencias
- ¿Cuál es número óptimo de personas en #MobProgramming?
Hoy queremos contaros más datos que consideramos importantes sobre el Mob Programming y sus diferentes tendencias como el Mob Testing del cual hablábamos en el post #MobTesting: uniendo #Mobprogramming y Testing Ágil.
Antes de empezar os recordamos que en las redes sociales se hace uso del hashtag #MobProgramming y #MobTesting y además os dejamos una de nuestras últimas fotos (que seguro la habréis podido ver por Twitter).
Profundizando en #MobTesting…
Cuando hacemos talleres de Mob Testing y consideramos que somos muchos podemos utilizar Mob con audiencia del cual hablábamos en el post ¿Cuál es número óptimo de personas en #MobProgramming?.
De esta manera cambia bastante la forma de llevar a cabo el Testing Exploratorio tradicional a las sesiones de Mob Testing donde podemos intercambiar ideas, mejorar las habilidades de comunicación, mejorar los hábitos de Testing…
Para ello existen varias técnicas de comunicación que las comentamos a continuación.
¿Comunicación específica en Mob Testing?
Según Llewellyn Falco cuando hacemos sesiones de Mob Testing basándonos en Testing Exploratorio (te dejamos un post que escribimos sobre #MobTesting: uniendo #Mobprogramming y Testing Ágil) podemos utilizar la comunicación llamada Strong-Style Pairing (utilizaremos el término en inglés porque nos resulta más cómodo), nace del Pair Programming (también te dejamos un post del blog sobre Pair Programming ¿Beneficios del pair programming? ¿Dos programadores en un solo ordenador es perder medio equipo?) pero se utiliza en Mob Programming y por lo tanto en Mob Testing y no nos hemos referido a ella como tal hasta el momento.
Este tipo de comunicación se basa en que la persona que tiene el rol de conductor en nuestras sesiones de Mob Testing es la persona que actúa como “las manos” de los navegantes, es decir, escribe lo que éstos le van diciendo.
Siendo más claras, siguiendo este estilo de comunicación toda idea que surja en Mob Testing deben ir al ordenador pero siempre pasando por las manos de otra persona, os dejamos la regla de Llewellyn Falco en cual que nos hemos basado para la anterior afirmación:
«For an idea to go from your head into the computer it MUST go through someone else’s hands»
Traducido al español…
“Si quieres hacer realidad una idea, desde tu cabeza a la computadora, es indispensable que se la transmitas a alguien primero.”
Puedes leer más en el post Llewellyn’s strong-style pairing. De esta manera compartimos ideas entre todos los participantes en la sesión de Mob Testing. Esta comunicación es extremadamente eficaz para aprender cómo funcionan las cosas, además tiene otros beneficios para la calidad del código, el aseguramiento de la prueba, la legibilidad y la colaboración.
Si tenéis un compañero nuevo en vuestro equipo, habrá palabras de uso diario que pueden parecer completamente ajenas a esa persona, con esta técnica, estas palabras pasarán a su vocabulario diario también.
Esta comunicación es diferente de “Ping-Pong Programming” donde una de las personas del Pair Programming utiliza el teclado y escribe la prueba y luego se lo pasa a otro miembro para que escriba el código que pase la prueba.
Si os dáis cuenta, de esta manera estamos haciendo TDD, primero hacemos las pruebas y luego el código que pase esas pruebas y al final, todo tiene su relación.
Profundizando en #MobProgramming…
Una vez que hemos profundizado más en #MobTesting… nos preguntamos…
En Mob Programming ¿qué pasa con el tester?
Hace unos meses ya hablábamos por el blog del tester preguntándonos si debería saber programar (puedes leer más en El Tester… ¿debe saber programar?) Veamos qué pasa en el Mob Programming…
De formar teórica hay quien dice que el tester tiene que pasar por el teclado con el rol de conductor, independientemente de la tarea que se esté llevando a cabo en la sesión. Como para otros muchos temas que tratamos hay opiniones de todo tipo: hay quienes piensan que puede ser productivo, otros que piensan que no es una buena idea…
Puede que algunos tester no quieran participar en la parte de desarrollo como fue el caso de Maaret Pyhäjärvi (puedes leer más aquí) en la primera sesión en la que participó, a la cual la sorprendió que no se hiciera nada de testing después de unas horas de trabajando en una sesión de Mob Programming.
En sus siguientes sesiones de Mob Programming le costó empezar a ver los beneficios, pero uno de ellos a los que alude es que si hacemos Mob Testing podemos hacer Testing con el mismo estilo de equipo, además las sesiones de Mob Testing se pueden enfocar de diferente manera que las de Mob Programming.
Un asistente de los workshop que dan Maaret y Llewellyn concretamente de TestBash (Brighton) 2016, puedes leer más de su experiencia aquí), afirma que le gustó bastante hacer sesiones de Mob Testing donde se utilizó el Testing Exploratorio y pudo comprobar que compartir ideas ayudan bastante a las pruebas.
Manifiesto ágil y Mob Programming
A modo de información adicional y una de las cosas importantes que no hemos dicho de manera explícita en los anteriores que citamos al principio, es que cuando utilizamos Mob Programming, Mob Testing, Mob Drawing… estamos siguiendo valores y principios del Manifiesto Ágil (te dejamos el post El manifiesto ágil cumple 15 años):
- El valor “Individuals and interactions over processes and tools”, cuando hacemos sesiones de Mob Programming o algunas de sus tendencias contamos con muchas personas las cuales comparten experiencias, conocimientos técnicos, sociales…
- El principio “The best architectures, requirements, and designs emerge from self-organizing teams”
Concluyendo…
Si trabajamos juntos la comprensión y el apoyo entre el equipo será mayor, por lo que se puede considerar una ventaja competitiva en el mercado frente a otros equipos u organizaciones. Además el trabajo del equipo tiene mayor calidad que el trabajo de una única persona.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023