# data[].attributes.body
Establece una relación saludable con tus compañero(a)s de estudio y con tu profesor. Esta experiencia es importante porque ayuda a que ganes confianza y tomes la iniciativa para ser dedicado y enfocado (resiliente y persistente) .
~~~~~~~~~~~~~~~~~~~~~~~
Este recurso digital tiene dos propósitos principales:

1. Qué actividades se les requie -re, a los aprendientes, en la materia y

2. porque se les requiere.

Estas actividades son el quid de los paradigmas educativos, aplicados en la materia, para promover el aprehendimiento autónomo.
El de educación mixta es un enfoque que combina materiales educativos interactivos (en línea) , con el enfoque presencial. La experiencia demuestra que el rendimiento de los estudiantes es mayor con un enfoque combinado que solo con el presencial o el de línea. El de aula invertida es un caso específico del aprendizaje mixto o combinado.
En el de aprendizaje orientado a proyectos, el aprendiente toma mayor responsabilidad de su propio aprendizaje al aplicar sus habilidades y conocimientos, adquiridos en o fuera del aula, en proyectos reales.
En la materia, también se promue -ven valores de vida, para que el aprendiente aprecie y observe una conducta constructiva.

~~~~~~~~~~~~~~~~~~~~~~~

Las actividades a realizar en la materia son:

Clases

Tareas

Laboratorios

Exámenes

Proyectos

Videos

Lecturas

Exposiciones

# data[].attributes.body
En el modelo de aula invertida el estudiante es responsable de su propio aprendizaje: El profesor indica al alumnado sobre el tema en particular a estudiar previo a la clase presencial. El alumno lee los textos y ve los videos pertinentes. El profesor actúa como un retroalimentador de las consultas de los alumnos.

# data[].attributes.body
Hoy día, casi todo alumno tiene una lap top, de ahí que un laboratorio es factible en el salón de clase, y por ende, el docente resuelve las dudas de inmediato en un contexto propicio para el estudiante.
Los laboratorios son una oportunidad para que los alumnos formen equipos de trabajo en la solución de problemas. Con lo que
se fomenta la comunicación  y la instrucción entre ellos.

# data[].attributes.body
Los exámenes no solo permiten al alumno conocer su nivel de conocimiento y habilidades en uno o más temas. También fomentan el aprendizaje enfocado y diligente.

# data[].attributes.body
En el aprendizaje por proyectos hay actividades diversas que deben coordinarse en equipo. El quid es  motivar la cooperación y  la colaboración entre los alumnos para que desarrollen su vocación de servicio, es decir, que pongan al servicio de los demás sus habilidades individuales y de  grupo.

# data[].attributes.body
Tiene el propósito de mostrarle al alumno su nivel cognitivo en la solución de problemas (software y otros).

# data[].attributes.body
Patrones de diseño ha cubrirse en la materia

# data[].attributes.headline
Los elementos de diseño esenciales para un aprendizaje por proyectos de acuerdo con BIE¹ son:                                       ¹Buck Institute of Education     ------------------------------------------

# data[].attributes.subject
Los elementos de diseño esenciales para un aprendizaje por proyectos de acuerdo con BIE¹ son:                                       ¹Buck Institute of Education     ------------------------------------------

# data[].attributes.body
Problema o cuestión retadora

El problema por resolver o cuestión a responder es la parte central del proyecto. El problema o cuestión debe demandar a los estudiantes que apliquen el aprendizaje en un contexto relevante, que sea atractivo para los estudiantes, sin límites fijos, y alineado con los metas de aprendizaje. El hilo conductor puede ser escrito por el profesor o por el profesor y los alumnos.

Indagación sostenida

La indagación del estudiante debe ser activa, profunda, y ocurrir en el tiempo, no en unos días. Durante la indagación los estudiantes deben estar ocupados en el uso de un amplio abanico de fuentes.
Autenticidad

El proceso de el aprendizaje basado en proyectos es auténtico, lo que significa que es relevante para el mundo real, tiene un impacto en otros y habla a los estudiantes de sus propias preocupaciones, intereses y problemas.

Voz y elección del estudiante

Los estudiantes deben tener sentido de pertenencia de su trabajo. Esto debe ser motivador, y además deben aportar y tener control según sea apropiado.

Reflexión

En todo el proceso, los estudiantes deben reflejar activamente lo que están aprendiendo, como lo están aprendiendo y por que lo están aprendiendo. En AOP los estudiantes aprenden a administrar su tiempo, fijar metas, monitorear su progreso hacia las metas y reflejar su participación y efectividad en el grupo,

