Mob Programming como forma de auto

Mob Programming como forma de auto-organizacin
de un equipo Agile
Oscar Amelunge
Scrum Coach
AgilEbanist
Santa Cruz, Bolivia +591-75520286
Email: oscar.amelunge@gmail.com
Abstract—El presente paper tiene como objetivo revisar e
introducir al lector en lo que es considerado la técnica de trabajo
en equipo Ágil llamada Mob-Programming. Veremos que este
estilo de trabajo fue planteado ya hace tiempo atrás y que hoy en
dı́a se está masificando y volviéndose popular entre las personas,
equipos y empresas que utilizan marcos de trabajo como Scrum,
Kanban y XP.
Keywords—MobProgramming, Scrum, XP.
II.
M OB P ROGRAMMING
MobProgramming es un enfoque ágil, extensión y
evolución del pair programming, planteado por Woody Sully
en su experience report del Agile Alliance 2014[2] , tiene
como premisa aprovechar todo el potencial, experiencia y
conocimiento de un equipo trabajando en el mismo lugar,
al mismo tiempo y sobre el mismo código usando una sola
computadora.
A. Principios del Mob Programming
I.
I NTRODUCI ÓN
Robert Brooks en su ensayo The mithical man month de
1975 [1] , plantea una serie de buenas y malas prácticas adoptadas en la gestión de proyectos de software, este compendio de
conocimiento escrito de forma poética (de echo es un ensayo
y no un tutorial o manual) es el fruto de alrededor de 30
años de experiencia del autor en el desarrollo de sistemas altamente complejos como sistemas operativos, compiladores,etc
en IBM. Entre las buenas prácticas recomendadas en el ensayo
de Brooks se plantea la necesidad de organizar los equipos de
desarrollo de software de la misma forma que los equipos de
cirugı́a ”En lugar de que cada miembro haga cortes sobre el
problema, uno sólo hace el corte y los demás le dan todo el
soporte posible, lo que mejorará la eficiencia y productividad
de toda la actividad”[1].
Todas y cada una de las llamadas Metodologı́as y/o Práticas
ágiles estn basadas en principios, los cuales establecen las
reglas del juego y ayudan a dictar una especie de pacto de
convivencia entre las personas que se desenvuelven en un
equipo, MobProgramming no es la excepción:
Amabilidad, Consideración y Respeto.- Todo equipo requiere interacción de personas, algunas con mayor grado de
experiencia y o conocimiento que otros, por ende es aquı́
donde surgen los conflictos en las interacciones, diferencias
de opiniones y niveles de conocimiento, es imprescindible
para interactuar en MobProgramming hacer sentir a todos sin
miramientos parte del equipo ya sea que estos aporten poco,
con el tiempo las personas nuevas o con menos experiencia
aprenderán.
B. Espacio Fı́sico
La idea suena descabellada desde el punto de vista del
Project Management tradicional y las horas hombre. Ahora
supongamos que tenemos un equipo Scrum de 7 personas, las
cuales significan como recurso 56 horas hombres diarias, y
que este total de recurso sea destinado solamente a atacar
1 tarea de un total de 7 tareas pendientes, lo más lógico
serı́a asignar a cada miembro del equipo una tarea, esta es
una hipótesis verdadera siempre y cuando las tareas a trabajar
sean mecánicas y repetitivas como por ejemplo: sembrar caña,
pintar una pared, asfaltar una calle, etc. Podremos notar que
este tipo de trabajos tienen la caracterı́stica der ser manuales y
ejecutados sobre Entes Fı́sicos; por otro lado la idea de 1 tarea
para 7 personas no es tan mala si hablamos de Software ya que
por su naturaleza no fsica y compleja (Accidental y Esencial)
(brooks) involucra la ejecución un trabajo que es mitad arte y
mitad ciencia, donde 2 mentes trabajan mejor que una, 3 mejor
que 2 y ası́ sucesivamente, por ende Mob Programming podrı́a
ser una herramienta interesante para afrontar el ”Mounstro” del
software.
Es recomendable un espacio compartido, al estilo de una
sala de reuniones (una mesa para todos), tratando de evitar la
separación entre las personas (cubı́culos o escritorios individuales), mientras más libre sea el espacio entre persona, mejor
fluirá la comunicación entre estas.
C. Proyectores
Lo ideal es trabajar con 2 proyectores, para minimizar
los cambios de pantalla, tal como tpicamente trabajan los
programadores.
D. Computadoras
Solo una computadora. Todo el código que se trabaja es
escrito a través de esta computadora, lo cual es una ventaja ya
que reduce duplicidad de código, sobre escrituras de código
(muy tı́pico cuando se trabaja con control versioning o sin él).
En la empresa en la que trabajamos tenemos 2 salas de
reuniones que tı́picamente se utilizan para hacer MobProgrammin, nuestro lugar no es fijo, por lo que la computadora que
usamos es una laptop, no siempre es la misma por ende es
importante tener un sistema de control de versiones (GIT mejor
si es GitHub o Bitbucket) que te de libertad de movimiento, de
esta manera la sesión de MobProgramming no queda amarrada
al espacio fı́sico, pude moverse de sala de reunión, de edificio o
hacerse remota utilizando algún software tipo GoogleHangOut
o ScreenHero.
E. Teclado y Mouse
Woody Sully [2] recomienda el uso e 2 teclados y dos
mouse, un par ergonómico y otro de los normales, en la
práctica hemos tenido la limitación de trabajar solo con un
teclado y un mouse y la única dificultad que hasta ahora encontramos es la configuración del teclado para los Idiomas Espaol
o Ingles (estamos en proceso de estandarizar la configuración
del teclado para todos).
III.
P R ÁCTICAS
Es recomendable para el MobProgramming trabajar en
equipos de +- 7 personas, como lo instruyen la mayorı́a de
las metodologı́as ágiles, ademá existen ciertas condiciones
de espacio y equipamiento que son recomendables pero no
obligatorias, cada equipo deberı́a acomodar su ambiente de
trabajo de la forma que más le convenga o le sea factible.
problema. Cuando se esta formando un equipo posiblemente
los miembros no vean sentido al MobProgramming por ende el
proceso de inducción es necesario, no solo del MobProgramming si no tambien del Manifiesto Ágil.
D. Reflexionar, Mejorar y Ajustar
Como toda practica ágil se recomienda al final de toda
sesión de MobProgramming hacer una retrospectiva para
analizar los aspectos a mejorar y tratar de resaltar y repetir
las cosas que salieron bien, en el libro Agile Retrospective de
Esther Derby[3], se sugiern varias retrospectivas que pueden
ser de utilidad, en lo personal recomendados la Retrospectiva
del Speed Boat.
IV.
MobProgramming es una práctica ágil que tienen un gran
potencial para escribir software de calidad, apoyado en la
fuerza e inteligencia colectiva del equipo, siempre y cuan
cuando las personas se respeten, colaboren y estén dispuestas
a aprender y ensear.
No es una SilverBullet, posiblemente no funcione en
todos los equipos ni en todos los ambientes de trabajo y
necesariamente hay que ajustar para ponerla en marcha y
mejorar, siempre respetando las practicas básicas y los valores.
R EFERENCES
[1]
A. Driver/Navigator
Exactamente igual que el pair programming, solamente uno
de los integrantes del equipo tiene el control del teclado y el
mouse y a este se lo denomina Driver, es el único que tiene
la responsabilidad de escribir código, los demás miembros del
equipo hace de Navigators, lo cual significa que están atentos
a todos lo que escribe el driver y además aportan con revisión
de código e ideas para solucionar el problema.
B. Rotación del Driver
Como recomendación en la experiencia del equipo de
Woddy Sully el Driver deberı́a rotar cada 15 minutos y
este tiempo se controla con un timer. En nuestra experiencia
práctica este tiempo puede ser un poco más largo inclusive
hasta 30 minutos, esta extensión se debe a que cuando empiezas a hacer MobProgramming el driver posiblemente no
este acostumbrado a procesar y escribir con mucha velocidad
las ideas que le dan los Navigator, por ende tampoco es
recomendable tener un driver trabajando más de 30 minutos ya
que por la experiencia vivida ese se ve agobiado por el equipo.
El Driver debe imaginarse como un salida de agua que si recibe
mucha presión durante mucho tiempo puede colapsar.
C. Todo el Equipo
Es imprescindible y necesario que todo el equipo este
enfocado y participe de manera activa, aqu el rol de lder de
equipo es fundamental (Scrum Master, Coach o Agile Project
Manager) l debe crear el ambiente necesario y motivar al
equipo para que todos participen del MobProgramming. Los
equipos ágiles normalmente adoptan esa práctica sin ningún
C ONCLUSIONES
Brooks, Frederick P, The mythical man-month, Addison-Wesley Reading,
MA, 1975.
[2] Woody
Zuill,
Mob
Programming
A
Whole
Team
Approach,
AgileAlliance,
http://www.agilealliance.org/files/6214/0509/9357/ExperienceReport.2014.Zuill.pdf,
2014.
[3] Larsen, Diana and Derby, Esther, Agile Retrospectives, Pragmatic Bookshelf, 2006.