madriagil. Quedada 1/9/10. Contratos ágiles y TDD

Hoy ha sido mi segunda quedada en Madriagil ^^^

Parece que todos hemos tenido cierto mono en vacaciones, porque nos hemos juntado unos cuantos más que la última vez ( quedada para refactorizar ). Creo que he contado 19. A través de la lista de correo se había acordado centrar la discusión entorno a dos temas. Contratos ágiles y cómo vender TDD a la gestión/management.  Hemos dedicado X tiempo a cada tema e intentado sacar algunas conclusiones en claro. Voy a hacer un pequeño resumen de lo ocurrido para quién le interese… agradeceré que cualquier asistente me corrija o complemente el resumen con alguna otra observación 😉

He llegado con el tema de los contratos ágiles empezado, de modo que no se como hemos iniciado la discusión…pero ahí algunos puntos donde nos hemos parado y algunas notas que he tomado en torno a ellos… y mi opinión personal e intrasferible.

Contratos ágiles

Partimos de la base de que queremos un contrato ágil y hemos tenido en cuenta las dos orillas del rio. Desde el punto de vista del contratante ¿Cómo podemos tener seguridad de que estamos contratando un equipo ágil? y desde el punto de vista del contratado ¿cómo puedo exponer el valor de mi equipo a través de un contrato?

Para entrar en materia hemos empezado trabajado entorno a una licitación pública de la de la junta de andalucia donde solicitan que el pliego técnico sea realizado empleando SCRUM. Luego hemos coincidido en que el hecho de que sea de la administración hace que gran parte de los beneficios que pueden venir por parte de tener un equipo ágil se pueden perder por la burocracia del trabajo con la administración. Por ejemplo… Si a la segunda iteración, no me gusta la empresa y quiero deshacerme de ese proveedor y contratar otra.. puedo tener una muerte por trámites 🙂

Talking points:

El pliego tiene techo pero también debería tener suelo. Deberían asegurarse una serie mínima de de iteraciones, si no lo hacemos podríamos encontrarnos en una situación en la que invirtamos en montar/contratar el equipo para el proyecto y se caiga antes de empezar.

¿Cómo comparamos proveedores en una licitación ágil? Obviamente podemos usar un portfolio o experiencias en anteriores proyectos, pero ¿Podemos medir a los proveedores en base a su velocidad? o ¿podemos establecer un estándar de puntos de esfuerzo para todos los proveedores? En MI opinión, estos son medidas PARA el equipo, internas, no creo que valgan en una oferta.  Otra opción era reunirse con los proveedores para que nos propusiesen un release plan y que valorasemos en torno a eso… siempre con cuidado de no caer en un Gannt y perder la agilidad por el camino. Tambien se han planteado las certificaciones… podemos confiar en el nivel de certificación en SCRUM/AGILIDAD del proveedor? o certificarlos nosotros? Si bien es una falsa seguridad, en mi opinión…algo es algo…

¿Es el contrato ágil un nuevo tipo de contrato? La mayoría pensabamos que no… que se puede enmarcar dentro de un modelo tradicional, ya sea de contrato por servicio o por obra.

Todos hemos coincidido en que la naturaleza de un contrato ágil nos debe permitir cambiar de dirección en las iteraciones. Bien  sea para parar, continuar o cambiar de proveedor.

 

TDD

Cuando ha sonado el gong ( a la segunda o tercera vez 😛 ) hemos cambiado de tercio y hemos pasado a ver cómo podíamos vender TDD a la gerencia. Al final nos hemos liado la manta a la cabeza y además de ver como vendérselo a la gerencia, nos hemos autoconvencido, se lo hemos vendido al equipo, entre equipos, hemos discutido de si TDD merece la pena, etcétera… vamos, que nos ha quedado completito el rato dedicado a TDD 🙂

Cabe destacar que NO todo el mundo de la reunión hace TDD, había personas que lo habían descartado por ahora y preferían quedarse con el enfoque tradicional de testing para sus proyectos. En lo que SI estabamos todos de acuerdo es que HAY QUE PROBAR el código 😉

