{"id":48,"date":"2020-02-18T15:27:59","date_gmt":"2020-02-18T14:27:59","guid":{"rendered":"https:\/\/www.julianmejio.com\/blog\/?p=48"},"modified":"2020-09-11T16:41:07","modified_gmt":"2020-09-11T15:41:07","slug":"devops-facil-desarrollo-en-espiral-2","status":"publish","type":"post","link":"https:\/\/www.julianmejio.com\/blog\/2020\/02\/18\/devops-facil-desarrollo-en-espiral-2\/","title":{"rendered":"DevOps f\u00e1cil, parte 2: Desarrollo en espiral"},"content":{"rendered":"\n

En la introducci\u00f3n<\/a> habl\u00e9 sobre los aspectos generales del desarrollo en cascada y c\u00f3mo podr\u00eda integrarse DevOps<\/em> en su ciclo de desarrollo de software. Sin embargo hay un punto importante a tener en consideraci\u00f3n:<\/p>\n\n\n\n

El desarrollo en cascada tiene tres etapas de dise\u00f1o: levantamiento de requisitos, an\u00e1lisis y dise\u00f1o. DevOps<\/em> no puede integrarse a estas etapas y por lo tanto solo la mitad del modelo es aplicable. No es \u00f3ptimo, los ciclos de desarrollo siguen siendo largos y los artefactos numerosos. Dado que la premisa principal de DevOps<\/em> es acortar los ciclos de desarrollo por medio de la automatizaci\u00f3n y el monitoreo, resulta dif\u00edcil llamar DevOps<\/em> cuando se implementa este modelo. Por definici\u00f3n hay tres capas incompatibles, y solo las otras tres son monitoreables y automatizables.<\/p>\n\n\n\n\n\n\n\n

Al final ser\u00eda solo una modificaci\u00f3n m\u00e1s del desarrollo en cascada, en donde se a\u00f1adir\u00eda un etapa transversal entre la etapa de codificaci\u00f3n y la etapa de integraci\u00f3n y operaciones.<\/p>\n\n\n\n

Desarrollo en espiral<\/h6>\n\n\n\n

Hay un modelo m\u00e1s que vale la pena mencionar antes de llegar a la guinda del pastel: el desarrollo en espiral.<\/p>\n\n\n\n

El principal objetivo de este modelo es reducir las situaciones y eventos que pueden hacer que el proyecto falle y no alcance sus objetivos. Esto es muy importante, tanto as\u00ed que muchos modelos de mejora como CMMI dan una importancia relevante a la gesti\u00f3n de riesgos, y muchas empresas se preocupan por implementar normas como la ISO 31000 en sus flujos de trabajo.<\/p>\n\n\n\n

El desarrollo en espiral pretende que la definici\u00f3n y las implementaciones de un sistema crezcan, mientras los riesgos disminuyen. Es una premisa muy ambiciosa y para que funcione realmente las personas deben estar completamente alineadas con el modelo. En el siguiente diagrama vemos la representaci\u00f3n de este modelo:<\/p>\n\n\n\n

\"\"
Diagrama original del modelo de desarrollo en espiral. Bohem, 1988.<\/figcaption><\/figure>\n\n\n\n

Los elementos en color naranja se comparten con el modelo en cascada. Todos los dem\u00e1s son nuevos o tienen un papel expl\u00edcito en el ciclo de desarrollo. Aqu\u00ed se puede apreciar tareas repetitivas, que est\u00e1n presentes en cada ciclo: el an\u00e1lisis de riesgos, prototipado y evaluaciones. Estos tres elementos garantizan el objetivo: disminuir riesgos y crecer el sistema. Las tareas nuevas dan peso a la retroalimentaci\u00f3n y validaci\u00f3n, el \u00e1mbito del que carec\u00eda el desarrollo en cascada.<\/p>\n\n\n\n

Ahora bien, existe la idea de que este modelo es solo un conjunto de desarrollos en cascada modificados y en secuencia, sin embargo esto no es cierto: cada etapa del desarrollo en espiral incrementa la madurez del proyecto y reduce el cono de incertidumbre. Aunque hay una l\u00ednea de evoluci\u00f3n expl\u00edcita, las tareas pueden repetirse si es necesario, y no necesariamente hay que seguir el orden estricto. Esta flexibilidad es posible gracias a las divisiones de etapas, las cuales definen el inicio del hito y el punto de llegada en cada etapa, donde las partes interesadas eval\u00faan y acuerdan su satisfacci\u00f3n en el progreso hecho y acumulado del sistema. Una vez pasado ese punto todo lo que se hizo atr\u00e1s est\u00e1 \u00abbien hecho\u00bb, y se puede seguir con la siguiente lista de tareas.<\/p>\n\n\n\n

DevOps se convierte en una herramienta transversal en este modelo pero no est\u00e1 presente en todas las etapas, al menos no de manera directa. La automatizaci\u00f3n caracter\u00edstica de esta t\u00e9cnica puede validar gran parte de todo un ciclo al final con los prototipos \u2013que tecnicamente es el producto de una planeaci\u00f3n y verificaci\u00f3n en las primeras etapas de cada ciclo\u2013, sin embargo dicho monitoreo no es constante (solo est\u00e1 presente en los prototipos y en la implementaci\u00f3n). Su retroalimentaci\u00f3n puede llegar muy tarde, ya que para que haya un prototipo que se pueda evaluar el equipo tuvo que haber pasado por el dise\u00f1o, planeaci\u00f3n, an\u00e1lisis de riesgos y dem\u00e1s. Luego de plasmado es m\u00e1s f\u00e1cil dejarlo pasar que devolverse todo un hito para replantear de nuevo el dise\u00f1o, sin mencionar que puede llegar a ser muy costoso.<\/p>\n\n\n\n

\u00bfRecuerda que este modelo no es un conjunto de desarrollos en cascada? Esto tiene que ver mucho, y es que el ciclo completo de desarrollo de software no es cuando se lanza un prototipo, sino cuando finaliza con la implementaci\u00f3n. Ubique en este momento la tarea de implementaci\u00f3n en el diagrama, \u00bfd\u00f3nde est\u00e1? S\u00ed, al final de toda la espiral, por lo que todo el ciclo de desarrollo lleva 15 etapas y todas las tareas que esto conlleva. \u00bfEsto es crucial para DevOps? Por supuesto, y para darme a entender voy a explicar un concepto usado en proyecto de software a menudo grandes: el congelamiento.<\/p>\n\n\n\n

El objetivo del congelamiento es restringir la adici\u00f3n de artefactos en el proceso de desarrollo luego de determinado punto. Despu\u00e9s de que todo un equipo ha dise\u00f1ado, planeado, estimado tiempos y generado decenas de artefactos, a\u00f1adir un nuevo requisito que por lo general est\u00e1n en las etapas iniciales tendr\u00eda much\u00edsimo impacto en las tareas subsecuentes, y obligar\u00eda al equipo a devolverse al principio para replantear sus dise\u00f1os, planeaci\u00f3n y estimaciones teniendo en cuenta el nuevo requisito que lleg\u00f3 a \u00ab\u00faltima hora\u00bb. Por eso los equipos, luego de determinado punto invocan un congelamiento, lo cual obliga a que nuevos requisitos o caracter\u00edsticas sean tenidos en cuenta en el siguiente ciclo de desarrollo. De esta manera el proyecto podr\u00e1 seguir su curso normal, mientras que se puede planear a futuro una pr\u00f3xima liberaci\u00f3n.<\/p>\n\n\n\n

Hay diferentes tipos de congelamiento: congelamiento por votaci\u00f3n, en donde el equipo vota si la nueva caracter\u00edstica tiene un impacto alto o bajo \u2013y pueden usar otras m\u00e9tricas\u2013 y si ven que el impacto en sus dise\u00f1os ya hechos es bajo o muy bajo lo pueden tener en consideraci\u00f3n. Est\u00e1 el congelamiento suave, el cual deja pasar las caracter\u00edsticas que cumplan con alguna condici\u00f3n especial, como tener prioridad muy alta o que haya un cambio en la l\u00f3gica de negocio. Y est\u00e1 el congelamiento duro. Este congelamiento no acepta ning\u00fan tipo de cambio y por lo general se encuentra en las \u00faltimas etapas de desarrollo, justo antes de empezar con la etapa de codificaci\u00f3n.<\/p>\n\n\n\n

Recordemos que DevOps<\/em> busca acortar los ciclos de desarrollo para hacer las liberaciones m\u00e1s frecuentes, e implementar congelamientos en ciclos de desarrollo con muchas etapas y tareas implica alargar el mismo desarrollo y tener que esperar m\u00e1s tiempo para la liberaci\u00f3n de las nuevas caracter\u00edsticas, lo que lleva a pensar que este tampoco es un modelo \u00f3ptimo para implementar esta pr\u00e1ctica.<\/p>\n\n\n\n

Hasta ahora hemos visto dos modelos: cascada y espiral. Ambos son r\u00edgidos y alienantes. Tratan de llevar el azar al m\u00ednimo y su orquestaci\u00f3n es casi perfecta, como los compases de m\u00fasica, as\u00ed son cada una de las etapas de ambos modelos.<\/p>\n\n\n\n

Debo recordar una vez m\u00e1s que la eficiencia de un modelo depende del tipo de proyecto y equipo de trabajo. Por eso ning\u00fan modelo es anticuado, sino al contrario, nos abre la posibilidad de organizarnos de distintas formas, seg\u00fan cual nos convenga m\u00e1s.<\/p>\n\n\n\n

Ahora, hay un modelo m\u00e1s, la cual est\u00e1 siempre agarrado de la mano con DevOps<\/em> y dificilmente se pueden concebir de manera separada. Esta, o mejor dicho, estos modelos son los bien conocidos como \u00ab\u00e1giles\u00bb, pero de estos hablar\u00e9 en la pr\u00f3xima entrega.<\/p>\n\n\n\n

Continuar\u00e1\u2026<\/h6>\n\n\n\n

En la pr\u00f3xima entrega hablar\u00e9 sobre los modelos \u00e1giles, sus caracter\u00edsticas y mostrar\u00e9 por qu\u00e9 su integraci\u00f3n con DevOps<\/em> es eficiente e intuitiva, y la codependencia entre ambos.<\/p>\n\n\n\n

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

En la introducci\u00f3n habl\u00e9 sobre los aspectos generales del desarrollo en cascada y c\u00f3mo podr\u00eda integrarse DevOps en su ciclo de desarrollo de software. Sin embargo hay un punto importante a tener en consideraci\u00f3n: El desarrollo en cascada tiene tres etapas de dise\u00f1o: levantamiento de requisitos, an\u00e1lisis y dise\u00f1o. DevOps no puede integrarse a estas […]<\/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 publicado un nuevo art\u00edculo. DevOps f\u00e1cil, parte 2: Desarrollo en espiral","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":[16,10],"class_list":["post-48","post","type-post","status-publish","format-standard","hentry","category-devops","tag-desarrollo-espiral","tag-devops"],"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\/48","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=48"}],"version-history":[{"count":3,"href":"https:\/\/www.julianmejio.com\/blog\/wp-json\/wp\/v2\/posts\/48\/revisions"}],"predecessor-version":[{"id":149,"href":"https:\/\/www.julianmejio.com\/blog\/wp-json\/wp\/v2\/posts\/48\/revisions\/149"}],"wp:attachment":[{"href":"https:\/\/www.julianmejio.com\/blog\/wp-json\/wp\/v2\/media?parent=48"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.julianmejio.com\/blog\/wp-json\/wp\/v2\/categories?post=48"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.julianmejio.com\/blog\/wp-json\/wp\/v2\/tags?post=48"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}