El Desarrollo R\u00e1pido nos mostr\u00f3 c\u00f3mo aumentar la velocidad de desarrollo del software y describi\u00f3 los l\u00edmites de velocidad de desarrollo para ayudarnos a tener una base firme para distinguir entre programas de mejora realistas y fantas\u00edas ilusorias.<\/p>\n\n
EL LIBRO EXPLICADO EN MENOS DE 60 SEGUNDOS<\/strong><\/p>\n\n El camino trazado en este libro es el menos transitado en la industria actual. Este libro analiza c\u00f3mo los equipos de desarrollo de software pueden aumentar la velocidad del desarrollo de software, permiti\u00e9ndole entregar software m\u00e1s r\u00e1pidamente. El desarrollo r\u00e1pido tambi\u00e9n destaca las pr\u00e1cticas que hacen visible el progreso, permiti\u00e9ndole disipar la apariencia de un desarrollo lento. <\/p>\n\n LAS TRES MEJORES CITAS<\/strong><\/p>\n\n \u00abElija sus batallas. Si el desarrollo r\u00e1pido es una prioridad m\u00e1xima, no encadene a sus desarrolladores insistiendo en demasiadas prioridades simult\u00e1neamente.\u00bb<\/p>\n\n \u00abIncluso si hace algunas cosas bien, como hacer un uso elevado de las pr\u00e1cticas de programaci\u00f3n modernas, puede cometer un error que anule sus ganancias de productividad\u00bb.<\/p>\n\n \u00abUn estudio tras otro ha demostrado que la motivaci\u00f3n tiene probablemente un mayor efecto sobre la productividad y la calidad que cualquier otro factor\u00bb.<\/p>\n\n RES\u00daMENES Y PUNTOS DESTACADOS DEL LIBRO<\/strong><\/p>\n\n PARTE I: DESARROLLO EFICAZ<\/strong><\/p>\n\n Cap\u00edtulo 1 Bienvenido al desarrollo r\u00e1pido<\/strong><\/p>\n\n Qu\u00e9 es el desarrollo r\u00e1pido<\/strong><\/p>\n\n Para algunos, el desarrollo r\u00e1pido implica aplicar una \u00fanica herramienta o m\u00e9todo favorito. Los hackers se refieren a esto como escribir c\u00f3digo durante 36 horas seguidas. Para un ingeniero inform\u00e1tico, RAD combina una implicaci\u00f3n exhaustiva del usuario, herramientas CASE y plazos ajustados. Todos estos m\u00e9todos y herramientas son ideales y pueden contribuir plenamente a aumentar la velocidad de desarrollo. Seg\u00fan el libro, Desarrollo r\u00e1pido es una frase descriptiva que significa desarrollar software m\u00e1s r\u00e1pido que con los enfoques habituales. Un proyecto de desarrollo r\u00e1pido es cualquier proyecto que necesite poner su \u00e9nfasis en la velocidad de desarrollo. En la actualidad, muchos proyectos entran dentro de esa descripci\u00f3n. <\/p>\n\n Lograr un desarrollo r\u00e1pido<\/strong><\/p>\n\n Para conseguir un desarrollo r\u00e1pido, debe tener en cuenta estos dos aspectos: la selecci\u00f3n de pr\u00e1cticas eficaces frente a las ineficaces y la selecci\u00f3n de t\u00e9cnicas orientadas a objetivos. La velocidad de desarrollo suele depender de las pr\u00e1cticas de desarrollo establecidas. La rapidez con la que dise\u00f1e un producto concreto vendr\u00e1 determinada por la medida en que seleccione t\u00e9cnicas eficaces y orientadas a la programaci\u00f3n. Existen tres pr\u00e1cticas orientadas al cronograma: Pr\u00e1cticas orientadas a la velocidad, Pr\u00e1cticas orientadas al riesgo del cronograma y Pr\u00e1cticas orientadas a la visibilidad. Sus inquietudes sobre la velocidad de desarrollo determinan el tipo de pr\u00e1cticas orientadas a la programaci\u00f3n que elija. Si cree que debe aumentar su velocidad de desarrollo, c\u00e9ntrese en las pr\u00e1cticas orientadas a la velocidad. Si prev\u00e9 que su velocidad est\u00e1 bien, pero que el problema es la percepci\u00f3n de su ritmo por parte del cliente, entonces oriente su atenci\u00f3n hacia las pr\u00e1cticas orientadas a la visibilidad. <\/p>\n\n Cap\u00edtulo 2: Estrategia de desarrollo r\u00e1pido<\/strong><\/p>\n\n Estrategia general de desarrollo r\u00e1pido<\/strong><\/p>\n\n El desarrollo r\u00e1pido puede lograrse siguiendo una estrategia de cuatro partes. Las cuatro partes son: evitar los errores cl\u00e1sicos, aplicar los fundamentos del desarrollo, gestionar los riesgos para evitar contratiempos catastr\u00f3ficos y aplicar pr\u00e1cticas orientadas al calendario. Disponga de todos los pilares y h\u00e1galos lo m\u00e1s s\u00f3lidos posible. Los tres primeros pilares determinan en gran medida su potencial para lograr el mejor calendario. Los tres primeros pilares proporcionan el apoyo necesario para lograr el mejor calendario posible. No el apoyo ideal, quiz\u00e1, pero s\u00ed la mayor parte de lo necesario. Es posible que pueda lograr un horario \u00f3ptimo sin pr\u00e1cticas orientadas al horario. <\/p>\n\n Cuatro dimensiones de la velocidad de desarrollo<\/strong><\/p>\n\n Tanto si trabaja despacio para evitar errores como si se mueve a gran velocidad con las mejores pr\u00e1cticas orientadas a la programaci\u00f3n. Su proyecto de software funciona con la ayuda de cuatro dimensiones esenciales: proceso, personas, producto y tecnolog\u00eda. En primer lugar, las personas son el factor que m\u00e1s influye en el desarrollo, la productividad y la calidad del software. Est\u00e1 claro que cualquier empresa que quiera mejorar la productividad debe considerar en primer lugar las cuestiones relacionadas con las personas. En segundo lugar, el proceso de desarrollo de software incluye metodolog\u00edas tanto t\u00e9cnicas como de gesti\u00f3n. Centrarse en los procesos aumenta la garant\u00eda de calidad, ayuda en la gesti\u00f3n de riesgos y permite evitar la reelaboraci\u00f3n. Producto: es la dimensi\u00f3n m\u00e1s tangible. Centrarse en el tama\u00f1o y las caracter\u00edsticas del producto presenta enormes oportunidades de reducci\u00f3n de plazos. Si puede reducir el conjunto de caracter\u00edsticas de un producto, podr\u00e1 reducir su calendario. Por \u00faltimo, la tecnolog\u00eda: cuando cambie sus herramientas tecnol\u00f3gicas, lo m\u00e1s probable es que mejore su velocidad de desarrollo. Puede cambiar de medios menos eficaces a herramientas m\u00e1s productivas. <\/p>\n\n Cap\u00edtulo 3: \u00bfQu\u00e9 dimensi\u00f3n importa m\u00e1s?<\/strong><\/p>\n\n Analice su proyecto para determinar cu\u00e1les de las cuatro dimensiones son limitadas y cu\u00e1les puede aprovechar al m\u00e1ximo. A continuaci\u00f3n, extienda cada una de ellas al m\u00e1ximo. Esa es, en pocas palabras, la clave del \u00e9xito del desarrollo r\u00e1pido. <\/p>\n\n Cita favorita de la parte: \u00abLa primera conclusi\u00f3n es que ahora sabemos con certeza que las cuestiones relacionadas con las personas tienen m\u00e1s impacto en la productividad y la calidad del software que cualquier otro factor\u00bb.<\/em><\/strong><\/p>\n\n PARTE II: DESARROLLO R\u00c1PIDO<\/strong><\/p>\n\n Cap\u00edtulo uno: \u00bfUna talla \u00fanica para todos?<\/strong><\/p>\n\n Diferentes proyectos tienen diferentes requisitos de desarrollo r\u00e1pido, incluso cuando todos necesitan desarrollarse \u00ablo m\u00e1s r\u00e1pido posible\u00bb. Por lo general, los productos que se distribuyen ampliamente deben dise\u00f1arse con m\u00e1s cuidado que los productos que se distribuyen poco. Los productos con una fiabilidad cr\u00edtica deben desarrollarse con m\u00e1s cuidado que los productos cuya fiabilidad es secundaria. Esto implica que debe personalizar una soluci\u00f3n que se adapte a su situaci\u00f3n. <\/p>\n\n \u00bfQu\u00e9 tipo de desarrollo r\u00e1pido necesita?<\/strong><\/p>\n\n La esencia del desarrollo r\u00e1pido gira en torno a determinar qu\u00e9 tipo de enfoque de desarrollo r\u00e1pido desea. \u00bfSe trata de una ligera ventaja en velocidad, una mejor visibilidad del progreso, un coste m\u00e1s bajo o una mayor previsibilidad? Mucha gente cree que necesita un desarrollo r\u00e1pido, pero en realidad lo que necesita son precios m\u00e1s bajos y m\u00e1s previsibilidad o un enfoque que evite un fracaso tr\u00e1gico. Para determinar qu\u00e9 tipo de desarrollo r\u00e1pido necesita, h\u00e1gase estas preguntas; <\/p>\n\n Los productos que tienen que centrarse en la velocidad de desarrollo m\u00e1s que en el coste o la previsibilidad tienen un valor temporal diferente en comparaci\u00f3n con los productos t\u00edpicos. A medida que pasa el tiempo, el valor de los productos espec\u00edficos suele reducirse gradualmente. Pero para los productos con s\u00f3lidas limitaciones de calendario, hay un punto en el que disminuyen precipitadamente. <\/p>\n\n Antes de orientar su proyecto hacia el calendario m\u00e1s corto en lugar de hacia el menor coste, el m\u00ednimo riesgo o el mejor rendimiento, descubra qu\u00e9 es lo que se necesita. Los parecidos al desarrollo r\u00e1pido exigen una velocidad de desarrollo sin l\u00edmites, pero exigen algo m\u00e1s. <\/p>\n\n Cap\u00edtulo 2: Planificaci\u00f3n del ciclo de vida<\/strong><\/p>\n\n Un modelo de ciclo de vida es un modelo prescriptivo de lo que ocurre entre el primer destello y el \u00faltimo suspiro. Todo esfuerzo de desarrollo de software pasa por un ciclo de vida que comprende todas las actividades entre el principio y el final. El modelo de ciclo de vida m\u00e1s familiar es el conocido modelo de ciclo de vida en cascada, que tiene algunas <\/p>\n\n debilidades igualmente notables. Existen otros modelos de ciclo de vida y, en muchos casos, son mejores opciones para el desarrollo r\u00e1pido que el modelo en cascada. <\/p>\n\n Cascada pura<\/strong><\/p>\n\n El modelo de cascada es la base de otros modelos de ciclo de vida eficaces, ya que est\u00e1 asociado a muchos problemas. En el modelo de cascada, un proyecto avanza en un curso ordenado de pasos desde el concepto inicial del software hasta la prueba del sistema. Al final de cada fase, se revisa el proyecto para determinar si est\u00e1 en condiciones de avanzar al siguiente paso, desde el an\u00e1lisis de requisitos hasta el dise\u00f1o arquitect\u00f3nico. Si la revisi\u00f3n esboza que el proyecto no est\u00e1 preparado para pasar a la siguiente fase, permanece en el paso actual hasta que est\u00e9 listo. <\/p>\n\n Code-and-Fix<\/strong><\/p>\n\n El modelo de c\u00f3digo y reparaci\u00f3n es est\u00e1ndar pero podr\u00eda ser m\u00e1s \u00fatil. Si no ha seleccionado otro modelo de ciclo de vida, deber\u00e1 utilizar c\u00f3digo-y-fijaci\u00f3n por defecto. Utilizar el modelo de c\u00f3digo y correcci\u00f3n significa empezar con una idea general de lo que quiere crear. Puede tener una especificaci\u00f3n formal o no. A continuaci\u00f3n, utilice a su conveniencia cualquier combinaci\u00f3n de metodolog\u00edas informales de dise\u00f1o, c\u00f3digo, depuraci\u00f3n y prueba hasta que tenga un producto listo para su lanzamiento. Este modelo no tiene sobrecarga, lo que significa que no dedicar\u00e1 tiempo a la planificaci\u00f3n, la garant\u00eda de calidad o la documentaci\u00f3n aparte de la codificaci\u00f3n. Tambi\u00e9n requiere poca experiencia. Cualquiera que est\u00e9 familiarizado con los programas inform\u00e1ticos puede utilizar el modelo de \u00abcodificar y corregir\u00bb. <\/p>\n\n Espiral<\/strong><\/p>\n\n Este modelo descompone un proyecto de software en miniproyectos y est\u00e1 muy orientado a los riesgos. Cada miniproyecto aborda riesgos significativos hasta que no queda ning\u00fan riesgo que gestionar. El riesgo en este contexto se refiere a requisitos incompetentes, problemas de rendimiento, arquitectura mal entendida y muchos m\u00e1s. En cuanto se han gestionado los riesgos, el modelo en espiral termina como el modelo en cascada. En el modelo en espiral, se empieza a peque\u00f1a escala en el centro de la espina dorsal, se identifican e inspeccionan todos los riesgos, se formula un plan para controlar los riesgos y, por \u00faltimo, se compromete un enfoque para la siguiente iteraci\u00f3n. El modelo en espiral proporciona al menos tanto control de gesti\u00f3n como el modelo tradicional en cascada. Dispone de puntos de control al final de cada iteraci\u00f3n. Como el modelo est\u00e1 orientado al riesgo, proporciona indicaciones tempranas de cualquier riesgo insuperable. <\/p>\n\n Cap\u00edtulo 3: Estimaci\u00f3n<\/strong><\/p>\n\n La estimaci\u00f3n de software es bastante compleja. Los altos y bajos directivos, los clientes y algunos desarrolladores no entienden por qu\u00e9 la estimaci\u00f3n es tan dif\u00edcil. La historia b\u00e1sica de la estimaci\u00f3n de software es que el desarrollo de software es un proceso de refinamiento gradual. Se empieza con una imagen borrosa de lo que se quiere construir y luego se pasa el resto del proyecto intentando aclarar esa imagen. Dado que la imagen del software que intenta desarrollar es borrosa, la estimaci\u00f3n del tiempo y el esfuerzo necesarios para construirlo tambi\u00e9n lo es. La previsi\u00f3n s\u00f3lo puede enfocarse junto con el propio software, lo que significa que la estimaci\u00f3n del proyecto de software es tambi\u00e9n un proceso de refinamiento gradual. <\/p>\n\n Cap\u00edtulo 4: Programaci\u00f3n<\/strong><\/p>\n\n Programaci\u00f3n excesivamente optimista<\/strong><\/p>\n\n Los calendarios de programaci\u00f3n excesivamente optimistas son una tradici\u00f3n desva\u00edda en el desarrollo de software. Todas las cuestiones esenciales de programaci\u00f3n son urgencias y muchos proyectos de software necesitan m\u00e1s tiempo de calendario. La presi\u00f3n excesiva del calendario es la influencia m\u00e1s destructiva en el software. La mayor\u00eda de los proyectos establecen sus calendarios antes de que se fijen los requisitos y no los establecen sin tiempo de sobra. Las causas de los calendarios excesivamente optimistas son profundas e incluyen; Los directores o los clientes se niegan a aceptar una serie de estimaciones y hacen <\/p>\n\n planes basados en una \u00fanica estimaci\u00f3n del \u00abmejor de los casos\u00bb. Los directivos y promotores subestiman deliberadamente el proyecto porque quieren un reto o les gusta trabajar bajo presi\u00f3n. La direcci\u00f3n o los comerciales subestiman deliberadamente el proyecto para presentar una oferta ganadora. <\/p>\n\n Vencer la presi\u00f3n del calendario<\/strong><\/p>\n\n La presi\u00f3n de los plazos es end\u00e9mica en el desarrollo de software y ha generado un pensamiento negativo a corto plazo. Uno, ha fomentado la toma de atajos en determinados proyectos, lo que ha dado lugar a una entrega deficiente. Dos, ha impulsado una mentalidad de apagafuegos sobre la propia presi\u00f3n de los calendarios. No podemos resolver el problema del desarrollo r\u00e1pido hasta que resolvamos el problema de la presi\u00f3n del calendario. <\/p>\n\n Cita favorita del cap\u00edtulo: \u00abTodo esfuerzo de desarrollo de software pasa por un \u00abciclo de vida\u00bb, que consiste en todas las actividades entre el momento en que la versi\u00f3n 1.0 de un sistema comienza su vida como un brillo en los ojos de alguien y el momento en que la versi\u00f3n 6.74b finalmente da su \u00faltimo suspiro en la m\u00e1quina del \u00faltimo cliente.\u00bb<\/em><\/strong><\/p>\n\n TERCERA PARTE: MEJORES PR\u00c1CTICAS<\/strong><\/p>\n\n Cap\u00edtulo uno: Junta del cambio<\/strong><\/p>\n\n Este enfoque controla los cambios realizados en un proyecto de software. Una junta de cambios integra a representantes de desarrollo, documentaci\u00f3n de usuario, control de calidad, atenci\u00f3n al cliente, gesti\u00f3n y marketing, otorg\u00e1ndoles autoridad suprema para aceptar y rechazar los cambios sugeridos. Este enfoque contribuye a un desarrollo r\u00e1pido al minimizar el n\u00famero de cambios incontrolados en el producto y aumentar la visibilidad de la fluencia de caracter\u00edsticas. Los tableros de cambios pueden ponerse en juego en cualquier tipo de entorno. <\/p>\n\n Cap\u00edtulo 2: Construcci\u00f3n diaria y prueba de humo<\/strong><\/p>\n\n Mediante el proceso Daily Build and Smoke Test, un producto de software se construye cada d\u00eda y se prueba varias veces para verificar sus operaciones primarias. Este proceso puede instituirse cuando el proyecto ya ha comenzado. Este proceso minimiza los riesgos de retraso, la escasa visibilidad del progreso y la integraci\u00f3n fallida. El proceso proporciona un control cr\u00edtico para los proyectos en modo de recuperaci\u00f3n. Su \u00e9xito depende de que los desarrolladores se tomen en serio el enfoque y de que se realicen pruebas de humo bien dise\u00f1adas. La construcci\u00f3n diaria y las pruebas de humo pueden utilizarse eficazmente en proyectos de pr\u00e1cticamente cualquier tama\u00f1o y complejidad. La idea que subyace en el proceso de construcci\u00f3n diaria y prueba de humo es sencilla: construya el producto y pru\u00e9belo a diario. <\/p>\n\n Cap\u00edtulo 3: Dise\u00f1ar para el cambio<\/strong><\/p>\n\n Dise\u00f1ar para el cambio es una aplicaci\u00f3n exhaustiva que engloba numerosas pr\u00e1cticas de dise\u00f1o orientadas al cambio. Para que estas pr\u00e1cticas sean eficaces, deben aplicarse durante las primeras fases del ciclo de vida del software. El \u00e9xito de este enfoque depende de que se identifiquen los cambios adecuados, se desarrolle un plan de cambios y se oculten las decisiones de dise\u00f1o para que los cambios no se propaguen por el programa. Algunas de las pr\u00e1cticas de dise\u00f1o orientado al cambio son m\u00e1s complejas de lo que la gente prev\u00e9. Cuando se aplican correctamente, estas pr\u00e1cticas sientan las bases de programas longevos y de una flexibilidad que minimiza los efectos en el calendario de las solicitudes de cambio de \u00faltima hora. Dise\u00f1ar para el cambio\u00bb no se refiere a una \u00fanica metodolog\u00eda de dise\u00f1o, sino a una panoplia de pr\u00e1cticas de dise\u00f1o que contribuyen a lograr dise\u00f1os de software flexibles. <\/p>\n\n Cap\u00edtulo 4: Entrega evolutiva<\/strong><\/p>\n\n La entrega evolutiva es un modelo de ciclo de vida que equilibra el control de la entrega por etapas y la flexibilidad de los prototipos evolutivos. Proporciona su ventaja de desarrollo r\u00e1pido al entregar partes seleccionadas del software antes de lo posible, pero no entrega necesariamente el producto final m\u00e1s r\u00e1pido. Ofrece cierta capacidad para cambiar la direcci\u00f3n del producto a mitad de camino en respuesta a las peticiones de los clientes. La entrega evolutiva se ha utilizado con \u00e9xito en software empresarial interno y en software retractilado. Si se utiliza con cuidado, puede conducir a una mejora de la calidad del producto, una reducci\u00f3n del tama\u00f1o del c\u00f3digo y una distribuci\u00f3n m\u00e1s uniforme de los recursos de desarrollo y pruebas. Al igual que otros modelos de ciclo de vida, la Entrega Evolutiva es una pr\u00e1ctica de todo el proyecto: si quiere utilizarla, debe empezar a planificar su uso en las primeras fases del proyecto. <\/p>\n\n Cita favorita del cap\u00edtulo: \u00abDemasiadas horas extraordinarias y la presi\u00f3n del calendario pueden da\u00f1ar un desarrollo<\/em><\/strong><\/p>\n\n horario, pero un poco de horas extra puede aumentar la cantidad de trabajo realizado cada semana y mejorar la motivaci\u00f3n\u00bb.<\/em><\/strong><\/p>\n\n C\u00d3MO PUEDE AYUDAR ESTE LIBRO A LOS DESARROLLADORES DE SOFTWARE<\/strong><\/p>\n\n \u00abDesarrollo r\u00e1pido\u00bb, de Steve McConnell, es una completa gu\u00eda para desarrolladores de software que ofrece consejos pr\u00e1cticos y t\u00e9cnicas para aumentar la velocidad y la eficacia del proceso de desarrollo de software. El libro abarca diversos temas como la planificaci\u00f3n del proyecto, la recopilaci\u00f3n de requisitos, el dise\u00f1o, la codificaci\u00f3n, las pruebas y la gesti\u00f3n del proyecto. El libro tambi\u00e9n analiza las mejores pr\u00e1cticas y estrategias para gestionar el riesgo, reducir los errores, mejorar la comunicaci\u00f3n y aumentar la calidad general de los proyectos de desarrollo de software. McConnell se basa en su amplia experiencia en este campo y proporciona numerosos ejemplos del mundo real para ilustrar sus puntos. En conjunto, \u00abDesarrollo r\u00e1pido\u00bb es un valioso recurso para los desarrolladores que deseen mejorar su productividad y la calidad de su trabajo. El libro ofrece consejos pr\u00e1cticos y procesables para ayudar a los desarrolladores de todos los niveles a ser m\u00e1s eficaces y eficientes. <\/p>\n","protected":false},"excerpt":{"rendered":" Un desarrollo lento afecta a todos los implicados en el proceso de desarrollo de software, incluidos clientes, desarrolladores, usuarios finales y directivos. Todos los equipos de desarrollo de software quieren resolver este gran problema: c\u00f3mo aumentar la velocidad de desarrollo y, al mismo tiempo, tener bajo control los apretados calendarios de desarrollo. En Desarrollo r\u00e1pido, […]<\/p>\n","protected":false},"author":1,"featured_media":21598,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_themeisle_gutenberg_block_has_review":false,"_jet_sm_ready_style":"","_jet_sm_style":"","_jet_sm_controls_values":"","_jet_sm_fonts_collection":"","_jet_sm_fonts_links":"","footnotes":""},"categories":[101],"tags":[],"writer":[],"class_list":["post-19995","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-club-del-libro"],"_links":{"self":[{"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/posts\/19995","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/comments?post=19995"}],"version-history":[{"count":1,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/posts\/19995\/revisions"}],"predecessor-version":[{"id":19997,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/posts\/19995\/revisions\/19997"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/media\/21598"}],"wp:attachment":[{"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/media?parent=19995"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/categories?post=19995"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/tags?post=19995"},{"taxonomy":"writer","embeddable":true,"href":"https:\/\/devologyx.io\/es\/wp-json\/wp\/v2\/writer?post=19995"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"\"](\"https:\/\/devologyx.io\/wp-content\/uploads\/2024\/02\/james-harrison-UVMPVIRCF5w-unsplash-1024x576.jpg\")
<\/figure>\n\n![\"\"](\"https:\/\/devologyx.io\/wp-content\/uploads\/2024\/02\/saffu-E4kKGI4oGaU-unsplash-edited.jpg\")
<\/figure>\n\n\n
![\"\"](\"https:\/\/devologyx.io\/wp-content\/uploads\/2024\/02\/brett-jordan-XAX8vCM5G6o-unsplash-edited-scaled.jpg\")
<\/figure>\n\n