Contenido del curso
Contenido del curso
Breylimar Andreina Castillo Monsant
Felipe Bernardo González Barranco
Duvan Carvajal
Jennifer Gomez
Marta Monterde Alonso
Denise Esquivel Arias
Diego Perdomo
Brian ⠀
Yusting Andrés Mora González
Marta Monterde Alonso
Diego Perdomo
Yusting Andrés Mora González
Nelson Rodríguez
Carlos Pérez
carlos pineda
Edgardo Marcano
Marta Monterde Alonso
Irving Juárez
Gerson Antonio Cabrera
MARIA TERESA PANIAGUA RIVERA
Pedro Isaac Aguilar
Felipe Bernardo González Barranco
Yusting Andrés Mora González
Miguel Angel Ruz Torres
Qué: descripcion del elemento o el proceso
Dónde:
Hablando de procesos ¿En qué circunstancias lo vamos a utilizar?
Si es componente o funcionalidad ¿Donde debe ubicarse y su caso de uso?
Sí es un principio ¿Dónde debe verse reflejado en nuestros proyectos?
Cómo: forma en la que se lleva a cabo, y debería responder a ciertas preguntas
¿Hay una estructura para implementarlo?
En caso de ser un componente o patrón, ¿Cuáles son sus características visuales y funcionales?
¿Qué herramientas o estrategias utilizaremos?
:clap: :clap: :clap: :clap:
Una buena documentación, ahorra tiempo y deja claro el porqué de un patrón, componente o proceso. Un sistema de diseño es un sistema vivo que debe ir evolucionando con el tiempo y ese sistema vivo debe comunicarse con diseñadores, desarrolladores y otros equipos interesados. Recordemos que un Design System es la fuente de la verdad.
Una buena documentación ayuda la consistencia a lo largo de un proyecto y permite que todo el equipo hable un mismo lenguaje.
Así es, Jennifer. Esto es súper importante para el buen funcionamiento del equipo! ;)
¿Por qué documentar?
Imagina que alguien del equipo se enferma, se va a otro proyecto o de vacaciones. Qué pasará si tu trabajo no está documentado? Pérdida de información para el resto del equipo.
El qué resuelve:
Descripción de qué es el elemento /proceso de sí mismo.
Por qué motivo lo necesitamos o usamos.
Qué problemas resuelve.
El dónde resuelve:
Si es un proceso, en qué casos lo vamos a utilizar.
Si es un componente o funcionalidad, ¿dónde se debe ubicar?
Si es un principio, dónde debe verse reflejado.
El cómo resuelve:
¿Hay una estructura básica para hacerlo?
En caso de ser un componente o patrón, ¿Cuáles son sus características visuales y funcionales?
¿Qué herramientas o estrategias utilizaremos?
¿Para qué sirve?
En caso de duda, revisa el Sistema de Diseño y la documentación del proyecto. Conocer a los usuarios y usuarias, y las necesidades que tienen.
Establecer:
¿Qué documentar? De cada uno de los patrones, componentes y procesos, dejar claro:
¿Qué pasara si alguien se va del equipo y no tiene su trabajo documentado? -> sino está documentado, no existe.
Dios bendiga la documentación.
¿Existe algún curso que nos ayude a saber como documentar nuestros proyectos de manera práctica? 🤔
Hola, Yusting. Cada proyecto requiere un tipo de documentación distinta, debes pensar en documentar todo lo que crees que tu futuro yo necesitará saber para poder utilizar tu producto o tu sistema de la mejor manera. En este caso, creo que los cursos de la escuela de Gestión de proyectos te pueden ayudar. Espero que sean de ayuda! Un saludo
Una de las cosas para lo que es útil tener un SSDD es para reducir el tiempo de la curva de aprendizaje de nuevos integrantes.
Parece que no, pero la documentación ayuda tremendamente a los desarrolladores cuando necesitan saber algo en específico, especialmente si es documentación basada en componentes.
El documentar pude llegar a ser tan importante que puede convertirse en un guion de tal forma que podamos contar una historia con ello y poder interpretar cual era el reto y ver cual fue el resultado.
Documentar: Que: El motivo Dónde: relacionado a un caso de uso Cómo: la forma en como lo vamos a llevar a cabo
Unos ejemplitos no caerían mal 😅
Donde está el curso de patrones y componentes en los sistemas de diseño?
Aquí lo tienes!
Me parece que este approach es incorrecto, ya que en equipos de software nosotros valoramos más Software funcionando a Documentación exhaustiva.
La razón es sencilla. Con base en que tenemos iteraciones muy cortas y cambios muy rapidos, no tiene caso documentar exhaustivamente algo que puede que quede deprecated o inutil en un mes.
Entonces, como lo solucionamos? Simple, usando el design system como nuestra documentacion viviente. Por ejemplo, con herramientas como Storybook, nosotros podemos acceder al sistema de diseño que tiene detalle acerca de como y cuando debe usarse tal componente, asi como algun link al figma.
De esa manera, tenemos codigo, diseño, casos de uso y basicamente todo centralizado y facilmente accesible. Lo mejor de todo, actualizado.
Y es cierto, "Lo que no esta escrito, no existe", aqui el tema es que en caso del software primero se escribe y luego existe
Solución 3️⃣ : Documentar todo
¿Para Qué Sirve la Documentación?
• Plasmar la Historia del Producto: Guarda el progreso y evolución del proyecto.
• Guía para Otros Proyectos: Facilita la replicación de mejores prácticas.
• Entender la Forma de Trabajar: Proporciona un marco claro de procesos y decisiones.
En caso de duda, revisa el Sistema de Diseño y su documentación. ¡Evita la pérdida de información valiosa! 🔍
Documentación en el Sistema de Diseño
• Conocer a los Usuarios y sus Necesidades: Asegura que los elementos cumplan expectativas.
• Establecer Elementos Clave:
• Arquitectura de Información 📂
• Nomenclatura de Secciones 🏷️
• Contenidos 📄
¿Qué Documentar?
Cada patrón, componente o proceso debe incluir:
• Descripción: Explica qué es el elemento o proceso.
• Motivo: ¿Por qué es necesario? ¿Qué problema resuelve?
• Para Procesos: ¿En qué situaciones se utilizará?
• Para Componentes o Funcionalidades: Ubicación en el proyecto y casos de uso.
• Para Principios: ¿Dónde deberían reflejarse en los proyectos?
• Estructura de Implementación: ¿Hay una base que seguir?
• Para Componentes o Patrones: Describe las características visuales y funcionales.
• Herramientas o Estrategias: ¿Qué usaremos para su implementación?
¿Por Qué Documentar?
• Garantiza Continuidad: Si alguien falta, la documentación evita la pérdida de contexto.
• Evita Retrasos: Menos tiempo aclarando dudas y más avanzando.
• Alinea al Equipo: Un recurso común para todos, sin perderse en el camino.
Resumen completo:
Gracias
Recuerda: Si algún elemento o proceso no está documentado en el Design System, no existe.
Lo mas importante a documentar es el
de todos los patrones componentes y procesos
Qué = Qué es. Cómo = Cómo se usa, comparaciones de buen uso, y mal uso. Dónde = En dónde debería de usarse.
Una buena documentación evita confusiones a la hora de la implementación