{"id":57,"date":"2020-02-24T23:25:46","date_gmt":"2020-02-24T22:25:46","guid":{"rendered":"https:\/\/www.julianmejio.com\/blog\/?p=57"},"modified":"2020-09-11T16:40:14","modified_gmt":"2020-09-11T15:40:14","slug":"devops-facil-paradigmas-agiles-3","status":"publish","type":"post","link":"https:\/\/www.julianmejio.com\/blog\/2020\/02\/24\/devops-facil-paradigmas-agiles-3\/","title":{"rendered":"DevOps f\u00e1cil, parte 3: El paradigma \u00e1gil"},"content":{"rendered":"\n

Ya hemos visto modelos de desarrollo tradicionales como el desarrollo en cascada<\/a> y el desarrollo en espiral<\/a>. Ahora veremos en qu\u00e9 consiste el modelo de desarrollo \u00e1gil.<\/p>\n\n\n\n

Antes de continuar debo aclarar que este paradigma comprende numerosas metodolog\u00edas y t\u00e9cnicas. Para no desviarme del objetivo de esta serie \u2013presentar DevOps<\/em> como t\u00e9cnicas de f\u00e1cil integraci\u00f3n en los flujos de trabajo\u2013 solamente voy a hablar de un par de puntos muy espec\u00edficos y vagos sobre este paradigma.<\/p>\n\n\n\n\n\n\n\n

Este paradigma se encuentra al lado opuesto de los modelos tradicionales. Redefine el dise\u00f1o de la soluci\u00f3n, la documentaci\u00f3n y la planeaci\u00f3n de tal modo que no se base en decenas de documentos archivos en un repositorio, p\u00e1ginas y p\u00e1ginas de tecnicismos anticuados y dif\u00edciles de mantener, y siendo lo m\u00e1s flexible que se pueda para poder moldearse a las necesidades en el mundo real.<\/p>\n\n\n\n

Este paradigma cuenta con m\u00faltiples metodolog\u00edas, tales como Scrum<\/em>, Kanban<\/em> y XP<\/em>. Tambi\u00e9n cuenta con m\u00faltiples pr\u00e1cticas, como TDD, CI\/CD, programaci\u00f3n por pares, Backlogging<\/em>, entre otros. Cada una de estas pr\u00e1cticas y metodolog\u00edas tiene sus caracter\u00edsticas y de acuerdo con las necesidad del equipo de trabajo y de la soluci\u00f3n se puede optar por una u otra.<\/p>\n\n\n\n

El paradigma de desarrollo \u00e1gil tiene doce principios, y de ah\u00ed deriva el Agile Manifesto<\/a><\/em>. Es toda una filosof\u00eda y ha tra\u00eddo muchas ventajas a los equipos de desarrollo. Entre las ventajas m\u00e1s especiales que hay se pueden describir la importancia de la comunicaci\u00f3n entre todos los actores \u2013consumidores y desarrolladores\u2013, y ciclos de desarrollo cortos.<\/p>\n\n\n\n

\u00bfCu\u00e1l es la relaci\u00f3n entre una buena comunicaci\u00f3n, ciclos de desarrollo cortos y DevOps<\/em>? si has seguido la serie ya sabr\u00e1s que el principal impedimento de una integraci\u00f3n DevOps<\/em> en modelos de desarrollo como cascada y espiral son los ciclos de desarrollo poco flexibles y a menudo lentos debido a los congelamientos a los cuales est\u00e1n expuestas las listas de caracter\u00edsticas. El paradigma \u00e1gil al tener un ciclo de vida corto se convierte en un complemento natural para DevOps<\/em>. Ambos se fusionan intuitivamente y permiten que el flujo de trabajo sea casi como el mecanismo de un reloj.<\/p>\n\n\n\n

\u00bfC\u00f3mo se complementan tan bien? En principio, el paradigma \u00e1gil est\u00e1 pensado para automatizar tareas que se repiten en todos los ciclos de desarrollo tales como las pruebas, que pueden ser unitarias, funcionales, de integraci\u00f3n, de aceptaci\u00f3n, entre otras. Recordemos que este paradigma se preocupa por una comunicaci\u00f3n robusta, y esto quiere decir que la comunicaci\u00f3n debe estar presente en todos los actores, y nunca debe estar fragmentada: el usuario final debe poder comunicarse con el equipo de soporte y desarrollo, y el equipo de soporte y desarrollo debe poder comunicarse con el equipo de infraestructura y operaciones. Mientras que el paradigma \u00e1gil ofrece pr\u00e1cticas que permiten la comunicaci\u00f3n entre el usuario final y el equipo de desarrollo, DevOps<\/em> ofrece un canal de comunicaci\u00f3n entre el equipo de desarrollo y el equipo de infraestructura y operaciones. Y para cerrar con broche de oro, DevOps<\/em> se preocupa del producto final y su mantenimiento.<\/p>\n\n\n\n

La retroalimentaci\u00f3n de los usuarios finales genera las nuevas tareas por hacer. El paradigma \u00e1gil dicta que las tareas son organizadas en el backlog<\/em>, y este a su vez en sprints y versiones. El equipo de desarrollo se encarga de implementar y trabajar en las nuevas caracter\u00edsticas, y las va enviando al repositorio del proyecto a medida que se van desarrollando. En este punto, el paradigma da paso a DevOps<\/em>, en donde este contin\u00faa con el proceso: el c\u00f3digo enviado al repositorio es probado y evaluado para determinar su calidad y que no vaya a da\u00f1ar ning\u00fan otro componente. Las pruebas son autom\u00e1ticas y la retroalimentaci\u00f3n es inmediata tanto para el equipo de desarrollo como para el equipo de infraestructura. Dependiendo de la estructura del repositorio, si el c\u00f3digo liberado es final, el repositorio lo libera al p\u00fablico general y luego es monitorizado, adem\u00e1s de ofrecer v\u00edas para que el usuario final entregue de nuevo su retroalimentaci\u00f3n, la cual alimenta el backlog de los desarrolladores y contin\u00faa as\u00ed con otro nuevo ciclo.<\/p>\n\n\n\n

Una buena integraci\u00f3n del paradigma \u00e1gil y DevOps<\/em> comprende al menos seis puntos:<\/p>\n\n\n\n

  1. Desarrollo y planeaci\u00f3n usando alguna metodolog\u00eda como XP, Kanban<\/em> o Scrum<\/em>.<\/li>
  2. Organizaci\u00f3n del trabajo usando alguna pr\u00e1ctica como backlogs, TDD, o propias de la metodolog\u00edas como los pools<\/em> de Kanban<\/em> o los sprints<\/em> de Scrum<\/em>.<\/li>
  3. Retroalimentaci\u00f3n del trabajo, generalmente usando t\u00e9cnicas de retrospectiva.<\/li>
  4. Integraci\u00f3n continua.<\/li>
  5. Pruebas continuas.<\/li>
  6. Entregas continuas.<\/li><\/ol>\n\n\n\n

    Los tres primeros puntos corresponden a la implementaci\u00f3n del modelo de desarrollo. Estos puntos no son parte de esta serie, por lo que solo tratar\u00e9 lo necesario.<\/p>\n\n\n\n

    Los \u00faltimos tres puntos es el tema de inter\u00e9s de esta serie, y en las pr\u00f3ximas entregas hablar\u00e9 no solo de ellas, sino tambi\u00e9n nos encargaremos de montar un entorno automatizado \u2013y real\u2013 donde usemos las caracter\u00edsticas b\u00e1sicas de DevOps<\/em>.<\/p>\n\n\n\n

    CONTINUAR\u00c1\u2026<\/h6>\n\n\n\n

    En la pr\u00f3xima entrega montaremos un entorno apto para integraci\u00f3n y automatizaci\u00f3n desde cero, usando Debian, Gitlab y Docker.<\/p>\n\n\n\n

    <\/p>\n","protected":false},"excerpt":{"rendered":"

    Ya hemos visto modelos de desarrollo tradicionales como el desarrollo en cascada y el desarrollo en espiral. Ahora veremos en qu\u00e9 consiste el modelo de desarrollo \u00e1gil. Antes de continuar debo aclarar que este paradigma comprende numerosas metodolog\u00edas y t\u00e9cnicas. Para no desviarme del objetivo de esta serie \u2013presentar DevOps como t\u00e9cnicas de f\u00e1cil integraci\u00f3n […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"He escrito un nuevo art\u00edculo. DevOps f\u00e1cil, parte 3: El paradigma \u00e1gil","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[9],"tags":[17,10,19,18],"class_list":["post-57","post","type-post","status-publish","format-standard","hentry","category-devops","tag-agil","tag-devops","tag-kanban","tag-scrum"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/www.julianmejio.com\/blog\/wp-json\/wp\/v2\/posts\/57","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.julianmejio.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.julianmejio.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.julianmejio.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.julianmejio.com\/blog\/wp-json\/wp\/v2\/comments?post=57"}],"version-history":[{"count":3,"href":"https:\/\/www.julianmejio.com\/blog\/wp-json\/wp\/v2\/posts\/57\/revisions"}],"predecessor-version":[{"id":148,"href":"https:\/\/www.julianmejio.com\/blog\/wp-json\/wp\/v2\/posts\/57\/revisions\/148"}],"wp:attachment":[{"href":"https:\/\/www.julianmejio.com\/blog\/wp-json\/wp\/v2\/media?parent=57"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.julianmejio.com\/blog\/wp-json\/wp\/v2\/categories?post=57"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.julianmejio.com\/blog\/wp-json\/wp\/v2\/tags?post=57"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}