A veces menos es más; proyectos más baratos con lean development

En el anterior post introduje uno de los fundamentos de las metodologías ágiles, el aumentar la frecuencia del feedback para mejorar el control del proyecto y su adaptabilidad a los cambios. En este post hablaré de otro principio fundamental en el agilismo, el lean development (desarrollo esbelto, pero no traduciré el término).

Para ser más competitivos muchas empresas deciden disminuir costes en sus proyectos. Su objetivo suele ser o bien obtener mayor margen de beneficio o bien ofertar más barato que la competencia. Existen muchas formas de hacer ésto. Algunas muy típicas son: pagar menos a los empleados, usar empleados de menor cualificación, llevarte la producción a lugares donde los empleados cobran menos, o la más cañí de todas, hacer muchas horas extras gratis. Estos métodos son muy eficientes en algunas industrias tales como cortar madera, extraer carbón o servir cervezas a los turistas, sin embargo, son bastante ineficaces para tareas como el desarrollo de software. Lo que nosotros sabemos, y muchos gestores de proyecto no, es que construir software es una tarea intelectual compleja que necesita de profesionales cualificados y altamente motivados. El bajarles el sueldo o hacerles hacer horas extra hacen que tu equipo quede exhausto y se desmotive volviéndose menos productivo.

¿Cómo conseguir que el coste de tu proyecto se reduzca sin sacrificar la calidad de éste? Es muy simple, elimina todo el waste de tu proyecto. Waste, que significa desperdicio, es una palabra técnica para referirse a cualquier actividad, trabajo o tiempo muerto que no tenga un efecto positivo en la productividad de tu proceso de desarrollo. Básicamente consiste en detectar cualquier cosa que haga que tu proceso sea menos eficiente y eliminarlo. La idea es realmente simple pero más difícil de hacer que de decir.

Veamos primero fuentes de waste típicas en el desarrollo de software:

• Tareas innecesarias. Cualquier tarea que no aporta valor al producto ni aumenta la productividad ni su calidad. En esta categoría tenemos típicamente: la funcionalidad que el cliente no pidió, la clase que programaste por si acaso y como no, la excesiva burocracia. Ojo, me refiero a la excesiva burocracia. Según el nivel de auditoria, transparencia ante el cliente, calidad, trazabilidad y eliminación de riesgo que tengamos, el nivel de burocracia esencial para un proyecto puede ser más o menos alta.
• Baja calidad. La baja calidad te obliga a hacer y rehacer una tarea varias veces hasta que su calidad sea aceptable. Por ejemplo implementamos una funcionalidad, esta no es aceptada en pruebas, hay que arreglarla, no vuelve a pasar las pruebas, etc. Cuanto antes lo hagamos bien menos trabajo haremos. Por ello el aseguramiento de la calidad también va a eliminar waste y hacer el proyecto más rentable a largo plazo. De aquí el posicionamiento del TDD como una práctica esencial.
• Falta de automatismos y herramientas. Algunas tareas necesarias pueden ser costosas de hacer o simplemente la velocidad a la que se hacen es crítica. Ejemplos: compilar, probar, integrar, desplegar, pases de entorno, etc. Para realizar estas tareas críticas hay que implantar herramientas y procedimientos automatizados como un compilador, IDE, JUnit (para probar y hacer TDD por ejemplo), maven y servidores de integración continua.
• Tiempos muertos. Cualquier intervalo de tiempo en el que alguno o todos lo miembros del equipo no hacen nada. El que un miembro de tu equipo no haga nada significa que le estás pagando por nada. Normalmente esto se produce por una ineficiencia en el proceso de desarrollo, relacionado o no con una tarea innecesaria. Hay que detectar esas ineficiencias y corregirlas. Si no detectamos ninguna deficiencia, y realmente tenemos a alguien que está ocioso de forma continuada, tal vez debamos echarlo del equipo. Quizás tenemos demasiados desarrolladores o a lo mejor es un gestor o coordinador que realmente no tiene nada que gestionar o coordinar.

¿Cómo llevamos todo esto a la práctica? Una forma sencilla de implantar la filosofía lean es aplicar los principios YAGNI (You Aren’t Going to Need It) y KISS (Keep It Simple, you Stupid). Cada vez que vayamos a realizar una tarea debemos tener una evidencia fuerte de que es totalmente necesaria, en caso contrario invocando el principio YAGNI, no la hacemos. Típico es el caso de la funcionalidad que nadie está seguro que el cliente realmente quiere pero es «chula» o la clase de utilidad con métodos que están ahí por «si acaso».

