Está en la página 1de 9

Universidad de las Fuerzas Armadas ESPE

Departamento de Ciencias de la Computación


Ingeniería en Software
Fundamentos de la Ingeniería en Software

_______________________________________________________________________________________________________

TAREA 2
_______________________________________________________________________

Integrante 1: Marco Esparza

Integrante 2: David Morillo

Integrante 3: Juan Pasquel

Puntaje: __ ptos. Fecha Entrega: 05 ENE 2023

Tiempo máximo 23H59 Lugar: MICAMPUS


de Entrega:

Docente: Ing. Mónica Gómez NRC: 7992


S. MsC

1. SCRUM

¿Qué es?

Scrum es un marco de trabajo para el desarrollo de proyectos de software y otros


productos complejos. Es una forma de llevar a cabo proyectos de manera ágil, lo
que significa que se enfoca en la entrega rápida de valor y la adaptabilidad al
cambio.

Scrum se basa en un conjunto de principios y valores que promueven la


colaboración y la transparencia. También incluye un conjunto de roles, ceremonias y
artefactos que se utilizan para guiar el proceso de desarrollo. Algunos de estos
elementos son:

● Roles: En Scrum, hay tres roles clave: el equipo de desarrollo, el Scrum


Master y el Product Owner. El equipo de desarrollo es responsable de
desarrollar el producto, el Scrum Master es el facilitador y el Product Owner
es el encargado de definir y priorizar el trabajo.
● Ceremonias: Scrum incluye varias ceremonias o reuniones que se llevan a
cabo regularmente durante el ciclo de vida del proyecto. Algunas de estas
ceremonias son la reunión diaria (Daily Scrum), la revisión (Review) y la
planificación (Planning).
● Artefactos: Scrum también incluye varios artefactos que se utilizan para
documentar y seguir el progreso del proyecto. Algunos de estos artefactos
son el producto Backlog, que es una lista de tareas pendientes, y el Sprint
Backlog, que es una lista de tareas seleccionadas para ser completadas
durante el próximo Sprint.

En resumen, Scrum es un marco de trabajo que se utiliza para llevar a cabo


proyectos de manera ágil, colaborativa y transparente. Se basa en principios y
valores que promueven la entrega rápida de valor y la adaptabilidad al cambio, y
utiliza roles, ceremonias y artefactos para guiar el proceso de desarrollo.

Aquí hay algunas ideas adicionales sobre Scrum:

● El objetivo de Scrum es entregar valor al cliente de manera rápida y continua.


Para hacer esto, el equipo debe enfocarse en completar tareas pequeñas y
concretas en cada Sprint, en lugar de tratar de completar todo el proyecto de
una vez.
● Scrum promueve la colaboración y la transparencia. El equipo debe trabajar
juntos y compartir su progreso y obstáculos regularmente, y el Product Owner
debe ser claro en cuanto a lo que se espera que se entregue.
● Scrum también promueve la adaptabilidad al cambio. Si surgen cambios en
las necesidades del cliente o en el entorno del proyecto, el equipo puede
hacer ajustes en el próximo Sprint.
● Los roles en Scrum son esenciales para que el proceso funcione
correctamente. El equipo de desarrollo es responsable de desarrollar el
producto, el Scrum Master es el facilitador y el Product Owner es el
encargado de definir y priorizar el trabajo.

Fases

En Scrum, el proceso de desarrollo se divide en ciclos o sprints, que suelen durar


entre una y cuatro semanas. Cada Sprint consta de las siguientes fases:

1. Planeación (Planning): En esta fase, el equipo se reúne con el Product Owner


