¿Cómo surgió el desarrollo ágil? Principios fundamentales
Principios fundamentales
Aunque probablemente el cambio de desarrollo tradicional a desarrollo ágil empezó mucho antes de los acontecimientos que voy a mencionar, estos son los más importantes que marcaron la base para lo que hoy en día llamamos agilidad, como todo buen cambio, no sucedió de la noche a la mañana, fue un proceso lento, como un cambio de paradigma, el cual la sociedad de la administración de proyectos y software empezaron poco a poco a interiorizar o al menos a utilizar.
En cuanto a los métodos, puede haber un millón y algo más, pero los principios son pocos. El hombre que capta los principios puede seleccionar con éxito sus propios métodos. El hombre que prueba métodos, ignorando principios, seguramente tendrá problemas.
Ralph Waldo Emerson
Es importante mencionar que a pesar de que el movimiento ágil se relaciona mucho con del desarrollo de software, realmente no tiene que ver específicamente con esta industria, más bien sus raíces son en las personas mismas, por lo que se aplica a todas las áreas que te puedas imaginar donde existan personas, es decir, en todo.
El desarrollo ágil es un cambio cultural, lleno de principios y valores humanos, que todos y cada uno de los integrantes de un equipo y de una empresa deben tener arraigado muy en su ser, para que de esta manera sucedan cosas mágicas, como la creación de productos que llenan de enorme satisfacción al usuario y los clientes, velocidad de producción, reducción de costos, proyectos exitosos, empleados felices y en general el beneficio de todos los involucrados, tanto internos como externos, directos o indirectos.
Total Quality Management (TQM)
El primer cambio significativo con dirección al desarrollo ágil sucede durante la segunda guerra mundial donde Williams Edwards Deming les enseño control estadístico de los procesos a los ingenieros estadounidenses con el fin de mejorar los materiales de guerra, aun así, parece que los estadounidenses no le prestaron mucho interés, probablemente debido a la guerra. Después de esto en 1950, Deming se trasladó a Japón, en la época donde la industria y economía de este país estaba en crisis, esta vez si pudo transmitir exitosamente sus conocimientos y filosofía de la calidad de los productos y servicios. Los japoneses lo escucharon y estuvieron dispuestos a cambiar la cultura de trabajo.
Al implementar los principios de la metodología de Deming, los japoneses convirtieron totalmente su economía e industria posicionándose como lideres mundiales en ámbitos como tecnología, industria manufacturera y comunicaciones
De hecho la metodología TQM que creo Deming fue la base para el nacimiento del movimiento ágil, los principios más importantes de TQM son los siguientes:
- Mejorar la calidad resulta en reducción de costos, reducción del costo de los defectos, reducción de soporte al cliente y menos llamadas de los mismos en relación con defectos.
- Mejora continua en todos las partes del sistema y las personas.
- Orgullo del trabajo que hace una persona, es la clave principal para obtener la calidad necesaria de un producto/servicio, que los empleados disfruten su trabajo y con orgullo.
- Plan – Do – Check – Act (PDCA) – Ciclo de desarrollo para poder probar y obtener retroalimentación sobre soluciones de problemas y creación de sistemas complejos.
Del punto uno y dos, Deming fomentó lo siguiente:
Mejorando la calidad, automáticamente, mejora la productividad.
Williams Edward Deming
En la actualidad, existe un principio ágil muy relacionado con lo que dijo el señor Deming:
La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
Principio ágil
Del punto tres tenemos su relación con el principio actual
Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
Principio ágil
Si analizamos los primeros tres puntos de TQM y en concreto el tercer punto, podemos concluir que al preocuparnos por las personas obtendremos calidad y una mejora continua tanto en los sistemas y procesos como en las personas mismas, por que al final de todo, los individuos son el recurso que genera productos/servicios y forman empresas.
En el manifiesto Ágil que veremos en otra publicación, el primer elemento de manifiesto y el más importante dice así:
Individuos e interacciones sobre procesos y herramientas.
Del manifiesto ágil
Como podemos ver el desarrollo ágil no es realmente algo nuevo, siempre se ha estado buscando mejores maneras de trabajar.
Sobre el último punto, el ciclo PDCA se parece mucho a lo que se utiliza actualmente en Lean, Lean startup, Lean thinking, Design thinking, RAD, DSDM, Extreme programming, Scrum, Crystal clear y demás metodologías estilo ágiles. El objetivo es obtener retroalimentación inmediatamente para aprender y mitigar errores o direcciones equivocadas.
Este ciclo PDCA nos permite responder al cambio, con lo cual se ejerce un principio fundamental del manifiesto ágil:
Respuesta al cambio sobre seguir un plan
Del Manifiesto ágil
Ahora veamos los diagramas de algunos de los ciclos de retroalimentación que tiene las metodologías ágiles:
¿Qué tal, todos estos ciclos son muy parecidos verdad?
Toyota Production System (TPS)
Este sistema desarrollado entre 1948 y 1975, y presentado formalmente en los 80´s fue inspirado en los trabajos de Henry Ford y también en TQM debido a que sus inicios datan de la misma época cuando Edwards Deming fue a Japón a transmitir sus conocimientos de Gestión de calidad Total (TQM) y en esos tiempos Taichii Ohno estaba trabajando para Toyota Motors Company. Como todo buen diseño, no solo de una fuente surgen las inspiraciones y las ideas, pero podemos notar la influencia y evolución de TQM en TPS.
Este sistema fue el precursor de Lean Manufacturing y demás metodologías Lean de la actualidad. Los principios en los que se basa TPS son los siguientes:
- Mejora continua, tomando como base a las personas, mejorando su ambiente laboral, su aprendizaje, su creatividad e ideas para que de esta manera mejoren en todo lo que hacen incluyendo los procesos, herramientas y métodos utilizados en toda la empresa.
- Respeto por las personas. Aquí de nuevo otra constante clave del éxito de este sistema, el respeto por las personas. Aunque también el enfoque es en la mejora continua, esto nunca se lograría sin el respeto, ¿Qué es el respeto? Para mí, y esto ya lo escribí en otro post cursi sobre agilidad (¿Qué es Scrum? ¿Por qué es importante en la creación de productos y/o servicios? Valores, empirismo y pilares) es el amor por otra persona, aunque no intenso, es la naturaleza del ser humano preocuparse por los demás, un sentimiento latente en mayor o menor medida, todos somos diferentes, y lamentablemente algunos de nosotros lo tenemos muy escondido, pero ahí esta, un principio natural que genera un ciclo infinito de buenas intenciones.
A través del principio de mejora continúa y respeto por las personas, TPS propone lo siguiente:
La eliminación de desperdicios (Muda), los cuales son provocados por la sobrecarga de trabajo y estrés de los empleados, máquinas, procesos, etc (Muri), también por inconsistencias y variaciones no previstas que causan un desequilibrio en la producción (Mura). Con Muri y Mura podemos destacar de nuevo la importancia de las personas para el éxito de este método. TPS define 7 tipos de desperdicios, solo los voy a mencionar:
- Desperdicio por sobreproducción
- Desperdicio por Tiempo de espera
- Desperdicio por transporte
- Desperdicio por procesos
- Desperdicio por inventario
- Desperdicio por movimientos
- Desperdicio por defectos
Lotes pequeños. La mejor manera de encontrar errores, aprender de ellos y mitigar sus efectos negativos lo más pronto posible es por tareas/procesos pequeños y simples mucho más fáciles de manejar y entender.
Kanban. Para eliminar el desperdicio, Taiichi utilizó un tablero con tarjetas (Kanban) donde se puede visualizar lo que se tiene que hacer, lo que sé está haciendo, lo que se terminó y si una tarea necesita de materiales o de la finalización de otra tarea para continuar.
Pruebas constantes. Siempre probando con lotes pequeños para encontrar errores y mitigarlos inmediatamente. En cada lote pequeño es más fácil hacer pruebas, actualmente en agilidad se utilizan las pruebas unitarias y funcionales de un lote pequeño de elementos del sistema que entregan valor para los usuarios/clientes en periodos cortos de tiempo.
Estos últimos puntos están muy relacionados con el siguiente principio ágil:
Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
Principio ágil
Todo lo anterior permite que Toyota se encuentre actualmente como una de las tres mejores compañías de autos, con un 70% de satisfacción de sus empleados. ¿Que compañía logra eso? el enfoque de respeto hacia las personas ha hecho de Toyota lo que hoy en día es.
¿El modelo en cascada propuso algunas practicas de lo que hoy llamamos desarrollo ágil?
¿Qué? ¿Cómo? y seguro pensaras algo así, “A mí me enseñaron que el ciclo del modelo en cascada era secuencial, no te creo”. Bueno a mí también me enseñaron lo mismo, pero investigando resulta que hay un mal entendido global de lo que propuso Winston Royce acerca del modelo en cascada y la prueba que encontré esta aquí, por si quieres abrir los ojos por ti mismo.
Expliquemos lo que propuso Winston Royce en su documento del año 1970, si, como he estado explicando, siempre ha existido una tendencia hacia el desarrollo ágil. Winston Royce presento el siguiente diagrama:
Pero inmediatamente aclaró que este modelo era muy riesgoso y propenso al fracaso. ¿Entonces por que demonios lo empezamos a utilizar? No lo sé, pero en mi caso, lamentablemente fue lo que me enseñaron en la universidad, cuando en esa época ya existían mejores métodos para el desarrollo de software como XP y Scrum que se establecieron formalmente a los mediados de los 90’s. Winston Royce propuso cinco mejoras al método de cascada, son los siguientes:
- El diseño del sistema debe ser primero
- Documentar el diseño
- Hacerlo dos veces
- Planear, controlar y monitorear pruebas
- Involucrar al cliente
Aunque las dos primeras mejoras se podría decir que no son ágiles, los ultimas tres mejoras claramente tienen su merito ágil. Aun así el método que propone Winston Royce no es secuencial, sino más bien iterativo e incremental, bueno, tampoco no tan iterativo e incremental como actualmente lo es el desarrollo ágil pero era un gran comienzo. Veamos ahora el diagrama con las cinco mejoras de Royce:
No explicare a detalle las cinco mejoras, pero las describiré brevemente y su relación con los principios fundamentales del desarrollo ágil. Antes de eso si se fijan de lado derecho existe otro ciclo de retroalimentación que va desde pruebas, desarrollo y requerimientos, por lo que totalmente lineal waterfall nunca lo fue.
- El diseño del sistema debe ser primero, esto actualmente siempre se hace solo que en ciclos pequeños e incrementales sobre todo el sistema, también en escala aún más pequeña al realizar las pruebas unitarias o funcionales se piensa inmediatamente primero en el diseño de la funcionalidad antes de escribir código para poder crear la prueba.
- Documentar el diseño. En las metodologías ágiles de hecho se realiza documentación solo que muchas veces no están en documentos, sino en las pruebas unitarias y funcionales, es decir, en lugares donde no se podrá mentir, en la fuente, el código. Pero esto último es otro tema, lo de mayor prioridad es tener un software funcionando, aun así la documentación también se hace por ciclos iterativos e incrementales.
- Hacerlo dos veces. Royce empieza a recomendar ciclos iterativos e incrementales al sugerir realizar dos veces la creación del sistema. Actualmente en desarrollo ágil no solo se realiza dos veces, sino muchas veces en periodos cortos del mismo día, en horas y hasta en minutos, también siendo iterativo e incremental,
- Planear, controlar y monitorear pruebas. En metodologías ágiles se utilizan las pruebas para obtener retroalimentación lo más pronto posible y hacer los arreglos necesarios, aunque el modelo de Royce a mi parecer no implementa las pruebas tan seguido como en las metodologías ágiles actuales, mínimo lo hace dos veces durante una iteración.
- Involucrar al cliente. Este es el más importante para mí porque hace mucho hincapié sobre las interacciones de las personas. En el manifiesto ágil de la actualidad tenemos lo siguiente:
Colaboración con el cliente sobre negociación contractual
Del manifiesto ágil
Métodos iterativos e incrementales
En el ámbito de la creación de software, mucha antes de la creación del famoso manifiesto ágil, metodologías y frameworks tradicionales que se utilizaban para crear productos o proyectos no estaban funcionando, existía un porcentaje muy alto de fracaso.
El porcentaje alto de fracasos fue influido por la mala implementación del modelo en cascada de Winston Royce. Entonces varias personas empezaron a preguntarse si habría mejores maneras de desarrollar software, es aquí donde empezaron a crear sus propias métodos ágiles, empezaron a surgir metodologías como:
Rapid Application Development (RAD) – 70s – 80s
Como vemos en este ciclo de retroalimentación, existen iteraciones en las fases de diseño y construcción.
Dynamic software development method (DSDM) – 80s
En el ciclo de retroalimentación de esta metodología, incluye iteraciones en la factibilidad y fundación, es decir, los requerimientos, además de poder hacer iteraciones en las fases diseño y construcción.
Extreme Programing (XP) – Mediados de los 90s, Kent Beck, Ward Cunningham, Ron Jeffries
Este es un mejor ciclo de retroalimentacion en comparacion con los anteriores, en todo momento se hacen iteraciones, en todos los niveles, además:
- Mucho uso de TDD, continuamente durante todas las etapas
- Pruebas de aceptación y unitarias
- Origen de los Dailys o stand up meetings
- También las famosas historias de usuario.
Scrum – A mediados de los 90s – Ken Schwaber, Jeff Sutherland
Bueno este es el más conocido de todos y el más usado actualmente, para mas detalles sobre este framework te dejo los siguentes enlaces:
Aunque estos frameworks ya habían empezado con el desarrollo ágil, era necesario definir ciertos principios comunes para mejorar el entendimiento y la rápida adopción de estas nuevas formas de crear software.
En el 2001, 17 desarrolladores de software se reunieron en Snowbird, Utah para analizar sobre los métodos de desarrollo de software ágil que estas 17 personas estaban utilizando, DSDM, Extreme Programming, Scrum y crystal clear. El resultado fue el Manifiesto ágil y los 12 principios ágiles.
¿Por que es de suma importancia el manifiesto y los 12 principios ágiles?
Es importante entender que más adelante podría surgir un nuevo framework ágil con una mejor manera de hacer las cosas y que probablemente deberíamos de adoptar, pero el manifiesto y los principios ágiles seguirán siendo la base primordial que si se comprende bien y se interiorizan, cualquier equipo u organización podra utilizar el framework o método que más le convenga en determinadas circunstancias o proyectos.
Es como la creación de código y piezas de un sistema computacional, no importa el lenguaje de programación, librería o frameworks de desarrollo, si no las bases de lógica, patrones y principios de diseño y arquitectura, los que harán entender cualquier nuevo lenguaje o framework que pudiera salir en el futuro.
Hablando un poco más sobre las prácticas utilizadas en los frameworks ágiles, estás prácticas están subordinadas por los principios, es decir, en un proyecto, se utilizarán las prácticas más acordes a las circunstancias del problema que se quiere solucionar. Por la tanto es importante comprender el porque se ejecuta una práctica, o sea, que practica me dará mejores resultados y agilidad basándome en los principios y factores específicos del problema.
¿Qué es ágil?
La capacidad de crear y responder al cambio con el fin de tener éxito en un ambiente incierto y turbulento
agilealliance.org
Manifiesto Ágil
Estamos descubriendo mejores formas de desarrollar software haciéndolo y ayudando a otras personas a hacerlo. A través de este trabajo hemos llegado a valorar:
Individuos e interacciones sobre procesos y herramientas.
Software funcionando sobre documentación exhaustiva.
Colaboración con el cliente sobre negociación de contratos.
Respuesta ante el cambio sobre seguir un plan
Es decir, aunque valoramos los elementos de la derecha, valoramos más los elementos de la izquierda.
En esta publicación explico a detalle la razón y como aplicar el manifiesto ágil:
12 Principios ágiles
Aquí están los 12 principios ágiles tomados de la fuente oficial, en otra publicación veremos a detalle cada uno de estos y como se aplica en un proyecto real.
Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.
El software funcionando es la medida principal de progreso.
Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.
ES_MX 
EN