El principio KISS se basa en hacer que las cosas que funcionen, lo hagan de la forma más simple posible, si nos podemos ahorrar una línea de código sin dañar la calidad lo hacemos. O como dijo un conocido sabio: «Hazlo todo tan simple como sea posible, pero no más simple». Según este principio cualquier complicación introducida en el sistema debe estar justificada de forma objetiva por un aumento de la calidad y/o disminución de costes de mantenimiento y desarrollo. ¿Cuántas veces hemos oído a un arquitecto decir «pues usaremos un patrón de diseño X combinado con el patrón Y mientras hacemos el pino» simplemente para implementar una funcionalidad trivial? A esta complicación innecesaria, la llamo programación barroca. En muchos proyectos existe esta programación barroca simplemente porque el arquitecto necesita reafirmar su valía y mostrar todos sus conocimientos, o tal vez para impresionar al cliente. Quizás esa gran consultora de renombre necesita pasarle una gran factura al cliente y sólo lo puede justificar haciendo una arquitectura realmente impresionante pero totalmente innecesaria e inútil. Huyamos de las complicaciones innecesarias, cuanto más simple sea un sistema antes lo terminaremos y más barato será de mantener.

Si os habéis dado cuenta, con KISS y YAGNI se elimina todo el waste que tenga que ver con tareas o generación de artefactos innecesarios. Sin embargo dejan de lado una fuente importante de waste, los tiempos muertos innecesarios. Dichos tiempos muertos son producidos por deficiencias en la forma de trabajar desde un punto de vista estructural. A estos puntos, donde se forman esperas y atascos de trabajo, se les denomina cuellos de botella; hay que detectarlos lo antes posible y eliminarlos. Por ejemplo, podemos tener al equipo de desarrollo parado mucho tiempo, en espera de que el proceso de pase al entorno de pruebas se complete y puedan probar. Tal vez necesitamos un entorno de pruebas con más capacidad, o quizás adoptar integración continua, o tal vez poner a los desarrolladores con el siguiente lote de trabajo mientras el pase sigue su curso, etc. Para eliminar los cuellos de botella normalmente hay o que automatizar alguna tarea, o que reestructurar la forma de trabajar o simplemente aumentar los recursos necesarios para la tarea que conforma el cuello de botella. Lo importante es detectarlos a tiempo y poder analizarlos, para ello la filosofía lean nos propone analizar el proceso de desarrollo frecuentemente en busca de ineficacias. Éste es el mismo concepto que vimos en el post anterior, aumentar la frecuencia de feedback para tener un ciclo de control más eficiente. En general ésto se suele hacer mediante varias prácticas propuestas por el movimiento agile. Por ejemplo en SCRUM tenemos:

• El daily scrum. Nos permite detectar atascos en el proceso de desarrollo y empezar a tomar medidas al respecto inmediatamente.
• La retrospectiva de fin de sprint, aquí puede salir a la luz cuellos de botella detectados durante el sprint con el fin de eliminarlos para el siguiente
• La retrospectiva de fin de proyecto. Podemos detectar aquí cuellos de botellas que han persistido durante todo el proyecto y buscar soluciones para el siguiente.

Como vemos volvemos a usar los ciclos de control anidados pero esta vez para mejorar y optimizar de forma empírica nuestros procesos. Otra forma de mejorar, si nuestra organización tiene un nivel de madurez muy alto, es mediante métricas, análisis de colas y simulación. Hablaré más de esto en mis posts relacionados con kanban, pero realmente lo más importante es empezar a usar técnicas, sencillas y eficaces, como las propuestas por SCRUM.

Nota. Si por ahí veis el siguiente palabro: kaizen o mejora continua, que sepáis que se refiere a esta práctica de vigilar continuamente el proceso de desarrollo, detectar deficiencias y mejorarlo.

Las metodologías ágiles incluyen, de forma integral, YAGNI y KISS como buenas prácticas básicas. De hecho todos sus procesos, ya sea si usamos XP, SCRUM o simplemente TDD están imbuidas de esta filosofía. De esta forma se elimina el waste y se produce una mejora continua del proceso de desarrollo con lo que se puede considerar al movimiento agile como un caso de lean aplicado al software.

