From 22f1bb0d1befd2b105eb2f073b9b569ee56ba514 Mon Sep 17 00:00:00 2001 From: JJ Merelo Date: Wed, 13 Sep 2023 17:23:09 +0200 Subject: [PATCH 01/22] Sync index.md de master a gh-pages --- index.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/index.md b/index.md index b7038f26..b9c9fe14 100644 --- a/index.md +++ b/index.md @@ -9,7 +9,7 @@ layout: index | [![Lint Markdown](https://github.com/JJ/IV/workflows/Lint%20Markdown/badge.svg)](https://github.com/JJ/IV/actions?query=workflow%3A%22Lint+Markdown%22) -[Infraestructura virtual](https://grados.ugr.es/informatica/pages/infoacademica/guias_docentes/curso_actual/cuarto/tecnologiasdelainformacion/infraestructuravirtual) +[Infraestructura virtual](https://grados.ugr.es/sites/grados/default/public/guias-firmadas/2022-2023/296114N.pdf) es una asignatura obligatoria de la rama "Tecnologías de la Información" del primer cuatrimestre del cuarto curso del Grado de Ingeniería Informática y optativa en otras ramas y en el Doble Grado de Informática y Matemáticas. @@ -35,11 +35,11 @@ disponibles con una licencia libre. Los fuentes de los mismos están en [GitHub](https://github.com/JJ/IV). La temporización de la asignatura y los objetivos de cada sesión figuran en la -[bitácora](https://github.com/JJ/IV-22-23/blob/master/sesiones/README.md) de +[bitácora](https://github.com/JJ/IV-/blob/master/sesiones/README.md) de clase. Enlazaremos también en ese fichero las grabaciones que se hagan de las sesiones en vivo. -Estos son los [objetivos de la asignatura](documentos/objetivos), cuyas +Estos son los [objetivos de la asignatura](documentos/objetivos.md), cuyas sesiones de clase se irán reflejando en un repositorio de GitHub. En resumen, nuestra intención es que el estudiante al final de la asignatura sea @@ -72,7 +72,7 @@ lo largo de la misma, cubriendo diferentes objetivos de aprendizaje a la vez que se realizan diferentes productos mínimamente viables de ese proyecto. Los proyectos [consisten en crear la infraestructura virtual junto con una aplicación desarrollada según el modelo -DevOps](documentos/proyecto/README.md). A grosso modo, los objetivos se +DevOps](documentos/proyecto/README). A grosso modo, los objetivos se organizarán de la forma siguiente. 1. [Objetivo cero: Uso básico de @@ -158,9 +158,9 @@ antelación. ## Criterios de evaluación Los criterios de evaluación figuran en la -[ficha de la asignatura](https://grados.ugr.es/informatica/pages/infoacademica/guias_docentes/curso_actual/cuarto/tecnologiasdelainformacion/gii_infraestructura_virtual_20172018_firmada) +[ficha de la asignatura](https://grados.ugr.es/sites/grados/default/public/guias-firmadas/2022-2023/296114N.pdf) en la web del grado, y -[se especifican en el repositorio de la clase](https://github.com/JJ/IV-21-22/blob/master/Metodolog%C3%ADa_y_criterios_de_evaluaci%C3%B3n). +[se especifican en el repositorio de la clase](https://github.com/JJ/IV-/blob/master/Metodolog%C3%ADa_y_criterios_de_evaluaci%C3%B3n.md). ## Convocatoria extraordinaria (AL FINAL DEL CUATRIMESTRE) From 39ffdd7465ce06b511e9a437088a66be34883ba3 Mon Sep 17 00:00:00 2001 From: JJ Merelo Date: Wed, 13 Sep 2023 20:45:57 +0200 Subject: [PATCH 02/22] Sync index.md de master a gh-pages --- index.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/index.md b/index.md index b9c9fe14..b2693e64 100644 --- a/index.md +++ b/index.md @@ -14,10 +14,10 @@ es una asignatura obligatoria de la rama "Tecnologías de la Información" del primer cuatrimestre del cuarto curso del Grado de Ingeniería Informática y optativa en otras ramas y en el Doble Grado de Informática y Matemáticas. -La asignatura en el curso 22-23 [se -imparte](https://etsiit.ugr.es/sites/centros/etsiit/public/inline-files/HorariosGII%2822-23%29.pdf) -en el aula 1.2 los viernes de 8:30 a 10:30 (grupo conjunto) y en la -1.2 los -jueves de 8:30 a 10:30 y de 12:30 a 14:30 (grupos divididos). Se recuerda a los +La asignatura en el curso 23-24 [se +imparte](https://etsiit.ugr.es/sites/centros/etsiit/public/inline-files/HorariosGII%2823-24%29.pdf) +en el aula 1.2 los jueves de 8:30 a 10:30 (grupo conjunto) y en la -1.2 los +viernes de 8:30 a 10:30 y de 12:30 a 14:30 (grupos divididos). Se recuerda a los estudiantes que en todas las clases será necesario llevar el portátil, ya que son siempre clases prácticas; por lo mismo, se recomienda encarecidamente la asistencia a todas las clases para realizar las prácticas in situ. From 2229fadd8268b865b480456b9e25ed1595347c3a Mon Sep 17 00:00:00 2001 From: JJ Merelo Date: Sat, 16 Sep 2023 11:41:46 +0200 Subject: [PATCH 03/22] Sync documentos/proyecto/0.Repositorio.md de master a gh-pages --- documentos/proyecto/0.Repositorio.md | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/documentos/proyecto/0.Repositorio.md b/documentos/proyecto/0.Repositorio.md index ec91698b..9e9ce917 100644 --- a/documentos/proyecto/0.Repositorio.md +++ b/documentos/proyecto/0.Repositorio.md @@ -144,7 +144,7 @@ se pueda validar como una solución aceptable al problema. ### Dónde buscar proyectos En clase se hará un [juego de -rol](../../actividades/juego-rol-design-thinking) para enfocar el +rol](../../actividades/juego-rol-design-thinking.md) para enfocar el problema, o poder hallar uno en caso de que se necesite ayuda. En general, encontrar un proyecto que se pueda desarrollar en la asignatura es @@ -268,7 +268,7 @@ para aplicar la lógica de negocio. 2. En general, va a ser necesario que entiendas el mecanismo de la asignatura y sus contenidos. Por ello, consulta los objetivos impartidos en la [primera - sesión](https://github.com/JJ/IV-/blob/master/sesiones/semana-01) + sesión](https://github.com/JJ/IV-/blob/master/sesiones/semana-01.md) si no has podido asistir a clase. ## Explicación @@ -380,7 +380,7 @@ procedimiento. será lo que se entregará. Una vez hecho lo anterior, se añadirá [al fichero de entrega del -proyecto](https://github.com/JJ/IV-/blob/master/proyectos/objetivo-0), +proyecto](https://github.com/JJ/IV-/blob/master/proyectos/objetivo-0.md), en la fila correspondiente (que estará ya pre-rellena con tu nombre), el nombre del proyecto, un enlace *al PR que has creado desde una rama de tu repositorio* y una versión, *que seguirá el formato estándar* `vx.y.z`, llamado [versionado @@ -407,8 +407,9 @@ condiciones que se indican en la propia plantilla de envíos: * Sólo debéis fusionar el PR en vuestro repositorio *cuando haya sido aceptado por el profesor*. -Se aconseja al estudiante que trate de solucionar los problemas que aparezcan de -la forma más rápida posible. +Se aconseja al estudiante que trate de solucionar los problemas que aparezcan, +bien en los tests o a través de los comentarios del profesor, de la forma más +rápida posible. * En el caso de la entrega en el repositorio de la asignatura, los tests no tardarán más de un minuto. Si falla, se aconseja que se corrija sobre la @@ -420,10 +421,11 @@ la forma más rápida posible. hecho. Se aconseja *no resolver nunca estas objeciones*, salvo que hayan dado lugar a cambio en otra línea y por tanto no se haya cerrado. La resolución rápida de problemas para adquirir un objetivo de aprendizaje es imprescincible - para progresar rápidamente en la asignatura. Una vez hecha la revisión por el - profesor la primera vez, se le notificarán todos los cambios en el PR; se - pide, sin embargo, que cuando la revisión esté completa se solicite, de nuevo - revisión explícitamente en un comentario en el que se mencione al profesor. + para progresar rápidamente en la asignatura. +* Una vez hecha la revisión por el profesor la primera vez, se le notificarán + todos los cambios en el PR; se pide, sin embargo, que cuando la revisión esté + completa se solicite de nuevo revisión explícitamente en un comentario en el + que se mencione al profesor o asignando como revisor al profesor en GitHub. El `README.md` del proyecto será, efectivamente, la descripción del proyecto en sí. Documentación adicional (por ejemplo, en la documentación de este objetivo From 42712509891fd249eda0176e0cb4cd9f06c03470 Mon Sep 17 00:00:00 2001 From: JJ Merelo Date: Sat, 16 Sep 2023 11:44:44 +0200 Subject: [PATCH 04/22] Sync documentos/proyecto/1.Infraestructura.md de master a gh-pages --- documentos/proyecto/1.Infraestructura.md | 31 ++++++++++++++---------- 1 file changed, 18 insertions(+), 13 deletions(-) diff --git a/documentos/proyecto/1.Infraestructura.md b/documentos/proyecto/1.Infraestructura.md index ded8173b..ae19996f 100644 --- a/documentos/proyecto/1.Infraestructura.md +++ b/documentos/proyecto/1.Infraestructura.md @@ -247,7 +247,7 @@ En [este vídeo se explica el concepto de producto mínimamente viable/milestone](https://www.youtube.com/watch?v=aEBv4dT7UGc&t=4s). Los recursos aportados por los estudiantes de la asignatura están -en [este fichero](1.Infraestructura.recursos). Puedes añadir algunos más que +en [este fichero](1.Infraestructura.recursos.md). Puedes añadir algunos más que te hayan ayudado si lo deseas. Como se va a empezar a revisar los PRs de los compañeros, conviene que [mires @@ -269,7 +269,7 @@ hagan mejoras en el PR, el estudiante deberá pedir explícitamente revisiones adicionales con un comentario en el mismo que diga "Listo para revisión". Subir los fuentes a GitHub y añadir al -[fichero](https://github.com/JJ/IV-/blob/master/proyectos/objetivo-1) el +[fichero](https://github.com/JJ/IV-/blob/master/proyectos/objetivo-1.md) el nombre del proyecto, el autor y un enlace al pull request mediante el cual se quiere alcanzar el objetivo y hacer un **pull request** al repositorio en el que se encuentra ese fichero. @@ -453,8 +453,14 @@ correspondiente de la asignatura. ## Plazo de entrega -El plazo para hacer la primera entrega termina **4 semanas** después del -comienzo de las clases. +El plazo aconsejado para hacer la primera entrega termina **4 +semanas** después del comienzo de las clases. En años anteriores, + +* el 50% lo había entregado en 18 días +* el 75% lo hizo en menos de 25 días +* el 90%, en la quinta semana desde el principio; +* todos los que aprobaron lo habían entregado ya dos meses después del + comienzo de las clases. Ningún estudiante que aprobó en la convocatoria ordinaria en cursos anteriores tardó más de 10 semanas en superar este objetivo. A partir @@ -464,13 +470,12 @@ superado. ## Corrección entre pares -A partir de este objetivo, se pondrá en práctica la asignación -aleatoria de revisores de cada PR entre los que ya lo hayan -superado. Cuando se haga el PR en el repositorio de la asignatura, se -sacarán hasta cinco nicks aleatoriamente entre las personas que hayan -superado ya el objetivo. No es obligatorio hacerlo para quien se -elija, pero sí se considerará positivamente en la nota final en el -apartado de aprendizaje autónomo. +A partir de este objetivo, se pondrá en práctica la asignación aleatoria de +revisores de cada PR entre los que ya lo hayan superado. Cuando se haga el PR en +el repositorio de la asignatura, se sacarán hasta cinco *nicks* +aleatoriamente. No es obligatorio hacer la revisión para quien se elija, pero sí +se considerará positivamente en la nota final en el apartado de aprendizaje +autónomo. > Que hagáis estas revisiones es fundamental para que entendáis bien > el concepto de historia de usuario, así como para poder elegir para @@ -480,8 +485,8 @@ apartado de aprendizaje autónomo. La aprobación final del objetivo es cosa del profesor, pero las revisiones que te hagan los compañeros podrán ayudar a que avances hacia la consecución del mismo en este objetivo y el resto. En este en concreto, como se ha repetido, -hace falta que *dos* estudiantes lo revisen y aprueben antes de que sea revisado -y aprobado por el profesor. +hace falta que al menos *dos* estudiantes lo revisen y aprueben antes de que sea +revisado y aprobado por el profesor. ## A donde ir desde aquí From fc567dde12c986161de3e139d7ddf94299581802 Mon Sep 17 00:00:00 2001 From: JJ Merelo Date: Tue, 19 Sep 2023 07:37:54 +0200 Subject: [PATCH 05/22] Sync documentos/proyecto/0.Repositorio.md de master a gh-pages --- documentos/proyecto/0.Repositorio.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/documentos/proyecto/0.Repositorio.md b/documentos/proyecto/0.Repositorio.md index 9e9ce917..3e3fa757 100644 --- a/documentos/proyecto/0.Repositorio.md +++ b/documentos/proyecto/0.Repositorio.md @@ -183,10 +183,10 @@ forma de una lógica de negocio. ### Cuál es el destino final del proyecto En los últimos objetivos, el proyecto será desplegado en la nube, tras la -descripción de la infraestructura virtual del mismo. El problema que se plantee -será tal que pueda ser resuelto de esa forma. No se requerirá que se resuelva el -problema *totalmente*, pero la mejor solución tiene que estar en una -infraestructura virtual en la nube. +descripción de la infraestructura virtual que necesitará para ello. El problema +que se plantee será tal que pueda ser resuelto de esa forma. No se requerirá que +se resuelva el problema *totalmente*, pero la mejor solución tiene que estar en +una infraestructura virtual en la nube. ### Preguntas frecuentemente preguntadas @@ -211,13 +211,13 @@ bien qué algoritmo se va a usar, o conjunto de procesamiento no trivial, para hallar la solución. También unos en los cuales una vez obtenido el resultado se pueda comprobar de forma más o menos independiente. -### ¿Qué tipo de problemas no van a ser adecuados? +#### ¿Qué tipo de problemas no van a ser adecuados? Todos los problemas que requieran entradas físicas; todos aquellos en los que el usuario o cliente tenga que introducir mucha información. En general, todo problema que no se entienda bien. -### ¿Tiene que haber algún negocio para que pueda llamarse lógica de *negocio*? +#### ¿Tiene que haber algún negocio para que pueda llamarse lógica de *negocio*? No. En inglés se usa a veces *business* para indicar la parte importante de algo, o la que hace el trabajo. Evidentemente, en una eventual publicación de la @@ -232,13 +232,13 @@ forma con la aplicación) y simples *usuarios* (que pueden beneficiarse o no, pero aportan información que pueda usarse para la lógica de negocio y por lo tanto el cliente). -### ¿Por qué necesita la lógica de negocio ser no trivial? +#### ¿Por es necesario que la lógica de negocio ser no trivial? Porque el estudiante tiene que programar esa lógica de negocio en los tests de los objetivos a partir del cuatro. Si es trivial, ni siquiera requiere tests; si es de almacena y busca, ni siquiera es lógica de negocio. -### ¿Puede alguna lógica de negocio ser inadecuada? +#### ¿Puede alguna lógica de negocio compleja ser inadecuada? Si requiere un modelo complejo del programa, o un algoritmo complejo para trabajar con ella, puede ser un problema, porque, insisto, *lo tiene que @@ -247,7 +247,7 @@ programar el estudiante*. Si requiere *predicción* y por tanto un algoritmo de programar el algoritmo. Se pueden usar, sin embargo, modelos ya entrenados siempre que esos modelos los programe uno. -### ¿Qué problemas serán adecuados para la nube? +#### ¿Qué problemas serán adecuados para la nube? Cualquiera que requiera muchos usuarios situados en muchos lugares diferentes, tendrán que desplegarse en la nube, siempre que los datos que necesite cada @@ -255,7 +255,7 @@ usuario estén en el servidor o bien proporcionados por el resto de usuarios. También los que usen datos agregados para generar información para otro cliente. -### ¿Cuáles serán inadecuados para una infraestructura virtual? +#### ¿Cuáles serán inadecuados para una infraestructura virtual? Las que estén dirigidas a un solo cliente, que tenga todos los datos necesarios para aplicar la lógica de negocio. From 8414eb0de551713229e31de5647c97dd484adb17 Mon Sep 17 00:00:00 2001 From: JJ Merelo Date: Tue, 19 Sep 2023 07:37:54 +0200 Subject: [PATCH 06/22] Sync documentos/proyecto/1.Infraestructura.md de master a gh-pages --- documentos/proyecto/1.Infraestructura.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/documentos/proyecto/1.Infraestructura.md b/documentos/proyecto/1.Infraestructura.md index ae19996f..6e12b301 100644 --- a/documentos/proyecto/1.Infraestructura.md +++ b/documentos/proyecto/1.Infraestructura.md @@ -221,6 +221,8 @@ el mismo todo lo que necesitemos en ese paso siguiente. ## Este objetivo es fundamental para el resto de la asignatura +> Como si hubiera alguno que no lo fuera... + Estamos en un proyecto que se irá desarrollando a lo largo de la asignatura, y esta es una parte esencial, la planificación del mismo. Esta planificación tendrá que servir para trabajar ya en el [siguiente objetivo](2.Modelo), From 26ad5c45b5ee09e81a6f9bb0acb5f28a066c69ca Mon Sep 17 00:00:00 2001 From: JJ Merelo Date: Tue, 19 Sep 2023 20:53:52 +0200 Subject: [PATCH 07/22] Sync documentos/proyecto/0.Repositorio.md de master a gh-pages --- documentos/proyecto/0.Repositorio.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/documentos/proyecto/0.Repositorio.md b/documentos/proyecto/0.Repositorio.md index 3e3fa757..304090b0 100644 --- a/documentos/proyecto/0.Repositorio.md +++ b/documentos/proyecto/0.Repositorio.md @@ -97,7 +97,12 @@ hallar una solución al mismo y mejor entenderás qué sería lo que lo solucion Otra cuestión es que ese problema /tenga entidad suficiente para poder crear, eventualmente, algún tipo de servidor que se pueda desplegar en la nube; es decir, tiene que tener descrita correctamente una **lógica de negocio**, que es -el código propio que resuelve el problema. +el código propio que resuelve el problema. El centrarnos en la lógica de negocio +(extraer información del texto de una página web *ya descargada*, por ejemplo) +en vez de en los aspectos mecánicos (cómo obtener el URL de la página y cómo +descargársela) permite que nos centremos en lo esencial de nuestro programa, que +es lo que añade valor al cliente (no el hecho de que uno se descargue una +página, o extraiga información de un API o como sea). > Propio quiere decir que toda la lógica de negocio tendrá que ser programada > por el estudiante, principalmente en el [objetivo 4](4.Tests), y de ahí en From 9d83ef61f5b743734f783cdb6e4ac5a92b5c165d Mon Sep 17 00:00:00 2001 From: JJ Merelo Date: Wed, 20 Sep 2023 08:33:11 +0200 Subject: [PATCH 08/22] :coffin: --- .../proyecto/1.Infraestructura.recursos.md | 16 -------------- documentos/proyecto/2.Tests.recursos.md | 21 ------------------- 2 files changed, 37 deletions(-) delete mode 100644 documentos/proyecto/1.Infraestructura.recursos.md delete mode 100644 documentos/proyecto/2.Tests.recursos.md diff --git a/documentos/proyecto/1.Infraestructura.recursos.md b/documentos/proyecto/1.Infraestructura.recursos.md deleted file mode 100644 index 1c4d80ba..00000000 --- a/documentos/proyecto/1.Infraestructura.recursos.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -layout: index - - ---- -# Recursos para el objetivo 1: Estructura general del proyecto - -## Introducción - -La descripción del hito está en [este documento](1.Infraestructura). Añadir -abajo, a través de un pull request, recursos que os hayan sido útiles para -resolver el mismo o que puedan ser útiles a algún compañero para resolver dudas -o sacar el hito adelante. - -Los PRs serán examinados y aceptados sólo si tienen relevancia -suficiente para el hito, y también entidad suficiente. diff --git a/documentos/proyecto/2.Tests.recursos.md b/documentos/proyecto/2.Tests.recursos.md deleted file mode 100644 index cbfdc4f1..00000000 --- a/documentos/proyecto/2.Tests.recursos.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -layout: index - - ---- -Segundo Hito: Tests -=================== - -Descripción ------------------ - -Recursos correspondientes al [segundo hito](2.Tests), sobre añadir -tests unitarios y código siguiendo la metodología TDD. - -Recursos --------- - -(Cread un subtítulo para cada lenguaje) - - - From 56cf82137a84e6bb4e9b6feb5a7ae78b281e010e Mon Sep 17 00:00:00 2001 From: JJ Merelo Date: Wed, 20 Sep 2023 08:39:45 +0200 Subject: [PATCH 09/22] Sync documentos/proyecto/1.Planificacion.md de master a gh-pages --- documentos/proyecto/1.Planificacion.md | 492 +++++++++++++++++++++++++ 1 file changed, 492 insertions(+) create mode 100644 documentos/proyecto/1.Planificacion.md diff --git a/documentos/proyecto/1.Planificacion.md b/documentos/proyecto/1.Planificacion.md new file mode 100644 index 00000000..40e09117 --- /dev/null +++ b/documentos/proyecto/1.Planificacion.md @@ -0,0 +1,492 @@ +--- +layout: index + + +--- +# Objetivo 1: Estructura general y planificación del proyecto + +## Descripción + +Se trata de empezar a planificar el proyecto que se va a ir elaborando durante +este curso, creando los hitos para organizar el trabajo en el mismo y +describiendo las *historias de usuario*, o qué es lo que cada cliente espera +alcanzar con el proyecto. Lo esencial en este objetivo es entender qué tipo de +proyectos se deben plantear para esta asignatura, describirlo correctamente en +el repositorio en GitHub y documentar el proyecto elegido y los pasos que se van +a dar en el mismo. + +Como en el [objetivo anterior](0.Repositorio), se aconseja vivamente la +**asistencia a clase** hasta la superación del mismo, para poder resolver sobre +la marcha las dudas que se planteen, recibir explicaciones genéricas que puedan +ayudar a la comprensión del mismo, así como sus diferentes subobjetivos. También +se podrá explicar conceptos anteriores a la asignatura que no estén del todo +claros. + +## Prerrequisitos + +El [objetivo 0](0.Repositorio) deberá haber pasado los tests en el +repositorio de la asignatura antes de poder avanzar a este. + +## TL;DR + +Hay que desarrollar la idea en una serie de *user journeys*; estos en +una serie de perfiles de usuario o *personas*, y a continuación crear +una serie de historias de usuario (HU). Se crearán también los hitos +(*milestones*) iniciales en el desarrollo, y habrá que asignar alguna +HU al milestone 0 para poder comenzar a trabajar en el objetivo +siguiente. + +## Introducción + +El desarrollo ágil está centrado en el cliente, e incluye una serie de +metodologías o buenas prácticas para poder llegar de los deseos del cliente a la +expresión de los mismos y de ahí, pasando por una serie de pasos intermedios, al +código que lo implementa. + +En este objetivo se busca que se entienda el sistema de desarrollo ágil en el +que se van elaborando, por iteraciones, versiones cada vez más avanzadas de un +proyecto/producto. + +Este sistema, como todos los sistemas de desarrollo, te ayuda a responder a +estas dos preguntas + +1. ¿Qué tengo que hacer ahora? +2. ¿Es correcta la solución que he planteado al problema que estoy resolviendo? + +Vamos a plantearnos en este objetivo, sobre todo, la respuesta a la primera +pregunta, es decir, plantear, a partir de la comprensión y la expresión de las +necesidades del cliente, la infraestructura del proyecto de forma que, en +cada momento, se sepa cómo uno mismo o la persona que se encargue de ello se +ponga a trabajar inmediatamente en lo que sea necesario *a continuación*. + +## Explicación + +Un *user journey* se correspondería con la fase de *empatizar* de *design +thinking*, y es un "viaje del usuario". Es decir, qué hace el usuario desde que +decide que va a usar la aplicación hasta que deja de usarla. En este *viaje* se +tendrían que incluir detalles sobre + +* Con qué frecuencia se usa +* En qué contexto +* Desde qué dispositivo (en general, esto no será relevante en esta asignatura) +* Qué pasos tiene que dar para obtener la solución a su problema + +No es lo mismo que se use desde un móvil que desde un portátil, o que se tenga +que usar con las manos libres. En todos los casos, hay implicaciones de diseño +que pueden llegar hasta la parte más profunda de la arquitectura. + +La implementación de historias de usuario se hará en una serie de *issues*, que +se agruparán en una serie de hitos o *milestones*. + +Hay que empezar a planificar la aplicación que resolverá el problema planteando: + +1. Historias de usuario. +2. Productos mínimamente viables, cada uno en su *milestone*. +3. Alguna HUs tendrá que asignarse al siguiente *milestone*, aunque se + podrán ir moviendo durante el avance del proyecto; de esta forma se + prioriza una HU frente a las otras para comenzar a desarrollar. + +En esta asignatura se desarrolla un proyecto. Este objetivo pretende cubrir la +organización de ese proyecto. Por lo tanto, hay que tratar de preguntarse, tras +la elaboración de HUs y *milestones*, si una persona ajena al mismo sería capaz +de comenzar el desarrollo en base a la información proporcionada. + +En este objetivo se empiezan a contestar las dos preguntas fundamentales de +cualquier metodología de desarrollo: + +1. *¿Qué hago ahora?* Habrá que empezar por el milestone 0, seguir por + el número 1 y comenzar por abordar una de las historias de usuario, + priorizándolas frente a las demás. +2. *¿Lo que hago está bien?* Estará si es viable según lo definido en cada + producto mínimamente viable, y en las historias de usuario se dirá qué es lo + que quiere el cliente; siempre habrá que avanzar para satisfacer al cliente. + +La metodología de esta asignatura está basada en la realización incremental, a +lo largo de los hitos de la misma, de un proyecto personal que se desplegará en +la nube, que sería (en general, o podría ser) parte de una aplicación más +grande. Por ello hay que empezar por el principio: perfilar ese proyecto como +solución al problema o como desarrollo de la idea que se ha planteado en el +[objetivo 0](0.Repositorio). + +El proceso, por tanto, que se suele seguir (y el que se tiene que +seguir para alcanzar este objetivo) es el siguiente: + +1. Partir del problema que se quiere resolver, objetivo que se tiene que haber + alcanzado previamente. +2. Seguir un proceso para entender los diferentes tipos de usuario que + necesitan una solución a ese problema, que serán siempre usuarios + que obtendrán *algún tipo de beneficio* con la solución del + mismo. Por ejemplo, un usuario quiere adquirir complementos que + sean adecuados para las prendas ya adquiridas. El beneficio que + quiere obtener es ese: máxima adecuación de los complementos. Otra + usuaria quiere saber cuales son las tendencias en búsqueda de + complementos para diseñar una estrategia de marca. Ese es el + beneficio que quiere obtener, y habrá que proporcionarle una + solución. +3. Los *deseos* de estos usuarios, es decir, los problemas que quieren que la + aplicación les resuelva, se tienen que resumir en las *historias de + usuario*. Tendrá que crearse alguna historia de usuario, especialmente las + que se consideren fundamentales para comenzar el desarrollo. Las historias de + usuario siempre expresan deseos y beneficios, están relacionadas con la + lógica de negocio y están en el dominio del problema. Dado que se ha hecho + énfasis en el objetivo anterior en que se trate de personas reales, aquí + ayuda si estás pensando en una persona específica, la que quiere que se + resuelva el problema, y le pongas el nombre de esa persona. +4. Finalmente, los diferentes productos que se van a entregar a estos clientes + (o al equipo de desarrollo antes de desarrollar los productos que se vayan a + entretar al cliente) se tendrán que describir en una serie de hitos o + *milestones*, en cada uno de los cuales se entregará un producto mínimamente + viable. El desarrollo ágil se basa en un método iterativo en el que se mejora + un producto, siempre con la aprobación del usuario. Por lo tanto, tendrá que + haber al menos un par de milestones que refleje los diferentes productos que + se van a entregar y que vayan agrupando las historias de usuario y los + diferentes *issues* que se saquen de las historias de usuario. + +Las historias de usuario son fundamentales, porque si no se expresa bien lo que +el usuario quiere hacer y ver, no se pueden hacer pruebas para comprobar que +efectivamente eso se está haciendo correctamente, lo que correspondería a la +pregunta dos que se ha hecho anteriormente. Estas especificaciones, en forma de +historias de usuario, se tendrán que documentar *en un issue de GitHub*. Los +issues del proyecto que sean historias de usuario tienen que tener dos +características: + +* Incluir `[HUxxx]` (comenzando a contar por 1) en la descripción del issue para + que se identifique claramente que se trata de ese tipo de issue. No todos los + issues tienen que ser historias de usuario, pero los issues que sirvan para ir + avanzando en la implementación de una historia de usuario se referirán siempre + a la historia de usuario correspondiente. +* Estas HUs se numeran desde uno, para ayudar a identificarlas y a referirse a + ellas en la documentación. +* Usar un `label` `user-stories`. Esta etiqueta no es de las que hay + por defecto en los proyectos de GitHub, así que habrá que + añadirla. + +Es muy importante que tengáis en cuenta que estas historias de usuario deben +*realmente* de guiar el desarrollo del proyecto, es decir, deben contener la +información suficiente para que se comience el desarrollo a partir de ellas. + +### Qué son los hitos o *milestones* + +En programación no se empieza a hacer lo primero que se le ocurre a uno +(especialmente *no* el *login* del usuario en la aplicación); como se ha dicho +más arriba, se tiene que aplicar una metodología que nos ayude en cada momento a +decidir qué se va a hacer a continuación. Pero se comienza por algún lugar +específico, que permita al equipo ir avanzando y cubriendo etapas de desarrollo; +cada una de esas etapas avanza en la comprensión del problema y se acerca más a +la solución que se entrega al usuario. + +> En general, estos hitos los elaborará un *product manager* o gestor +> de producto en una empresa de mediana complejidad; sin embargo, es +> conveniente que se entienda en qué consisten y cómo se pueden llevar +> a cabo. + +Los *milestones* son herramientas para comenzar a trabajar y organizar +el trabajo con un objetivo claro en cada fase, lo que ocurrirá ya en +el siguiente objetivo; por eso habrá que plantear los suficientes para +poder hacerlo, pero nunca más de los que se puedan abordar en la +asignatura. + +> En general, en desarrollo ágil se van decidiendo cuales son los +siguientes productos mínimamente viables durante el desarrollo del +anterior, así que programas más allá de los dos *milestones* +siguientes no merece la pena. + +Como todo el resto de los objetivos de aprendizaje, no se trata de un +ejercicio académico, se trata de que mostréis que sois capaces de +planificar un proyecto, dividiéndolo en diferentes etapas, y que estas +sean realistas y alcanzables dentro del marco temporal de la +asignatura. + +> En la mayor parte de los casos, no se podrá resolver los problemas +> que se expresan en las historias de usuario, porque no se hará +> ningún interfaz de cara al mismo. Sin embargo, con los *milestones* +> diseñados se tratará de probar que efectivamente se sabe avanzar +> hacia eso. + +Los productos son siempre *entregables*. No son conceptos, hay que +explicar qué es lo que se va entregar, cómo se sabe que es válido y el +soporte concreto que va a tener. Lo esencial, en todo caso, es leer +atentamente los milestones que se han entregado y *verse uno mismo* +llevando a cabo el desarrollo del producto, sin ningún (o muy poco) +material adicional. + +Los milestones generalmente se van a numerar desde el cero, donde el cero será +uno "interno", el primero que se va a llevar a cabo. + +Y en este milestone lo fundamental será entender el problema, porque +sin una modelización del mismo será imposible comenzar a +programarlo. Este *milestone* incluirá todo lo necesario para poder +comenzar a trabajar con el siguiente, en el que se implementa la +lógica de negocio; por eso lo esencial es incluir como *entregable* en +el mismo todo lo que necesitemos en ese paso siguiente. + +## Este objetivo es fundamental para el resto de la asignatura + +> Como si hubiera alguno que no lo fuera... + +Estamos en un proyecto que se irá desarrollando a lo largo de la asignatura, y +esta es una parte esencial, la planificación del mismo. Esta planificación +tendrá que servir para trabajar ya en el [siguiente objetivo](2.Modelo), +pero también en todos los objetivos siguientes. Los entregables/productos +mínimamente viables se repartirán entre varios objetivos, pero tendrán +eventualmente que entregarse, y las historias de usuario se tendrán que +desarrollar en issues (que expresan problemas) para eventualmente expresarse en +código, que será lo que se entregue en los diferentes objetivos. + +Por tanto, es esencial que estos milestones e historias de usuario contengan +toda la información suficiente para que alguien, que será otra persona, se pueda +poner a trabajar. + +## Información adicional + +Se pueden consultar el siguientes tema del [curso +0](https://jj.github.io/curso-tdd) sobre cómo especificar los +[requisitos](https://jj.github.io/curso-tdd/temas/dise%C3%B1o.html) y +qué hacer para diseñar los primeros pasos de una aplicación y cómo +diseñar las [*personas*](https://jj.github.io/curso-tdd/temas/ddd) que +van a usar la aplicación. + +En [este vídeo se explica el concepto de producto mínimamente +viable/milestone](https://www.youtube.com/watch?v=aEBv4dT7UGc&t=4s). + +Como se va a empezar a revisar los PRs de los compañeros, conviene que [mires +este material sobre le +mismo](https://jj.github.io/curso-tdd/temas/revisiones.html). + +## Entrega de la práctica + +Como en toda esta asignatura, siempre se incorporará código al repositorio +propio usando *pull requests*. *Todo* el material necesario para alcanzar a este +objetivo estará en un PR, que tendrá que ser aprobado por el profesor (lo que +indicará que el objetivo se ha alcanzado). En este objetivo 1 se anima a los +estudiantes a que comenten, e incluso aprueben, PRs de otros compañeros, aunque +la aprobación definitiva tiene que venir del profesor. + +**Importante**: el título de este *pull request* **tiene* que incluir la cadena +`[IV-23-24]` para que pueda filtrar fácilmente los mensajes recibidos. Cuando se +hagan mejoras en el PR, el estudiante deberá pedir explícitamente revisiones +adicionales con un comentario en el mismo que diga "Listo para revisión". + +Subir los fuentes a GitHub y añadir al +[fichero](https://github.com/JJ/IV-/blob/master/proyectos/objetivo-1.md) el +nombre del proyecto, el autor y un enlace al pull request mediante el cual se +quiere alcanzar el objetivo y hacer un **pull request** al repositorio en el que +se encuentra ese fichero. + +Los avances en todos los aspectos de cara al público del proyecto se +reflejarán en el fichero `README.md` del mismo, que tendrá que estar +estructurado como una descripción del proyecto, y *con enlaces* a +información adicional requerida por el profesor para su +corrección. Esta información adicional *deberá* estar enlazada desde +el README, y en un directorio `docs` escrita en Markdown. + +> El `README` no debe incluir pantallazos ni nada que no sea +> estrictamente descripción del proyecto en el hito en el que se +> encuentre en ese momento. + +Como mínimo, y para pasar los tests, esta entrega incluirá + +* Un subdirectorio `docs` donde se pondrá material adicional (que se + tendrá que enlazar desde el `README` en el apartado que se esté + corrigiendo en ese momento). +* Al menos una "historia de usuario" en un issue de la + forma descrita más arriba, es decir, con la cadena HU en la + descripción y la etiqueta user-stories. +* Uso de *issues* para añadir siempre código al repositorio. Los issues + se cerrarán, cuando se hayan cumplido, *siempre* con un commit. En + este objetivo no hay que añadir todavía nada de código, queda fuera + del ámbito del mismo, pero es una práctica que hay que respetar a + partir de ahora. +* Varios *milestones*, los que se considere suficientes. Para pasar los tests + tiene que haber al menos dos. +* El `README` tiene que seguir reflejando el estado del proyecto. En este caso, + habrá al menos que enlazar cómo se ha planificado el mismo con algún tipo de + justificación adicional que sea conveniente. +* Finalmente, este objetivo tendrá que ser revisado por al menos dos personas + aparte del profesor (salvo las dos-tres primeras personas que lo entreguen) + antes de ser aceptado; una vez que te lo hayan aceptado, *deberás* revisar los + PRs de compañeros que se te asignen. Las revisiones, como figura en la guía + docente, se califican dentro del apartado de "aprendizaje autónomo". + +**Se ruega no hacer push a la rama que ya se haya revisado hasta que +no se hayan hecho todas las revisiones solicitadas por el +profesor**. Adicionalmente, se puede pasar el PR a "borrador" +(*draft*) y no revertir a "listo para revisar" hasta que no se haya +hecho. + +Igual que en el objetivo anterior, hay un tiempo limitado para hacer +la entrega; por eso se aconseja que se asista a clase y se utilice el +tiempo de la misma para trabajar en el objetivo, de forma que el +profesor pueda guiar hacia su consecución, corregirlo sobre la marcha +*tras la entrega y admisión del PR*, o dar consejos o sugerencias de +material adicional. No es buena idea abandonar la clase cuando +terminen "las explicaciones", porque se harán explicaciones en clase +en cualquier momento según lo solicite uno o varios estudiantes. + +En el siguiente objetivo hay que trabajar en equipo, por lo que es +esencial que se llege a él de forma más o menos simultánea. + +## Preguntas frecuentemente preguntadas + +### ¿Qué se considera un producto? + +En general, no será producto si no implica, para alcanzarlo, cambios en el +repositorio, y se describe como tal, es decir, como algo físico, que está +empaquetado y se va a enregar al resto del equipo o al cliente. En el +repositorio hay ficheros de diferente tipo, pero generalmente se tratará de +código organizado siguiendo las buenas prácticas. + +No es lo único necesario para que sea un producto; tendrá que decirse también +ese código (o conjunto de código y otros artefactos) cómo se tiene +que entregar y qué lo hace válido. + +Que sea lo mínimo que resuelve los *issues* correspondientes está implícito, +pero también hay que tenerlo en cuenta a la hora de describirlo con claridad y +precisión, para que quede claro cuál es el ámbito de acción de cada hito. + +### ¿Qué no se considera un producto? + +Nada que no lo sea. Un diseño no es un producto (lo será un fichero en un +formato estándar que se pueda usar directamente); un modelo tampoco (lo será una +implementación del modelo, presentada como se ha comentado en la pregunta +anterior). Una estructura de datos o función no son un +producto. Tendrá que describirse claramente cómo se va a entregar ese +código para que constituya un producto. + +## Listas de comprobación + +A partir de este objetivo, deberás *comprobar* que la respuesta a +estas preguntas es positiva. Ante la duda o la posible ambigüedad, +explica claramente qué has hecho en ese aspecto. Si no lo es, tendrás +que pensar que alguno de los conceptos no los entiendes muy bien y +tendrás que replantearte la formulación correspondiente. Están +puestas aquí para que las copies y pegues en el cuerpo del PR que +hagas en tu propio repositorio. + +Si te toca revisar el objetivo de un compañero/a, esta lista de comprobación tiene +ser la guía para que compruebes si el compañero/a lo ha hecho correctamente. + +### Sobre los milestones + +```plain +* [ ] ¿Las historias de usuario y los milestones constituyen una guía + suficiente para poder comenzar el desarrollo de un proyecto? +* [ ] ¿Los milestones están ordenados correctamente, de forma que el 1 o + 0 sea lo primero que hay que empezar a publicar? +* [ ] ¿Todos los milestones se construyen sobre el anterior, teniendo un + orden lógico el desarrollo? +* [ ] ¿El milestone 0 tiene asignada alguna historia de usuario? +* [ ] ¿El milestone 0 corresponde con lo mencionado varias veces en + clase, y en concreto con lo que se solicita en el objetivo + siguiente? +* [ ] ¿Todos los milestones describen correctamente un producto y qué + lo hace válido, y no un concepto vago, una funcionalidad o una tarea? +* [ ] ¿Los milestones son graduales, o hay un salto grande entre ellos? +* [ ] ¿Los milestones iniciales son internos, y hay a continuación milestones o + productos externos? +* [ ] ¿Los milestones son mínimos, es decir, incluyen un producto + mínimamente viable para poder avanzar? +* [ ] ¿El milestone 0 es mínimo *y* viable? +* [ ] ¿Se indica claramente cómo comprobar la viabilidad del PMV de cada hito? Es + decir, ¿se dice qué requisitos técnicos tiene que cumplir el producto de + cada hito? +* [ ] ¿Entre dos milestones consecutivos, no hay ningún PMV posible o por el + contrario podrían desarrollarse muchas posibles etapas internas o externas + de un proyecto? +``` + +### Sobre las historias de usuario + +```plain +* [ ] ¿He tenido en cuenta en las historias de usuario que se trata de un + proyecto que se desplegará en la nube? +* [ ] ¿Están descritos todos los conceptos mencionados en las HUs con + suficiente claridad, generalmente en documentos aparte? +* [ ] ¿Tienen coherencia suficiente las historias de usuario, y en caso + de que no lo tengan, se ha escrito un *user journey* para + aclararlo? +* [ ] ¿Todas las historias de usuario representan un beneficio para el + mismo y se relacionan con la lógica de negocio? Es decir, ¿los usuarios + *desean* hacerlo o tú deseas que el usuario te lo pida para hacerlo? +``` + +### Resumen + +En general, la pregunta sería: si entregara estos hitos y milestones +a otra persona, ¿sería capaz de ponerse a desarrollar empezando por el +primero y creando issues para el desarrollo del mismo? + +## Material adicional + +Se puede consultar [la presentación sobre historias de +usuario](../../preso/hu.html) y sobre [productos mínimamente +viables](../../preso/pmv.html). + +## Objetivo alcanzado + +Se habrá alcanzado este objetivo si pasa los tests automáticos, y: + +1. Se siguen usando las buenas prácticas. +2. Se muestra claramente que se ha comprendido el objetivo de la asignatura y + que el proyecto, que aquí se tiene que comenzar a organizar y desglosar, + corresponde a este objetivo. +3. Se han creado historias de usuario escritas para empezar a trabajar a + partir de ellas, y están reflejadas en los *issues* de GitHub que estén marcados + como se ha indicado más arriba; por supuesto, enlazadas desde el + `README.md` (y también descritos en el PR). +4. Las historias de usuario están agrupadas en (al menos) un par de hitos o + *milestones* (y también están descritos en el PR). +5. Si los milestones describen productos mínimamente viables y están + ordenados correctamente. +6. Al menos dos compañeros/as han aprobado este PR (con excepciones en las + primeras entregas). + +En todo caso, y como en todos los objetivos, se tendrá que esperar a +que el profesor apruebe el PR en el repositorio del proyecto para +considerarlo alcanzado. + +## Valoración + +El alcanzar este objetivo avanzará, en principio, 7.5% del apartado +correspondiente de la asignatura. + +## Plazo de entrega + +El plazo aconsejado para hacer la primera entrega termina **4 +semanas** después del comienzo de las clases. En años anteriores, + +* el 50% lo había entregado en 18 días +* el 75% lo hizo en menos de 25 días +* el 90%, en la quinta semana desde el principio; +* todos los que aprobaron lo habían entregado ya dos meses después del + comienzo de las clases. + +Ningún estudiante que aprobó en la convocatoria ordinaria en cursos +anteriores tardó más de 10 semanas en superar este objetivo. A partir +de la 9ª semana del comienzo, sería mejor que planificaras el resto de +la asignatura para la convocatoria extraordinaria si todavía no lo has +superado. + +## Corrección entre pares + +A partir de este objetivo, se pondrá en práctica la asignación aleatoria de +revisores de cada PR entre los que ya lo hayan superado. Cuando se haga el PR en +el repositorio de la asignatura, se sacarán hasta cinco *nicks* +aleatoriamente. No es obligatorio hacer la revisión para quien se elija, pero sí +se considerará positivamente en la nota final en el apartado de aprendizaje +autónomo. + +> Que hagáis estas revisiones es fundamental para que entendáis bien +> el concepto de historia de usuario, así como para poder elegir para +> el próximo objetivo algún proyecto con el que tengáis ya cierta +> familiaridad. + +La aprobación final del objetivo es cosa del profesor, pero las revisiones que +te hagan los compañeros podrán ayudar a que avances hacia la consecución del +mismo en este objetivo y el resto. En este en concreto, como se ha repetido, +hace falta que al menos *dos* estudiantes lo revisen y aprueben antes de que sea +revisado y aprobado por el profesor. + +## A donde ir desde aquí + +Si has terminado, comienza con [el siguiente](2.Modelo). From fcd81f3502b1d65a66d70fef9c95481c2f0e75a9 Mon Sep 17 00:00:00 2001 From: JJ Merelo Date: Wed, 20 Sep 2023 08:40:29 +0200 Subject: [PATCH 10/22] Sync index.md de master a gh-pages --- index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.md b/index.md index b2693e64..aceddce5 100644 --- a/index.md +++ b/index.md @@ -78,7 +78,7 @@ organizarán de la forma siguiente. 1. [Objetivo cero: Uso básico de herramientas, problema a resolver](documentos/proyecto/0.Repositorio). 2. [Historias de usuario y - planificación](documentos/proyecto/1.Infraestructura). + planificación](documentos/proyecto/1.Planificacion). 3. [Modelización del problema](documentos/proyecto/2.Modelo). 4. [Automatización de las tareas](documentos/proyecto/3.Automatizar). 5. [Tests unitarios para la clase/s diseñadas](documentos/proyecto/4.Tests). From bdfc715c9f13ec6d10ed0e32612be892e5b2dedc Mon Sep 17 00:00:00 2001 From: JJ Merelo Date: Wed, 20 Sep 2023 08:42:42 +0200 Subject: [PATCH 11/22] Sync index.md de master a gh-pages --- index.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/index.md b/index.md index aceddce5..3f357857 100644 --- a/index.md +++ b/index.md @@ -24,7 +24,8 @@ asistencia a todas las clases para realizar las prácticas in situ. > Las clases de cursos anteriores están grabadas, y puedes acceder a ellas [en > esta lista de reproducción de -> YouTube](https://www.youtube.com/playlist?list=PLsYEfmwhBQdKIwbMDIwK64pt3Fs03BDz9). +> YouTube](https://www.youtube.com/playlist?list=PLsYEfmwhBQdKIwbMDIwK64pt3Fs03BDz9). Conviene +> que te refieras a ellas *sólo para los conceptos*, no para los temas administrativos. Se usará [GitHub](https://github.com) para el proyecto, la forma principal de examinar la asignatura; llamaremos *objetivos* a cada una de las entregas que hay From c9a3730587b0e96d82eb8acbe8a452c24ee11fdd Mon Sep 17 00:00:00 2001 From: JJ Merelo Date: Wed, 20 Sep 2023 09:03:43 +0200 Subject: [PATCH 12/22] Sync index.md de master a gh-pages --- index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/index.md b/index.md index 3f357857..abb70f5c 100644 --- a/index.md +++ b/index.md @@ -28,8 +28,8 @@ asistencia a todas las clases para realizar las prácticas in situ. > que te refieras a ellas *sólo para los conceptos*, no para los temas administrativos. Se usará [GitHub](https://github.com) para el proyecto, la forma principal de -examinar la asignatura; llamaremos *objetivos* a cada una de las entregas que hay -que hacer del mismo. +examinar la asignatura; cada una de las entregas representan haber alcanzado +objetivos de aprendizaje, y por lo tanto se denominan *objetivos*. Los materiales de la asignatura están enlazados desde abajo y disponibles con una licencia libre. Los fuentes de los mismos están en From 54aeeb29299135f952cb97bd0cf3940468816183 Mon Sep 17 00:00:00 2001 From: JJ Merelo Date: Wed, 20 Sep 2023 09:15:45 +0200 Subject: [PATCH 13/22] Sync index.md de master a gh-pages --- index.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/index.md b/index.md index abb70f5c..00aa9cbf 100644 --- a/index.md +++ b/index.md @@ -25,7 +25,8 @@ asistencia a todas las clases para realizar las prácticas in situ. > Las clases de cursos anteriores están grabadas, y puedes acceder a ellas [en > esta lista de reproducción de > YouTube](https://www.youtube.com/playlist?list=PLsYEfmwhBQdKIwbMDIwK64pt3Fs03BDz9). Conviene -> que te refieras a ellas *sólo para los conceptos*, no para los temas administrativos. +> que te refieras a ellas *sólo para los conceptos*, no para los temas +> administrativos. Se usará [GitHub](https://github.com) para el proyecto, la forma principal de examinar la asignatura; cada una de las entregas representan haber alcanzado From 57e36c6ac2064fc8c70f8c8b1307c71a1040d579 Mon Sep 17 00:00:00 2001 From: JJ Merelo Date: Wed, 20 Sep 2023 09:42:39 +0200 Subject: [PATCH 14/22] Sync documentos/proyecto/0.Repositorio.md de master a gh-pages --- documentos/proyecto/0.Repositorio.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/documentos/proyecto/0.Repositorio.md b/documentos/proyecto/0.Repositorio.md index 304090b0..a404921f 100644 --- a/documentos/proyecto/0.Repositorio.md +++ b/documentos/proyecto/0.Repositorio.md @@ -385,13 +385,13 @@ procedimiento. será lo que se entregará. Una vez hecho lo anterior, se añadirá [al fichero de entrega del -proyecto](https://github.com/JJ/IV-/blob/master/proyectos/objetivo-0.md), -en la fila correspondiente (que estará ya pre-rellena con tu nombre), el nombre -del proyecto, un enlace *al PR que has creado desde una rama de tu repositorio* -y una versión, *que seguirá el formato estándar* `vx.y.z`, llamado [versionado -semántico](https://semver.org/lang/es/). Para enviar este PR crearás también una -rama específica del repositorio de la asignatura, y harás un nuevo PR desde la -misma. +proyecto](https://github.com/JJ/IV-/blob/master/proyectos/objetivo-0.md), en la +fila correspondiente (que estará ya pre-rellena con tu nick de GitHub si lo has +proporcionado), el nombre del proyecto, un enlace *al PR que has creado desde +una rama de tu repositorio* y una versión, *que seguirá el formato estándar* +`vx.y.z`, llamado [versionado semántico](https://semver.org/lang/es/). Para +enviar este PR crearás también una rama específica del repositorio de la +asignatura, y harás un nuevo PR desde la misma. > Por si queda poco claro, son dos PRs en **dos** repositorios diferentes. Uno > en tu repositorio, desde una rama creada específicamente para cada objetivo a From 15658f62d0a12b1427ded4ab70cd9e42df5df92b Mon Sep 17 00:00:00 2001 From: JJ Merelo Date: Wed, 20 Sep 2023 09:44:39 +0200 Subject: [PATCH 15/22] Sync index.md de master a gh-pages --- index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/index.md b/index.md index 00aa9cbf..6e5390b8 100644 --- a/index.md +++ b/index.md @@ -24,8 +24,8 @@ asistencia a todas las clases para realizar las prácticas in situ. > Las clases de cursos anteriores están grabadas, y puedes acceder a ellas [en > esta lista de reproducción de -> YouTube](https://www.youtube.com/playlist?list=PLsYEfmwhBQdKIwbMDIwK64pt3Fs03BDz9). Conviene -> que te refieras a ellas *sólo para los conceptos*, no para los temas +> YouTube](https://www.youtube.com/playlist?list=PLsYEfmwhBQdKIwbMDIwK64pt3Fs03BDz9). +> Conviene que te refieras a ellas *sólo para los conceptos*, no para los temas > administrativos. Se usará [GitHub](https://github.com) para el proyecto, la forma principal de From 9ca16308eba50aadac7d077b89500cc84d054153 Mon Sep 17 00:00:00 2001 From: JJ Merelo Date: Wed, 20 Sep 2023 09:46:32 +0200 Subject: [PATCH 16/22] :see_no_evil: --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 7eb39484..e5cbda16 100644 --- a/.gitignore +++ b/.gitignore @@ -5,3 +5,4 @@ node_modules/ fatlib/ .idea .Rproj.user +.RData \ No newline at end of file From cf834b1c94b34fdfe6798cda4e5115c15b5829c4 Mon Sep 17 00:00:00 2001 From: JJ Merelo Date: Wed, 20 Sep 2023 09:47:53 +0200 Subject: [PATCH 17/22] Sync documentos/proyecto/0.Repositorio.md de master a gh-pages --- documentos/proyecto/0.Repositorio.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/documentos/proyecto/0.Repositorio.md b/documentos/proyecto/0.Repositorio.md index a404921f..ac5b61b3 100644 --- a/documentos/proyecto/0.Repositorio.md +++ b/documentos/proyecto/0.Repositorio.md @@ -32,7 +32,7 @@ llevar a cabo su desarrollo durante el resto de la asignatura. Hago énfasis en *el resto de la asignatura*. *Realmente* tendrás que intentar desarrollar un producto que resuelva parcialmente el problema que has planteado -aquí. En el [siguiente objetivo](1.Infraestructura) tendrás que plantar los +aquí. En el [siguiente objetivo](1.Planificacion) tendrás que plantar los hitos de desarrollo del proyecto y plasmar las necesidades del usuario, y en el [segundo objetivo](2.Modelo) comenzar a modelizar el problema de forma que se pueda empezar a trabajar en él en los objetivos siguientes. @@ -532,7 +532,7 @@ A partir de la entrega, si se tarda más de 17 días en superar el objetivo la ## A donde ir desde aquí Una vez entregado, puedes comenzar por tu cuenta con [el -siguiente](1.Infraestructura) objetivo. Puedes tener todos los PRs +siguiente](1.Planificacion) objetivo. Puedes tener todos los PRs que desees abiertos en tu repositorio. Se aconseja en todo caso que se inicie el trabajo en ese objetivo From c7554f75b337be3e66f99f6595e17ea6b96c2fd4 Mon Sep 17 00:00:00 2001 From: JJ Merelo Date: Wed, 20 Sep 2023 09:47:53 +0200 Subject: [PATCH 18/22] Sync documentos/proyecto/2.Modelo.md de master a gh-pages --- documentos/proyecto/2.Modelo.md | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/documentos/proyecto/2.Modelo.md b/documentos/proyecto/2.Modelo.md index d697dd61..8c0c65ca 100644 --- a/documentos/proyecto/2.Modelo.md +++ b/documentos/proyecto/2.Modelo.md @@ -11,7 +11,7 @@ Se trata de entender el paso de historias de usuario al diseño inicial del código, con las estructuras de datos y posiblemente constantes necesarias para comenzar la implementación. Este paso incluye *un modelo del problema*, con lo que es esencial comprender las historias de usuario planteadas en el [objetivo -1](1.Infraestructura) y partir de las mismas para poder resolver el problema. +1](1.Planificacion) y partir de las mismas para poder resolver el problema. Como en todos los objetivos hasta ahora, se considera imprescindible la **asistencia a clase**, ya que la metodología en la asignatura está centrada en @@ -21,7 +21,7 @@ presenta una serie de ventajas insustituibles. ## Prerrequisitos -Se tendrá que haber avanzado en el [objetivo 1](1.Infraestructura) hasta +Se tendrá que haber avanzado en el [objetivo 1](1.Planificacion) hasta haber superado los tests antes de poder entregar este. ## TL;DR @@ -43,7 +43,7 @@ trabajando. Tanto la modelización como las estructuras de datos diseñadas en sí tendrán que hacerse teniendo en cuenta las historias de usuario creadas en el [objetivo -1](1.Infraestructura). El desarrollo ágil está centrado en el cliente, y el +1](1.Planificacion). El desarrollo ágil está centrado en el cliente, y el código que se añada al repositorio *siempre* tiene que añadir valor al cliente (cuyos deseos están representados en las historias de usuario). @@ -454,7 +454,7 @@ revisión del código, y si es pertinente, cambios en las historias de usuario o sesión de preguntas y respuestas donde quien desarrolla te pregunta "qué quieres hacer" y tú lo dices (salvo en el caso del lenguaje de programación, donde tendrá que haber un consenso). Las historias de usuario creadas en el [objetivo -1](1.Infraestructura) *deben ser guía suficiente* para los dos retos +1](1.Planificacion) *deben ser guía suficiente* para los dos retos esenciales en el desarrollo: ¿Qué hay que hacer *ahora*? Y ¿Lo que hago está bien?. @@ -532,6 +532,15 @@ días**. Este objetivo es crítico para la comprensión y la superación de la asignatura, por eso se recomienda que se le preste la máxima atención y se trate de que no transcurran más de **dos semanas** entre entrega y superación del mismo. +El plazo de entrega aconsejado es de **siete semanas** a partir del +comienzo de las clases; en años anteriores, entre los que aprobaron + +* el 50% lo había entregado en 6 semanas, +* el 75% en 7 semanas, +* el 90% en 9 semanas; +* todos los aprobados lo habían entregado ya a las 13 semanas del + comienzo del curso. + ## Valoración El alcanzar este objetivo avanzará, en principio, 15% de la nota del apartado From 6b8b1ddc8945201e8d8659414df262ebf92f852f Mon Sep 17 00:00:00 2001 From: JJ Merelo Date: Wed, 20 Sep 2023 11:48:15 +0200 Subject: [PATCH 19/22] Sync documentos/proyecto/0.Repositorio.md de master a gh-pages --- documentos/proyecto/0.Repositorio.md | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/documentos/proyecto/0.Repositorio.md b/documentos/proyecto/0.Repositorio.md index ac5b61b3..a8606f5d 100644 --- a/documentos/proyecto/0.Repositorio.md +++ b/documentos/proyecto/0.Repositorio.md @@ -27,7 +27,7 @@ prácticas que puedan retrasar la aceptación de los siguientes objetivos. ## TL;DR -Pensar en una idea o problema a resolver que tenga entidad suficiente para poder +Pensar en un problema a resolver que tenga entidad suficiente para poder llevar a cabo su desarrollo durante el resto de la asignatura. Hago énfasis en *el resto de la asignatura*. *Realmente* tendrás que intentar @@ -129,8 +129,13 @@ añadido en forma de lógica de negocio, y que se describa correctamente el problema a solucionar de forma que haga falta tal lógica de negocio para solucionarlo. -En general, la descripción de la solución del problema (que tiene que pasar por -la lógica de negocio) debe: +En este objetivo no se pide que se especifique la solución al problema. Sin +embargo, sí habrá que hacerlo más adelante y si se trata de un problema cuyas +posibles soluciones no sean válidas para esta asignatura, se rechazará en este +objetivo. Por eso hay que pensar en la solución al problema, y en caso de que no +quede claro su entidad por la sola descripción del mismo, especificarlo. Y esta +descripción (que tiene que pasar por la lógica de negocio), sea explícitamente +porque sea necesaria en este objetivo, o en objetivos siguientes, debe: * Incluir palabras como *calcular*, *generar*, *procesar*, *predecir*, *visualizar* (teniendo en cuenta en esta última que se va a hacer en el From cec5e149891177b16464a5d8f6effdc0077b0392 Mon Sep 17 00:00:00 2001 From: JJ Merelo Date: Wed, 20 Sep 2023 11:51:17 +0200 Subject: [PATCH 20/22] Sync documentos/proyecto/0.Repositorio.md de master a gh-pages --- documentos/proyecto/0.Repositorio.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/documentos/proyecto/0.Repositorio.md b/documentos/proyecto/0.Repositorio.md index a8606f5d..36c27f6d 100644 --- a/documentos/proyecto/0.Repositorio.md +++ b/documentos/proyecto/0.Repositorio.md @@ -32,10 +32,11 @@ llevar a cabo su desarrollo durante el resto de la asignatura. Hago énfasis en *el resto de la asignatura*. *Realmente* tendrás que intentar desarrollar un producto que resuelva parcialmente el problema que has planteado -aquí. En el [siguiente objetivo](1.Planificacion) tendrás que plantar los -hitos de desarrollo del proyecto y plasmar las necesidades del usuario, y en el -[segundo objetivo](2.Modelo) comenzar a modelizar el problema de forma que -se pueda empezar a trabajar en él en los objetivos siguientes. +aquí. En el [siguiente objetivo](1.Planificacion) tendrás que plantear los +hitos de desarrollo del proyecto y reflejar con más detalle qué problemas se van +a resolver y para qué clientes y plasmar las necesidades del usuario, y en el +[segundo objetivo](2.Modelo) comenzar a modelizar el problema de forma que se +pueda empezar a trabajar en él en los objetivos siguientes. > En este caso, *no necesariamente* trabajarás en *tu* problema, sino en otro de > otro estudiante de la asignatura. From 035b79ee3b26db3af085fce660be13a5c843c50e Mon Sep 17 00:00:00 2001 From: JJ Merelo Date: Thu, 21 Sep 2023 07:46:39 +0200 Subject: [PATCH 21/22] Sync documentos/proyecto/0.Repositorio.md de master a gh-pages --- documentos/proyecto/0.Repositorio.md | 20 +++++++++----------- 1 file changed, 9 insertions(+), 11 deletions(-) diff --git a/documentos/proyecto/0.Repositorio.md b/documentos/proyecto/0.Repositorio.md index 36c27f6d..12d397f7 100644 --- a/documentos/proyecto/0.Repositorio.md +++ b/documentos/proyecto/0.Repositorio.md @@ -251,12 +251,12 @@ es de almacena y busca, ni siquiera es lógica de negocio. #### ¿Puede alguna lógica de negocio compleja ser inadecuada? -Si requiere un modelo complejo del programa, o un algoritmo complejo para +Si requiere un modelo complejo del problema, o un algoritmo complejo para trabajar con ella, puede ser un problema, porque, insisto, *lo tiene que programar el estudiante*. Si requiere *predicción* y por tanto un algoritmo de *machine learning*, doble problema, porque requiere conjunto de entrenamiento y programar el algoritmo. Se pueden usar, sin embargo, modelos ya entrenados -siempre que esos modelos los programe uno. +siempre que se programe el intérprete de ese modelo. #### ¿Qué problemas serán adecuados para la nube? @@ -374,19 +374,17 @@ procedimiento. 1. En este caso, tras crear el repositorio, se creará una rama específica para este objetivo (a partir de ahora, cada objetivo tendrá su propia rama). Con - el plugin de git para IV instalado, esto se hará en este caso con `git iv + el *plugin* de git para IV instalado, esto se hará en este caso con `git iv objetivo 0`, que creará la rama y se trabajará en la misma. 2. En esta rama se modificarán los ficheros necesarios para llevar a cabo todo lo requerido, que no se haya hecho en la creación del repo. -3. Desde esa rama, se creará un pull request *al propio repositorio* - indicando los cambios realizados. Este PR tendrá que ser aprobado - por el profesor para que se considere el objetivo - alcanzado. También se puede hacer con el plugin (en parte), - escribiendo `git iv sube-objetivo`. El mismo git imprimirá - instrucciones que se podrán seguir (pinchando en un enlace) para - crear el *pull request* (de una rama en tu repositorio a la rama - principal). +3. Desde esa rama, se creará un pull request *al propio repositorio* indicando + los cambios realizados. Este PR tendrá que ser aprobado por el profesor para + que se considere el objetivo alcanzado. También se puede hacer con el + *plugin* (en parte), escribiendo `git iv sube-objetivo`. El mismo git + imprimirá instrucciones que se podrán seguir (pinchando en un enlace) para + crear el *pull request* (de una rama en tu repositorio a la rama principal). 4. Una vez creada esta rama, se debe copiar el URL de la misma, que será lo que se entregará. From e6327794ac4fc3a47798e0c30eb1b9cd5efdea27 Mon Sep 17 00:00:00 2001 From: JJ Merelo Date: Tue, 26 Sep 2023 10:49:42 +0200 Subject: [PATCH 22/22] Sync documentos/proyecto/1.Planificacion.md de master a gh-pages --- documentos/proyecto/1.Planificacion.md | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/documentos/proyecto/1.Planificacion.md b/documentos/proyecto/1.Planificacion.md index 40e09117..9f867ecd 100644 --- a/documentos/proyecto/1.Planificacion.md +++ b/documentos/proyecto/1.Planificacion.md @@ -180,11 +180,10 @@ la solución que se entrega al usuario. > conveniente que se entienda en qué consisten y cómo se pueden llevar > a cabo. -Los *milestones* son herramientas para comenzar a trabajar y organizar -el trabajo con un objetivo claro en cada fase, lo que ocurrirá ya en -el siguiente objetivo; por eso habrá que plantear los suficientes para -poder hacerlo, pero nunca más de los que se puedan abordar en la -asignatura. +Los *milestones* son herramientas para comenzar a trabajar y organizar el +trabajo con un objetivo claro y concreto en cada fase, lo que ocurrirá ya en el +siguiente objetivo; por eso habrá que plantear los suficientes para poder +hacerlo, pero nunca más de los que se puedan abordar en la asignatura. > En general, en desarrollo ágil se van decidiendo cuales son los siguientes productos mínimamente viables durante el desarrollo del @@ -239,7 +238,7 @@ poner a trabajar. ## Información adicional -Se pueden consultar el siguientes tema del [curso +Se pueden consultar el siguiente tema del [curso 0](https://jj.github.io/curso-tdd) sobre cómo especificar los [requisitos](https://jj.github.io/curso-tdd/temas/dise%C3%B1o.html) y qué hacer para diseñar los primeros pasos de una aplicación y cómo @@ -297,7 +296,7 @@ Como mínimo, y para pasar los tests, esta entrega incluirá este objetivo no hay que añadir todavía nada de código, queda fuera del ámbito del mismo, pero es una práctica que hay que respetar a partir de ahora. -* Varios *milestones*, los que se considere suficientes. Para pasar los tests +* Varios *milestones*, los que se consideren suficientes. Para pasar los tests tiene que haber al menos dos. * El `README` tiene que seguir reflejando el estado del proyecto. En este caso, habrá al menos que enlazar cómo se ha planificado el mismo con algún tipo de @@ -323,6 +322,10 @@ material adicional. No es buena idea abandonar la clase cuando terminen "las explicaciones", porque se harán explicaciones en clase en cualquier momento según lo solicite uno o varios estudiantes. +Cuando se apruebe el objetivo, hay que asegurarse de que el contenido del PR y +los milestones e historias de usuario en el repo de GitHub tienen el mismo +contenido; en objetivos sucesivos se trabajará sobre ellos, no sobre el texto. + En el siguiente objetivo hay que trabajar en equipo, por lo que es esencial que se llege a él de forma más o menos simultánea.