Principios de las metodologías ágiles, conclusiones.

1. Charla para http://themelee.org/
Me pedían que hablase de mi experiencia personal, y he intentado resumir mi camino
por el agilismo, mis razones y mis conclusiones actuales.
1

2. El nombre es una etiqueta, realmente lo que me define es…
Actualmente desempeño mi labor profesional en Biko, donde llevamos tres años
implantando metodologías ágiles, y soy co-fundador de la “nueva” agile-spain, que ha
conseguido aglutinar un importante movimiento alrededor de la misma: conferencias,
coding dojo, etc.
Escribo el blog http://najaraba.blogspot.com , donde hablo especialmente de
metodologías ágiles.
2

3. - ¿sois capaces de adivinar el futuro?
3

4. -¿y con un diagrama de gantt?
No solo no adivinamos el futuro, si no que somos malos imaginándolo, pues tendemos a
aplicar lo que ya conocemos. ¿Cuántas veces somos capaces de preveer algo que nos
tire por la borda un proyecto? Nassim Taleb destaca en su libro “El cisne negro” que las
evaluaciones de riesgo se basan en lo que ha ocurrido en el pasado, y que por tanto los
problemas inesperados y de gran impacto no son incluidos.
4

5. - ¿sois capaces de leer la mente?
5

6. -¿y sí de plasmarlo en un documento de requisitos?
Seguimos pensando en cerrar los alcances como mejor se pueda, cuando es mejor
asumir simplemente que ni se puede, ni es el enfoque más correcto. Por muy detallado
que esté un alcance:
a) Siempre faltan cosas
b) Nunca representa la realidad, pues esta evoluciona
c) Hay errores de comunicación e interpretación a través de la documentación
6

7. Pero eso era lo que creía al principio, con mi plan y mi documentación, podía llevar a un
grupo de desarrolladores al éxito por mi nivel como jefe de proyectos.
Sin embargo, no funcionaban las cosas como esperaba.
Tres cuestiones han tocado algún resorte en mi cabeza, que me plantean las cuestiones
básicas del desarrollo de software.
7

8. La primera, y la que más me ha hecho pensar es esta igualdad. Equipo = Producto
1) El producto resultante es tan bueno como el equipo que lo ha hecho
2) En realidad, mi producto como “jefe de proyecto” es el equipo. Debo crear equipos
capaces de hacer productos.
http://www.amazon.com/Software-Your-Head-Protocols-Maintaining/dp/0201604566
8

9. Segunda, que el desarrollo de software es un juego cooperativo de comunicación, finito.
Las partes implicadas quieren ganar algo desarrollando software. Debemos conseguir
que nuestras acciones estén encaminadas a ganar el juego, que significa, entregar valor
creado para el cliente. (siendo muy relativo la definición de ganar el juego)
Además es cooperativo, por que no se juega unos “contra” otros, si no que se busca el
resultado final.
http://alistair.cockburn.us/Software+development+as+a+cooperative+game
9

10. Tercera, el desarrollo de software es un Sistema complejo, y el mejor Enfoque es el de
adaptación – acción
Las mismas causas no provocan siempre los mismos resultados. Hace que no estén
claras las reglas del juego, y que debamos adaptarnos, y entender las cosas examinando
el pasado.
http://www.amazon.com/Management-3-0-Developers-Developing-Addison-
Wesley/dp/0321712471
10

11. Así que con esas ideas, el manifiesto ágil encaja como un guante.
http://agilemanifesto.org/
11

12. No perdamos el foco, entregar valor al cliente, de eso va este juego, y hay que ganarlo,
no solo jugarlo
Planteate si cada acción que haces ayuda al objetivo final
No quedarse contemplando el paisaje, si no andando el camino hacia el objetivo final.
12

13. (Ejemplo tomado de Henrik Kniberg)
13

14. Assumptions:
The customer discovers what he wants
The developers discover how to build it
Things change along the way
14

15. Así que ahora destaco lo que más valoro de las metodologías ágiles. Lo primero:
Colaboración, palabra clave: Visión compartida
Sincronización mental  ¿sin telepatía?  técnicas!! Debemos trabajarlas
Cuando un desarrollador debe tomar cientos de decisiones al día que afectan
directamente al valor entregado al cliente, lo mejor es que tenga en mente la idea más
cercana y parecida a la realidad del mismo.
15

16. ¡¡Fuerzate a comunicarte!!
16

17. Mejora continua. Inspección y adaptación.
Para un poco y piensa.
17

18. Personas, autoorganización, poder a los equipos
Permitir explotar el potencial de cada persona, no solo hasta dónde llegue el del jefe de
proyecto.
18

19. La calidad no es opcional, acostumbrarse a la nueva velocidad, y no dejarse presionar.
19

20. Las prácticas acercan a principios, pero no los llevan implícitos
PERO SON MUY IMPORTANTES, tampoco se pueden hacer cambios sin prácticas que los
soporten
20

21. La implantación sugiero hacerla abriendo dos caminos en paralelo: Gestión y técnico
¡Delegar!
21

22. 22

23. Objetivos, qué es el agilismo
• Entrega de Valor al cliente
• Pasarlo bien, disfrutar del trabajo
23

24. 24

25. 25