Realmente yo no termino de distinguir entre el lean y el agile. Ciertamente pienso que son lo mismo pero visto desde dos puntos de vista distintos. El lean se originó en la industria automovilística con lo cual supongo que se usará éste término cuando se quiere orientar la discusión a prácticas industriales. Yo creo que el agile se originó en parte al adoptar la filosofía lean dentro de la industria del software y adaptarla a las necesidades de ésta. De todas formas yo personalmente los uso como sinónimos.

Read Full Post »

Tu proyecto vive en medio de caos; contrólalo con metodologías ágiles

Empiezo con este una serie de posts sobre metodologías ágiles. No trataré, por ahora, de explicar los detalles de cada una de ellas, sino más bien sus fundamentos y lo que las distinguen de metodologías más tradicionales.

El primer aspecto que me gustaría explicar fue el que más me llamó la atención en un primer momento. Se trata simplemente de que dichas metodologías nos proporcionan una mayor capacidad de control de nuestros proyectos a través de un feedback o ciclo de retroalimentación de mayor frecuencia.

Suponed que estáis conduciendo un coche por una carretera. Si la carretera consistiera en una larga recta, la conducción sería aburrida, sólo necesitarías atender a ésta muy de vez en cuando y corregir raramente vuestro volante. A esto lo llamo un feedback de baja frecuencia. Si la carretera es más realista, no será una larga recta, sino que implica curvas, baches y más tráfico. Esto hace que tengáis que estar pendiente de ésta con bastante frecuencia y estar corrigiendo continuamente la trayectoria de vuestro vehículo. A esto le llamo un ciclo de feedback frecuente. En el caso extremo os encontráis conduciendo campo a través y no podéis despistaros ni un segundo; ciclo de feedback continuo.

Las metodologías tradicionales, sobre todo las basadas en ciclo de vida waterfall, asumen que una vez planificado el proyecto y realizado la fase de análisis éste no va a sufrir cambios y por lo tanto no se admiten cambios en él. En este sentido se asemejan al primer ejemplo, el conducir por una carretera recta sin baches y sin apenas tráfico. Si aparece el cliente a mitad del proyecto con cambios, estas metodologías aconsejan rechazar los nuevos cambios bajo la excusa de que ya se hizo el análisis al principio del proyecto y que se tienen las actas para demostrarlo. Algunas de ellas admiten cambios pero sólo tras pasar por un proceso de gestión de cambios que normalmente es caro y retrasa el proyecto.

Como todos sabemos el mundo real no se asemeja a un entorno estable sino a un entorno caótico y turbulento, más parecido a conducir en hora punta por Madrid en medio de las obras de la M30 que a una carretera solitaria. Es por esto que uno de los caballos de batalla de las metodologías ágiles consiste en adaptarse y absorber el cambio de forma flexible y eficiente. Para conseguir ésto lo primero que necesitamos es un ciclo de feedback muy frecuente, ¿por qué? Pues para poder percibir rápidamente tanto problemas en el proyecto como cambios en el funcional lo antes posible. Cuanto antes percibamos las cosas antes podremos reaccionar a ellas. De hecho cuanto más tardemos en percibir un problema o cambio y más tardemos en darle solución, más coste e impacto tendrá sobre nuestro proyecto. Valorad según vuestra experiencia cuanto os cuesta asimilar un cambio a principio de proyecto y cuanto os cuesta absorberlo a una semana de entrar en producción. Sin embargo el hecho de aceptar los cambios en cualquier momento y de cualquier manera también puede llevar tu proyecto al fracaso. Los cambios hay que aceptarlos de manera ordenada y planificada, de otra forma no estaríamos hablando de metodología sino del barra libre y el caos absoluto. El parar los cambios tiene también ventajas: por un lado el equipo de trabajo se concentra y es más eficiente;  por otro evitamos aceptar cambios espurios frutos de impulsos, cambios que en dos o tres días el mismo cliente puede decidir eliminar y volver a lo que quería antes; finalmente podemos priorizar en que orden acometer los cambios según el valor que den al proyecto. Evidentemente la necesidad de aceptar cambios cuanto antes y la de parar los cambios para que el proyecto se pueda gestionar se contraponen. Aquí es donde las metodologías ágiles intentan dar una solución de compromiso.