Criterios y revisión

El aprendizaje orientado a proyectos involucra la comunicación clara de criterios de evaluación al inicio del proceso. Los estudiantes usan rúbricas, modelos, protocolos detallados, comentarios oportunos para evaluar los resultados de lo aprendido.

Producto público

Al final del trabajo, los estudiantes deben tener una audiencia fuera del aula. El trabajo de los estudiantes debe ser algo tangible o una presentación que sea comunicada efectivamente a su audiencia.

Traducción libre

Tomado del enlace siguiente:
https://justaskpublications.com/just-ask-resource-center/e-newsletters/msca/bringing-the-standards-to-life-through-project-based-learning/
El enlace siguiente lo amplia

# data[].attributes.headline
Requerimientos previos para la realización de un Aprendizaje por Proyectos                              ------------------------------------------

# data[].attributes.subject
Requerimientos previos para la realización de un Aprendizaje por Proyectos                              ------------------------------------------

# data[].attributes.body
a) Requerimientos de los alumnos: Deben tener los antecedentes académicos necesarios y suficientes para la realización del mismo.
b) Requerimientos de la propuesta: El qué del proyecto (cual), El porqué (su importancia) y el cómo (definición de los requerimientos esenciales para la implementación del proyecto).

# data[].attributes.body
Incluye:

constructores

destructor

funciones asociadas

operadores aritméticos

operadores de relación

entrada y salida

otros

~~~~~~~~~~~~~~~~~~~~~~~

Antecedentes

1) Conocimiento básico del álgebra lineal: notación y aritmética.
2) Conocimiento y experiencia básicos en programación orientada a objetos con C++.
~~~~~~~~~~~~~~~~~~~~~~~

Este aprendizaje combina dos modelos educativos en dos fases:
1ra fase: Aula invertida
2da fase: Aprendizaje x proyectos
https://www.youtube.com/playlist?list=PLGCj8f6sgswnm7f0QbRxA6h4P0d1DSD6Q

# data[].attributes.body
Enlace a colección de videos y textos sobre computación,  valores, aprendizaje y otros.

# data[].attributes.body
Durante el semestre se indicará qué proyecto(s) se desarrollara(n). La herramienta fundamental del proyecto es la elaboración de la antología digital pertinente.

# data[].attributes.attachment_link.readable_text
Me suelen hacer esta pregunta: ¿Qué es la metodología ágil? Ágil es una palabra que se usa en la industria de la tecnología de la información para describir un método alternativo de gestión de proyectos.

¿Qué es la metodología Ágil?

Se me suele preguntar la siguiente cuestión: ¿Qué es la metodología ágil? Es simple, ágil es una palabra que la industria de la tecnología de la información usa para describir un método alternativo de gestión de proyectos.

El método Ágil es un proceso que permite al equipo dar respuestas rápidas e impredecibles a las valoraciones que reciben sobre su proyecto. Crea oportunidades de evaluar la dirección de un proyecto durante el ciclo de desarrollo. Los equipos evalúan el proyecto en reuniones regulares, llamadas sprints o iteraciones.

El método ágil es un proceso de empoderamiento que ayuda a las empresas a diseñar y crear el producto idóneo. El proceso de gestión es muy beneficioso para las compañías de software porque les permite analizar y mejorar su producto durante el desarrollo del mismo. Esto da a las empresas la capacidad de fabricar un producto valioso, de manera que se mantengan competitivas en el mercado.

¿De dónde procede la metodología Ágil?

En 2001, un pequeño grupo de personas, cansadas de los modos tradicionales de gestionar proyectos de desarrollo software, crearon el manifiesto ágil. Es un método mejorado de gestionar los proyectos de desarrollo software.

El manifiesto ágil tiene cuatro valoraciones importantes:

1. El foco se debe poner más sobre las personas y las interacciones que sobre los procesos y herramientas

2. El software funcionando es más importante que la documentación extensiva

3. La colaboración con el cliente es más importante que la negociación contractual

4. El proceso debería responder ante el cambio, en lugar de seguir un plan

El desarrollo ágil de software posee 12 principios:

1. La mayor prioridad es satisfacer al cliente mediante la entrega continua de software con valor

2. Siempre se acepta que los requisitos cambien, sin importar cuán pronto o tarde sea en el proyecto

3. Se entrega software funcional en un pequeño periodo de tiempo

4. Tanto los desarrolladores como los responsables del negocio deben trabajar juntos a diario durante todo el proyecto

5. La información se transmite más fácilmente cara a cara

6. Hay que motivar a la gente mediante la creación de un ambiente de apreciación, confianza y empoderamiento

7. El software funcionando es la medida principal de progreso

8. El proceso ágil promueve el desarrollo sostenible

9. La atención continua a la excelencia técnica y la calidad en el diseño mejora la agilidad

10. La simplicidad es una parte vital de una buena gestión ágil

11. Los equipos auto-organizados producen las mejores arquitecturas, requisitos y diseños.

12. Los equipos deben reflexionar mediante la revisión y la adaptación para ser más efectivos

Hay diferentes métodos ágiles que fomentan los valores y principios del manifiesto. Scrum y XP son dos muy conocidos.

Los Beneficios del Desarrollo Ágil de Software

Los mejores desarrolladores de software llevaron a cabo reuniones ágiles. Después de experimentar las limitaciones del modelo de desarrollo en cascada, buscaban un proceso más eficiente para analizar el proceso de desarrollo. El enfoque que utilizaron supera los problemas relacionados con las filosofías y los procesos de los métodos clásicos.

Podemos encontrar muchos beneficios en el desarrollo ágil de software. Entre otros:
Compromiso y Satisfacción de los inversores
La metodología ágil crea muchas oportunidades en cada reunión para conseguir un compromiso sincero entre el equipo y los inversores. Ya que el cliente participa activamente en el proyecto, existe una continua colaboración entre todas las partes. Esto brinda al equipo la oportunidad de entender completamente la visión del cliente. Al entregar software funcional y de gran calidad con frecuencia, los inversores crean una relación de confianza con el equipo. Esto ayuda también a que se vuelvan a producir acuerdos entre el equipo y el cliente en el futuro.
Transparencia
El método ágil involucra al cliente en el proyecto completo, incluyendo en el planteamiento de la iteración, las sesiones de revisión, y el anuncio de nuevas características en el software. Los clientes, sin embargo, deben entender que, aunque el proyecto sea transparente, están viendo un WIP (trabajo en curso) y no el producto final.
Entrega Temprana y Predecible
Los sprints se llevan a cabo en un horario fijo durante 1 a 4 semanas. Gracias a este método, la entrega del producto es muy predecible, ya que las nuevas características pueden ser entregadas a los inversores de manera rápida y frecuente. También permite al equipo a probar o lanzar el software antes si tiene suficiente valor empresarial.
Horarios y Costes Predecibles
Ya que los sprints se realizan en un horario fijo, los costes son limitados y predecibles, y se basan en la cantidad de trabajo finalizada. Combinando los costes estimados antes de cada sprint, el cliente entenderá mejor los costes aproximados de cada característica. Esto ofrece mejores oportunidades para tomar decisiones a la hora de priorizar características o añadir iteraciones.
Priorización Flexible
Las metodologías Scrum permiten una mayor flexibilidad, al priorizar las funciones dirigidas al cliente. El equipo tiene un mayor control sobre las unidades de trabajo que se pueden entregar al final de cada sprint; consiguiendo un progreso continuo hacia el objetivo del producto final. Para obtener con rapidez un RIO del equipo de ingeniería, el trabajo debe ser enviado pronto a los consumidores, de manera que sepan el valor de las funciones del producto.
Se Permite el Cambio
Aunque el objetivo debería ser entregar el subconjunto acordado de funciones del producto, los procesos Ágiles brindan la oportunidad de cambiar las prioridades y refinar el Backlog del producto. Estos cambios pueden añadirse a la siguiente iteración, de manera que pueden ser introducidos en unas pocas semanas.
Se Pone el foco en el Valor de Negocio
El equipo entiende mejor qué es más importante para el negocio del cliente y puede entregar las características que le den el mayor valor posible a dicho negocio.
Se Centra en los Usuarios
Las historias de usuario se usan normalmente para definir las funciones del producto, ya que estas se refieren a criterios de aceptación centrados en el negocio. Al centrarse en las necesidades del usuario, cada característica ofrece un valor real y no solamente un componente TI. Otorga una mejor oportunidad para ganar buenas valoraciones a través de pruebas beta del software al finalizar cada Sprint. Esto genera un feedback crucial, ya que a partir del mismo se pueden realizar los cambios necesarios.
Se Mejora la Calidad
Los proyectos se dividen en unidades manejables, permitiendo al equipo centrarse en el desarrollo de alta calidad, en el testeo y en la colaboración. Al crear compilaciones y realizar pruebas o revisiones a lo largo de la iteración, se pueden encontrar errores y defectos y solucionarlos pronto, mejorando la calidad general del producto.
Se da un Objetivo a tu Equipo
La mayoría de los procesos ágiles se centran en crear un sentimiento compartido de propiedad y objetivos para todos los miembros del equipo. Esto le pone metas a tu equipo, en lugar de crear una falsa sensación de urgencia. Los equipos que tienen metas son más productivos y se desafían a ellos mismos para ser más rápidos y eficientes.

Los Beneficios Empresariales del Método Ágil

La gestión Ágil reduce los riesgos comunes asociados a la entrega, el alcance, y el presupuesto del proyecto.

Favorece la colaboración entre el cliente y el equipo; ofreciendo beneficios mutuos en la mitigación de los grandes riesgos que surgen durante el desarrollo del software.

En 2009, el Dr. David F Rico comparó el método Ágil con los métodos tradicionales de gestión de proyectos software. Durante la investigación y la síntesis, analizó 23 procesos Ágiles, comparándolos con 7.500 proyectos tradicionales.

Encontró 20 beneficios en los proyectos Ágiles:

El 41% fueron mejores en cuanto al valor empresarial

El 83% mostró un menor tiempo de lanzamiento al mercado

El 50% tenían una calidad mayor

El 50% tenían menos costes

El 83% fueron más productivos

Metodologías Ágiles

Hay bastantes metodologías ágiles; todas comparten filosofías, características y prácticas similares. Sin embargo, tras ser implementada, cada metodología tiene sus propias prácticas, terminología y tácticas. Algunas de las principales metodologías de desarrollo ágil de software son:
Scrum
Scrum es un framework de gestión con grandes posibilidades de control y gestión de las iteraciones y los incrementos en todo tipo de proyectos. Las tácticas Scrum son ligeras y se pueden combinar con otras metodologías ágiles. Su popularidad ha crecido dentro de la comunidad de desarrollo ágil, ya que son sencillas y tienen una probada productividad.
Lean and Kanban 1.Desarrollo de Software Lean
El desarrollo de software lean es una metodología iterativa originalmente desarrollada por Mary y Tom Poppendieck. Muchos de los principios y prácticas de esta metodología vienen de la tendencia de iniciativas lean y fueron usadas por primera vez en grandes compañías, como Toyota. Este método basado en el valor se centra en entregar al cliente un eficiente mecanismo de "Flujo de Valor" que define el valor del proyecto.

Los principios esenciales de esta metodología son:

No desperdiciar

Ampliar el aprendizaje

Tomar las decisiones tan tarde como sea posible

Entregar los resultados tan rápido como sea posible

Empoderar al equipo

Lograr integridad

Visualizar todo el Proyecto

Al escoger solo las características que tienen valor real para el sistema, priorizándolas y entregándolas en pequeñas tandas, se hace desaparecer el despilfarro. En cambio, la metodología lean pone el énfasis en la velocidad y la eficiencia; dependiendo del feedback entre los clientes y los programadores. Se centra en la idea de que las peticiones de los clientes "tiran" del producto. El foco se pone más sobre la habilidad de las personas o de pequeños equipos de tomar decisiones más rápida y eficientemente, en lugar de un método jerárquico. Esta metodología se concentra en la eficiencia de su equipo, asegurando que todo el mundo es siempre tan productivo como puede.

Las organizaciones utilizan el método Kanban para gestionar la creación del proyecto a la vez que se pone el énfasis en la entrega continua y en no sobrecargar al equipo de desarrollo. Como el método Scrum, los procesos Kanban están diseñados para ayudar a los equipos a trabajar juntos de manera más eficiente.

Tiene tres principios:

1. Visualiza lo que haces: ve todos los elementos dentro del contexto de cada uno - más informativo

2. Limita la cantidad de trabajo en progreso (WIP): equilibra el flujo de trabajo, de manera que los equipos no se ven forzados a realizar mucho trabajo

3. Mejora el flujo de trabajo: tan pronto como una tarea esté finalizada, comienza con el siguiente trabajo más grande del backlog

El método Kanban promueve la colaboración continua entre el cliente y el equipo. Incentiva el continuo aprendizaje y las mejoras para dar al equipo el mejor flujo de trabajo posible
Programación Extrema (XP)
El método Programación Extrema (XP) fue originalmente descrito por Kent Beck. Es una de las metodologías ágiles más populares y controvertidas. XP es un método de mucha disciplina que consiste en entregar continuamente software de alta calidad con rapidez. El cliente se involucra activamente con el equipo para realizar la planificación, el testeo y dar feedback, consiguiendo entregar software funcional con frecuencia. El software debería ser entregado por intervalos, cada tres semanas.