y OJO que TDD no exime de hacer otras pruebas o de utilizar herramientas como PEX para asegurar la consistencia del código.

Talking Points

Cómo vender el valor de TDD a la gerencia. En realidad hemos visto que la gerencia que tiene un perfil de negocio no es problema. No esta capacitado para tomar esas decisiones y va a tener que fiarse de algún técnico. El problema esta en si TDD afecta demasiado al rendimiento en las fases iniciales y esto impacta a la productividad. Estabamos de acuerdo en que TDD como proceso tiene su tiempo de adopción y su curva deaprendizaje, y una vez implantado, hay que meter tiempo en ello… si un gerente comercial se queja, siempre podemos enseñarle un diagrama donde se vea que el número de bugs disminuye o uno donde se vea que aumenta la cobertura de código.

De acuerdo…cobertura de código no tiene porqué implicar calidad…. pero como hemos dicho antes…algo es algo. Y recordemos que estamos hablando con un gerente comercial.

TDD desde el equipo de desarrollo. Otra posibilidad es que los individuos comiencen a hacer TDD, por su cuenta, sin que tenga que venir impuesto por el gerente. El equipo puede ser el iniciador del cambio. Hemos pensado en algunos motivos que esgrimir cuando queremos convencer a alguien a que haga TDD:

TDD mantiene el diseño a prueba constantemente

TDD nos permite avanzar con seguridad en el contexto de un dominio desconocido

TDD ayuda a detectar antes los posibles fallos

Es más fácil empezar a hacer TDD si hacemos pair programming

TDD es una herramienta efectiva para la gestión del cambio

TDD implica mejorar como desarrollador porque a base de usarlo vas a reconocer patrones, refactorizar, detectar bugs…

TDD es un acto de fé… prueba y verás como te engancha

Cómo empezar con TDD. Una vez el equipo se decide… ¿Cuál es la mejor manera de empezar a hacer TDD? ¿Dónde lo aplicamos? En estos puntos han surgido también varias ideas:

Podemos enfocarlo como diseñar orientado a ejemplos. Escribimos el ejempo de como ha de quedar y luego el código que lo resuelve.

En lugar de empezar directamente con TDD, podemos emprezar con unit testing tradicional y cuando el equipo se sienta cómodo probando y refactorizando…dar el paso de empezar con los tests en lugar de con el código.

Los tests de aceptación pueden ser también un acelerador de la adopción de TDD. Si tenemos requisitos de negocio escritos como pruebas nos va a resultar mucho más natural escribir los requisitos funcionales también como pruebas.

Podemos restringir el uso de TDD a la parte del proyecto que tenga un dominio más desconocido.

 

Conclusión

Al igual que el primer dia, me lo he pasado bien y he aprendido un montón en base a la experiencia del resto de compañeros. Nada de lo que tratamos ni ninguna de las conclusiones en un axioma que nadie deba memorizar. De hecho, reina la divergencia de opiniónes en las reuniones, pero creo que hay temas en los que estamos TODOS de acuerdo. Para mi hoy han sido los beneficios que aporta el trabajo iterativo de los equipos de desarrollo y la importancia de las pruebas a la hora de construir software robusto.

Como he destacado, ninguna de las opiniones es ley, pero si no haces alguna de esas dos cosas tal vez podrías probar… nosotros 19 estábamos de acuerdo en que a nosotros nos funcionan 😉

 

Próxima quedada.

Nos hemos propuesto vernos el 23/9 (lugar por determinar) para hablar sobre:

Mejores prácticas de branching

Cómo repartir tareas dentro de un equipo en SCRUM

Si quieres venirte estate atento a la lista o a la web para cuando anunciemos el sitio.

 

Recursos

Web de madriagil

Madriagil es uno de los grupos de personas interesadas en metodologías ágiles… pero hay más!  Mira en este enlace  http://www.agile-spain.com/ y anímate

 

Happy hacking!!

~ds

PD –> No pongo nombres de los asistentes pq no me los sé todos aun y no quiero poner unos sí y otros no. O todos o ninguno.

Publicado por

4 comentarios en “madriagil. Quedada 1/9/10. Contratos ágiles y TDD”

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *