Practico # 2

SCRUM y Modelo C4

1. ¿Qué es SCRUM?
Es una metodología ágil para el desarrollo y mantenimiento de productos complejos de
software.
Este marco de trabajo se realizan varios procesos para un fin especifico mediante roles,
evento y artefactos.
a) El qué y el quién: Esto se basa en el que se desea implementar en el desarrollo del
producto (objetivos que se desean realizar en el proyecto) y a quien va (rubro) el
producto que se va a realizar.
b) El dónde y el cuándo: Se basa en dónde será realizada las reuniones de acuerdo a
lo que el SCRUM requiere (sprint planning, daily SCRUM) y la planificación del
cuándo estará realizado el proyecto para su funcionamiento.
c) El por qué y el Cómo: se trata del por qué se desea realiza dicho producto y cómo
se conseguirá completar el trabajo seleccionado.
d) Planeación del Sprint/Sprint Planning: El sprint es el corazón de SCRUM es el
bloque en el cual en un tiempo de aproximadamente un mes o menos se realizas
una parte del producto (incremento). Para ello se realiza el sprint planinng en el
cual se traza objetivos y se cuestionar preguntas como el como se realizará el
incremento, como también que funcionalidades se realizaran del producto
backlog.
2. Reunión del equipo SCRUM/SCRUM TEAM MEETING.
las reuniones que realiza el equipo Scrum son las siguientes:
Sprint planinng: Es la primera reunión que realiza el equipo Scrum para poder trazar
objetivos, seleccionar funcionalidades, responder preguntas como el “que” y el “como”
para conseguir los objetivos esperados en el sprint. La duración de esta reunión es de
aproximadamente 8hrs y la realiza el Scrum Master junto con el Product Owner y el
equipo de desarrollo.
Daily Scrum: en esta reunión se desarrolla con el equipo de desarrollo para que esta
verifique actividades pasadas y sincronice las actuales con preguntas como:
¿Qué hice ayer que ayudo al equipo…?
¿Qué hare hoy que ayude al equipo…?
¿Qué impedimentos existen para no poder realizar dichas actividades?
La reunión es diaria y tiene una duración de 15 minutos a lo máximo. Es realizada por el
Scrum Master para poder ayudar a aclarar dudas del equipo de desarrollo.
Practico # 2

Sprint Review: Esta reunión se realiza para poder visualizar el artefacto realizado en el
Sprint anterior. En ella se reúnen todo el equipo Scrum como también personas externas.
Esta tiene un tiempo de 3 horas y lo organiza el Scrum Master. En ella se inspecciona el
artefacto y se crea un plan para implementar mejoras.
Sprint Retrospective: En este evento se realiza una reunión de 3 horas en el cual se realiza
las mejorar pertinentes al incremento el cual se desea realizar las mejoras
correspondientes. Esta reunión solo se realiza entre el Scrum Master y el grupo de
desarrollo, donde el Scrum Master anima al equipo a poder realizar dichas mejoras al
incremento.
3. Refinamiento del Product/Backlog.
Es la realización de añadir detalles, estimaciones y orden a los elementos de las lista del
producto backlog. Es un proceso continuo en el cual se realiza entre el dueño del producto
y el equipo de desarrollo. En si le quita un 10% d capacidad al equipo pero aun así ellos
deciden como y cuando hacerlo.
4. Revisión del Sprint Review.
Es un evento que se realiza luego de la realización del Sprint. Esta reunión se realiza para
poder visualizar el artefacto realizado en el Sprint anterior. En ella se reúnen todo el
equipo Scrum como también personas externas. Esta tiene un tiempo de 3 horas y lo
organiza el Scrum Master. En ella se inspecciona el artefacto y se crea un plan para
implementar mejoras.
5. Retrospectiva del Sprint.
En este evento se realiza una reunión de 3 horas en el cual se realiza las mejorar
pertinentes al incremento el cual se desea realizar las mejoras correspondientes. Esta
reunión solo se realiza entre el Scrum Master y el grupo de desarrollo, donde el Scrum
Master anima al equipo a poder realizar dichas mejoras al incremento.
6. Herramientas Scrum del Por Qué y Cómo.
a) Backlog de producto: es la lista de parte del dueño del producto en la cual se
encuentran todas las funcionalidades, características, requisitos para la realización
del proyecto de desarrollo de software.
b) Historia de usuario: Es un elemento básico para aplicar en Scrum. Así el rol que
escojamos que va a utilizar la aplicación de software, requiere de una acción que
ocurra, porque desea cubrir una funcionalidad: corto, conciso, directo y claro.
(como-quiero-para).
c) Backlog del Sprint: al momento de realizar el backlog principal el equipo de
desarrollo realiza el bakclog del sprint donde se almacena las funciones
seleccionadas del backlog principal. Estas son principalmente las primeras
funcionalidades de la lista backlog.
Practico # 2