El método XP original está basado en cuatro simples valores:

Tiene 12 prácticas de apoyo:
Crystal
La metodología Crystal es una de las menos pesadas y más adaptables en el mundo del desarrollo software. Está compuesta de varios procesos ágiles, que incluyen el Clear, Crystal Yellow, Crystal Orange, y otros métodos. Hay muchos factores que impulsan estos procesos, incluyendo: el tamaño del equipo y del sistema, y las prioridades del proyecto.

La familia de Crystal se centra en el hecho de que cada proyecto tiene características únicas, por tanto, las políticas y prácticas tienen que adaptarse a estas características.

El método Crystal tiene varios principios fundamentales, incluyendo:

Este proceso ágil, como otras metodologías, promueve la entrega temprana y frecuente de software funcional. Incentiva la adaptación e involucración del usuario, eliminando las distracciones y la burocracia.
Método de Desarrollo de Sistemas Dinámicos (DSDM)
El Método de Desarrollo de Sistemas Dinámicos (DSDM) se creó en 1994 para proveer un framework estándar para la entrega de proyectos, y por entonces se llamó Desarrollo Rápido de Aplicaciones (DRA). Aunque era muy popular en los 90, el modelo DRA se desarrolló de manera no estructurada.

Desde sus inicios, el DSDM ha evolucionado y madurado; ahora proporciona una base para la planificación, la gestión, la ejecución y el escalado del proceso ágil y los proyectos iterativos.

El método DSDM tiene seis principios fundamentales:

El DSDM utiliza un enfoque "de propósito comercial" para la entrega y los criterios de aceptación. Se centra en la fórmula: lanzamiento del 80% del sistema en el 20% del tiempo.
Desarrollo Basado en Funcionalidades (FDD)
Jeff De Luca, junto a los colaboradores A.m. Rajashima, Lim Bak Wee, Paul Szego, Jon Kern y Stehen Palmer desarrollaron el método de Desarrollo Basado en Funcionalidades (FDD). Es un proceso iterativo que comienza estableciendo la forma del modelo ágil. Las iteraciones del "diseño basado en las funcionalidades, build basada en las funcionalidades" duran dos semanas. Las funcionalidades gustan a los clientes porque son pequeñas y útiles.

El diseño y desarrollo FDD se basa en estas ocho prácticas:

1. Modelado de objetos del dominio

2. Desarrollo de funcionalidades

3. Propiedad de clases y componentes

4. Equipos de Funcionalidades

5. Inspección

6. Administración de configuración

7. Builds regulares

8. Reporte de progresos y resultados

Roles en el método Ágil

En el proceso de desarrollo ágil, la metodología Scrum define perfectamente qué es el método ágil en la gestión de proyectos.

Hay tres roles en un proyecto Scrum: el Dueño del Producto, el Scrum Master y los miembros del equipo.

El Product Owner supervisa todas las condiciones comerciales del proyecto para asegurarse de que se está desarrollando el producto correcto y en el orden establecido. Un buen dueño de producto equilibra las prioridades competitivas, está disponible para el equipo, y toma decisiones sobre el proyecto.

El Scrum Master es el coach del equipo; ayudan al equipo a trabajar juntos con efectividad. Los Scrum Masters rompen las barreras que impiden el progreso, facilitando reuniones y grupos de discusión, monitorizando los progresos, solucionando problemas, y realizando otras tareas de gestión del proyecto.

El equipo trabaja conjuntamente para determinar la mejor manera de conseguir los objetivos establecidos por el dueño del producto. El equipo decide qué miembros realizarán tareas específicas, y subraya las prácticas técnicas requeridas para alcanzar los objetivos.

¿Dónde encaja el rol del Scrum Master en el Desarrollo Ágil de Software?

En la gestión ágil de un proyecto, el Scrum Master es la versión del siglo XXI del director del proyecto. Sin embargo, a diferencia de los directores de proyecto tradicionales, el Scrum Master no se apunta el tanto ni acusa a nadie del éxito o fracaso de un proyecto.

Su autoridad solo se extiende al proceso. La experiencia del Scrum Master motiva y guía al equipo a trabajar a su máximo nivel. Otros roles tradicionales de dirección, como el alcance del producto, el coste, el personal, y la gestión del riesgo son todavía responsabilidad del director del proyecto.
Sorpresa: ¡Las Organizaciones Ágiles están Jerarquizadas!
Una de las ideas equivocadas sobre las organizaciones Ágiles es que no son jerárquicas. Nada podría ser menos verídico. Los más altos directos todavía definen la dirección y el tono del resto de la organización y las personas todavía son despedidas si no hacen su trabajo. La búsqueda del mayor rendimiento es aún más implacable que en las organizaciones tradicionales y burocráticas. En una burocracia, el personal que no rinda a su máximo potencial puede esconderse en los recovecos del sistema. Pero en una organización ágil, hay una trasparencia radical que hace a todos los compañeros responsables de sus acciones.

La jerarquía en una organización ágil es muy diferente de la existente en una burocrática. La jerarquía ágil está basada en la competencia, no en la autoridad. El rendimiento no está basado en complacer al jefe, sino en añadir valor al consumidor. La organización utiliza una comunicación horizontal y vertical, que es muy interactiva. Las ideas pueden venir de cualquier persona, incluyendo al cliente. Es una red que crece continuamente, aprendiendo y adaptándose al constante flujo; añade nuevo valor a los consumidores al explotar las oportunidades que se presentan. Si se hace de manera correcta, la continua entrega de valor a los clientes con menos trabajo resultará en un aumento de los beneficios de la organización.

El método ágil distingue claramente las diferencias entre la explotación y la exploración. En una organización ágil, todos los miembros están explorando continuamente formas de añadir más valor al consumidor.

Durante los primeros años del Método Ágil de Gestión, los críticos pensaban que equipos pequeños nunca podrían manejar grandes y complejos problemas. Pero estaban equivocados. Todos los equipos son parte de una red que está basada en las conversaciones entre todos los grupos que buscan objetivos comunes. Los ritmos constantes y comunes de estos grupos dan lugar a una sólida plataforma que permite a los equipos pequeños enfrentarse a problemas complejos. Esto es, de largo, un sistema mucho mejor que el burocrático.

Proceso Ágil

El proceso ágil divide un proyecto de software en pequeñas partes, que pueden ser desarrolladas en incrementos o iteraciones. Varios estudios han probado que hay una correlación negativa entre el tamaño del proyecto y el éxito del mismo (en otras palabras: cuanto más pequeño el proyecto, más alta la probabilidad de tener éxito)

El método ágil reduce el tamaño del proyecto, creando muchos proyectos pequeños. Este método iterativo distingue al método Ágil de los demás.

A diferencia de otros métodos, el método Ágil utiliza iteraciones durante la planificación y las fases de desarrollo. Cada iteración dura, por norma general, una semana. Durante estas sesiones, el equipo del proyecto y el equipo de clientes colaboran para priorizar las necesidades que se añadirán a la iteración. El resultado final es un programa de software que se entrega rápidamente al cliente. Los clientes pueden probar su programa y hacer cambios si son necesarios. Se realizan muchos lanzamientos durante el proceso, a la par que se hacen algunos cambios al programa. El proceso iterativo se repite hasta que el proyecto está finalizado.

Dirección general y Ágil

La programación de software es un componente esencial de casi cualquier empresa hoy en día. Esto significa que el método Ágil es fundamental para cualquier tipo de organización y forma de trabajo.

Las metodologías Ágiles que incorporan nuevos valores, prácticas, principios y beneficios son una mejor alternativa ante el estilo tradicional de mando y control en la gestión de proyectos. El método Ágil se está extendiendo incluso a otras industrias y funciones, incluyendo los C-Suites.

Sin embargo, aunque muchas empresas están optando por algunos procesos Ágiles, todavía trabajan bajo un método burocrático en su base. En la economía de hoy día, donde domina lo digital, es vital para las compañías desarrollar prácticas de gestión ágil. Pero muchas compañías todavía tienen problemas con esta transición y siguen operando bajo la cultura del mando. Esto se refleja en la mentalidad y las habilidades de la dirección y es el mayor obstáculo al que se enfrentan las empresas hoy en día.

Prácticas Ágiles

Hay muchas prácticas ágiles diferentes; muchas no son utilizadas por profesionales ágiles. Aquellos que quieran realizar la transición al modelo ágil, deberán comprender las diferentes prácticas para saber cómo aplicarlas en su entorno. Los siguientes ejemplos ilustran cómo se pueden aplicar las prácticas Ágiles.
Reuniones diarias (Stand-Up Meetings)
A las reuniones diarias también se las conoce como reuniones diarias de Scrum. Estas sesiones de Scrum se llevan a cabo cada día y en ellas participa todo el equipo, de manera que puedan compartir información importante entre ellos. Estas reuniones tienen como objetivo mantener a todos los miembros del equipo informados y actualizados sobre el estado del proyecto. La clave de estas reuniones es la brevedad.

Durante las reuniones diarias de scrum, cada miembro del equipo debería responder a tres cuestiones:
Historias de usuario
Una historia de usuario es una breve descripción de la función que requiere el usuario. Contiene tres elementos, que son:

1. Una descripción escrita, planificando la historia (normalmente escrita en una tarjeta)

2. Una conversación sobre la historia, para entenderla mejor

3. Una serie de criterios de aceptación para confirmar la historia.

Las historias están escritas desde la perspectiva del usuario final y usa un lenguaje que el usuario pueda entender. Las historias actúan como una moneda entre los desarrolladores y los clientes; ambas partes se entienden perfectamente. Puedes leer más acerca de las 4 razones por las que no se "finalizan" Historias de Usuario.
Pruebas Automatizadas
Implementar un riguroso y formal sistema de pruebas automatizadas es vital en el proceso ágil. Las pruebas encuentran y eliminan defectos del código para asegurar que se entrega al cliente un software funcional. Los desarrolladores pueden crear el código de las pruebas bajo una red de seguridad usando una variedad de los frameworks disponibles mientras que desarrollan el código del software. Este método protege otras funciones mientras se realizan cambios en el software. Es además una manera más rápida y eficiente de encontrar errores en el programa.
Builds Automatizadas
Un principio fundamental en las metodologías Ágiles es poseer un software funcional en todo momento. En la práctica, la única manera de hacer esto es asegurando que todo el desarrollo de software se compila, lanza y testea regular y automáticamente. Esto se realiza normalmente muchas veces al día y al menos una vez cada vez que un desarrollador "ingresa" código como parte de la rama principal de desarrollo.
Planificación Ágil: Release, Iteraciones y Tareas
to be done. Encontramos tres niveles en la planificación Ágil del desarrollo: release, iteration y task. En las primeras etapas del desarrollo, los desarrolladores y clientes se reúnen para discutir las historias de usuario que se necesitan para el software. Esta reunión inicial se centra en las funciones que deben aparecer, de manera que se pueda estimar y priorizar todo lo que se necesita hacer.

La planificación de la Release (lanzamiento, en español) es una sesión de planificación dirigida al cliente. Tanto los clientes como los desarrolladores eligen un día para el primer lanzamiento del producto. Colaboran en decidir qué historias incorporar en cada release. Los desarrolladores se centran en los esfuerzos estimados de cada historia, mientras que los clientes se centran en la selección de historias. Hay varias formas de estimar esfuerzos, que están determinados por las necesidades y deseos del cliente y los equipos de desarrollo.

La planificación de Iteraciones requiere esfuerzos conjuntos entre los clientes y los desarrolladores para impulsar parte del plan de release. Durante las iteraciones, el cliente define y prioriza las historias de usuario, mientras que los desarrolladores estiman cuánto esfuerzo es necesario para desarrollar cada historia de usuario. La línea de tiempo es mucho menor en las iteraciones, durando solo semanas, en lugar de meses.

La planificación de Tareas ocurre tras la planificación de la iteración. Las historias se dividen en una serie de pasos realizables por el equipo de desarrollo. Se hacen las listas de tareas y se publican en la sala de proyecto de manera que todos los miembros del equipo puedan verlas. Las herramientas que se utilizan comúnmente en este proceso son los post-it y las pizarras. Cada desarrollador elige voluntariamente una tarea y asigna un tiempo estimado para realizarla.
Pair Programming
Gracias al pair programming, dos desarrolladores trabajan como un equipo en una tarea. Una persona es la Conductora, la persona que ingresa el código, mientras que la segunda persona es la navegadora, la que planea los siguientes pasos mientras que adecúa el código al conjunto.

Una de las quejas más comunes sobre el pair programming es que se malgastan recursos humanos para realizar la tarea. No se debería utilizar dos personas para un trabajo que puede hacer una sola. Aun así, aunque la programación gasta más energía humana, el resultado final justifica el coste. Un estudio reciente afirma que el pair programming utiliza un 15% más de esfuerzo humano, pero da lugar a un 15% menos de defectos. Aunque los resultados pueden variar en cada caso, los desarrolladores suelen afirmar que la reducción de errores hace que los recursos extra utilizados merezcan la pena.

