Inicio > Español > Agilismo ‘waterfallero’

Agilismo ‘waterfallero’

15 marzo, 2014

Y andaba yo “feliz-guiño-guiño” con mis gráficas, mis veintemil indicadores, mis plazos, mis documentos de análisis y diseño, mi margen de contribución esperado, etc… Total, que en eso que en la empresa deciden que el agilismo está de moda, y que hay que poder ponerse la medalla de agilistas. Nos mandan a los que andábamos con temas de gestión a un curso de scrum. Hasta aquí bien.

Llegamos al curso, que a la sazón era impartido por una empresa que vendía certificaciones en scrum. Y empiezan a hablarnos de sprints, de sprint reviews, de stand-ups, de sprint plannings y esas cosas. Y empiezan a aparecer un concepto: ‘my-scrum‘:

—”Ojo, si no se hace un stand-up diario, no estáis haciendo scrum: estáis haciendo my-scrum
—”Ni se os ocurra alterar un sprint durante el mismo: si lo hacéis no estáis haciendo scrum, sino my-scrum
—”El producto se muestra al cliente al final del sprint y no a medias: si no, estaríais haciendo my-scrum

Y en esto que alguien pregunta:

— “¿Qué pasa si hacemos my-scrum?”

Y ojo a la respuesta:

— “Que entonces la metodología no funciona

Estamos hablando de hace unos cuatro años. Tras escuchar esto, con mi mente waterfall queda claro que todo es más o menos lo mismo: una metodología más, pero de moda.

Ahora saltamos a unos meses después. La empresa, con una estructura jerárquica clásica intenta hacer sus pinitos con scrum, en un entorno de analistas, jefes de proyecto y plazos prefijados. Evidentemente, el asunto no funciona. En uno de los proyectos que gestiono, logro que me permitan probar scrum durante un minidesarrollo. Por supuesto con plazos fijos. Y por supuesto, cuando intento aplicar scrum, no acaba de ajustar con la realidad del proyecto. Pero persevero: de algún modo mágico, si logro evitar hacer my-scrum, la metodología funcionará. Por supuesto, al final el intento de scrum queda en algo vacío y casi ridículo.

Ahora, viéndolo con unos años de perspectiva, me doy cuenta de que una parte importante de la industria no ha entendido el agilismo. Creen que son unas metodologías más, que se pueden aplicar igual que antes se aplicaba waterwall. Coges tu empresa clásica, pagas unas certificaciones para tus gestores, ¡y viva el agilismo! Y de paso, surgen a tu alrededor empresas que certifican.

El agilismo no es una metodología. El agilismo es un estilo de resolver problemas basado en unos principios. Es despejar todo lo accesorio para quedarte con la esencia: usar la razón, no los dogmas. Veamos el manifiesto ágil:

Valoramos más a las personas y las interacciones entre ellas que a los procesos y herramientas

Es decir: si crees que aplicando tal o cuál metodología vas a poder conseguir que unos programadores desmotivados, o poco dotados, o sin buen ambiente de equipo elaboren un producto de calidad, vas listo. Para obtener velocidad y calidad, necesitas buenos programadores. Olvídate de métodos mágicos. Los procesos y las herramientas están para que los buenos programadores se organicen bien, automaticen sus tareas repetitivas, y sean felices. No para camuflar malos profesionales, o condiciones de trabajo inadecuadas.

Valoramos más el software en funcionamiento que la documentación extensa

No te engañes: estás haciendo software. Cualquier cosa que te retrase o te descentre de la tarea de hacer software, es muy posiblemente desperdicio. Mantén algo de documentación pero solo en tanto te ayude a mantener/producir tu software de forma más eficiente. Además, yo añadiría que cuando más limpio es el código y mejor es tu UX, menos documentación necesitas: fuérzate a generar poca documentación como forma de estimularte a hacer mejor código y UX.

Valoramos más la colaboración con el cliente que el ceñirse a contratos rígidos

Nadie, salvo las lógicas excepciones fruto de la probabilidad, ha logrado realizar una recogida de requisitos a principios de un proyecto que explique de verdad qué quiere el cliente. No lo intentes, no se puede hacer. No gastes energías en evitar el cambio. En lugar de eso, vuelca tus esfuerzos en abrazar el cambio de un modo que te suponga el menor impacto posible. La conclusión habitual de esto es mostrar al cliente tus avances con mucha frecuencia. Pero no te quedes en eso: haz buen software, aplica TDD, patrones de diseño, etc. Todo esto ayuda a que un cambio sustancial en tu aplicación sea menos traumático.

Valoramos más adaptarte a los cambios que intentar seguir un plan fijo

Un poco mezclado con el anterior. El desarrollo de software es incertidumbre. Desde qué quiere el cliente, hasta cuánto tardarás en tener la idea feliz que te haga resolver tal bug. No se puede seguir un plan, salvo muy a grandes rasgos. Usa sprints, o no los uses, pero intenta que tu forma de trabajo implique redefinir de forma continua hacia dónde vas.

Pues bien, mi gran descubrimiento personal durante mis últimos años de trabajo es que no necesitas nada más que estos principios. Olvídate de metodologías, prácticas y demás: úsalas si te ayudan a seguir los principios ágiles. Pero no te ates: modifícalas si te conviene. Abandónalas en mitad de un proyecto si de pronto ya no aplican, y vuelve a asumirlas si vuelven a tener relevancia. Prueba y experimenta. Usa scrum y desfigúralo hasta que te diga “padre, mátame”.

Y sobre todo, mantente atento a los waterfalleros del agilismo. A aquellos que te dicen que my-scrum no funciona. A aquellos que te obligan a hacer un stand-up diario tenga o no tenga sentido.

Guárdate de la liturgia ágil.

Categorías:Español Etiquetas:
A %d blogueros les gusta esto: