Documentación Front-End

Explore

Documentación Front-End

Lineamientos Generales Front-end

React JS es una librería de JavaScript muy popular que permite crear interfaces de usuario interactivas y escalables. Se ha convertido en una opción preferida para el desarrollo de aplicaciones web modernas debido a su capacidad para construir componentes reutilizables y su enfoque en la eficiencia y la velocidad.

El sistema que vamos a desarrollar con React JS será una aplicación web que permitirá a los usuarios realizar diversas tareas, como visualizar información, agregar y editar datos, y realizar búsquedas. Para lograr esto, utilizaremos la estructura modular de React JS para crear componentes reutilizables y mantener un flujo de datos coherente en toda la aplicación.

Uno de los principales beneficios de trabajar con React JS es su capacidad para manejar grandes cantidades de datos y actualizar la interfaz de usuario de manera eficiente. Esto significa que los usuarios podrán interactuar con el sistema de manera rápida y fluida, incluso cuando manejen grandes cantidades de información.

En resumen, el sistema que vamos a trabajar con React JS será una aplicación web moderna, eficiente y escalable que permitirá a los usuarios realizar diversas tareas de manera rápida y sencilla. Con la ayuda de React JS, crearemos una interfaz de usuario atractiva y fácil de usar, así como una estructura de datos coherente y reutilizable que nos permitirá expandir y mantener el sistema a largo plazo.

Metodologias de Trabajo.

El Sprint

El sprint es un período de tiempo fijo y corto durante el cual el equipo de desarrollo trabaja en una serie de tareas y objetivos específicos. Normalmente, los sprints tienen una duración de dos a cuatro semanas, y son una forma de organizar el trabajo en iteraciones manejables y enfocadas.

Durante el sprint, el equipo de desarrollo se reúne diariamente para discutir el progreso y hacer ajustes necesarios. Al final de cada sprint, el equipo realiza una revisión para demostrar los avances y obtener retroalimentación del cliente o del product owner. También realizan una retrospectiva para identificar oportunidades de mejora y ajustar el proceso para el siguiente sprint.

El objetivo de los sprints es desarrollar funcionalidades completas y listas para ser entregadas al final de cada ciclo. Cada sprint tiene una lista de tareas prioritarias, conocida como el "backlog del sprint", que se centra en las funcionalidades o tareas más importantes a realizar durante ese período.

En resumen, los sprints son una forma clave de la metodología ágil para organizar el trabajo en períodos cortos y enfocados, con el fin de producir entregables útiles y mejorar continuamente el proceso de desarrollo.

El Daily

El daily es una reunión de 15 minutos de duración aproximado, del equipo de desarrollo, en el que se sincronizan las actividades que están ocurriendo en el sprint, y la planificación de las actividades de las próximas 24 horas. Se realiza con la intención de inspeccionar el trabajo realizado desde el anterior daily y también poder planificar el trabajo que se hará antes del siguiente, Por lo tanto se pueden plantear los siguientes topicos:

¿Qué he hecho desde el último daily para ayudar al equipo de desarrollo a cumplir el objetivo del sprint?

¿Qué haré durante el día de hoy para ayudar al equipo a cumplir el objetivo del sprint?

¿He visto o encontrado algún impedimento que me impida a mi, o al equipo, a cumplir el objetivo del sprint?

Estimaciones de tiempo.

⁠

Planning Poke⁠

Se trata de una dinámica ágil en la que se reúne el equipo con una “-baraja de Poker” modificada y se hacen rondas de estimación con ayuda de estas cartas. Esta es una técnica para calcular una estimación basada en el consenso, en su mayoría utilizada para estimar el esfuerzo o el tamaño relativo de las tareas de desarrollo.

Para una sesión de estimación ágil será necesario que cada participante tenga una baraja la cuales cuentan con los numeros 0, 1/2, 1, 3, 5, 8, 13, ?, ∞, los que le daran un “peso” al requerimiento o Historia de usuario.

0: La historia ya está hecha o no requiere ningún esfuerzo

1/2: La historia requiere un bajo esfuerzo, por lo que son tareas sencillas y faciles de lograr.

1: La tarea se logra con un esfuerzo bajo, sin embargo puede llevar tiempo en lograrlo

2:la tarea se lleva a cabo en una parte de la jornada de trabajo (ejemplo la mitad de la maña)

3: tareas de una complejidad moderada que tienen cierta logica y que podrian llevar parte del dia en completar

5: ya tienen una mayor complejidad, son tareas que podrian llevar un periodo de tiempo considerable pero no una jornada.

8: tareas complejas que podrian requerir un esfuerzo que podria llevar la mayor parte de la jornada.

13: Complejidad de tiempo y esfuerzo mayor, podrian llevar una jornada de trabajo o un poco mas para llevarlas a cabro

∞: Tareas las cuales tienen un esfuerzo demasiado grande y podria ser necesario dividirlas en tareas mas pequeñas.

?: Tareas en las cuales se dificulta la toma de decicion al momento de estimar, ya que puede requerir tareas adicionales o bien pueden depender de otras tareas al momento de desarrollarla y evaluaciones en conjunto.

Para comenzar la estimacion cada participante debe tener conocimiento de las historias de usuarios o requerimientos a estimar, por lo que se recomienda una breve introduccion y explicación sobre el requerimiento.

Uno por uno se leen las historias de usuarios o requerimientos y el equipo completo. Una vez todos tienen claro en qué consiste el requerimiento, cada uno elige una carta en función del esfuerzo que prevé requerirá esa historia.

Al momento de revelar las “Cartas”, si no hay un concenso claro se debera discutir y arguntentar por que la decición, tomando en cuenta la estimaciones mas altas y mas bajas, luego se procede a repetir la estimación. Si no se consigue a la segunda se vuelve a discutir. A la tercera si no hay consenso se escoge o bien la media o bien el máximo (preferiblemente el máximo).

Al final de la sesión el resultado es una estimación consensuada y validada por todo el equipo para cada una de las historias o tareas seleccionadas.

EL planning poker favorece el proceso de estimación ya que al realizar sesiones y acuerdos concensuados con distintos focos podems tener puntos de vista distintos, ayudando a identificar posibles problemas, tareas que nos e tenian previstas, tener una vision global de la historia de usuario y sprints ademas de “Tener estimaciones más realistas (no más precisas). La idea es que entre todos los numeros que salgan se evalue lo más cercano a la realidad posible. Para ello necesitas eliminar la presión contractual, esto es, dejar margen para equivocarse y evitar así introducir buffers “inconscientes” por si acaso. Lo que buscamos es realismo, no precisión, es decir, quiero saber si una historia serán 3 o 5 días, si me dices que tardarás 26,5 horas dudaré de que hayas hecho un buen ejercicio de estimación.”

Gallery

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.