Otro beneficio es que (emparejamiento, en español) no se requiere a tiempo completo. Los equipos pueden establecer sus propias reglas y horario al decidir si es mejor hacer parejas.
Integración Continua
Durante la integración continua, los equipos de desarrollo integran su código en el sistema varias veces al día. Se realizan una serie de pruebas antes de ingresar el código para asegurarse de que no dañará otras funciones del sistema. El desarrollador debe ejecutar primero todas las pruebas del sistema y solucionar cualquier error que surja antes de integrar los demás códigos. Cuanto más a menudo se integra un código en el software, más fácil y rápido es detectar errores.
Retrospectivas
Las Retrospectivas son reuniones que se llevan a cabo al final de cada proyecto o cerca de él. Dan a todos los equipos envueltos en el proyecto la oportunidad de echar la vista atrás y reflexionar sobre el trabajo hecho durante el proceso. Todo el equipo puede ver qué funciono bien, qué no, qué se puede mejorar y, más importante, cómo pueden convertir las lecciones adquiridas en cambios sustanciales.

Conclusión

La gestión Ágil es un fascinante y excitante método de desarrollo de software. Al integrar los desarrolladores del producto y los clientes en los procesos de planificación e implementación, el resultado es una experiencia más gratificante para todo el mundo.

Cuando la programación Ágil se realiza correctamente, las organizaciones pueden encontrar continuamente caminos para incrementar el valor para sus clientes. Da más significado a aquellos que están trabajando en el proyecto y crea una experiencia más positiva para el cliente, produciendo beneficios mayores para la compañía.

# data[].attributes.attachment_link.description
Me suelen hacer esta pregunta: ¿Qué es la metodología ágil? Ágil es una palabra que se usa en la industria de la tecnología de la información para describir un método alternativo de gestión de proyectos. Se me suele preguntar la siguiente cuestión: ¿Qué es la metodología ágil?

# data[].attributes.body
Diseñe e implemente la clase CsPar, con la  siguiente pauta.

template <class G0, class G1>
class CsPar {
public:
//   Funciones asociadas
G0 PrimeroG0;
G1 SegundoG1;
};

Para ello, diseñe e implemente todo comportamiento de la clase pair   que se exhibe, con ejemplos,  en el siguiente enlace.

# data[].attributes.attachment_link.readable_text
The pair container is a simple container defined in <utility> header consisting of two data elements or objects.

The first element is referenced as 'first' and the second element as 'second' and the order is fixed (first, second).

Pair is used to combine together two values which may be different in type. Pair provides a way to store two heterogeneous objects as a single unit.

Pair can be assigned, copied and compared. The array of objects allocated in a map or hash_map are of type 'pair' by default in which all the 'first' elements are unique keys associated with their 'second' value objects.

To access the elements, we use variable name followed by dot operator followed by the keyword first or second.

Syntax :
 pair (data_type1, data_type2) Pair_name;

Output:

100 G

Initializing a pair
We can also initialize a pair.
Syntax :

pair (data_type1, data_type2) Pair_name (value1, value2) ;

Different ways to initialize pair:

pair  g1;         //default
pair  g2(1, 'a');  //initialized,  different data type
pair  g3(1, 10);   //initialized,  same data type
pair  g4(g3);    //copy of g3

Another way to initialize a pair is by using the make_pair() function.

g2 = make_pair(1, 'a');

Output:

GeeksForGeeks 1.23

Note: If not initialized, the first value of the pair gets automatically initialized.

Output:

00

Member Functions
Output:

This is pair g1 with value Geeks.

This is pair g3 with value QuizThis pair was initialized as a copy of pair g2

This is pair g2 with value .com
The values of this pair were changed after initialization.

This is pair g4 with values 5 and 10 made for showing addition.
The sum of the values in this pair is 15.

We can concatenate the values of the pairs g1, g2 and g3 : GeeksQuiz.com

We can also swap pairs (but type of pairs should be same) :
Before swapping, g1 has Geeks and g2 has .com
After swapping, g1 has .com and g2 has Geeks

This article is contributed by MAZHAR IMAM KHAN. If you like GeeksforGeeks and would like to contribute, you can also write an article using contribute.geeksforgeeks.org or mail your article to contribute@geeksforgeeks.org. See your article appearing on the GeeksforGeeks main page and help other Geeks.

Please write comments if you find anything incorrect, or you want to share more information about the topic discussed above.

Article Tags :

Please write to us at contribute@geeksforgeeks.org to report any issue with the above content.

# data[].attributes.attachment_link.title
Pair in C++ Standard Template Library (STL) - GeeksforGeeks

# data[].attributes.attachment_link.description
The pair container is a simple container defined in header consisting of two data elements or objects. The first element is referenced as 'first' and the second element as 'second' and the order is fixed (first, second). Pair is used to combine together two values which may be different in type.