para definir el trabajo que se llevará a cabo durante el próximo Sprint. Se
priorizan las tareas y se seleccionan las que entran en el Sprint Backlog.
2. Desarrollo: Durante el desarrollo, el equipo trabaja en las tareas
seleccionadas y las completa de acuerdo con los criterios de aceptación
acordados. El equipo también se reúne diariamente en una reunión corta
llamada Daily Scrum para compartir el progreso e identificar obstáculos.
3. Revisión (Review): Al final del Sprint, el equipo se reúne con el Product
Owner para revisar el trabajo completado y demostrar el valor entregado. Se
discute qué funcionó bien y qué se puede mejorar en el siguiente Sprint.
4. Retrospectiva: Después de la revisión, el equipo se reúne para reflexionar
sobre el Sprint y discutir qué se puede hacer para mejorar el proceso en el
futuro.

Estas son las fases principales de Scrum, aunque es importante tener en cuenta
que el proceso puede adaptarse a las necesidades específicas de cada proyecto.
Además, el equipo puede hacer ajustes en cualquier momento durante el Sprint si
es necesario.

Roles

Un equipo Scrum suele estar compuesto por grupos de trabajo entre 3 a 9 miembros
del equipo de desarrollo, más el Scrum Master y el Product Owner. Cada uno de
estos roles tiene diferentes responsabilidades y debe rendir cuentas de distinta
manera, tanto entre ellos como para el resto de la organización. la suma de todos
los roles es lo que llamamos equipo Scrum.

● Product Owner: El Product Owner es el encargado de optimizar y maximizar


el valor del producto, siendo la persona encargada de gestionar el flujo de
valor del producto a través del Product Backlog. Adicionalmente, es
fundamental su labor como interlocutor con los stakeholders y sponsors del
proyecto, así como su faceta de altavoz de las peticiones y requerimientos de
los clientes. Si el Product Owner también juega el rol de representante de
negocios, su trabajo también aportará valor al producto.
● Scrum Master: el Scrum Master tiene 2 funciones principales dentro del
marco del trabajo: gestionar el proceso scrum y ayudar a eliminar
emprendimientos que puedan afectar a la entrega del producto. Además, se
encarga de las labores de mentoring y formación, coaching y de facilitar
reuniones y eventos si es necesario.
1. Gestionar el proceso Scrum: el Scrum Master se encargará
de gestionar y asegurar que el proceso scrum se lleve a cabo
correctamente, así como de facilitar la ejecución del proceso y
sus mecánicas.
2. Eliminar impedimentos: esta función del Scrum Master indica
la necesidad de ayudar a eliminar progresiva y constantemente
impedimentos que van surgiendo en la organización y que
afectan a su capacidad para entregar valor, así como a la
integridad de esta metodología.
● El equipo de desarrollo: el equipo de desarrollo suele estar formado por
entre 3 a 9 profesionales que se encargan de desarrollar el producto, auto
organizándose y autogestionado se para conseguir entregar un incremento
de software al final del ciclo de desarrollo. El equipo de desarrollo se
encargará de crear un incremento terminado a partir de los elementos del
Product Backlog seleccionados (Sprint Backlog) durante el Sprint Planning.
Artefactos

¿Qué son los artefactos de Scrum?

Los artefactos de scrum son información que un equipo de scrum y las partes
interesadas utilizan para detallar el producto en desarrollo, las acciones para
producirlo y las tareas realizadas durante el proyecto. Estos artefactos ofrecen
metadatos que dan una idea del rendimiento de un sprint.

Los principales artefactos de Scrum son:

● Product backlog: El backlog del producto es una lista de nuevas funciones,


