desarrollo ágil de software

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

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

- ¿sois capaces de adivinar el futuro?

3

-¿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

- ¿sois capaces de leer la mente?

5

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

6

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

La primera, y la que más me ha hecho pensar es esta igualdad. Equipo = Producto1) El producto resultante es tan bueno como el equipo que lo ha hecho2) 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

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

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

Así que con esas ideas, el manifiesto ágil encaja como un guante.

http://agilemanifesto.org/

11

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

12

(Ejemplo tomado de Henrik Kniberg)

13

Assumptions:

The customer discovers what he wants

The developers discover how to build it

Things change along the way

14

Así que ahora destaco lo que más valoro de las metodologías ágiles. Lo primero:

Colaboración, palabra clave: Visión compartidaSincronizació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

¡¡Fuerzate a comunicarte!!

16

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

17

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

18

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

19

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

20

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

21

22

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

23

24

25