d) El panel de tareas: Es el tablero que mantenemos en Scrum como soporte virtual,

para que en cualquier momento de Sprint se localice la información de la situación.
Esta se elabora en cada Sprint Planinng, para definir todo lo que se va a realizar en
el Sprint, a la hora que se negocie con el dueño del producto la cantidad de
historias de usuario allí se visualiza como esta se va completando.
e) BurnDown/Up: Es un grafico de 2 ejes (x,y) comúnmente utilizado en se llevan los
registros de los puntos de estimación de las tareas que se deben desarrollar en
todas las historias de los usuarios a los que se han comprometido.
7. Definición de “Listo”- “Done”.
Cuando una lista de producto o un incremento se encuentra ya “terminado” va a que ese
producto sea entendible para todo el equipo Scrum, demostrando que el elemento sea
completamente claro para todos los miembros. La definición de “terminado” se utiliza
para evaluar cuando se ha completado el trabajo sobre el incremento del producto.
Se selecciona las funcionalidades de la lista del backlog para la realización del Sprint el cual
debe ser completamente funcional y adaptativa al incremento general. Para ello, se realiza
una revisión exhaustiva de dicho incremento. Si esta cumple con todos los estudios, se
encuentra listo para su uso.
8. Los 12 principios de Scrum.
Principio 1: Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana
y continuada de software con valor
Principio 2: Aceptamos que los requisitos cambien, incluso en etapas tardías del
desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja
competitiva al cliente.
Principio 3: Entregamos software funcional frecuentemente, entre dos semanas y dos
meses, con preferencia por periodos de tiempo lo más corto posibles.
Principio 4: Los responsables de negocio y los desarrolladores trabajamos juntos de forma
cotidiana durante todo el proyecto
Principio 5: Los proyectos se desarrollan en torno a individuos motivados. Hay que darles
el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
Principio 6: El método más eficiente y efectivo de comunicar información al equipo de
desarrollo y entre sus miembros es la conversación cara a cara
Principio 7: El software funcionando es la principal medida progreso
Principio 8: Los procesos Ágiles promueven el desarrollo sostenible. Los promotores,
desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de
forma indefinida.
Practico # 2

Principio 9: La atención continua a la excelencia técnica y al buen diseño mejora la

Agilidad
Principio 10: La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es
esencial.
Principio 11: Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-
organizados.
Principio 12: A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para
a continuación ajustar y perfeccionar su comportamiento en consecuencia.
9. ¿Qué hace un Scrum Master?
El Scrum Master tiene la responsabilidad de que el proyecto se entienda y se adapte
ayudando a que el equipo se adapte y trabaje de acuerdo a lo que pide la metodología. El
es el líder que esta al servicio del equipo Scrum y ayuda a que personas externas puedan
entender como se esta desarrollando el proyecto, ayuda al entendimiento de las
funcionalidades del proyecto, ayuda a liderar la organización, planifica la implementación
de Scrum en la organización.
10. ¿Como se ejecuta una reunión diaria de Scrum?
La reunión diaria de Scrum se ejecuta antes de la realización de las actividades del equipo
de desarrollo esta tiene una duración de 15 minutos para que el equipo de desarrollo
sincronice sus actividades y realicen un plan de 24 horas.
Las preguntas que se le realiza a cada equipo de desarrollo en la reunión son las
siguientes:
¿Que hice ayer que ayudo al equipo a desarrollar el objetivo del Sprint?
¿Qué hare hoy que ayude al equipo a desarrollar el objetivo del Sprint?
¿Veo algún impedimento que evite que el equipo de desarrollo no logre aplicar el objetivo
del Sprint?
El Scrum master es el encargado de que el equipo de desarrollo realice su Scrum diario y
verifique que este dure 15 minutos.
11. ¿Le permite a alguien cambiar un requisito?
No, no se le permite a nadie a cambiar requisitos. Solamente el dueño del producto tiene
la posibilidad de hacerlo. El equipo Scrum puede darle opiniones, sugerencias. Sim
embargo, solo el puede manipular los requerimientos que se necesitan para el desarrollo
tanto de los incrementos como del proyecto en sí.
Practico # 2