mejoras, correcciones de errores, tareas o requisitos de trabajo necesarios
para crear un producto. Se obtiene a partir de fuentes como la atención al
cliente, los análisis de la competencia, las demandas del mercado y los
análisis empresariales en general, (HARRIS, s.f.)
● Sprint planning: En Scrum, cada proyecto se divide en bloques de tiempo
llamados sprints, generalmente de dos a cuatro semanas de duración. Una
reunión de planificación de sprint es cuando el equipo (incluido Scrum Master,
Scrum Product Manager y Scrum Team) se reúne para determinar qué
elementos del backlog se manejan en el próximo sprint. La ceremonia Scrum
de planificación de sprints es un proceso colaborativo que permite a los
miembros del equipo opinar cuando se lleva a cabo el trabajo. (Equipo de
comunicaciones de Adobe, 2022)
● Sprint backlog: El Sprint Backlog es la suma de el Objetivo del Sprint, los
elementos del Product Backlog elegidos para el Sprint, más un plan de acción
de cómo crear el Incremento de Producto. se construye durante el evento del
Sprint Planning. Es un plan realizado por y para los Developers. El equipo
generalmente divide el trabajo en elementos llamados Sprint Backlog Ítems
(SBI). Estos elementos pueden representar tareas que el equipo debe
completar, bloques de construcción intermedios que se combinan en una
entrega, o cualquier otra unidad de trabajo que ayude al equipo a comprender
cómo lograr el Sprint Goal dentro del Sprint. (Garcia, 2020)
● Sprint: En inglés la palabra Sprint se refiere a una carrera a máxima
velocidad para alcanzar una meta. En Scrum se trata de un pequeño bloque
de tiempo, de cuatro semanas o menos, durante el cual se crea un
incremento de producto “terminado”, utilizable y potencialmente entregable.
Para explicar de manera más simple, el Sprint es un contenedor de los
demás eventos y actividades de Scrum. Un
Sprint no busca velocidad, sino que se enfoca en el trabajo colaborativo y
conectado durante un período de tiempo acotado.
2. DevOps

¿Qué es?

DevOps es una práctica de desarrollo de software que busca mejorar la eficiencia y


la velocidad de entrega de los proyectos de software. Se basa en la idea de que el
desarrollo y la operación de software deben ser tratados como un proceso continuo
y sin interrupciones, en lugar de como dos fases separadas.

Una de las principales ventajas de DevOps es que permite a los equipos de


desarrollo y operaciones trabajar juntos de manera más efectiva. Esto se logra a
través de la automatización de tareas y el uso de herramientas y procesos comunes.
Al hacer que el proceso de desarrollo y operación sea más fluido, DevOps permite a
los equipos entregar software de manera más rápida y con mayor calidad.

Algunos de los elementos clave de DevOps son:

● Automatización: La automatización es una parte esencial de DevOps. Se


utilizan herramientas para automatizar tareas como el despliegue de código y
la monitorización de sistemas. Esto permite a los equipos entregar software
de manera más rápida y consistente.
● Colaboración: DevOps promueve la colaboración entre los equipos de
desarrollo y operaciones. Esto se logra a través de la utilización de prácticas
ágiles y la adopción de una cultura de trabajo colaborativa.
● Integración continua: La integración continua es un proceso que permite a los
equipos integrar código de manera frecuente y detectar problemas de manera
temprana. Esto permite a los equipos entregar software de manera más
rápida y con mayor calidad.
● Monitorización: La monitorización es una parte importante de DevOps. Se
utilizan herramientas para monitorear el rendimiento y la disponibilidad de los
sistemas y detectar problemas de manera temprana.

En resumen, DevOps es una práctica de desarrollo de software que busca mejorar


la eficiencia y la velocidad de entrega de los proyectos de software. Se basa en la
automatización, la colaboración, la integración continua y la monitorización para
lograr esto. Esto permite a los equipos entregar software de manera más rápida y
con mayor calidad.

Algunas de las ventajas de utilizar DevOps son:

● Mayor velocidad de entrega: DevOps permite a los equipos entregar software


de manera más rápida gracias a la automatización y la integración continua.
● Mayor calidad: DevOps promueve la detección temprana de problemas y la
resolución rápida de ellos, lo que ayuda a mejorar la calidad del software.
● Mayor eficiencia: DevOps permite a los equipos trabajar de manera más
eficiente gracias a la automatización y la colaboración.
● Mayor escalabilidad: DevOps permite a los equipos ajustar rápidamente su
proceso de desarrollo y operación para adaptarse a cambios en las
necesidades del negocio.
● Mayor satisfacción del cliente: DevOps permite a los equipos entregar
software de manera más rápida y con mayor calidad, lo que puede mejorar la
satisfacción del cliente.
● Mayor flexibilidad: DevOps permite a los equipos adaptarse rápidamente a
cambios en las necesidades del negocio y en el entorno del proyecto.

