{"id":3559,"date":"2019-08-18T12:15:09","date_gmt":"2019-08-18T18:15:09","guid":{"rendered":"http:\/\/pensemosweb.com.mx\/?p=22"},"modified":"2024-03-07T16:03:17","modified_gmt":"2024-03-07T22:03:17","slug":"como-surgio-el-desarrollo-agil-principios-fundamentales","status":"publish","type":"post","link":"https:\/\/pensemosweb.com\/en\/como-surgio-el-desarrollo-agil-principios-fundamentales\/","title":{"rendered":"\u00bfC\u00f3mo surgi\u00f3 el desarrollo \u00e1gil? Principios fundamentales"},"content":{"rendered":"<h2 class=\"wp-block-heading\">Principios fundamentales<\/h2>\n\n\n\n<p>Aunque probablemente el cambio de desarrollo tradicional a desarrollo \u00e1gil empez\u00f3 mucho antes de los acontecimientos que voy a mencionar, estos son los m\u00e1s importantes que marcaron la base para lo que hoy en d\u00eda llamamos agilidad, como todo buen cambio, no sucedi\u00f3 de la noche a la ma\u00f1ana, fue un proceso lento, como un cambio de paradigma, el cual la sociedad de la administraci\u00f3n de proyectos y software empezaron poco a poco a interiorizar o al menos a utilizar.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\"><p>En cuanto a los m\u00e9todos, puede haber un mill\u00f3n y algo m\u00e1s, pero los principios son pocos. El hombre que capta los principios puede seleccionar con \u00e9xito sus propios m\u00e9todos. El hombre que prueba m\u00e9todos, ignorando principios, seguramente tendr\u00e1 problemas.<\/p><cite>Ralph Waldo Emerson<\/cite><\/blockquote>\n\n\n\n<p>Es importante mencionar que a pesar de que el movimiento \u00e1gil se relaciona mucho con del desarrollo de software, realmente no tiene que ver espec\u00edficamente con esta industria, m\u00e1s bien sus ra\u00edces son en las personas mismas, por lo que se aplica a todas las \u00e1reas que te puedas imaginar donde existan personas, es decir, en <strong>todo<\/strong>.<\/p>\n\n\n\n<p>El desarrollo \u00e1gil 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\u00e1gicas, como la creaci\u00f3n de productos que llenan de enorme satisfacci\u00f3n al usuario y los clientes, velocidad de producci\u00f3n, reducci\u00f3n de costos, proyectos exitosos, empleados felices y en general el beneficio de todos los involucrados, tanto internos como externos, directos o indirectos.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Total Quality Management (TQM)<\/h2>\n\n\n\n<p>El primer cambio significativo con direcci\u00f3n al desarrollo \u00e1gil sucede durante la segunda guerra mundial donde <strong>Williams Edwards Deming<\/strong> les ense\u00f1o <strong>control estad\u00edstico de los procesos<\/strong> a los ingenieros estadounidenses con el fin de mejorar los materiales de guerra, aun as\u00ed, parece que los estadounidenses no le prestaron mucho inter\u00e9s, probablemente debido a la guerra. Despu\u00e9s de esto en 1950, Deming se traslad\u00f3 a Jap\u00f3n, en la \u00e9poca donde la industria y econom\u00eda de este pa\u00eds estaba en crisis, esta vez si pudo transmitir exitosamente sus conocimientos y filosof\u00eda de la calidad de los productos y servicios. Los japoneses lo escucharon y estuvieron dispuestos a cambiar la cultura de trabajo.<\/p>\n\n\n\n<p>Al implementar los principios de la metodolog\u00eda de Deming, los japoneses convirtieron totalmente su econom\u00eda e industria posicion\u00e1ndose como lideres mundiales en \u00e1mbitos como tecnolog\u00eda, industria manufacturera y comunicaciones<\/p>\n\n\n\n<p>De hecho la metodolog\u00eda TQM que creo Deming fue la base para el nacimiento del movimiento <strong>\u00e1gil<\/strong>, los principios m\u00e1s importantes de TQM son los siguientes:<\/p>\n\n\n\n<ol class=\"wp-block-list\"><li>Mejorar la calidad resulta en reducci\u00f3n de costos, reducci\u00f3n del costo de los defectos, reducci\u00f3n de soporte al cliente y menos llamadas de los mismos en relaci\u00f3n con defectos.<\/li><li>Mejora continua en todos las partes del sistema y las personas.<\/li><li>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.<\/li><li>Plan &#8211; Do &#8211; Check &#8211; Act (PDCA) &#8211; Ciclo de desarrollo para poder probar y obtener retroalimentaci\u00f3n sobre soluciones de problemas y creaci\u00f3n de sistemas complejos.<\/li><\/ol>\n\n\n\n<p>Del punto uno y dos, Deming foment\u00f3 lo siguiente:<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\"><p>Mejorando la calidad, autom\u00e1ticamente, mejora la productividad.<\/p><cite>Williams Edward Deming<\/cite><\/blockquote>\n\n\n\n<p>En la actualidad, existe un principio \u00e1gil muy relacionado con lo que dijo el se\u00f1or Deming:<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\"><p>La atenci\u00f3n continua a la excelencia t\u00e9cnica y al buen dise\u00f1o mejora la Agilidad.<\/p><cite><a href=\"https:\/\/agilemanifesto.org\/iso\/es\/principles.html\">Principio \u00e1gil<\/a><\/cite><\/blockquote>\n\n\n\n<p>Del punto tres tenemos su relaci\u00f3n con el principio actual<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\"><p>Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecuci\u00f3n del trabajo.<\/p><cite><a href=\"https:\/\/agilemanifesto.org\/iso\/es\/principles.html\">Principio \u00e1gil<\/a><\/cite><\/blockquote>\n\n\n\n<p>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.<\/p>\n\n\n\n<p>En el <a href=\"https:\/\/agilemanifesto.org\/iso\/es\/manifesto.html\">manifiesto \u00c1gi<\/a>l que veremos en otra publicaci\u00f3n, el primer elemento de manifiesto y el m\u00e1s importante dice as\u00ed:<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\"><p><strong>Individuos e interacciones <\/strong>sobre procesos y herramientas.<\/p><cite><a href=\"https:\/\/agilemanifesto.org\/iso\/es\/manifesto.html\">Del manifiesto \u00e1gil<\/a><\/cite><\/blockquote>\n\n\n\n<p>Como podemos ver el desarrollo \u00e1gil no es realmente algo nuevo, siempre se ha estado buscando mejores maneras de trabajar.<\/p>\n\n\n\n<p>Sobre el \u00faltimo 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\u00e1s metodolog\u00edas estilo \u00e1giles. <strong>El objetivo es obtener retroalimentaci\u00f3n inmediatamente para aprender y mitigar errores o direcciones equivocadas.<\/strong><\/p>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"aligncenter\"><img decoding=\"async\" src=\"https:\/\/www.pensemosweb.com\/wp-content\/uploads\/2019\/07\/Ciclo-PDCA-300x204.png\" alt=\"\" class=\"wp-image-1036\"\/><\/figure><\/div>\n\n\n\n<p>Este ciclo PDCA nos permite responder al cambio, con lo cual se ejerce un principio fundamental del manifiesto \u00e1gil:<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\"><p><strong>Respuesta al cambio<\/strong> sobre seguir un plan<\/p><cite><a href=\"https:\/\/agilemanifesto.org\/iso\/es\/manifesto.html\">Del Manifiesto \u00e1gil<\/a><\/cite><\/blockquote>\n\n\n\n<p>Ahora veamos los diagramas de algunos de los ciclos de retroalimentaci\u00f3n que tiene las metodolog\u00edas \u00e1giles:<\/p>\n\n\n\n<div class=\"wp-block-image wp-image-1058 size-medium\"><figure class=\"aligncenter\"><img decoding=\"async\" src=\"\/wp-content\/uploads\/2019\/07\/design-thinking-cycle-600x607.png\" alt=\"Design Thinking Ciclo de retroalimentaci\u00f3n\" class=\"wp-image-1058\"\/><figcaption>Design Thinking Ciclo de retroalimentaci\u00f3n<\/figcaption><\/figure><\/div>\n\n\n\n<div class=\"wp-block-image wp-image-130 size-medium\"><figure class=\"aligncenter\"><img decoding=\"async\" src=\"\/wp-content\/uploads\/2018\/12\/Construir-Medir-Aprender-2-600x401.jpg\" alt=\"Ciclo Construir, Medir, Aprender\" class=\"wp-image-130\"\/><figcaption>Lean Startup ciclo de retroalimentaci\u00f3n<\/figcaption><\/figure><\/div>\n\n\n\n<div class=\"wp-block-image wp-image-1046 size-medium\"><figure class=\"aligncenter\"><img decoding=\"async\" src=\"https:\/\/www.pensemosweb.com\/wp-content\/uploads\/2019\/07\/scrum-cycle-600x278.png\" alt=\"Scrum ciclo de retroalimentaci\u00f3n\" class=\"wp-image-1046\"\/><figcaption>Scrum ciclo de retroalimentaci\u00f3n<\/figcaption><\/figure><\/div>\n\n\n\n<div class=\"wp-block-image wp-image-1047 size-medium\"><figure class=\"aligncenter\"><img decoding=\"async\" src=\"https:\/\/www.pensemosweb.com\/wp-content\/uploads\/2019\/07\/xtremeProgrammingCycle-600x551.png\" alt=\"Extreme Programming\" class=\"wp-image-1047\"\/><figcaption>Extreme Programming<\/figcaption><\/figure><\/div>\n\n\n\n<div class=\"wp-block-image wp-image-1053 size-medium\"><figure class=\"aligncenter\"><img decoding=\"async\" src=\"https:\/\/www.pensemosweb.com\/wp-content\/uploads\/2019\/07\/DSDM_Cycle-600x524.png\" alt=\"DSDM ciclo de retroalimentaci\u00f3n\" class=\"wp-image-1053\"\/><figcaption>DSDM ciclo de retroalimentaci\u00f3n<\/figcaption><\/figure><\/div>\n\n\n\n<p>\u00bfQu\u00e9 tal, todos estos ciclos son muy parecidos verdad?<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Toyota Production System (TPS)<\/h2>\n\n\n\n<p>Este sistema desarrollado entre 1948 y 1975, y presentado formalmente en los 80\u00b4s fue inspirado en los trabajos de Henry Ford y tambi\u00e9n en TQM debido a que sus inicios datan de la misma \u00e9poca cuando Edwards Deming fue a Jap\u00f3n a transmitir sus conocimientos de Gesti\u00f3n de calidad Total (TQM) y en esos tiempos <strong>Taichii Ohno<\/strong> estaba trabajando para Toyota Motors Company. Como todo buen dise\u00f1o, no solo de una fuente surgen las inspiraciones y las ideas, pero podemos notar la influencia y evoluci\u00f3n de TQM en TPS.<\/p>\n\n\n\n<p>Este sistema fue el precursor de Lean Manufacturing y dem\u00e1s metodolog\u00edas <strong>Lean <\/strong>de la actualidad. Los principios en los que se basa TPS son los siguientes:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li><strong>Mejora continua<\/strong>, 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\u00e9todos utilizados en toda la empresa.<\/li><li><strong>Respeto por las personas<\/strong>. Aqu\u00ed de nuevo otra constante clave del \u00e9xito de este sistema, el r<strong>espeto por las personas<\/strong><span style=\"color: #777777;\">. Aunque tambi\u00e9n el enfoque es en la mejora continua, esto nunca se lograr\u00eda sin el respeto, \u00bfQu\u00e9 es el respeto? Para m\u00ed, y esto ya lo escrib\u00ed en otro post cursi sobre agilidad <\/span><a style=\"background-color: #ffffff;\" href=\"https:\/\/pensemosweb.com\/en\/scrum-importante-creacion-productos-servicios-valores-empirismo-pilares\/\">(\u00bfQu\u00e9 es Scrum? \u00bfPor qu\u00e9 es importante en la creaci\u00f3n de productos y\/o servicios? Valores, empirismo y pilares)<\/a><span style=\"color: #777777;\"> es el amor por otra persona, aunque no intenso, es la naturaleza del ser humano preocuparse por los dem\u00e1s, un sentimiento latente en mayor o menor medida, todos somos diferentes, y lamentablemente algunos de nosotros lo tenemos muy escondido, pero ah\u00ed esta, un principio natural que genera un ciclo infinito de buenas intenciones.<\/span><\/li><\/ul>\n\n\n\n<p>A trav\u00e9s del principio de mejora contin\u00faa y respeto por las personas, TPS  propone lo siguiente:<\/p>\n\n\n\n<p><strong>La eliminaci\u00f3n de desperdicios<\/strong> (<strong>Muda<\/strong>), los cuales son provocados por la sobrecarga de trabajo y estr\u00e9s de los empleados, m\u00e1quinas, procesos, etc (<strong>Muri<\/strong>), tambi\u00e9n por inconsistencias y variaciones no previstas que causan un desequilibrio en la producci\u00f3n <strong>(Mura)<\/strong>. Con Muri y Mura podemos destacar de nuevo la importancia de las personas para el \u00e9xito de este m\u00e9todo. TPS define 7 tipos de desperdicios, solo los voy a mencionar:<\/p>\n\n\n\n<ol class=\"wp-block-list\"><li>Desperdicio por sobreproducci\u00f3n<\/li><li>Desperdicio por Tiempo de espera<\/li><li>Desperdicio por transporte<\/li><li>Desperdicio por procesos<\/li><li>Desperdicio por inventario<\/li><li>Desperdicio por movimientos<\/li><li>Desperdicio por defectos<\/li><\/ol>\n\n\n\n<p><strong>Lotes peque\u00f1os<\/strong>. La mejor manera de encontrar errores, aprender de ellos y mitigar sus efectos negativos lo m\u00e1s pronto posible es por tareas\/procesos peque\u00f1os y simples mucho m\u00e1s f\u00e1ciles de manejar y entender.<\/p>\n\n\n\n<p><strong>Kanban. <\/strong>Para eliminar el desperdicio, Taiichi utiliz\u00f3 un tablero con tarjetas (<strong>Kanban<\/strong>) donde se puede visualizar lo que se tiene que hacer, lo que s\u00e9 est\u00e1 haciendo, lo que se termin\u00f3 y si una tarea necesita de materiales o de la finalizaci\u00f3n de otra tarea para continuar.<\/p>\n\n\n\n<p><strong>Pruebas constantes. <\/strong>Siempre probando con lotes peque\u00f1os para encontrar errores y mitigarlos inmediatamente. En cada lote peque\u00f1o es m\u00e1s f\u00e1cil hacer pruebas, actualmente en agilidad se utilizan las pruebas unitarias y funcionales de un lote peque\u00f1o de elementos del sistema que entregan valor para los usuarios\/clientes en periodos cortos de tiempo.<\/p>\n\n\n\n<p>Estos \u00faltimos puntos est\u00e1n muy relacionados con el siguiente principio \u00e1gil:<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\"><p>Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de&nbsp;tiempo m\u00e1s corto posible.<\/p><cite><a href=\"https:\/\/agilemanifesto.org\/iso\/es\/principles.html\">Principio \u00e1gil<\/a><\/cite><\/blockquote>\n\n\n\n<p>Todo lo anterior permite que Toyota se encuentre actualmente como una de las tres mejores compa\u00f1\u00edas de autos, con un 70% de satisfacci\u00f3n de sus empleados. \u00bfQue compa\u00f1\u00eda logra eso? el enfoque de respeto hacia las personas ha hecho de Toyota lo que hoy en d\u00eda es.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">\u00bfEl modelo en cascada propuso algunas practicas de lo que hoy llamamos desarrollo \u00e1gil?<\/h2>\n\n\n\n<p>\u00bfQu\u00e9? \u00bfC\u00f3mo?&nbsp; y seguro pensaras algo as\u00ed, &#8220;A m\u00ed me ense\u00f1aron que el ciclo del modelo en cascada era secuencial, no te creo&#8221;. Bueno a m\u00ed tambi\u00e9n me ense\u00f1aron 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\u00e9 esta <a href=\"http:\/\/www-scf.usc.edu\/~csci201\/lectures\/Lecture11\/royce1970.pdf\">here<\/a>, por si quieres abrir los ojos por ti mismo.<\/p>\n\n\n\n<p>Expliquemos lo que propuso Winston Royce en su documento del a\u00f1o 1970, si, como he estado explicando, siempre ha existido una tendencia hacia el desarrollo \u00e1gil. Winston Royce presento el siguiente diagrama:<\/p>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"aligncenter\"><img decoding=\"async\" src=\"\/wp-content\/uploads\/2019\/08\/modelo-cascada-SDLC-1024x680.png\" alt=\"Model en cascada\" class=\"wp-image-1077\"\/><\/figure><\/div>\n\n\n\n<p>Pero inmediatamente aclar\u00f3 que este modelo era muy riesgoso y propenso al fracaso. \u00bfEntonces por que demonios lo empezamos a utilizar? No lo s\u00e9, pero en mi caso, lamentablemente fue lo que me ense\u00f1aron en la universidad, cuando en esa \u00e9poca ya exist\u00edan mejores m\u00e9todos para el desarrollo de software como XP y Scrum que se establecieron formalmente a los mediados de los 90&#8217;s. Winston Royce propuso cinco mejoras al m\u00e9todo de cascada, son los siguientes:<\/p>\n\n\n\n<ol class=\"wp-block-list\"><li><strong>El dise\u00f1o del sistema debe ser primero<\/strong><\/li><li><strong>Documentar el dise\u00f1o<\/strong><\/li><li><strong>Hacerlo dos veces<\/strong><\/li><li><strong>Planear, controlar y monitorear pruebas<\/strong><\/li><li><strong>Involucrar al cliente<\/strong><\/li><\/ol>\n\n\n\n<p>Aunque las dos primeras mejoras se podr\u00eda decir que no son \u00e1giles, los ultimas tres mejoras claramente tienen su merito \u00e1gil. Aun as\u00ed el m\u00e9todo que propone Winston Royce no es secuencial, sino m\u00e1s bien iterativo e incremental, bueno, tampoco no tan iterativo e incremental como actualmente lo es el desarrollo \u00e1gil pero era un gran comienzo. Veamos ahora el diagrama con las cinco mejoras de Royce:<\/p>\n\n\n\n<div class=\"wp-block-image wp-image-1078 size-large\"><figure class=\"aligncenter\"><img decoding=\"async\" src=\"https:\/\/www.pensemosweb.com\/wp-content\/uploads\/2019\/08\/modelo-cascada-real-SDLC-1024x597.png\" alt=\"Modelo cascada \u00e1gil\" class=\"wp-image-1078\"\/><figcaption>Modelo cascada \u00e1gil<\/figcaption><\/figure><\/div>\n\n\n\n<p>No explicare a detalle las cinco mejoras, pero las describir\u00e9 brevemente y su relaci\u00f3n con los principios fundamentales del desarrollo \u00e1gil. Antes de eso si se fijan de lado derecho existe otro ciclo de retroalimentaci\u00f3n que va desde pruebas, desarrollo y requerimientos, por lo que totalmente lineal waterfall nunca lo fue.<\/p>\n\n\n\n<ol class=\"wp-block-list\"><li><strong>El dise\u00f1o del sistema debe ser primero<\/strong>, esto actualmente siempre se hace solo que en ciclos peque\u00f1os e incrementales sobre todo el sistema, tambi\u00e9n en escala a\u00fan m\u00e1s peque\u00f1a al realizar las pruebas unitarias o funcionales se piensa inmediatamente primero en el dise\u00f1o de la funcionalidad antes de escribir c\u00f3digo para poder crear la prueba.<\/li><li><strong>Documentar el dise\u00f1o.&nbsp;<\/strong>En las metodolog\u00edas \u00e1giles de hecho se realiza documentaci\u00f3n solo que muchas veces no est\u00e1n en documentos, sino en las pruebas unitarias y funcionales, es decir, en lugares donde no se podr\u00e1 mentir, en la fuente, el c\u00f3digo.  Pero esto \u00faltimo es otro tema, lo de mayor prioridad es tener un software funcionando, aun as\u00ed la documentaci\u00f3n tambi\u00e9n se hace por ciclos iterativos e incrementales.<\/li><li><strong>Hacerlo dos veces.&nbsp;<\/strong>Royce empieza a recomendar ciclos iterativos e incrementales al sugerir realizar dos veces la creaci\u00f3n del sistema. Actualmente en desarrollo \u00e1gil no solo se realiza dos veces, sino muchas veces en periodos cortos del mismo d\u00eda, en horas y hasta en minutos, tambi\u00e9n siendo iterativo e incremental,<\/li><li><strong>Planear, controlar y monitorear pruebas.&nbsp;<\/strong>En metodolog\u00edas \u00e1giles se utilizan las pruebas para obtener retroalimentaci\u00f3n lo m\u00e1s 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\u00edas \u00e1giles actuales, m\u00ednimo lo hace dos veces durante una iteraci\u00f3n.<\/li><li><strong>Involucrar al cliente.&nbsp;<\/strong> Este es el m\u00e1s importante para m\u00ed porque hace mucho hincapi\u00e9 sobre las interacciones de las personas. En el <a href=\"https:\/\/agilemanifesto.org\/iso\/es\/manifesto.html\">manifiesto \u00e1gil<\/a> de la actualidad tenemos lo siguiente: <\/li><\/ol>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\"><p><strong>Colaboraci\u00f3n con el cliente<\/strong> sobre negociaci\u00f3n contractual <\/p><cite><a href=\"https:\/\/agilemanifesto.org\/iso\/es\/manifesto.html\">Del manifiesto \u00e1gil<\/a><\/cite><\/blockquote>\n\n\n\n<h2 class=\"wp-block-heading\">M\u00e9todos iterativos e incrementales<\/h2>\n\n\n\n<p>En el \u00e1mbito de la creaci\u00f3n de software, mucha antes de la creaci\u00f3n del famoso manifiesto \u00e1gil, metodolog\u00edas y frameworks tradicionales que se utilizaban para crear productos o proyectos no estaban funcionando, exist\u00eda un porcentaje muy alto de fracaso.<\/p>\n\n\n\n<p>El porcentaje alto de fracasos fue influido por la mala implementaci\u00f3n del modelo en cascada de Winston Royce. Entonces varias personas empezaron a preguntarse si habr\u00eda mejores maneras de desarrollar software, es aqu\u00ed donde empezaron a crear sus propias m\u00e9todos \u00e1giles, empezaron a surgir metodolog\u00edas como:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Rapid Application Development (RAD) &#8211; 70s &#8211; 80s<\/h3>\n\n\n\n<p>Como vemos en este ciclo de retroalimentaci\u00f3n, existen iteraciones en las fases de dise\u00f1o y construcci\u00f3n.<\/p>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"aligncenter is-resized\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/www.pensemosweb.com\/wp-content\/uploads\/2019\/08\/RADModel.jpeg\" alt=\"\" class=\"wp-image-1093\" width=\"363\" height=\"232\"\/><figcaption>RAD ciclo de retroalimentaci\u00f3n<\/figcaption><\/figure><\/div>\n\n\n\n<h3 class=\"wp-block-heading\">Dynamic software development method (DSDM) &#8211; 80s<\/h3>\n\n\n\n<p>En el ciclo de retroalimentaci\u00f3n de esta metodolog\u00eda, incluye iteraciones en la factibilidad y fundaci\u00f3n, es decir, los requerimientos, adem\u00e1s de poder hacer iteraciones en las fases dise\u00f1o y construcci\u00f3n.<\/p>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"aligncenter is-resized\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/www.pensemosweb.com\/wp-content\/uploads\/2019\/07\/DSDM_Cycle.png\" alt=\"\" class=\"wp-image-1053\" width=\"560\" height=\"489\"\/><figcaption>DSDM ciclo de retroalimentaci\u00f3n<\/figcaption><\/figure><\/div>\n\n\n\n<h3 class=\"wp-block-heading\">Extreme Programing (XP) &#8211; Mediados de los 90s,  Kent Beck, Ward Cunningham, Ron Jeffries<\/h3>\n\n\n\n<p>Este es un mejor ciclo de retroalimentacion en comparacion con los anteriores, en todo momento se hacen iteraciones, en todos los niveles, adem\u00e1s:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>Mucho uso de TDD, continuamente durante todas las etapas<\/li><li>Pruebas de aceptaci\u00f3n y unitarias<\/li><li>Origen de los Dailys o stand up meetings<\/li><li>Tambi\u00e9n las famosas historias de usuario.<\/li><\/ul>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"aligncenter is-resized\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/www.pensemosweb.com\/wp-content\/uploads\/2019\/07\/xtremeProgrammingCycle-1024x940.png\" alt=\"\" class=\"wp-image-1047\" width=\"491\" height=\"451\"\/><figcaption>Extreme progamming ciclo de  retroalimentaci\u00f3n<\/figcaption><\/figure><\/div>\n\n\n\n<h3 class=\"wp-block-heading\">Scrum &#8211; A mediados de los 90s &#8211; Ken Schwaber, Jeff Sutherland<\/h3>\n\n\n\n<p>Bueno este es el m\u00e1s conocido de todos y el m\u00e1s usado actualmente, para mas detalles sobre este framework te dejo los siguentes enlaces:<\/p>\n\n\n\n<figure class=\"wp-block-embed-wordpress wp-block-embed is-type-wp-embed is-provider-pensemos-web\"><div class=\"wp-block-embed__wrapper\">\nhttps:\/\/www.pensemosweb.com\/scrum-importante-creacion-productos-servicios-valores-empirismo-pilares\/\n<\/div><\/figure>\n\n\n\n<p><a href=\"https:\/\/www.scrum.org\/\">https:\/\/www.scrum.org\/<\/a><\/p>\n\n\n\n<figure class=\"wp-block-image alignfull\"><img decoding=\"async\" src=\"https:\/\/www.pensemosweb.com\/wp-content\/uploads\/2019\/07\/scrum-cycle-1024x475.png\" alt=\"\" class=\"wp-image-1046\"\/><figcaption>Scrum ciclos de retroalimentaci\u00f3n<\/figcaption><\/figure>\n\n\n\n<p>Aunque estos frameworks ya hab\u00edan empezado con el desarrollo \u00e1gil, era necesario definir ciertos principios comunes para mejorar el entendimiento y la r\u00e1pida adopci\u00f3n de estas nuevas formas de crear software.<\/p>\n\n\n\n<p>En el 2001, 17 desarrolladores de software se reunieron en Snowbird, Utah para analizar sobre los m\u00e9todos de desarrollo de software \u00e1gil que estas 17 personas estaban utilizando, DSDM, Extreme Programming, Scrum y crystal clear. El resultado fue el Manifiesto \u00e1gil y los 12 principios \u00e1giles.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">\u00bfPor que es de suma importancia el manifiesto y los 12 principios \u00e1giles?<\/h2>\n\n\n\n<p>Es importante entender que m\u00e1s adelante podr\u00eda surgir un nuevo framework \u00e1gil con una mejor manera de hacer las cosas y que probablemente deber\u00edamos de adoptar, pero el manifiesto y los principios \u00e1giles seguir\u00e1n siendo la base primordial que si se comprende bien y se interiorizan, cualquier equipo u organizaci\u00f3n podra utilizar el framework o m\u00e9todo que m\u00e1s le convenga en determinadas circunstancias o proyectos.<\/p>\n\n\n\n<p>Es como la creaci\u00f3n de c\u00f3digo y piezas de un sistema computacional, no importa el lenguaje de programaci\u00f3n, librer\u00eda o frameworks de desarrollo, si no las bases de l\u00f3gica, patrones y principios de dise\u00f1o y arquitectura, los que har\u00e1n entender cualquier nuevo lenguaje o framework que pudiera salir en el futuro.<\/p>\n\n\n\n<p>Hablando un poco m\u00e1s sobre las pr\u00e1cticas utilizadas en los frameworks \u00e1giles, est\u00e1s pr\u00e1cticas est\u00e1n subordinadas por los principios, es decir, en un proyecto, se utilizar\u00e1n las pr\u00e1cticas m\u00e1s acordes a las circunstancias del problema que se quiere solucionar. Por la tanto es importante comprender el porque se ejecuta una pr\u00e1ctica, o sea, que practica me dar\u00e1 mejores resultados y agilidad bas\u00e1ndome en los principios y factores espec\u00edficos del problema.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"quesgil\">\u00bfQu\u00e9 es \u00e1gil?<\/h2>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\"><p>La capacidad de crear y responder al cambio con el fin de tener \u00e9xito en un ambiente incierto y turbulento<\/p><cite><a href=\"https:\/\/www.agilealliance.org\/\">agilealliance.org<\/a><\/cite><\/blockquote>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"manifiestogil\">Manifiesto \u00c1gil<\/h2>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\"><p>Estamos descubriendo mejores formas de desarrollar software haci\u00e9ndolo y ayudando a otras personas a hacerlo. A trav\u00e9s de este trabajo hemos llegado a valorar:<\/p><p><strong>Individuos e interacciones <\/strong>sobre procesos y herramientas.<\/p><p><strong>Software funcionando <\/strong>sobre documentaci\u00f3n exhaustiva.<\/p><p><strong>Colaboraci\u00f3n con el cliente <\/strong>sobre negociaci\u00f3n de contratos.<\/p><p><strong>Respuesta ante el cambio <\/strong>sobre seguir un plan<\/p><p>Es decir, aunque valoramos los elementos de la derecha, valoramos m\u00e1s los elementos de la izquierda.<\/p><\/blockquote>\n\n\n\n<p>En esta publicaci\u00f3n explico a detalle la raz\u00f3n y como aplicar el manifiesto \u00e1gil:<\/p>\n\n\n\n<figure class=\"wp-block-embed-wordpress wp-block-embed is-type-wp-embed is-provider-pensemos-web\"><div class=\"wp-block-embed__wrapper\">\nhttps:\/\/www.pensemosweb.com\/el-corazon-agil-manifiesto\/\n<\/div><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">12 Principios \u00e1giles<\/h2>\n\n\n\n<p>Aqu\u00ed est\u00e1n los <a href=\"https:\/\/agilemanifesto.org\/iso\/es\/principles.html\">12 principios \u00e1giles tomados de la fuente oficial<\/a>, en otra publicaci\u00f3n veremos a detalle cada uno de estos y como se aplica en un proyecto real.<\/p>\n\n\n\n<p>Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.<\/p>\n\n\n\n<p>Aceptamos que los requisitos cambien, incluso en etapas tard\u00edas del desarrollo. Los procesos \u00c1giles aprovechan el cambio para proporcionar ventaja competitiva al cliente.<\/p>\n\n\n\n<p>Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo m\u00e1s corto posible.<\/p>\n\n\n\n<p>Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.<\/p>\n\n\n\n<p>Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecuci\u00f3n del trabajo.&nbsp;<br \/><\/p>\n\n\n\n<p>El m\u00e9todo m\u00e1s eficiente y efectivo de comunicar informaci\u00f3n al equipo de desarrollo y entre sus miembros es la conversaci\u00f3n cara a cara.<\/p>\n\n\n\n<p>El software funcionando es la medida principal de progreso.<\/p>\n\n\n\n<p>Los procesos \u00c1giles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.<\/p>\n\n\n\n<p>La atenci\u00f3n continua a la excelencia t\u00e9cnica y al buen dise\u00f1o mejora la Agilidad.<\/p>\n\n\n\n<p>La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.<\/p>\n\n\n\n<p>Las mejores arquitecturas, requisitos y dise\u00f1os emergen de equipos auto-organizados.<\/p>\n\n\n\n<p>A intervalos regulares el equipo reflexiona sobre c\u00f3mo ser m\u00e1s efectivo para a continuaci\u00f3n ajustar y perfeccionar su comportamiento en consecuencia.<\/p>","protected":false},"excerpt":{"rendered":"<p>En cuanto a los m\u00e9todos, puede haber un mill\u00f3n y algo m\u00e1s, pero los principios son pocos. El hombre que capta los principios puede seleccionar con \u00e9xito sus propios m\u00e9todos. El hombre que prueba m\u00e9todos, ignorando principios, seguramente tendr\u00e1 problemas.<\/p>","protected":false},"author":2,"featured_media":3731,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"","_et_pb_old_content":"","_et_gb_content_width":"","footnotes":""},"categories":[21,29],"tags":[45,56],"class_list":["post-3559","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-agilidad","category-lean-startup","tag-desarrollo-agil","tag-lean-startup"],"_links":{"self":[{"href":"https:\/\/pensemosweb.com\/en\/wp-json\/wp\/v2\/posts\/3559","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/pensemosweb.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/pensemosweb.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/pensemosweb.com\/en\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/pensemosweb.com\/en\/wp-json\/wp\/v2\/comments?post=3559"}],"version-history":[{"count":1,"href":"https:\/\/pensemosweb.com\/en\/wp-json\/wp\/v2\/posts\/3559\/revisions"}],"predecessor-version":[{"id":3596,"href":"https:\/\/pensemosweb.com\/en\/wp-json\/wp\/v2\/posts\/3559\/revisions\/3596"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/pensemosweb.com\/en\/wp-json\/wp\/v2\/media\/3731"}],"wp:attachment":[{"href":"https:\/\/pensemosweb.com\/en\/wp-json\/wp\/v2\/media?parent=3559"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/pensemosweb.com\/en\/wp-json\/wp\/v2\/categories?post=3559"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/pensemosweb.com\/en\/wp-json\/wp\/v2\/tags?post=3559"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}