Mob programming es un enfoque ágil, extensión y evolución del pair programming, planteado por Woody Sully en su experience report del Agile Alliance 2014 , 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. Esta charla pretende dar a conocer la filosofía del mob programing y sus diferencias con el pair programming, además de compartir las experiencias de aplicación vivida por el autor como Scrum Master.

1. MOB
PROGRAMMING
como
forma
de
auto-­‐
organización
de
un
equipo
SCRUM
@oscaramelunge

2. 2

3. “All
of
the
monsters
who
fill
nightmares
of
our
folklore,
none
terrify
more
then
werewolves,
because
they
transform
unexpectedly
from
a
familiar
into
horrors.
For
these
,
we
seek
bullets
of
silver
than
can
magically
lay
them
to
rest”
No
Silver
Bullet-­‐
Frederick
Brooks
1986
3

4. “SoAware
has
something
with
this
character,
usually
innocent
and
straighBorward,
but
capable
of
becoming
a
monster
of
messed
schedules,
blown
budgets,
and
flawed
products.
SO
WE
HEAR
DESPERATE
CRIES
FOR
A
SILVER
BULLET”
No
Silver
Bullet-­‐
Frederick
Brooks
1986
4

6. 6

7. 7
Complejidad
Accidental
Complejidad
Esencial
FRED
BROOKS
"No
Silver
Bullet
—
Essence
and
Accidents
of
Software
Engineering"
1986

8. 8
Complejidad
Accidental
Variable
Independiente
Complejidad
Esencial
Variable
Dependiente
VARIABLE
INTERVINIENTE

9. 9

10. 10
Complejidad
Accidental
Variable
Independiente
Complejidad
Esencial
Variable
Dependiente
VARIABLE
INTERVINIENTE

11. 11
“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”
F. Brooks, Cap2, The Mythical Man-Month
1975

12. MOB
PROGRAMMING
“Mob
programming
is
a
software
development
approach
where
the
whole
team
works
on
the
same
thing
at
the
same
time,
in
the
same
space,
and
at
the
same
computer.”
Woody
Zuill

13. 13
Pair-Programming

14. 14

15. Principle
“Treat
each
other
with
kindness,
consideration,
and
respect.”

16. Practice
Driver/navigator
pair
programming
adapted
to
work
with
the
whole
team

17. Practice
Timed
Rotation

18. Practice
Practice:
Whole
Team

19. Practice:
Reflect,
Tune,
and
Adjust
Frequently

20. Donde
Aplicamos
MOB
1. Historias
de
usuario
que
son
muy
grandes
no
se
puede
partir.
2. No
todos
los
miembros
del
equipo
son
expertos
en
la
historias
de
usuario
o
no
tienen
la
habilidades
para
desarrollar
toda
la
historia
de
usuario.

21. Historias
Grandes
1. Brainstorming
para
generar
ideas
de
por
donde
empezamos.
2. Dividir
la
historias(tareas)
en
posibles
tareas
(sub-­‐tareas)
3. Empezar
a
trabajar
las
tareas
menos
claras.
4. Volver
al
paso
1
si
las
tareas
son
muy
grandes
5. Codificar
(Se
recomienda
TDD)
Recomendación:
Tener
siempre
a
mano
al
P.O.
o
experto
del
negocio

22. On
Boarding
=
Aprendizaje
+
Educación
1. Una
tarea
seleccionada
es
trabajada
por
un
“driver
expert”.
2. Los
“navigators
dummy”
observan
3. Se
termina
la
tarea
y
se
discute
y
conceptualiza
que
se
realice
4. “Borro
todo
el
código”
y
el
“navigator
dummy”
se
vuelve
a
tartar
de
escribir
todo.
4. El
“navigator
dummy”
hace
una
tarea
similar

23. Problemas
del
MOB
• Navigators
“Pasivos”.
• Puede
no
ser
productivo
para
historias
de
usuarios
simples.
• Los
Drivers
“Genios”
• Los
Navigators
“Teóricos
que
saben
como
resolver
el
problema”
• Si
la
visión
de
la
empresa
es
Horas/
Hombre,
va
a
ser
un
desastre
• Problemas
Técnicos

24. Beneficios
• El
código
tiene
el
talento
y
el
ingenio
de
todo
el
equipo.
• Implícitamente
se
da
el
code
review
• Si
la
empresa
se
enfoca
en
el
valor
de
negocio
es
genial.
• Se
genera
un
proceso
de
aprendizaje
técnico
y
del
negocio.
• Se
optimiza
la
productividad
al
trabajar
todos
en
una
maquina.
• Se
eliminan
los
silos
de
conocimiento.

25. Conclusiones
• A
equipos
ágiles
les
es
mas
sencillo
adoptar
esta
practica
• Funciona
cuando
las
personas
se
respetan,
colaboran
y
están
dispuestas
a
aprender
y
enseñar.
• Se
nos
da
muy
bien
para
trabajar
historias
de
usuario
o
requerimientos
poco
claros.
• Facilita
el
On
Boarding
=
Educación
+
Aprendizaje
de
los
miembros
del
equipo
en
el
Complejidad
Accidental
o
Complejidad
Esencial.
• No
siempre
es
bien
visto
por
los
directivos
de
la
empresa.
• No
es
un
SilverBullet.

26. 26
“Si caminas solo, irás más rápido;
si caminas acompañado,
llegarás más lejos.”
Anonimo.

28. @oscaramelunge
oscar.amelunge@gmail.com
oscar.amelunge
www.amelunge.com