{"id":416,"date":"2020-07-08T22:02:46","date_gmt":"2020-07-08T22:02:46","guid":{"rendered":"https:\/\/arsum.cl\/?page_id=416"},"modified":"2020-07-08T23:20:45","modified_gmt":"2020-07-08T23:20:45","slug":"documentacion-en-entornos-agiles","status":"publish","type":"page","link":"https:\/\/arsum.cl\/?page_id=416","title":{"rendered":"Y\u2026 \u00bfqu\u00e9 hay de la documentaci\u00f3n en entornos \u00e1giles?"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t
\n\t\t\t\t

Seguramente has o\u00eddo el mito que \u201cen entornos \u00e1giles no se documenta\u201d.
Aqu\u00ed tienes un art\u00edculo donde te orientamos al respecto.<\/b><\/p>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t
\n\t\t\t\t

\u00c1gil <\/i>se refiere a un enfoque para el desarrollo de software que enfatiza el desarrollo r\u00e1pido y flexible y la infraestructura de proyectos y procesos por su propio bien. La siguiente declaraci\u00f3n muestra el \u00abmanifiesto\u00bb para el desarrollo de software \u00e1gil que ha servido desde 2001 como Desiderata <\/i>del movimiento:<\/p>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t
\n\t\t\t\t

Individuos e interacciones<\/b> sobre procesos y herramientas<\/i><\/p>\n

Software funcionando<\/b> sobre documentaci\u00f3n extensiva<\/i><\/p>\n

Colaboraci\u00f3n con el cliente<\/b> sobre negociaci\u00f3n contractual<\/i><\/p>\n

Respuesta ante el cambio<\/b> sobre seguir un plan<\/i><\/p>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t

Hay una variedad de metodolog\u00edas \u00e1giles<\/h2>\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t
\n\t\t\t\t

Hay muchas instancias metodol\u00f3gicas diferentes del enfoque \u00e1gil. Estos incluyen Programaci\u00f3n Extrema, Scrum, Desarrollo Basado en Funciones y Crystal Clear. Las pr\u00e1cticas que aparecen en uno o m\u00e1s de los m\u00e9todos \u00e1giles incluyen lo siguiente:<\/p>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t
\n\t\t\t\t
    \n
  • Historias del usuario<\/b>. El texto especifica requisitos funcionales que describen las acciones de las personas.<\/li>\n
  • Desarrollo basado en pruebas<\/b>. Los desarrolladores crean pruebas automatizadas al mismo tiempo que escriben el c\u00f3digo probado.<\/li>\n
  • Iteracciones cortas<\/b>. El plan de desarrollo consiste en breves iteraciones (unas pocas semanas); Tambi\u00e9n se llama sprints.<\/li>\n
  • Programaci\u00f3n en pareja<\/b>. Los desarrolladores trabajan en parejas, donde uno est\u00e1 tipificando el c\u00f3digo y el otro revisa el c\u00f3digo buscando defectos y formas de mejorar el dise\u00f1o.<\/li>\n
  • Refactorizaci\u00f3n<\/b>. Como parte del ciclo de implementaci\u00f3n, el c\u00f3digo se refactoriza para mejorar la estructura interna y la capacidad de mantenimiento sin alterar el comportamiento visible desde el exterior.<\/li>\n<\/ul>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
    \n\t\t\t\t\t\t
    \n\t\t\t\t\t\t\t
    \n\t\t\t\t\t
    \n\t\t\t
    \n\t\t\t\t\t\t\t
    \n\t\t\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t

    Mitos y Conceptos Err\u00f3neos<\/h2>\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t
    \n\t\t\t\t

    Para algunos, la agilidad se usa como una excusa para evitar el desarrollo disciplinado. La figura siguiente representa esta visi\u00f3n temprana del mundo \u00e1gil:<\/p>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
    \n\t\t\t\t\t\t
    \n\t\t\t\t\t\t\t
    \n\t\t\t\t\t
    \n\t\t\t
    \n\t\t\t\t\t\t\t
    \n\t\t\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t
    \n\t\t\t\t

    Una idea err\u00f3nea relacionada con el agilismo es que la codificaci\u00f3n comienza el primer d\u00eda del proyecto. En la pr\u00e1ctica, la primera iteraci\u00f3n puede pasar sin ning\u00fan c\u00f3digo de producci\u00f3n escrito. Esto sucede porque el equipo est\u00e1 ordenando alternativas de dise\u00f1o y realizando experimentos t\u00e9cnicos con diferentes marcos, plataformas o tecnolog\u00edas.<\/p>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

    \n\t\t\t\t\t\t
    \n\t\t\t\t\t\t\t
    \n\t\t\t\t\t
    \n\t\t\t
    \n\t\t\t\t\t\t\t
    \n\t\t\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t
    \n\t\t\t\t

    El objetivo clave del dise\u00f1o y modelado en proyectos \u00e1giles no es evitar el dise\u00f1o, sino evitar el \u00abgran dise\u00f1o por adelantado\u00bb. Las estrategias de arquitectura amplias y de largo alcance se elaboran por adelantado, pero muchas otras decisiones de dise\u00f1o se pueden diferir hasta que se necesiten.\u00a0<\/span><\/p>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t

    \n\t\t\t
    \n\t\t\t\t\t\t\t
    \n\t\t\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t
    \n\t\t\t\t
    <\/b>

    \u00abUna idea err\u00f3nea relacionada con el agilismo es que la codificaci\u00f3n comienza el primer d\u00eda del proyecto.\u00bb<\/b><\/span><\/p><\/blockquote>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

    \n\t\t\t\t\t\t
    \n\t\t\t\t\t\t\t
    \n\t\t\t\t\t
    \n\t\t\t
    \n\t\t\t\t\t\t\t
    \n\t\t\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t

    Principios de documentaci\u00f3n<\/h2>\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t\t\t
    \n\t\t\t\t\t\t\t
    \n\t\t\t\t\t
    \n\t\t\t
    \n\t\t\t\t\t\t\t
    \n\t\t\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t
    \n\t\t\t\t

    Las filosof\u00edas Views and Beyond y \u00c1gil coinciden firmemente en un punto central:\u00a0si no se necesita informaci\u00f3n, no la documente<\/span>. Toda la documentaci\u00f3n debe tener en mente el <\/span>uso previsto y la audiencia<\/b>, y debe producirse de manera que sirva a ambos.\u00a0 Uno de los principios fundamentales de la documentaci\u00f3n t\u00e9cnica es \u00abescribir para el lector\u00bb. Eso significa comprender qui\u00e9n leer\u00e1 la documentaci\u00f3n y c\u00f3mo la usar\u00e1n. Si no hay audiencia, no hay necesidad de producir la documentaci\u00f3n.<\/p>

    La selecci\u00f3n de vista de arquitectura es un ejemplo de aplicaci\u00f3n de este principio. El enfoque <\/span>Views and Beyond<\/i> prescribe la producci\u00f3n de una vista si y solo si aborda las preocupaciones de una comunidad de partes interesadas expl\u00edcitamente identificada.<\/p>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t

    \n\t\t\t
    \n\t\t\t\t\t\t\t
    \n\t\t\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t
    \n\t\t\t\t


    \n<\/b><\/p>\n

    \u00abSi no se necesita informaci\u00f3n,
    <\/i>no la documente.\u00bb<\/i><\/b><\/p>


    <\/i><\/b><\/p>\n<\/blockquote>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t
    \n\t\t\t\t

    Otra idea central para recordar es que la documentaci\u00f3n no es una actividad monol\u00edtica que detiene todos los dem\u00e1s avances hasta que se completa, sino la producci\u00f3n de la documentaci\u00f3n se prescribe en etapas priorizadas para satisfacer las necesidades de las partes interesadas que la necesitan en un determinado momento, el truco es saber qui\u00e9nes son los receptores y qu\u00e9 movimientos necesitan hacer.<\/span><\/p>

    Con esto en mente, el siguiente es el enfoque sugerido para producir documentaci\u00f3n de arquitectura basada en Views and Beyond utilizando principios \u00e1giles:<\/span><\/p>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

    \n\t\t\t\t\t\t
    \n\t\t\t\t\t\t\t
    \n\t\t\t\t\t
    \n\t\t\t
    \n\t\t\t\t\t\t\t
    \n\t\t\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t
    \n\t\t\t\t
    1. Adopte una plantilla u organizaci\u00f3n est\u00e1ndar para capturar sus decisiones de dise\u00f1o.<\/li>
    2. Planifique documentar una vista si y solo si tiene un electorado de partes interesadas fuertemente identificado.<\/li>
    3. Complete las secciones de la plantilla para obtener una vista de arquitectura cuando la informaci\u00f3n est\u00e9 disponible. Pero solo haga esto si escribir esta informaci\u00f3n har\u00e1 que sea m\u00e1s f\u00e1cil (o m\u00e1s barato o que el \u00e9xito sea m\u00e1s probable) para alguien que est\u00e1 haciendo su trabajo.<\/li><\/ol>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
      \n\t\t\t\t\t\t
      \n\t\t\t\t\t\t\t
      \n\t\t\t\t\t
      \n\t\t\t
      \n\t\t\t\t\t\t\t
      \n\t\t\t\t\t\t
      \n\t\t\t\t
      \n\t\t\t\t\t\t\t\t
      \n\t\t\t\t

      M\u00e1s all\u00e1 de esta orientaci\u00f3n estrat\u00e9gica, tambi\u00e9n puede usar los siguientes consejos:<\/p>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

      \n\t\t\t\t\t\t
      \n\t\t\t\t\t\t\t
      \n\t\t\t\t\t
      \n\t\t\t
      \n\t\t\t\t\t\t\t
      \n\t\t\t\t\t\t
      \n\t\t\t\t
      \n\t\t\t\t\t\t\t\t
      \n\t\t\t\t
        \n
      • Deje de dise\u00f1ar tan pronto como sienta que est\u00e1 listo para comenzar a codificar<\/b>. No se preocupe por crear un documento de dise\u00f1o arquitect\u00f3nico y luego un documento de dise\u00f1o m\u00e1s detallado. Produzca suficiente informaci\u00f3n de dise\u00f1o que le permita pasar al c\u00f3digo. Capture la informaci\u00f3n de dise\u00f1o en un formato que sea simple de usar y f\u00e1cil de cambiar, una wiki, tal vez. En el pr\u00f3ximo sprint<\/i>, puede expandir el dise\u00f1o existente seg\u00fan sea necesario para capturar las decisiones de dise\u00f1o necesarias para implementar las caracter\u00edsticas enumeradas para ese sprint<\/i>.<\/li>\n
      • No se sienta obligado a llenar todas las secciones de la plantilla, y ciertamente no todas a la vez<\/b>. Todav\u00eda le sugerimos que defina y use plantillas ricas porque pueden ser \u00fatiles en algunas situaciones. Pero siempre puede escribir \u00abN\/A\u00bb para las secciones para las que no necesita registrar la informaci\u00f3n. En los equipos \u00e1giles, el modelado a veces ocurre como breves discusiones en la pizarra. M\u00e1s informaci\u00f3n sobre los elementos (cat\u00e1logo de elementos), discusi\u00f3n de fundamentos (antecedentes de la arquitectura), mecanismos de variabilidad utilizados (gu\u00eda de variabilidad) y todo lo dem\u00e1s se comunicar\u00e1 verbalmente al equipo, al menos por ahora. M\u00e1s adelante, si descubre que es \u00fatil registrar una pieza de informaci\u00f3n sobre un elemento, un diagrama de contexto, la justificaci\u00f3n de una determinada decisi\u00f3n de dise\u00f1o u otra cosa, puede reemplazar el \u00abN\/A\u00bb con la informaci\u00f3n correspondiente.<\/li>\n
      • Si no vale la pena actualizar el dise\u00f1o, des\u00e9chelo<\/b>. Como ejemplo, suponga que cre\u00f3 un diagrama de secuencia que se convirti\u00f3 en parte de la documentaci\u00f3n de la arquitectura. En la implementaci\u00f3n, se comenz\u00f3 siguiendo lo que est\u00e1 en el diagrama de secuencia. Sin embargo, encontr\u00f3 mejores formas de implementar esa transacci\u00f3n y el resultado final result\u00f3 ser bastante diferente del diagrama de secuencia. El diagrama original cumpli\u00f3 su objetivo principal al guiar la implementaci\u00f3n inicial. \u00bfQu\u00e9 debe hacer con el diagrama ahora? Usted puede:<\/li>\n<\/ul>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
        \n\t\t\t\t\t\t
        \n\t\t\t\t\t\t\t
        \n\t\t\t\t\t
        \n\t\t\t
        \n\t\t\t\t\t\t\t
        \n\t\t\t\t\t\t
        \n\t\t\t\t
        \n\t\t\t\t\t\t\t\t
        \n\t\t\t\t
          • Dejarlo como est\u00e1<\/b>. Esta es la peor opci\u00f3n, porque ahora la documentaci\u00f3n estar\u00e1 en desacuerdo con la implementaci\u00f3n. Nada hace que un lector huya de la documentaci\u00f3n m\u00e1s r\u00e1pido que el descubrimiento de que est\u00e1 desactualizado, y ahora el lector tampoco confiar\u00e1 en ninguna otra parte de la documentaci\u00f3n de la arquitectura.<\/li>
          • Actualizar el diagrama<\/b>. Esta es la opci\u00f3n ideal, el diagrama actualizado ayudar\u00e1 a los mantenedores que necesitar\u00e1n comprender esa parte de la implementaci\u00f3n.<\/li>
          • Eliminar o tachar el diagrama<\/b>. Esta opci\u00f3n es la opci\u00f3n realista en muchos proyectos. El diagrama est\u00e1 desactualizado; es mejor que lo quite o lo marque como obsoleto o que ya no tenga autoridad para que no enga\u00f1e a los lectores de la documentaci\u00f3n. En los proyectos \u00e1giles, el c\u00f3digo, los comentarios de c\u00f3digo y las pruebas unitarias asociadas a menudo sirven como documentaci\u00f3n autorizada para dise\u00f1os locales (espec\u00edficos de elementos).<\/li><\/ul><\/li><\/ul>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
            \n\t\t\t\t\t\t
            \n\t\t\t\t\t\t\t
            \n\t\t\t\t\t
            \n\t\t\t
            \n\t\t\t\t\t\t\t
            \n\t\t\t\t\t\t
            \n\t\t\t\t
            \n\t\t\t\t\t\t\t\t
            \n\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
            \n\t\t\t\t\t\t
            \n\t\t\t\t\t\t\t
            \n\t\t\t\t\t
            \n\t\t\t
            \n\t\t\t\t\t\t\t
            \n\t\t\t\t\t\t
            \n\t\t\t\t
            \n\t\t\t\t\t\t\t\t
            \n\t\t\t\t
              \n
            • Muchas veces, los bocetos son todo lo que necesitas<\/b>. No pierdas el tiempo creando el diagrama m\u00e1s ordenado utilizando la \u00faltima y m\u00e1s rica notaci\u00f3n disponible. No gaste dinero en herramientas de modelado sofisticadas si solo necesita dibujar diagramas simples. En muchos proyectos \u00e1giles, especialmente en aquellos con equipos peque\u00f1os y colocados, el verdadero valor de los diagramas de dise\u00f1o proviene de dibujarlos, lo que lo obliga a pensar en los problemas; Una vez que se resuelven los problemas, la documentaci\u00f3n se puede refinar. Muchas veces el dise\u00f1o se representa como un boceto en una pizarra blanca o en una hoja de papel como en el siguiente ejemplo:<\/li>\n<\/ul>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
              \n\t\t\t\t\t\t
              \n\t\t\t\t\t\t\t
              \n\t\t\t\t\t
              \n\t\t\t
              \n\t\t\t\t\t\t\t
              \n\t\t\t\t\t\t
              \n\t\t\t\t
              \n\t\t\t\t\t\t\t\t
              \n\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":"

              Seguramente has o\u00eddo el mito que \u201cen entornos \u00e1giles no se documenta\u201d. Aqu\u00ed tienes un art\u00edculo donde te orientamos al respecto. \u00c1gil se refiere a un enfoque para el desarrollo de software que enfatiza el desarrollo r\u00e1pido y flexible y la infraestructura de proyectos y procesos por su propio bien. La siguiente declaraci\u00f3n muestra el […]<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":305,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"ocean_post_layout":"","ocean_both_sidebars_style":"","ocean_both_sidebars_content_width":0,"ocean_both_sidebars_sidebars_width":0,"ocean_sidebar":"0","ocean_second_sidebar":"0","ocean_disable_margins":"enable","ocean_add_body_class":"","ocean_shortcode_before_top_bar":"","ocean_shortcode_after_top_bar":"","ocean_shortcode_before_header":"","ocean_shortcode_after_header":"","ocean_has_shortcode":"","ocean_shortcode_after_title":"","ocean_shortcode_before_footer_widgets":"","ocean_shortcode_after_footer_widgets":"","ocean_shortcode_before_footer_bottom":"","ocean_shortcode_after_footer_bottom":"","ocean_display_top_bar":"default","ocean_display_header":"default","ocean_header_style":"","ocean_center_header_left_menu":"0","ocean_custom_header_template":"0","ocean_custom_logo":0,"ocean_custom_retina_logo":0,"ocean_custom_logo_max_width":0,"ocean_custom_logo_tablet_max_width":0,"ocean_custom_logo_mobile_max_width":0,"ocean_custom_logo_max_height":0,"ocean_custom_logo_tablet_max_height":0,"ocean_custom_logo_mobile_max_height":0,"ocean_header_custom_menu":"0","ocean_menu_typo_font_family":"0","ocean_menu_typo_font_subset":"","ocean_menu_typo_font_size":0,"ocean_menu_typo_font_size_tablet":0,"ocean_menu_typo_font_size_mobile":0,"ocean_menu_typo_font_size_unit":"px","ocean_menu_typo_font_weight":"","ocean_menu_typo_font_weight_tablet":"","ocean_menu_typo_font_weight_mobile":"","ocean_menu_typo_transform":"","ocean_menu_typo_transform_tablet":"","ocean_menu_typo_transform_mobile":"","ocean_menu_typo_line_height":0,"ocean_menu_typo_line_height_tablet":0,"ocean_menu_typo_line_height_mobile":0,"ocean_menu_typo_line_height_unit":"","ocean_menu_typo_spacing":0,"ocean_menu_typo_spacing_tablet":0,"ocean_menu_typo_spacing_mobile":0,"ocean_menu_typo_spacing_unit":"","ocean_menu_link_color":"","ocean_menu_link_color_hover":"","ocean_menu_link_color_active":"","ocean_menu_link_background":"","ocean_menu_link_hover_background":"","ocean_menu_link_active_background":"","ocean_menu_social_links_bg":"","ocean_menu_social_hover_links_bg":"","ocean_menu_social_links_color":"","ocean_menu_social_hover_links_color":"","ocean_disable_title":"default","ocean_disable_heading":"default","ocean_post_title":"","ocean_post_subheading":"","ocean_post_title_style":"background-image","ocean_post_title_background_color":"","ocean_post_title_background":435,"ocean_post_title_bg_image_position":"top center","ocean_post_title_bg_image_attachment":"","ocean_post_title_bg_image_repeat":"","ocean_post_title_bg_image_size":"","ocean_post_title_height":0,"ocean_post_title_bg_overlay":0.5,"ocean_post_title_bg_overlay_color":"","ocean_disable_breadcrumbs":"default","ocean_breadcrumbs_color":"","ocean_breadcrumbs_separator_color":"","ocean_breadcrumbs_links_color":"","ocean_breadcrumbs_links_hover_color":"","ocean_display_footer_widgets":"default","ocean_display_footer_bottom":"default","ocean_custom_footer_template":"0"},"_links":{"self":[{"href":"https:\/\/arsum.cl\/index.php?rest_route=\/wp\/v2\/pages\/416"}],"collection":[{"href":"https:\/\/arsum.cl\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/arsum.cl\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/arsum.cl\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/arsum.cl\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=416"}],"version-history":[{"count":14,"href":"https:\/\/arsum.cl\/index.php?rest_route=\/wp\/v2\/pages\/416\/revisions"}],"predecessor-version":[{"id":438,"href":"https:\/\/arsum.cl\/index.php?rest_route=\/wp\/v2\/pages\/416\/revisions\/438"}],"up":[{"embeddable":true,"href":"https:\/\/arsum.cl\/index.php?rest_route=\/wp\/v2\/pages\/305"}],"wp:attachment":[{"href":"https:\/\/arsum.cl\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=416"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}