12. ¿Qué requisito utiliza para los equipos?

Que contengan los valores fundamentales del Scrum que son:
Compromiso.
Respeto.
Coraje.
Foco.
Apertura.
13. ¿Como lidias con la discordia en tu equipo?
Tratando de que el entorno sea un ambiente de respeto y entendimiento. Quiere decir a
que respetemos las ideas implementadas, pero también ser accesibles a que nuestras
ideas no sean las adecuadas he incentivando a seguir con el objetivo propuesto.
14. ¿Como motiva a un equipo nuevo en Scrum?
Dando ánimos al grupo tratando de entender sus frustraciones y impulsarlos mediante sus
habilidades y fortalezas.
15. ¿Describa el proceso de SCRUM?
a) Planificación de la iteración: Este se crea mediante un trabajo colaborativo del
Scrum Completo. Este tiene una duración de 8hrs donde se planifican los objetivos,
se realiza el backlog del Sprint, aclaraciones a las personas externas entiendan el
propósito.
Se realiza las preguntas “que” y “como” para consolidar el objetivo del Sprint que
se va a elaborar.
b) Ejecución de la iteración: una vez elaborado el Sprint se realiza la elaboración de
las funcionalidades seleccionadas del backlog principal. En este sector, se crea el
incremento y se va elaborando mediante objetivos diarios que el equipo de
desarrollo se traza de forma individual.
c) Inspección y adaptación: una vez finalizado el Sprint mediante la reunión de
revisión se encarga de realizar la inspección y adaptación del Sprint en el conjunto
ya elaborado del Sprint. Esto lo hacen en conjunto he inclusive lo verifica personas
externas.
d) Revisión (demostración): El incremento es puesto a prueba donde ingresa a una
inspección exhaustiva viendo la falencia que el incremento pueda tener esto se
hace junto a todo el equipo Scrum y se anota las mejorías que necesita para
ingresar a la siguiente etapa.
e) Retrospectiva: Una vez que se tiene las mejorías que el incremento necesita el
grupo de desarrollo ingresa a la etapa de retrospección donde con ayuda del
Practico # 2

Scrum Master y en un tiempo de 3 horas, el equipo se encargara de realizar dichas

mejoras al incremento.

16. Arquitectura de Software: ¿Explicar y entender para hacer una descripción general
del modelo C4 y por quien fue propuesto?
El modelo C4 consiste en un conjunto jerárquico de diagramas de arquitectura de
software para contexto, contenedores, componentes y Código. La jerarquía de los
diagramas C4 proporciona diferentes niveles de abstracción, cada uno de los cuales es
relevante para una audiencia diferente. Para crear estos mapas de su código, primero
necesita un conjunto común de abstracciones para crear un lenguaje ubicuo que describa
la estructura estática de un sistema de software.

Simón Brown es un consultor independiente especializado en arquitectura de software y

autor del libro “Software Architecture for Developers” (una guía amigable para
desarrolladores de arquitectura de software, liderazgo técnico y equilibrio con agilidad).
También es el creador del modelo de arquitectura de software C4, que es un enfoque
simple para crear mapas de su código. Simon es un orador habitual en conferencias
internacionales de desarrollo de software y viaja por el mundo para ayudar a las
organizaciones a visualizar y documentar su arquitectura de software.
17. ¿Explicar porque se basa en el principio de ir de lo general a lo particular en el
modelo C4?
El modelo C4 considera las estructuras estáticas de un sistema de software en términos de
contenedores (aplicaciones, almacenes de datos, microservicios, etc.), componentes y
código.
Las características principales son:
El modelo C4 está basado en un enfoque de “abstracción primero” que refleja como los
arquitectos y desarrolladores piensan y crean el software.
El modelo C4 presenta un conjunto jerárquico de diagramas de arquitectura de software
para contexto, contenedores, componentes y código.
Es un modelo relativamente simple para describir la arquitectura de un sistema, siendo
potente, ya que tiene la agilidad de incorporar desarrolladores con facilidad y facilita el
entendimiento del software.
Evita la ambigüedad en los diagramas, incluyendo una cantidad suficiente de texto, así
como una clave para la notación utilizada.
Practico # 2

La jerarquía de los diagramas C4 proporciona diferentes niveles de abstracción, cada uno