De aquí nace la idea de dividir el proyecto en iteraciones más cortas, de dos o tres semanas aproximadamente. Los cambios no se admiten durante una iteración, sino que se encolan para la siguiente iteración. De este modo conseguimos mayor flexibilidad sin tener que aceptar cambios de forma caótica. De esto se concluye que cuanto más cortas sean las iteraciones más capacidad de reacción tendremos. El tamaño de las iteraciones depende del tipo de proyecto, cliente y entorno en el que nos movamos. Cuanto más volátil sea el entorno más cortas deben ser.

Si no estáis familiarizados con metodologías ágiles, pensad, ¿qué es más arriesgado, un proyecto de un mes o uno de un año? Obviamente el de un año, por eso la idea de dividir el proyecto de un año en doce proyectos de un mes (iteraciones). Por otra parte se le pueden enseñar al cliente los progresos del proyecto al finalizar cada iteración, lo que le lleva a estar más tranquilo sobre el progreso del proyecto y el equipo de desarrollo puede obtener feedback del cliente más frecuentemente para saber si van por buen camino o necesitan cambiar algo. Esto nos lleva también a una forma de pago más justa, el cliente nos puede pagar por cada trozo o iteración de proyecto completado con éxito en vez de por el proyecto completo. Esto es ventajoso tanto para el cliente como para el proveedor.

Sin embargo las iteraciones no son la única fuente de feedback que nos proponen las metodologías ágiles. De hecho las metodologías ágiles promueven varios ciclos de control anidados. Cada ciclo de control trabaja con su propia frecuencia de feedback y su propio ámbito de aplicación. En general a mayor frecuencia menor ámbito de aplicabilidad. También hay que hace énfasis en que dichos ciclos no tienen como único cometido adaptarse a cambios sino también detectar y subsanar errores lo antes posible. Es en este último punto donde las metodologías dejan lugar a evolucionar los procesos en si para adaptarse a cada organización y entorno y hacerlos cada vez más eficientes. Es una forma de hacer tuning de nuestros procesos en base a los resultados obtenidos. En otro post pienso explorar más a fondo esto.

Algunos ciclos de control típicos son los siguientes:

• Retrospectiva de fin de proyecto. Nos permite detectar que ha funcionado y que no en el proceso durante el proyecto. El objetivo es optimizar el proceso para el siguiente proceso.
• Ciclo de iteración. Como anteriormente comentamos suele ser de una a tres semanas. Nos permiten reaccionar ante cambios funcionales, bugs y de prioridad entre requisitos. También al final de cada iteración se suele revisar la eficacia del proceso de desarrollo con el fin de mejorar éste, es lo que se suele llamar una retrospectiva. La iteración forma la base de la planificación del trabajo en metodologías como SCRUM (donde llaman sprints a las iteraciones).
• Integración continua. Se produce en el orden de las horas o como mucho, un día. Se trata de integrar todos los cambios realizados por el equipo de desarrollo en una única base de código estable y en funcionamiento. Durante el proceso de integración continua se fusionan los distintos cambios que hay en el repositorio de versiones, se compila todo, se pasa las pruebas unitarias, se instala en entorno de pruebas y se pasan las pruebas de integración. Nos permite por un lado tener una base de código estable sobre la que seguir trabajando y por otro lado detectar rápidamente problemas de integración.
• Test Driven Development (TDD). Este ciclo se mide en minutos o como mucho en pocas horas. Su ámbito es de unos pocos  artefactos de código. Nos permite detectar de forma temprana errores en la programación de uno o varios artefactos de código (como las clases por ejemplo). El tema del TDD es algo que espero tratar en otro post.
• Pair Programming. Este ciclo se mide en segundos o en minutos en un ámbito de una función o trozo de código. Permite a una pareja de programadores detectar fallos en funcionalidad y diseño de pequeños trozos de código de forma instantánea. De nuevo es un tema que se merece su propio post. Por cierto yo suelo llamar a esta práctica calidad continua ya que permite de forma continua vigilar la calidad del código.

Por supuesto se me habrán quedado en el tintero más ciclos de control pero los anteriormente expuestos son los más importantes.

Finalmente un comentario personal. Me extraña bastante que en un país como España no se hayan adoptado las metodologías ágiles de forma más amplia. Realmente encuentro en el día a día que se adoptan metodologías muy burocráticas y que no son capaces de responder a los cambios y mucho menos a la realidad de los proyectos. Sin embargo esto está asumido y a la hora de aplicarlas en la práctica la mayoría de la gente se las saltan para adoptar un enfoque más ágil (aunque generalmente desectructurado). Es decir, vivimos en un mundo caótico, donde se usan oficialmente metodologías no ágiles, pero en la práctica no se usan éstas sino que simplemente se ignoran las metodologías o en su mejor caso se realiza agilismo extremo de forma soterrada. Es una situación absurda que clama por que sea cambiada.

