Conceptos sobre GitHub

¿Qué es GitHub?

Plataforma en donde se publican repositorios de código remotos, y se trabajan con el sistema de control de versiones Git. en otros proyectos y publicar proyectos propios. De esta manera se posibilita la colaboración, al ser de código abierto, es posible ésta reprocidad de que colaboren en tus proyectos y vos en otros, si se desea. Los equipos de desarrollo podremos coordinar, trackear, actualizar tareas de un proyecto desde cualquier lugar, de ésta manera la transparencias de estos serán tanto por los desarrolladores, como para clientes, usuarios, etc.

Adentremosnos en las herramientas que ofrece GitHub -Issues: Unidad de trabajo para realizar mejoras en un sistema informático (tarea, arreglo de fallo, ideas, sugerencias). Para crear ésta una unidad de tarea o trabajo, se crea con un título obligatorio y una descripción, cuando la persona es miembro del equipo, puede asignar _metadatos:_etiquetas (labels), hitos (milestone). _Assignees (opcional): permite asignar 1 hasta 10 personas a una tarea. _Milestone (opcional): Categorías para tener filtro de la información, pueden tener una fecha programada indicando el tiempo que es necesario para cumplir cierta tarea. Deberíamos crear milestone cuando aún no se han completado al 100% todas las tareas designadas, de ésta manera utilizando la programación de fechas estipuladas el equipo de trabajo concretará con cada pauta que se le fue asignada.

Label (opcional): Especifica el tipo de issue(bug, documentation, duplicate, invalid, etc). Etiquetas los issues permite acceder mas rápido.
Project (opcional): Configuración del proyecto en cuestión. Con Project boards permite organizar y priorizar el trabajo de un equipo de desarrollo, se adapta al fluo de trabajo del quipo.

GIT

Git maneja sus datos como un conjunto de copias instantáneas de un sistema de archivos miniatura.
Cada vez que confirmas un cambio, o guardas el estado de tu proyecto en Git, él básicamente toma una foto del aspecto de todos tus archivos en ese momento y guarda una referencia a esa copia instantánea.
Si los archivos no se han modificado Git no almacena el archivo de nuevo.
La mayoría de las operaciones en Git sólo necesitan archivos y recursos locales para funcionar. Debido a que tienes toda la historia del proyecto ahí mismo, en tu disco local, la mayoría de las operaciones aparecen prácticamente inmediatas.
Todo en Git es verificado mediante una suma de comprobación (checksum en inglés) antes de ser almacenado, y es identificado a partir de ese momento mediante dicha suma. Esto significa que es imposible cambiar los contenidos de cualquier archivo o directorio sin que Git lo sepa. La suma de comprobación se conoce como hash SHA-1. Git, guarda todo no por nombre de archivo, sino por el valor hash de sus contenidos.

Git tiene tres estados principales en los que se pueden encontrar tus archivos:

confirmado (committed), modificado (modified), y preparado (staged).

Confirmado: significa que los datos están almacenados de manera segura en tu base de datos local.
Modificado: significa que has modificado el archivo pero todavía no lo has confirmado a tu base de datos.
Preparado: significa que has marcado un archivo modificado en su versión actual para que vaya en tu próxima confirmación.

Esto nos lleva a las tres secciones principales de un proyecto de Git:

-El directorio de Git (Git directory): donde se almacenan los metadatos y la base de datos de objetos para tu proyecto. Es la parte más importante de Git, y es lo que se copia cuando se clona un repositorio desde otra computadora.

-El directorio de trabajo (working directory): trabajo es una copia de una versión del proyecto. Estos archivos se sacan de la base de datos comprimida en el directorio de Git, y se colocan en disco para que los puedas usar o modificar.

-El área de preparación (staging area): es un archivo, generalmente contenido en tu directorio de Git, que almacena información acerca de lo que va a ir en tu próxima confirmación.

Software

El software son los programas, los documentos asociados y la configuración de datos que se necesitan para hacer que estos programas operen de manera correcta La documentación se refiere a documentos que describen:

la organización del sistema,
documentos para el usuario que les explica cómo utilizar el sistema
sitios web que permitan a los usuarios descargar la información de actualizaciones del producto

Software (IEEE): parte de un sistema que se puede codificar para ejecutarse en una computadora como un conjunto de instrucciones. Incluye la documentación asociada necesaria para comprender, transformar y usar esa solución.

Características

Es intangible.
Tiene alto contenido Intelectual.
Su proceso de desarrollo es humano intensivo, basado en equipos y construidos en proyectos.
Puede ser potencialmente modificado, en forma permanente. (Robert Cochram)
El software no se manufactura, se desarrolla. ● El software no se desgasta.
A pesar de la tendencia de la industria a desarrollar por componentes, gran parte del software aún se construye a medida. (Pressman)

El desarrollo de software

Define un conjunto completo de actividades necesarias para transformar los requerimientos de un usuario en un producto.**

Agile

Es una ideología con un conjunto definido de principios que guían al desarrollo de un producto. Agilidad: “La gestión de proyectos ágil no se formula sobre la necesidad de anticipación, sino sobre la adaptación continua.”

Manifiesto Agile (Valores)

Valorar a los individuos por encima de los procesos. ● El software que funciona por encima de la documentación exhaustiva. ● La colaboración del cliente por encima de la negociación contractual. ● La respuesta al cambio por encima del seguimiento de un plan.

Los doces Principios agile

Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
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.
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.
El software funcionando es la medida principal de progreso.
Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

Procesos Ágiles:

Programación extrema
Desarrollo de prototipo
Scrum
Desarrollo rápido de aplicaciones(RAD)

Pilares de Scrum:

Para poder desarrollar un proceso, Scrum se sustenta en 3 pilares:

Transparencia: Los aspectos significativos del proceso deben ser visibles y definidos en base a un estándar común. Ejemplo: Aquellos que desempeñan el trabajo y quienes inspeccionan el incremento resultante deben compartir una definición común de “Terminado” (“Done”).
Inspección: Deben inspeccionarse frecuentemente los Artefactos de Scrum y el progreso hacia un objetivo para detectar variaciones indeseadas.
Adaptación: Si se determina que uno o más aspectos de un proceso se desvían de los límites aceptables y que el producto resultante será inaceptable, el proceso o el material que está siendo procesado deben ajustarse. Dicho ajuste deberá realizarse cuanto antes para minimizar desviaciones mayores.

SCRUM

¿Qué es SCRUM?

Es un marco de trabajo a través del cual las personas pueden abordar problemas complejos adaptativos, a la vez que se entregan productos de forma eficiente y creativa con el máximo valor. Es una enfoque ágil para la gestión de un proyecto. Más que una metodología o proceso, es un Marco de Trabajo.

Utiliza procesos interactivos/incrementales.
Orientado a resultados y compromisos.
No está restringido a proyectos de software solamente.
Su visión es opuesta a la propuesta por la metodología en cascada.

Sprint en SCRUM

Son las diferentes partes en las que dividimos el proyecto Scrum, lo que permite abordarlas de forma más rápida y eficiente.

Cada Sprint se puede considerar un mini-proyecto que no durará más de un mes. Al igual que los proyectos, los Sprint se utilizan para lograr algo. Cada Sprint cuenta con una definición de lo que se va a construir, un diseño y un plan flexible que guiará la construcción del plan, el trabajo, y el producto resultante. El mismo se repite n veces a lo largo del proyecto y permite hacer entregas de producto en partes, donde cada entrega, es un incremento de funcionalidad respecto al anterior. Esto difiere del conocido ciclo de vida en cascada muy utilizado en el campo de desarrollo de software en que, las fases del ciclo de vida (requisitos, análisis, diseño, codificación, testing, etc.) se realizan una única vez y, el inicio de cada fase no comienza hasta que termina la que precede.

Gracias a los sprints, los proyectos son más fáciles de gestionar, permiten a los equipos enviar trabajo de gran calidad más rápido y con más frecuencia, y les ofrecen más flexibilidad para adaptarse al cambio.

Características de los SPRINTS

Una vez que han sido definidos no puede haber cambios durante la ejecución que supongan un riesgo para la consecución de los objetivos.
Se deben trabajar en orden de mayor a menor importancia para el cliente, y mejor de uno en uno.
No hay tiempos intermedios, en cuanto acaba un Sprint comienza el siguiente.
Cada Sprint puede tener una duración diferente, pero todos los que conforman un Scrum no deberían durar más de un mes.
La cancelación del Sprint es decisión exclusiva del Product Owner.

Beneficios de los SPRINTS

Permiten a los equipos centrarse en cómo aportar más valor al producto o al proyecto, al aislarlos de cualquier distracción.
Cuantos más Sprints se hacen mejor se puede predecir el avance de los proyectos, lo que mejora la eficiencia al hacer más fácil el abordaje de las dificultades que pueden surgir.
Al no producirse cambios en el sprint goal, todo el equipo tiene un gran control sobre la planificación y los costes.
Cada miembro el equipo puede trabajar de forma auto-organizada, pero siempre en consonancia con los demás.
Permite entregar valor al cliente de forma más ágil y que este pueda ver cómo evoluciona poco a poco el proyecto.

Etapas de los SPRINTS

Reunión de planificación de Sprint
El Scrum Diario
Trabajo de desarrollo durante el Sprint
Revisión del Sprint
Retrospectiva del Sprint

Algunos Conceptos de Git

Base de datos de objetos alternativos A través del mecanismo de alternativas, un repositorio puede heredar parte de su base de datos de objetos de otra base de datos de objetos, que se denomina "alternativa".

repositorio Un repositorio simple normalmente es un directorio con un nombre apropiado con un .gitsufijo que no tiene una copia extraída localmente de ninguno de los archivos bajo control de revisión. Es decir, todos los archivos administrativos y de control de Git que normalmente estarían presentes en el .gitsubdirectorio oculto están directamente presentes en el repository.gitdirectorio, y ningún otro archivo está presente y desprotegido. Por lo general, los editores de repositorios públicos ponen a disposición repositorios básicos.

rama Una "rama" es una línea de desarrollo. La confirmación más reciente en una rama se conoce como la punta de esa rama. La punta de la rama está referenciada por una cabeza de rama , que avanza a medida que se realiza un desarrollo adicional en la rama. Un solo repositorio de Git puede rastrear un número arbitrario de ramas, pero su árbol de trabajo está asociado solo con una de ellas (la rama "actual" o "desprotegida"), y HEAD apunta a esa rama.

núcleo Git Estructuras de datos fundamentales y utilidades de Git. Expone solo herramientas limitadas de administración de código fuente.

sistema de archivos Linus Torvalds diseñó originalmente Git para ser un sistema de archivos de espacio de usuario, es decir, la infraestructura para almacenar archivos y directorios. Eso aseguró la eficiencia y la velocidad de Git.

archivo git Un archivo simple .giten la raíz de un árbol de trabajo que apunta al directorio que es el repositorio real.

repositorio remoto Un repositorio que se usa para rastrear el mismo proyecto pero reside en otro lugar. Para comunicarse con controles remotos.

repositorio Una colección de referencias junto con una base de datos de objetos que contiene todos los objetos a los que se puede acceder desde las referencias.

Un repositorio puede compartir una base de datos de objetos con otros repositorios a través de un mecanismo alternativo .

etiqueta Una referencia en refs/tags/el espacio de nombres que apunta a un objeto de un tipo arbitrario (por lo general, una etiqueta apunta a una etiqueta o a un objeto de confirmación ). A diferencia de headcommit , el comando no actualiza una etiqueta . Una etiqueta Git no tiene nada que ver con una etiqueta Lisp (que se llamaría tipo de objeto en el contexto de Git). Una etiqueta generalmente se usa para marcar un punto particular en la cadena de ascendencia de confirmación .

rama temática Una rama normal de Git que utiliza un desarrollador para identificar una línea conceptual de desarrollo. Dado que las bifurcaciones son muy sencillas, a menudo es deseable tener varias bifurcaciones pequeñas que contengan cada una conceptos muy bien definidos o pequeños cambios incrementales pero relacionados.

arbol de trabajo El árbol de archivos extraídos reales. El árbol de trabajo normalmente contiene el contenido del árbol de confirmaciones HEAD , además de cualquier cambio local que haya realizado pero que aún no haya confirmado.

árbol de trabajo Un repositorio puede tener cero (es decir, un repositorio simple) o uno o más árboles de trabajo adjuntos. Un "árbol de trabajo" consiste en un "árbol de trabajo" y metadatos del repositorio, la mayoría de los cuales se comparten entre otros árboles de trabajo de un solo repositorio, y algunos de los cuales se mantienen por separado por árbol de trabajo (p. ej., el índice, HEAD y pseudorefs como MERGE_HEAD, per- referencias de árbol de trabajo y archivo de configuración por árbol de trabajo).

Ceremonias Scrum

El marco de trabajo Scrum propone realizar un total de 4 ceremonias (a modo de reuniones o eventos) durante un Sprint para ayudar a alcanzar los resultados esperados. Estas ceremonias son:

Sprint Planning Meeting (al inicio de un Sprint, se planifica qué es lo que se hará en el mismo y cómo se hará, se establece un Objetivo)
Daily Scrum Meeting (reunión diaria, con una duración de hasta 20 minutos, en la que se evalúa qué se hizo, qué se hará y qué problemas se encontraron. Se inspecciona el progreso hacia el Objetivo)
Sprint Review Meeting (al final del Sprint, se muestra lo que se ha completado y lo que no. Debe estar presente el Product Owner)
Sprint Retrospective Meeting (se realiza también al finalizar el Sprint, y se documenta qué funcionó bien durante el mismo, y qué se puede mejorar para el próximo)

SofiaEJac / Grupo5A17_Programador2022

Glosario Metodologías Ágiles y Gestión de Proyectos #5