de los cuales es relevante para una audiencia diferente.
El modelo C4 es un modelo que se puede complementar junto con otros diagramas
adiciones como: diagrama entidad-relación, secuencia, diagrama de flujo, etc.
No es necesario ocupar los cuatro niveles del diagrama; solo aquellos que aportan
valor.
18. Cuál es el objetivo y explique de forma breve: Nivel 1: Contexto del sistema
modelo C4 y elabore un ejemplo.
Nivel1. Diagrama del contexto del sistema:
En el Nivel 1, Se muestra el sistema de software que está construyendo y cómo encaja en
el mundo en términos de las personas que lo utilizan y los otros sistemas de software con
los que interactúa.
En otras palabras, este tipo de diagrama muestra un panorama general de la aplicación,
sin importar los detalles, tecnologías. Protocolos u otras características de bajo nivel, a fin
de que las personas sin conocimientos técnicos puedan entenderlo.
Ejemplo:

Sus clientes bancarios utilizan el sistema de banca por Internet para visualizar información
sobre sus cuentas bancarias y realizar pagos. El sistema de banca por Internet utiliza el
sistema del banco en el mainframe existente del banco para hacer esto y utiliza el sistema
de correo electrónico existente del banco para enviar correo electrónico a los clientes. El
código de color en el diagrama indica los sistemas de software que ya existen (las cajas
grises) y los que se van a construir (azules).
19. Cuál es el objetivo y explique de forma breve: Nivel 2: Contenedores modelo C4 y
elabore un ejemplo.
Practico # 2

Nivel2. Contenedor:
En el nivel 2 se muestra el diagrama de contenedores, que amplía el sistema de software y
muestra los contenedores (aplicaciones del lado del servidor, almacenamiento de datos,
microservicios, aplicaciones del lado del cliente, etc.) que componen el sistema de
software. Las decisiones técnicas también son una parte clave de este diagrama. Siendo
este diagrama sencillo y centrado en la tecnología de alto nivel, resulta útil tanto para los
desarrolladores como para el personal de operaciones y soporte.
Ejemplo:

La Aplicación Web es un sistema Java/Spring MVC que simplemente muestra contenido

estático (HTML, CSS y JavaScript), incluyendo el contenido que constituye la aplicación de
una sola página. La aplicación de una sola página es una aplicación Angular que se ejecuta
en el navegador web del cliente, proporcionando todas las características de la banca por
Internet. Alternativamente, los clientes pueden utilizar una aplicación móvil integrada en
Xamarin, plataforma cruzada, para acceder a un subconjunto de funcionalidades de banca
por Internet. La aplicación de una sola página y la aplicación móvil utilizan una API
JSON/HTTTPS, que proporciona otra aplicación Java/Spring MVC que se ejecuta en el lado
del servidor. La aplicación en la API obtiene información de usuario de la base de datos (un
Practico # 2

esquema de base de datos relacional). La aplicación de la API también se comunica con el

sistema bancario en el mainframe existente, utilizando una interfaz XML/HTTTPS
propietaria, para obtener información sobre cuentas bancarias o realizar transacciones. La
aplicación de la API también utiliza el sistema de correo electrónico existente si necesita
enviar correo electrónico a los clientes.
20. Cuál es el objetivo y explique de forma breve: Nivel 3: Componentes del Sistema y
elabore un ejemplo.
Nivel3. Componentes:
En el nivel 3 se muestra el diagrama de componentes, que amplía un solo contenedor para
mostrar los componentes y cuáles son los componentes. Estos componentes se asignan a
abstracciones reales en la base del código (por ejemplo, un conjunto de códigos).
Ejemplo:

Dos controladores MVC Spring en Rest proporcionan puntos de acceso a la API de

JSON/HTTTPS, y cada controlador utiliza posteriormente otros componentes para acceder
a los datos de la base de datos y del sistema bancario en el mainframe.
Practico # 2

21. Cuál es el objetivo y explique de forma breve: Nivel 4: Código modelo C4 y elabore
un ejemplo.
Nivel4. Código:
Finalmente, si realmente lo desea, o si es necesario, el nivel 4 se puede hacer zoom en
componentes individuales para mostrar cómo se implementa ese componente; utilizando
diagramas de clases UML, diagramas modelo entidad – relación u otros.
Ejemplo:

Este diagrama muestra que el componente consta de varias clases y que los detalles de
implementación reflejan directamente el indicador. No recomendaría necesariamente la
creación de diagramas a este nivel de detalle, especialmente cuando se pueden obtener
bajo demanda de la mayoría de los IDEs.