DevOps es una práctica de desarrollo de software que permite a los equipos


entregar software de manera más rápida y con mayor calidad. Se basa en la
automatización, la colaboración, la integración continua y la monitorización para
lograr esto. Las ventajas de utilizar DevOps incluyen mayor velocidad de entrega,
mayor calidad, mayor eficiencia, mayor escalabilidad, mayor satisfacción del cliente
y mayor flexibilidad. DevOps es una práctica clave para cualquier empresa que
quiera mejorar su proceso de desarrollo y entrega de software.

Fases

Aunque cada equipo puede implementar DevOps de manera ligeramente diferente,


en general, hay algunas fases clave que se suelen seguir:

1. Planificación: En esta fase, el equipo define los objetivos y alcance del


proyecto y establece un plan para alcanzar esos objetivos. También se
definen los roles y responsabilidades del equipo y se seleccionan las
herramientas y procesos necesarios.
2. Desarrollo: Durante la fase de desarrollo, el equipo trabaja en el código y
completa las tareas necesarias para alcanzar los objetivos del proyecto. Se
utilizan prácticas ágiles y se hace un seguimiento del progreso del proyecto
de manera regular.
3. Integración y despliegue: En esta fase, el equipo integra el código y lo
despliega a un ambiente de pruebas. Se realizan pruebas automatizadas y se
hace un seguimiento de los problemas para resolverlos de manera rápida.
4. Operación: Una vez que el software ha sido desplegado a un ambiente de
pruebas y ha pasado las pruebas necesarias, se despliega a producción. En
esta fase, el equipo se encarga de la monitorización y el mantenimiento del
software en producción. También se hacen mejoras y ajustes continuos para
asegurar que el software cumple con las necesidades del negocio.
5. Retrospectiva: Al final de cada proyecto o ciclo de vida, el equipo se reúne
para reflexionar sobre lo que funcionó bien y lo que se puede mejorar en el
futuro. Esto ayuda a mejorar continuamente el proceso de DevOps.

En resumen, las fases de DevOps incluyen planificación, desarrollo, integración y


despliegue, operación y retrospectiva. Cada equipo puede adaptar estas fases a sus
necesidades específicas y hacer ajustes en cualquier momento si es necesario.
Roles

En un entorno de DevOps, estos cuatro roles funcionan de manera coherente para


crear un entorno colaborativo y eficiente con responsabilidad compartida de cada
producto a través del desarrollo, la implementación y la supervisión. La creación de
un equipo DevOps puede ayudar a mejorar en gran medida la calidad de los
productos y las aplicaciones y, al mismo tiempo, llevarlos al mercado más rápido.
Esto conduce a resultados positivos para el cliente ya un proceso de desarrollo y
entrega de software más colaborativo.

● Evangelista DevOps: Solo el nombre del puesto resulta curioso. Pues bien,
las funciones que ejerce, también lo son. Un Evangelista DevOps es el
encargado de promocionar y desarrollar prácticas DevOps en el
departamento de IT adaptando y creando estrategias DevOps de procesos
manuales que podrían automatizarse.

Aunque en ocasiones no se le da toda la importancia que merece, se trata de


una de las funciones principales, especialmente si es el DevOps Engineer el
encargado de poner en marcha esta metodología en la compañía. Como ya
comentamos en el anterior artículo, efectuar la transición hacia una cultura
DevOps en un departamento de informática, puede provocar confusión en las
primeras fases. Sin embargo, será responsabilidad directa del ingeniero
DevOps efectuarla, más allá de su departamento, en toda la organización.

● Experto en Automatización: Será el encargado de poner en marcha las


