Hola, seguimos con la polémica del TDD, pero no temais, en este post no voy a hablar de TDD (al menos no mucho). En el anterior post defendí que si se hacía bien el TDD, con su refactor y que si además se complementaba con un pair programming, la necesidad de métricas estáticas de calidad de código desaparecen. Comentarios a dicho post por parte de @jmbeas, Chuidiang e @ydarias indicaban que mi postura era correcta en un equipo experto, pero que si tenías equipos menos maduros, entonces necesitabas estas métricas porque los equipos no iban a hacer TDD, refactor y pair programming, ya sea por inexperiencia o por simplemente no querer. Bien, esto es cierto, de hecho es interesante que al enseñar TDD y refactor a equipos novatos, usemos análisis de código estático para ver como de forma incremental, y emergente, el código alcanza una buena calidad.
En el fondo, mi problema es que pienso que los equipos que no hacen TDD o pair programming, sencillamente no están haciendo agilismo… Enrique, no te metas en más líos, mejor digamos que sencillamente no están usando una buena metodología. En el resto de este post voy a explicar tan inverosímil afirmación.
El agilismo propone un metaproceso para definir un proceso de desarrollo e ir evolucionándolo en el tiempo, con el objetivo de adaptarnos a los cambios en nuestro entorno y mejorar dicho proceso de forma continua, de manera que maximicemos el valor entregado al cliente. No vale con que el proceso sea bueno hoy, sino que debe ser mejor mañana y no debe quedarse obsoleto. Y por mejor entendemos que entregamos más valor al cliente en menos tiempo y con menos coste. Obviamente, para poder implementar el proceso de desarrollo en la realidad, y poder hacer mejora continua, se nos propone un conjunto de buenas prácticas. Mi pregunta es, ¿cuál es el conjunto mínimo de buenas prácticas para considerarnos ágiles? Dicho de otra forma, ¿cuál es la metodología ágil más ligera posible? Dada la definición de agilismo anteriormente expuesta, la metodología ágil más ligera, es aquella que sólo obliga prácticas que proporcionen lo más rápidamente posible información de los problemas del proyecto, y nos ayuden a resolverlos cuanto antes. Armados con unos ciclos de feedback rápidos, que nos informen sobre problemas en el proyecto, podemos practicar mejora continua, y terminaremos con una metodología que es perfecta para nuestro entorno de trabajo específico, y que va a evolucionar para adaptarse a cualquier imprevisto.
Dicho esto, hay que tener en cuenta que los problemas nos lo podemos encontrar a múltiples niveles: estimación y planificación, desarrollo, build y pases de entornos, explotación, etc. Necesitamos pues, ciclos de feedback y mejora continua en cada uno de esos niveles. Obviamente algunos de dichos niveles escapan a mi control, pero al menos planificación y desarrollo sí están bajo mi control. Al conjunto mínimo de prácticas, que te permiten conseguir mejora continua de forma efectiva, lo llamaré agilismo minimalista.
A nivel de control de proyecto y mejora continua lo mínimo que puedes hacer es:
- Retrospectiva al final de proyecto. Hay que reunirse para saber las causas del éxito o fracaso del proyecto, y que cosas se pueden mejorar y cómo. Es el nivel básico de mejora, aprender del resultado de un proyecto para el siguiente. Debería participar la dirección de la empresa también y el cliente.
- Múltiples reuniones de seguimiento del proyecto, a ser posible a intervalos regulares, predecibles y ni demasiado largos ni cortos. Un ejemplo de reunión de seguimiento es la retrospectiva de sprint dentro de SCRUM. Otro ejemplo es la demo de final de sprint, este último más orientado a obtener feedback del cliente. Nos permite enterarnos rápidamente de los problemas que se producen durante el proyecto sin esperar a que acabe. Si hay algún problema podemos tener la oportunidad de solucionarlo. También podemos ajustar nuestras estimaciones con la realidad del proyecto, y aprender a estimar mejor en el futuro. Se puede involucrar a todos los participantes en el proyecto, al fin y al cabo no se hace todos los días. Esto es importante para que la información del estado del proyecto llegue a todo el mundo por igual y no se quede información escondida en nichos. También debe participar un representante del cliente, para ver como va el proyecto, proporcionar información adicional y aclarar dudas.
- Reunión diaria o daily scrum. Es un nivel de feedback más rápido, diario, que involucra a los miembros de un mismo equipo y al menos un responsable. En proyectos grandes pueden haber varios equipos cada uno con su propia reunión diaria.
- Reunión de emergencia. Para solventar cualquier problema grave y no previsto, detectado mediante cualquier mecanismo.
A nivel de planificación y estimación:
- Dividir el trabajo en unidades manejables. Dichas unidades deben ser estimables, representar un incremento en el valor entregado al cliente, concisas y claras, de un tamaño similar entre si, independientes entre si, tener un criterio de aceptación y no demasiado grandes. Esto se suele conocer como historias de usuario. La importancia de las historias de usuario es que te proporcionan una unidad de planificación y estimación que está bien correlacionada con el valor del proyecto desde el punto de vista del cliente. El criterio de aceptación es importante para saber cuando se ha terminado de implementar la historia.
- Revisa las estimaciones frecuentemente, teniendo en cuenta los resultados obtenidos en las retrospectivas y reuniones anteriormente mencionadas. Si las historias no fueran pequeñas, independientes y de tamaños similares, el ajuste de las estimaciones basándonos en lo que pasó en otras historias sería prácticamente imposible.
- Refina y revisa la definición de las historias frecuentemente. Tal vez a intervalos regulares (SCRUM sprint planning) o tan pronto como te sea posible (kanban). Para ello hay que hablar con el propio usuario, o en su defecto con un experto de negocio.
- Implementa primero las historias con más valor. Esto maximiza el valor entregado al cliente. También nos evita tener que implementar historias que pueden cambiar o quedar obsoletas con el transcurso del tiempo.
De momento a nivel de gestión y planificación, el agilismo minimalista no es ninguna sorpresa. El punto es que si no implementas todas estas buenas prácticas, no eres ágil. Simplemente no vas a poder reaccionar a los cambios en tu proyecto ni mejorar la forma de trabajo. Casi todas estas prácticas las realizan todas las empresas serias que conozco, excepto la reunión diaria, las historias de usuario y la implementación por orden de valor. Si no practicas la reunión diaria tendrás problemas ocultos y enquistados al menos hasta la próxima reunión de seguimiento, que será dentro de ¿entre 2 y 4 semanas? ¿No es muy ágil cierto? Hasta aquí casi todos estareis de acuerdo, pero todo esto no es suficiente para reaccionar ante problemas y mejorar en un proyecto software. Necesitamos tener en cuenta otro aspecto, la ingeniería.
Desde el punto de vista de mejora continua de la ingeniería y desarrollo:
- Programación por parejas. Es otro ciclo de feedback, esta vez sobre el diseño y la calidad de código. Lo podemos considerar una revisión de código continua o una QA continua. El feedback proporcionado por un compañero a la persona que está tecleando es rapidísimo, del orden de segundos.
- TDD. Nos permite saber si nuestro código funciona, o si la modificación que hemos hecho rompe algo. Feedback del orden de minutos.
- Refactor frecuentemente. Dentro de un ciclo de TDD para garantizar que se hace a menudo, y guiado por la programación por parejas, nos permite mejorar de forma continua la calidad de nuestro código.
- Integración Continua. Feedback a nivel de horas, que nos permite detectar problemas de integración.
Bien, con esto quiero decir que el agilismo minimalista necesita de mejora continua no sólo a nivel de gestión, sino a nivel de ingeniería, con lo cual necesitas hacer TDD, refactor, pair programming e integración continua, como mínimo, para ser ágil. Si no haces integración continua no detectas los problemas de integración hasta que no haces un pase, ¿es eso ser ágil? Si no haces TDD no detectas si has roto funcionalidad al introducir un cambio hasta que no lo prueba el equipo de QA, ¿es eso ser ágil? Además si no haces TDD no puedes hacer integración continua, sino como mucho, compilación continua. Si no haces pair programming no detectas errores de programación o fallos de diseño hasta dios sabe cuando, ¿es eso ser ágil? El refactor frecuente te permite arreglar tu código, sin necesidad de esperar al super arquitecto/guru. Lo importante es que todas estas prácticas se realimentan y se producen sinergias positivas entre ellas. Cada una cubre cosas que la otra no. Si quitas una sola el edificio se empieza a derrumbar. Por ejemplo si quitas el pair programming puedes introducir fake TDD o simplemente saltarte el refactor. Si quitas el TDD te cargas la integración continua. Las necesitas todas, no son opcionales, son obligatorias.
Ya contamos en la CAS2010 nuestra experiencia de implantación del agilismo. Hubo un momento que teníamos sprints, retrospectivas, etc. Pero no teníamos TDD ni pair programming ni se hacía refactor, y mucho menos integración continua. Eso no funcionaba. Asi que lo siento, a aquellos que piensen que puedes hacer agilismo con un equipo que no controle estas técnicas y no esté dispuesto a hacerlas, os aviso: no va a funcionar, no basta con el sprint planning y el daily scrum, no vas a ser ágil, necesitas prácticas ágiles de ingeniería y gente capaz de llevarlas a cabo.
Afortunadamente parece que hay gente por ahí de acuerdo conmigo, sino leed lo mismo que digo pero explicado de otra manera en este blog de Luis Artola. SCRUM y KANBAN sólo se ocupan del nivel de gestión y planificación de proyecto, pero no de la ingeniería. Para que tu proyecto sea exitoso, necesitas también buenas prácticas de ingeniería y trabajadores capaces de llevarlas a cabo. Muchos piensan que son ágiles porque aplican prácticas ágiles a nivel de planificación y gestión, pero se olvidan de la ingeniería. Esta es una maldición eterna en el mundo de los proyectos software, parece que por poner una capa de gestión se arreglan todos los problemas, pero nadie presta atención a lo más básico, la ingeniería y la capacidad profesional de los «pikachus».
En resumen, lo mínimo que puedes hacer para considerarte ágil (agilismo minimalista) es: pair programming, TDD+Refactor, integración continua, reuniones diarias, reuniones periódicas de seguimiento (internas y externas para el cliente), retrospectivas de proyecto y planificación y estimación basada en historias de usuario. Si te falta, aunque sea una sola de estas prácticas, no eres ágil.
¿Y las demás buenas prácticas? Bueno, para mi no forman parte del agilismo minimalista, las considero muy dependientes del entorno en el que se mueva cada uno. Aquí es, donde creo yo, que se debe aplicar eso de probar a usar una buena práctica, experimentar y ver si va con tu proyecto o no. Lo importante es que con el agilismo minimalista irás descubriendo cuales son útiles y cuales no. Por ejemplo, a nosotros los sprints no nos han funcionado bien, por eso estamos pensando en pasar a kanban, pero conservando los principios del agilismo minimalista. Quizás esto de agilismo minimalista+kanban sea algo parecido al scrumban que he escuchado por ahí. En cualquier caso el resto de las prácticas debéis experimentar con ellas antes de adoptarlas en serio o no.
Corolario: si ves que necesitas métricas estáticas de calidad de código, es una señal de que no eres ágil, algo falla (pesaito soy). Saludos y ahora me voy a dormir, que ya me vale.
[…] This post was mentioned on Twitter by Enrique Amodeo Rubio, Kinisoftware. Kinisoftware said: Tendré que dedicar una tarde entera el último artículo de @eamodeorubio sobre TDD http://wp.me/pQAdW-40 🙂 […]
Te daría un beso, pero luego tu mujer se enfada, así que lo dejaremos en un abrazo al estilo David Bonilla. 🙂
Estoy muy de acuerdo contigo. Especialmente en la afirmación de que:
A ver si llega el mensaje a todos esos que leen Scrum y creen que se compra en los estancos junto a los sellos de calidad AENOR.
En mi opinión, ser ágil EXIGE un cambio de mentalidad en la empresa. Hoy había un tweet corriendo sobre una vieja cita de Peter Drucker (que no es precisamente santo de mi devoción, pero la cita es suya): «La cultura come estrategias para desayunar, todos los días». Hay gente que usa una versión de esta cita «La cultura come procesos para desayunar». Y ahí voy yo, Enrique. Sólo para matizar una cosa que dices:
Yo creo que sería bueno refrasear la definición a algo como:
«Si queremos mejorar nuestro proceso de desarrollo, necesitamos prácticas que proporcionen lo más rápidamente posible información sobre los problemas de cada proyecto». Porque si no queremos mejorar nuestro proceso de desarrollo, sino simplemente terminar cada proyecto (con un enfoque cortoplacista o, como dirían algunos, «pragmático»), entonces no necesitamos abordar el esfuerzo de cambiar la cultura de nuestros equipos, que es lo que nos permite tener éxito en la implantación de las prácticas («las personas y sus interacciones sobre los procesos y las herramientas»).
Por cierto, se me olvidaba. También podías haber resumido todo en dos palabras: «Inspect and Adapt» 😉
Es que tengo incontinencia verbal, y me gusta escribir truño-posts. Mi blog es muy bueno como remedio contra el insomnio 🙂
A mi me gustaria saber cuanto incrementa el coste de desarrollo de aplicaciones de negocio la utilización de TDD para tenerlo en cuenta a la hora de cotizar los proyectos.
He leido que según la metodología hay que hacer varias reuniones, hasta diarias. ¿no son muchas reuniones?.
En la metodología convencional que se utiliza para el desarrollo de aplicaciones de negocio no se hacen tantas reuniones y sin embargo los proyectos salen.
Ademas me gustaria saber como se implementa TDD en entornos de negocio donde intervienen Bases de datos complejas (de mas de 500 tablas), para poder realizar test repetitivos y fiables a traves del tiempo.
¿Quizas TDD solo se puede aplicar para el desarrollo de componentes de arquitectura y no para aplicaciones convencionales, con paneles que exigen introducción de datos y accesos a bases de datos?, vamos lo de siempre.
Je, je, el punto de Yeray Darias es bueno, se hacen más reuniones pero menos documentación, y las reuniones diarias tienen un límite máximo de 15 minutos, según apunta Yeray, que no lo comenté en el post. En general las reuniones ágiles no son abiertas en duración sino que tienen una duración fija inamovible. Ésto mantiene a la gente enfocada y evita que divaguen. También es importante que cuanto más frecuente sea una reunión, más corta debe ser, y por tanto su orden del día debe ser menor. Asi en la reunión diaria de 15 minutos sólo se mira que se pudo hacer ayer, que se va a hacer hoy y si existe algún problema que bloquea el trabajo. En las de seguimiento cada 2 o 3 semanas se pueden invertir un par de horas y hablar más del estado general del proyecto.
Sobre el TDD, como dijo Yeray, te ahorras los costes de mantinimiento correctivo, yo creo que hasta un 90%. También te da la seguridad de tener una suite de pruebas automáticas que puedes ejecutar en cualquier momento para validar que un cambio no rompe nada. Pero te proporciona ahorros adicionales también. Te ahorras el tener que tirarte semanas definiendo una arquitectura detallada («large upfront design») que lo mismo después está mal o tienes que cambiar. Te permite implementar integración continua, imposible sin TDD, lo que te ahorra problemas de integración y pases entre entornos. En proyectos grandes este ahorro en costes de integración y pases entre entornos es enorme, debes de saberlo, que seguro que has estado en proyectos grandes. Todos estos ahorros y aumento de calidad compensan con creces el coste extra del TDD
Sobre hacer TDD con BBDD, bien, el ciclo de TDD más frecuente es de tests unitarios, que simplementen simulan la BBDD (no llegan ejecutar el SQL realmente). Después hay tests de integración con BBDD de verdad para probar las SQL y/o los DAOs, para ello hay frameworks especiales que te limpian la BBDD y te ponen datos de tests cada vez que lanzas un tests, sin que te tengas que morir programando. Estos tests de integración son menores en número y se suelen ejecutar menos frecuentemente, todas las noches por ejemplo, debido a que tardan más.
Finalmente, precisamente el TDD es más sencillo de hacer con aplicaciones normales, donde tienes lógica de negocio que probar. De hecho la técnica nació y se gestó en aplicaciones de gestión. Precisamente los componentes de arquitectura son más problemáticos ya que tienen más aspectos no funcionales a probar (rendimiento, seguridad, etc.), y sus casos de uso pueden ser más difusos y abiertos.
Finalmente, eso de que los proyectos con metodología tradicional salen, es muy discutible. De hecho es al revés, muchos fracasan, y los que no, terminan tarde y con sobrecoste. Es esta la razón de que el movimiente Agile empieza a tener éxito, hay que buscar otra forma de hacer las cosas. Al parecer la cosa se empezó a torcer cuando se empezaron a hacer aplicaciones web, puedes ver los datos en:
IT Cortext También en InfoQ y InfoQ failure starts after internet y Standish
Me ha gustado el artículo, aunque quizás peca un poco de demasiado «fanático» (sin ánimo de ofender :-)). Aunque realmente es cierto que son necesarias todas estas prácticas para ser realmente ágil (puede que incluso alguna más), es cierto que ir adoptándolas poco a poco es perfectamente factible, y se observan mejoras desde el principio. Por cierto me ha gustado eso de «agilismo minimalista» 😛
Aunque estoy totalmente de acuerdo en que colgar una pizarra en la pared y reunirte con todo el equipo delante de ella no es ser ágil de verdad, y hay que trabajar muy duro para llegar a esta meta, tanto en el plano de la gestión como en el plano técnico.
En respuesta a José María, creo que Enrique aquí aclaró que no iba a hablar de TDD en concreto, está mencionando diferentes procesos, algunos incluyen reuniones y otros no. En el caso de TDD no veo que requiera reuniones diarias, es un proceso que es perfectamente individual.
Respecto al tema de las reuniones diarias, por ejemplo Scrum recomienda una reunión diaria de seguimiento, pero muy breve en el tiempo (no más de 15 minutos). Tú comentabas que las metodologías clásicas no requieren de tanta reunión, bien puede ser cierto dependiendo de la metodología a la que te refieras, pero por lo que me tocó estudiar en su momento, recuerdo que necesitaban de muchos documentos e informes, en gran parte de seguimiento. Diría que si hacemos números, esos 15 minutos diarios en suma son menos que lo que ocupa hacer toda la documentación sugerida por las metodologías clásicas. Además del hecho de que al ahorrar la fase de diseño el cliente recibe funcionalidades implementadas mucho antes.
Con respecto a implementar TDD en grandes entornos de negocio no soy experto, pero hay muchas empresas que lo hace, literatura que comenta el tema y hasta frameworks como DbUnit por lo que no es algo descabellado.
Para acabar comentar que TDD puede incrementar muy ligeramente el coste de implementación de un producto, pero en mi opinión, reduce drásticamente el coste de mantenimiento, número de bugs y aumenta la fiabilidad del sistema. Que son cosas más interesantes para el cliente, desde mi punto de vista claro, que seguramente tendrá muchos fallos.
Un saludo.
Sí, cada vez soy más radical, no se si es bueno o malo, 😉
Lo siento, pero no he podido resistirme. ¿¿¿Cómo que el coste de las reuniones es superior en un proyecto ágil??? ¿Nunca habéis tenido que reuniros TODO el equipo para ver por qué el proyecto se está yendo al garete? ¿O quedaros hasta las 3 de la mañana durante dos semanas para conseguir poner en producción? ¿Eso no cuenta como reunión?
Excelente artículo Enrique. Creo que este tipo de visión «radical» es la que produce cambios.
Por otro lado, estoy muy de acuerdo en todo lo que se dice.
He pasado muchos años desarrollando de forma tradicional y recuerdo aquellas hojas excel llenas de bugs y bugs justo después de entregar una aplicación al cliente. Con metodologías ágiles se minimiza en gran parte todos estos bugs (y sus costes asociados claro).
Todos sabemos que la fase de mantenimiento de un proyecto siempre será mayor que la fase de desarrollo, por tanto, el incremento en el coste de hacer TDD es casi despreciable del incremento del coste de tener una fase de mantenimiento larga.
Por otro lado, a quién no le ha pasado tirarse semanas con una funcionalidad de una aplicación que luego finalmente el cliente no quería.
No olvidemos quienes fueron los promotores de todo esto del agilismo. Gente como Martin Fowler, Kent Beck, Robert C Martin, Ron Jeffries,….en fin, gente que llevaba años y años desarrollando de forma tradicional.
Creo sinceramente que tenemos miedo al cambio. Hemos desarrollado de forma tradicional durante demasiados años como para ahora hacerlo de otra forma, nos da miedo lo desconocido, pero seamos sinceros, se pueden hacer las cosas distintas.
Si pudiéramos empezar el mismo proyecto en paralelo de forma ágil (con agilismo minimalista por lo menos) y de forma tradicional, veríamos los beneficios del enfoque ágil desde el primer momento: Estaríamos entregándole constantemente cosas al cliente, además le entregaríamos antes las cosas mas importantes para su negocio. Podríamos adaptarnos a los continuos cambios de requisitos en un tiempo muy corto (semanas).
YO veo muchos beneficios y pocos riesgos.
NO me extiendo mas, interesante discusión.
Un saludo
[…] [3]:https://eamodeorubio.wordpress.com/2010/06/28/sin-tdd-no-hay-mejora-continua-y-por-lo-tanto-no-eres-a… This entry was posted in Development/Desarrollo. Bookmark the permalink. ← Preparado para la Conferencia Agile-Spain 2010 […]
Un gran post que deja muy claras las bases en las que debería asentarse cualquier metodología ágil que una empresa de desarrollo quiera aplicar para conseguir un objetivo claro, poder entregar a sus clientes lo que les aporta valor, con calidad y según los plazos acordados.
Estoy muy de acuerdo con tigo compa, la verdad mas de una vez me he metido en un lio cuando dije que sin TDD no hay agilismo (suena muy extremo), pero la verdad creo que el concepto de construye al revez, cuando haces TDD, puedes hacer entregas continuas de codigo, sin gastar tiempo extra probando todo la aplicacion otra vez porque depronto dañamos algo que ya funcionaba, y como podemos hacer entregas continuas, el concepto de hacer sprints, me parece que es concecuencia de esto mas que una el TDD una concecuencia del sprint, el sprint una concecuencia de hacer TDD, sino que desde el punto de vista del scrum, que tal vez tiene conocimientos de gestión pero no ingenieril no puede ver esto, obviamente no me cabe la menor duda que el TDD, requiere un equipo experimientado, pero a mi juicio es obligatorio si de verdad queremos ser agiles y no «agiles».