En el siguiente post hablaré sobre el siguiente pilar de las metodologías ágiles, la eliminación del trabajo innecesario.

Read Full Post »

Víctimas de la moda

Bueno pensaba que mi primer post iba a ser técnico, pero no, me han entrado ganas de soltar una «filosofada».

Desde hace ya un tiempo me he dado cuenta que mucho de los profesionales que nos dedicamos al desarrollo de aplicaciones web hemos caído en la tentación de tomar decisiones técnicas basadas en la moda. Yo suelo tener que vigilarme a mi mismo para no caer en esta trampa.

¿Quién no se ha encontrado pensando que para su nuevo proyecto va a usar las últimas tecnologías que están más de moda? Quizás es que nos aburrimos de usar siempre las mismas tecnologías o simplemente no queremos quedarnos «deprecated» y evolucionar.

Sin embargo esta forma de tomar decisiones nos puede llevar al desastre en un proyecto, si elegimos la tecnología equivocada, el proyecto puede fracasar. No nos servirá de nada decir que es lo último, lo más moderno, que era el proyecto de código abierto más popular o que el google trends decía que se iba a imponer. Al fin y al cabo somos ingenieros y debemos tomar decisiones basadas en razonamientos sólidos, evaluar coste/beneficio y ver que herramientas son las más adecuadas para nuestra misión. No deberíamos dejarnos guiar por nuestros deseos o dejarnos engañar por campañas de marketing viral.

Lo peor ocurre cuando te encuentras con algún arquitecto o programador o incluso cliente que ya ha transcendido su etapa de víctima de la moda y se ha transformado en un fanático. Algunas citas textuales de fanáticos que me he encontrado: «pues el framework X es el mejor» o «eso que haces es una mierda, es mucho mejor la tecnología Z» o la última que escuché, «es que el framework XYZ es el que hace todas las cosas chulas». Siempre termino preguntándoles ¿Por qué? y ellos responden «¿No lo sabes? Todo el mundo lo usa…»

Usemos las herramientas adecuadas para cada tipo de problema.

No seamos víctimas de la moda, sino profesionales.

Read Full Post »

¡Hola Mundo!

¡Hola a todos! En este primer post simplemente presentaré este blog.

Lo primero de todo es comentaros cual es la temática del mismo. Aquí intentaré ir escribiendo un articulo o dos al mes contando mi visión de las últimas tendencias en ingeniería del software, frameworks e informática profesional en general.  Explicaré, con más o menos fortuna, cosas como servicios REST, metodologías ágiles, TDD, aplicaciones RIA y AJAX y buenas prácticas en general.

¿Por qué este blog? Simplemente me di cuenta de que mis compañeros y yo tenemos de vez en cuando conversaciones y discusiones donde vamos aprendiendo como aplicar todas estas nuevas ideas para mejorar los proyectos en los que estamos inmersos. Así que reflejar lo aprendido mediante un blog se me antoja una buena idea. Se trata de dar un enfoque práctico, desde la realidad del día a día sobre todos estos temas a veces tan confusos, abstractos o teóricos. Normalmente no pondré código, este no es un blog de «ejemplos de código», sino que más bien trataré de explicar conceptos de forma sencilla y como aplicarlos a la realidad.

Espero que vosotros participéis en la discusión y dejéis muchos comentarios. Respetaré todos los comentarios, aunque sean negativos, siempre y cuando sean educados, sigan las normas básicas de la etiqueta y vengan a cuento. Creo que este blog puede ser de utilidad y generar un debate constructivo.

Intentaré no hacer posts largos, sino cortos y sencillos. Si alguna cosa es compleja la abordaré en varios posts.

¿Por qué en español? Pues muy sencillo, ¡ya hay muchos blogs en inglés! Además no esta de más dar una visión «hispana» de todo esto, por aquí también sabemos hacer las cosas bien. Sin embargo, aunque escribiré en español, no pienso traducir palabras técnicas. No escribiré cosas como ‘cadenas’ o ‘arreglos’ sino ‘strings’ y ‘arrays’ y en vez de ‘servicios web’ hablaré de ‘web services’.

Nos vemos pronto

Read Full Post »