estrategias previamente establecidas por el evangelista DevOps. Muchas
empresas unen ambos perfiles en uno, sin embargo, resulta mucho más
beneficioso que ambos puestos sean independientes y estén bien definidos:
por un lado, el evangelista DevOps y por el otro el experto de Automatización.
Y es que la carga de trabajo es enorme.
● DevOps Engineer QA (Quality Assurance): En este caso, ha llegado la
hora de hacer realidad lo que hasta el momento era solo una estrategia sobre
“papel”. El DevOps Engineer QA (Quality Assuance) es responsable de la
automatización de las pruebas y el mantenimiento de calidad del código, algo
completamente imprescindible en cualquier empresa, especialmente si la
automatización ya está implantada en la organización como parte de su
cultura.
● Ingeniero de seguridad DevOps: Este perfil profesional también cuenta con
un plus de adrenalina ya que, se encarga de realizar el despliegue masivo de
software especializado en seguridad bajo los estándares de seguridad
internacionales como ISO 27001.
Configurar los procesos de forma masiva en miles de máquinas al mismo
tiempo, con el diseño y la implementación de aplicaciones a través del código
como infraestructura.

Artefactos

Desarrollo continuo. Esta práctica abarca las fases de planificación y codificación del
ciclo de DevOps. Puede incluir también mecanismos de control de versiones.

● Realización de pruebas continuas. Esta práctica incorpora continuas


pruebas de código automatizadas y programadas con antelación que se
realizan a medida que el código de aplicación se está creando o
actualizando. Gracias a estas pruebas, el código pasa antes a la fase de
producción.
● Integración continua (CI). En esta práctica se combinan herramientas de
gestión de configuración (CM) con otras herramientas de pruebas y desarrollo
para saber qué cantidad del código que se está creando está listo para pasar
a producción. Para ello, debe existir un intercambio fluido de información
entre las fases de prueba y de desarrollo que permita identificar y resolver
con rapidez problemas en el código.
● Entrega continua. Esta práctica automatiza la introducción de cambios en el
código para pasar a un entorno de preproducción o de almacenamiento
provisional tras la fase de pruebas. Un miembro de la plantilla podría
entonces decidir si es conveniente promover estos cambios de código a la
fase de producción.
● Puesta en marcha continua (CD). Al igual que sucede con la entrega
continua, esta práctica automatiza el lanzamiento de código nuevo o
modificado a la fase de producción. Una empresa que pone en práctica la
puesta en marcha continua podría publicar cambios en código o funciones
varias veces al día. Las tecnologías de contenedor, como Docker y
Kubernetes, hacen posible esta fase de puesta en marcha continua al ayudar
a mantener la coherencia del código entre los diferentes entornos y
plataformas de puesta en marcha.
● Supervisión continua. Esta práctica implica la supervisión continua del
código en la fase de producción y la infraestructura subyacente que la
sustenta. A través de un bucle de retroalimentación en el que se notifican
errores o problemas, este podría volver a la fase de desarrollo.
● Infraestructura como código. Esta práctica se puede utilizar durante varias
fases de DevOps para automatizar el aprovisionamiento de la infraestructura
que se necesita para publicar el software. Los desarrolladores añaden
«código» de infraestructura procedente de las herramientas de desarrollo
actuales. Por ejemplo, los desarrolladores podrían crear un volumen de
almacenamiento bajo demanda desde Docker, Kubernetes u OpenShift.
Gracias a esta práctica, los equipos de operaciones también pueden
supervisar las configuraciones de entorno, registrar los cambios y simplificar
la reversión de las configuraciones.

Bibliografía

Deloitte . (s.f.). Obtenido de


https://www2.deloitte.com/es/es/pages/technology/articles/roles-y-resp
onsabilidades-scrum.html

TheBridge. (20 de Julio de 2022). Obtenido de


https://www.thebridge.tech/blog/roles-devops-que-debes-conocer

PagerDuty. (s.f.). Obtenido de


https://www.pagerduty.com/resources/learn/essential-devops-roles/

También podría gustarte