- Organización. Equipo (3-4 integrantes)
- Modo. Síncrono
- Estrategia. Pair Programming / Collaborative programming
- Duración. 45 días (9 sprints de 5 días)
- Dedicación. 2.5 horas diarias (112.5 horas en total)
- 🎯 Objetivos de aprendizaje
- 🚀 Producto Mínimo Viable
- 🚩 Requisitos técnicos
- 📐 ETAPA 1: Definición del producto (1 semana)
- 🔨 ETAPA 2: Codificación (8 semanas)
- Adquirir experiencia práctica en el desarrollo de aplicaciones móviles utilizando React Native.
- Mejorar las habilidades de trabajo colaborativo en entornos remotos para el desarrollo de aplicaciones.
- Utilizar herramientas de colaboración remota, como GitHub, de manera efectiva y eficiente.
- Utilizar herramientas de comunicación remota, como Slack, Google Meet y Gather Town, para facilitar la colaboración y la comunicación en el equipo de desarrollo.
- Utilizar herramientas de gestión de proyectos, como GitHub Projects, para planificar y organizar el desarrollo del MVP de la aplicación.
- Utilizar herramientas de gestión de tareas, como GitHub Issues, para asignar y dar seguimiento a las tareas relacionadas con el desarrollo del MVP.
Un MVP (Minimum Viable Product o Producto Mínimo Viable) es una versión inicial y funcional de un producto que contiene las características fundamentales necesarias para cumplir con los objetivos y satisfacer las necesidades básicas de los usuarios. Se trata de un enfoque estratégico que busca lanzar rápidamente al mercado una versión temprana del producto con el fin de obtener retroalimentación real y validar su viabilidad.
El propósito principal del MVP es aprender y validar hipótesis sobre el producto, su mercado y sus usuarios, antes de invertir grandes cantidades de tiempo y recursos en su desarrollo completo. Al enfocarse en las características esenciales, el MVP permite obtener información valiosa sobre la aceptación y demanda del producto, así como identificar oportunidades de mejora y ajustar la dirección del desarrollo de manera ágil.
Un MVP se diferencia de una versión finalizada del producto en que no incluye todas las características planificadas ni los detalles finos de diseño. En lugar de eso, se enfoca en ofrecer una experiencia básica y funcional que permita a los usuarios interactuar y experimentar con el producto, y proporcionar comentarios y sugerencias que ayuden a iterar y mejorar su desarrollo.
El desarrollo de un MVP implica un enfoque iterativo y centrado en el usuario, en el que se busca lanzar versiones sucesivas del producto, cada vez más completas, basadas en las lecciones aprendidas y la retroalimentación de los usuarios. Esta metodología ágil permite ahorrar tiempo y recursos al evitar el desarrollo de características innecesarias o no deseadas, y garantiza que el producto final se ajuste mejor a las necesidades y expectativas de los usuarios.
En resumen, un MVP es una versión temprana y funcional de un producto de software que se desarrolla con el objetivo de obtener retroalimentación, validar hipótesis y establecer una base sólida para el desarrollo continuo. Permite lanzar rápidamente al mercado una versión básica del producto y obtener información valiosa que guíe el proceso de desarrollo y mejora.
Requisitos técnicos mínimos para el prototipo a desarrollar:
- HTML ó HAML: La aplicación debe generar y renderizar páginas web utilizando la estructura y los elementos HTML ó preferentemente HAML.
- CSS ó SASS: Se deben aplicar estilos y utilizar selectores CSS ó preferentemente SASS para el diseño de las páginas web.
- JavaScript: La aplicación debe utilizar JavaScript para manejar eventos y manipular el DOM, proporcionando interactividad en las páginas web.4
- Lenguaje de programación Ruby: La aplicación debe estar desarrollada en Ruby, un lenguaje de programación dinámico y orientado a objetos.
- Active Record: Se debe utilizar Active Record, el ORM de Ruby on Rails, para interactuar con la base de datos y realizar operaciones de consulta, inserción, actualización y eliminación
- Active View: La presentación de datos en las vistas de Ruby on Rails debe realizarse utilizando Active View, que permite generar y renderizar la interfaz de usuario.
- Active Storage: Se debe utilizar Active Storage para gestionar los archivos adjuntos en la aplicación, permitiendo el almacenamiento y la manipulación de archivos de manera sencilla.
- Action Mailer: La aplicación debe utilizar Action Mailer para manejar el envío y recepción de correos electrónicos.
- Active Job: Se debe utilizar Active Job para procesar tareas en segundo plano de manera eficiente, mejorando el rendimiento y la respuesta de la aplicación.
- Rutas: La configuración y gestión de las rutas de la aplicación deben ser realizadas en Ruby on Rails, definiendo las URL y las acciones correspondientes.
- Gestión de autenticación y autorización con Devise: Se debe implementar la autenticación y autorización de usuarios utilizando Devise, una gema de Ruby on Rails que utiliza Active Record para su funcionamiento. Esto implica aprender a configurar Devise, gestionar el registro de usuarios, iniciar sesión y proteger las rutas y acciones según los roles de usuario.
- Controladores: Los controladores de Ruby on Rails deben procesar las solicitudes HTTP y ejecutar las acciones correspondientes para proporcionar la funcionalidad requerida.
- Migraciones: Se deben utilizar migraciones de base de datos para realizar cambios controlados en la estructura de la base de datos, como crear tablas, modificar columnas, etc.
- Modelado de datos relacionales: El diseño estructurado de la base de datos debe seguir el modelado de datos relacionales, asegurando la integridad y la coherencia de los datos.
- Sidekiq y Resque: Se pueden utilizar Sidekiq o Resque como manejadores de procesos en segundo plano para ejecutar tareas de manera eficiente y escalable.
- Manipulación de archivos CSV: La aplicación debe permitir la lectura y/o escritura de archivos CSV para importar y exportar datos, utilizando las funcionalidades proporcionadas por Ruby on Rails.
- Caché: Se debe aprovechar las funcionalidades de caché incluidas en Ruby on Rails para mejorar el rendimiento de la aplicación, almacenando en memoria datos que se acceden con frecuencia.
- Calidad del código: El ejercicio enfatiza en la calidad del código, utilizando herramientas como Rubocop y Ruby Critic para garantizar que el código esté en el formato correcto, siga las convenciones de estilo y obtenga una calificación adecuada.
- Pruebas unitarias: Se debe crear al menos una prueba por controlador y modelo en la aplicación para verificar su funcionalidad. Para cada funcionalidad de la aplicación, se debe presentar al menos un escenario de prueba.
- Valores iniciales para la base de datos (seeds): Se debe proporcionar una lista de valores iniciales útiles para las pruebas de la aplicación. Estos valores iniciales deben ser adecuados para validar el funcionamiento de las funcionalidades principales.
Esta etapa tiene una duración de 5 días. Durante este equipo los equipos deberán:
- Definir el producto que van a desarrollar.
- Puede ser un producto completamente nuevo, una mejora de un producto existente, o la clonación de un producto.
- Definir el alcance del MVP.
- Se debe considerar que se incluyan cubran todas las consideraciones técnicas descritas en la sección anterior.
- Definir la estructura de la interfaz de usuario (prototipo de baja fidelidad).
- Definir el modelo de la base de datos
- Presentar Planificar el desarrollo del MVP.
- Discusión sobre el concepto y objetivo del proyecto.
- Definición del alcance y características principales del prototipo/MVP.
- Identificación de usuarios y casos de uso.
- Documentación de la descripción del proyecto.
Entregable:En el archivo README.md del repositorio, agregar la sección Descripción del Proyecto en donde se detalle el resultado de esta primer sesión de trabajo
Sugerencia: Realizar una lluvia de ideas y análisis de viabilidad técnica y, en su caso, comercial para refinar y concretar el concepto del proyecto.
- Identificación y definición de los requerimientos funcionales del prototipo/MVP.
- Identificación y definición de los requerimientos no funcionales del prototipo/MVP.
- Priorización de los requerimientos.
- Documentación de los requerimientos funcionales y no funcionales.
Entregable: En el archivo README.md del repositorio, agregar las secciones Requerimientos Funcionales y No Funcionales en donde se detalle el resultado de esta reunión de trabajo.
Sugerencia: Realizar un análisis detallado de los requisitos y considerar la viabilidad técnica y temporal para cumplir con ellos en el plazo establecido.
- Definición de la estructura de la interfaz de usuario (UI).
- Creación de prototipos de baja fidelidad utilizando herramientas como lápiz y papel o herramientas de diseño gráfico como:
Entregable: Documento de Diseño de la Interfaz de Usuario. Integrarlo al archivo README.md del repositorio mediante un enlace.
Sugerencias:
- Establecer objetivos claros: Antes de comenzar el diseño, asegúrate de tener una comprensión clara de los objetivos del prototipo. ¿Qué problema intentas resolver con el diseño? ¿Cuáles son las características clave que debes incluir? Establecer objetivos claros ayudará a enfocar los esfuerzos de diseño y evitará la pérdida de tiempo en detalles innecesarios.
- Investigar y recopilar inspiración: Siempre es útil buscar inspiración en otros diseños existentes. Examina interfaces de usuario similares o de referencia y observa cómo abordan los desafíos de diseño. Esto te proporcionará ideas y te ayudará a comprender las mejores prácticas en tu campo.
- Utilizar patrones de diseño comunes: Los patrones de diseño son soluciones probadas y eficientes para problemas de diseño recurrentes. Al utilizar patrones de diseño comunes, como menús desplegables, formularios estándar o navegación basada en pestañas, podrás diseñar más rápidamente sin tener que crear todo desde cero. Existen diversas bibliotecas y recursos en línea que recopilan patrones de diseño.
- Simplificar y priorizar: Dado que hay poco tiempo disponible, es esencial simplificar el diseño y centrarse en las características clave. Identifica las funciones más importantes y asegúrate de que estén claramente representadas en el prototipo. Elimina cualquier elemento innecesario o complejo que pueda ralentizar el proceso de diseño.
- Utilizar una paleta de colores limitada: La elección de colores puede llevar tiempo y resultar complicada. Para agilizar el proceso, elige una paleta de colores limitada y coherente que se adapte a la identidad de tu proyecto. Esto evitará decisiones difíciles y te permitirá enfocarte en otros aspectos del diseño.
- Aprovechar plantillas y recursos preexistentes: En lugar de comenzar desde cero, busca plantillas y recursos preexistentes que puedan acelerar tu proceso de diseño. Hay muchas bibliotecas de recursos gratuitos en línea, como iconos, ilustraciones y plantillas de diseño, que pueden ser de gran ayuda.
- Identificación de las entidades y relaciones principales del sistema.
- Diseño del modelo conceptual de la base de datos utilizando diagramas de entidad-relación (DER).
- Normalización del modelo de datos, si es necesario.
- Documentación del modelo de la base de datos. Puedes utilizar dbdiagram.io o una herramienta similar.
Entregable: Documento del Modelo de la Base de Datos. Integrarlo al archivo README.md del repositorio mediante un enlace.
Sugerencia: Realizar un análisis detallado de los datos necesarios y asegurar la integridad y eficiencia del modelo de la base de datos.
- Presentación de la propuesta a mentores.
- Planificación del primer sprint de trabajo.
- Definición de las tareas a realizar.
- Iniciación del proyecto.
Entregable: Proyecto inicializado en GitHub.
Sugerencia: Calendarizar con tiempo la reunión con los mentores y realizar una revisión
Después de analizar las instrucciones, se identificaron algunas áreas donde se puede mejorar la claridad y el orden de las ideas. A continuación, se presenta una versión mejorada de las instrucciones:
Duración del proyecto:
- El proyecto de codificación del prototipo tendrá una duración total de 8 semanas, divididas en sprints de 1 semana cada una.
Modo de trabajo y colaboración:
- Al inicio, se utilizará el enfoque de "mob programming" para la codificación, donde todo el equipo trabajará en conjunto. Con el tiempo, se irá transitando hacia el "pair programming", permitiendo que cada miembro del equipo pueda trabajar de manera independiente pero en colaboración con los demás.
Reuniones diarias:
- Independientemente del modo de trabajo (mob programming, pair programming o tareas individuales), se llevarán a cabo reuniones diarias para revisar el progreso y resolver dudas.
Horario de trabajo:
- El horario que se tiene establecido será el horario en el cual todos los miembros del equipo deberán dedicarse a avanzar en sus tareas, facilitando así la comunicación e interacción.
Ceremonias de planificación y revisión:
- Se realizarán ceremonias de planificación y revisión al final de cada sprint, para establecer los objetivos y revisar los resultados obtenidos.
Flujo de trabajo:
- Se seguirá el flujo de trabajo descrito en la guía de desarrollo ágil [enlace a la guía], asegurándose de aplicar las prácticas correspondientes.
Responsabilidades del líder de sprint:
- Cada sprint contará con un líder designado, quien será responsable de mantener la comunicación, colaboración, integración y motivación del equipo.
- El líder también se encargará de mantener el tablero de trabajo actualizado y presentar los avances al finalizar cada sprint.