Se trata de entender el paso de historias de usuario al diseño inicial de una clase o clases en nuestro programa.
Se tendrá que haber avanzado en el objetivo 1 antes de poder entregar este.
Tras elegir el lenguaje de programación que se va a usar, se creará un módulo o módulos que compilen, aunque no pueden tener todavía ninguna funcionalidad. Estos módulos tendrán que usar las estructuras de datos más adecuadas para resolver el problema, así como el interfaz de la clase o de la estructura de datos que mejor permita implementar las historias de usuario existentes, evidentemente avanzando las historias de usuario que se hayan creado en el primer hito en la secuencia.
El convertir los deseos de los clientes en una realidad informática implica una serie de decisiones técnicas, y en principio no tiene nada de trivial. En entornos de desarrollo ágil hay que tener en cuenta no sólo los requisitos (historias de usuario) que se conozcan en ese momento, sino también posibles cambios que pueda haber en el futuro.
En desarrollo ágil, también, se va a separar lo más posible la lógica de negocio (lo que efectivamente hace la aplicación) de su implementación completa (cómo va a aparecer al público, cómo va interaccionar con el sistema). El hacerlo así permite asegurarse de que esta lógica de negocio cumpla todos los requisitos (que están expresados en historias de usuario), y que se pueda adaptar a diferentes entornos según evolucione la aplicación.
En todo caso, hay que pasar de una historia de usuario al diseño general de algunas de las clases (o módulos) que van a intervenir en una aplicación. La metodología más aceptada se denomina Domain Driven Design, y consiste en identificar las entidades (clases que van a incluir lógica de negocio, y van a ser capaces de gestionar otras clases, así como almacenamiento y otros objetos) y objetos valor (objetos inmutables cuyo ciclo de vida va a estar controlado por objetos de otras clases).
Diferentes conceptos a tener en cuenta:
Los factores anteriores son comunes a casi todas las aplicaciones, y llevarían normalmente a la elección de un lenguaje que tenga comprobación de tipos en tiempo de ejecución, o tipado “fuerte” o tipado gradual. Este objetivo se cumplirá evidentemente cuando se elija un lenguaje, porque sin él no se puede crear los primeros interfaces o clases sin código (sólo declaración de métodos y funciones).
Finalmente, en el momento que vaya a haber algo de código se tiene que comenzar a seguir las mejores prácticas del lenguaje correspondiente, que incluirán una disposición de directorios determinada, forma de llamar los ficheros y las clases dentro de los ficheros, y así sucesivamente. Conviene antes de crear el fichero o ficheros informarse sobre el tema.
Usar un repositorio de forma correcta no solo permite organizar el trabajo de desarrollo de forma más eficiente, sino que también contribuye a que sea más fácil colaborar con él y a la creación de buenos hábitos de trabajo colaborativo. Hay una serie de buenas prácticas, que incluyen las comentadas en el objetivo anterior, pero que además, en este objetivo, deberán de tener en cuenta lo siguiente.
Trabajar siempre con hitos (milestones) y órdenes de trabajo (issues) en el repositorio. En este caso, el hito será la entrega de la práctica y las órdenes de trabajo las diferentes soluciones necesarias para terminar el hito. Cada milestone contendrá, al menos, una historia de usuario (y los issues relacionados con la misma).
Todo commit debe resolver un problema que se haya establecido en el
repositorio, es decir, una historia de usuario o issue que forme parte del
milestone actual. Todo issue se cierra con un commit (simplemente incluyendo
closes #[issue], por ejemplo closes #1 si es el primer issue o problema
que se ha resuelto. Para referenciar un issue, simplemente se pone su número,
por ejemplo
soluciona #1 de la forma x
Estos mensajes de commit deben seguir el formato estándar y las buenas prácticas.
No incluir en el repositorio ningún fichero que pueda ser generado a
partir del mismo: incluir un procedimiento para generar tales
ficheros. Por ejemplo, ningún fichero compilado a partir de otros, o
un PDF generado a partir de los ficheros LaTeX, o los ficheros
generados por los entornos virtuales de ciertos lenguajes. Esos
ficheros, además, se tendrán que incluir en .gitignore para que no
aparezcan como “no seguidos” cuando se haga git status.
No incluir en el repositorio ningún código que no sea propio; si se va a hacer, se incluirá en el mismo el procedimiento para incluir ese código en la compilación, generalmente en forma de fichero de requisitos. Si el código sobre el que se va a trabajar es directamente de otro repositorio, hacer un fork del mismo, no copiar los ficheros. La estructura de un repositorio siempre tiene que respetarse, y la mejor forma de atribuir correctamente los cambios es trabajar sobre el repositorio original modificado.
No incluir ficheros binarios en el repositorio, aunque se necesiten en el proyecto. Para ello están los releases. En general los ficheros binarios son generados, así que esto es una simple consecuencia de lo de arriba.
Estas buenas prácticas se tendrán que seguir en todos los objetivos subsiguientes del proyecto, empezando por este, y no hacerlo se indicará al estudiante para su mejora. También se testearán a la hora de hacer el envío.
Este objetivo construye sobre el anterior. Se tienen que empezar a implementar las historias de usuario y avanzar hasta el primer hito, que podría ser perfectamente el resultado de este objetivo (ya que es una clase diseñada con todos los elementos que permitan implementarse luego). Así que
Implícitamente, en este objetivo se seleccionará el lenguaje de programación; pero el hacerlo será también un issue en el que se discutirá la elección.
Importante: si en tres semanas la persona a la que se ha asignado el repositorio propio no hace nada, conviene ponerse en contacto con el profesor para asignar a otra persona.
El 50% de los estudiantes el año pasado tardó 23 días o menos en hacer la entrega. Si en este plazo no ha habido ningún contacto, es mejor solicitar un cambio para no bloquear el resto del desarrollo, especialmente si la persona que está bloqueada ya ha superado este objetivo.
Se pueden consultar los siguientes temas del curso 0:
Todo el material para este objetivo se tiene que desarrollar, como siempre, en
una rama. Desde esta rama se hará un pull request a la rama principal del
repositorio propio del estudiante. Importante: el título de este pull
request *tiene que incluir la cadena [IV-22-23] para que puedan 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”.
Como en este hito el trabajo se hace sobre un repositorio ajeno, esa persona tendrá que revisar el trabajo que se ha enviado en un PR y aceptar (no fusionar). Cuando se haga, se etiquetará a JJ en un comentario donde se diga que está listo para revisión.
A este fichero se subirá (mediante un PR desde una rama) el nombre del proyecto, el autor y un enlace al pull request creado en el repositorio.
A partir de este hito, habrá que especificar ficheros y otros
parámetros de configuración para test en un fichero iv.yaml que
estará en el directorio principal, escrito en formato
YAML. Por ejemplo, este
entidad: camino/a/loquesea.raku
Las claves, tales como en este caso entidad, tendrán un valor que será lo
que se examine y se usará en un test para ver si se ha llevado a cabo
correctamente alguno de los elementos del hito requeridos. El formato YAML se
usa extensivamente en DevOps, y se puede consultar sobre él, por ejemplo, en la
Wikipedia. Se puede editar a mano (usando
el modo correspondiente del editor o IDE) o, por supuesto, generarse usando
alguna biblioteca o utilidad de línea de órdenes.
Como mínimo, y para pasar los tests, esta entrega incluirá, además de lo solicitado en las entregas anteriores:
iv.yaml, y, en la clave entidad, el fichero donde se haya
programado la entidad en forma de una clase, módulo o paquete que es el
objeto de este hito, con el camino correcto, por ejemplolenguaje: node.js
entidad: src/Recordatorio.js
Antes de proponer el material de este objetivo para revisión, hazte las siguientes preguntas y, si es posible, contéstalas. Esto debe ir en el cuerpo del PR que se haga en el repo correspondiente.
* [ ] ¿He seguido las mejores prácticas en el nombre de las clases y ficheros y
disposición de los mismos?
* [ ] ¿Se han planteado una serie de issues, asignados a las historias de
usuario pertinentes, que clarifiquen qué es lo que necesitan los usuarios e
identifiquen las diferentes partes del problema?
* [ ] ¿Los issues representan un problema, y no una tarea?
* [ ] ¿Se ha documentado qué análisis se ha hecho sobre el dominio para decir lo
que se ha creado?
* [ ] ¿Se ha documentado por qué se ha elegido que lo creado sea un objeto valor,
una entidad o un agregado?
* [ ] ¿He propuesto un producto mínimamente viable, que en muchos casos será un solo
objeto valor que no dependa de ningún otro (y que sea la base de muchos
otros)?.
* [ ] ¿Todos los mensajes de commit explican el cambio, y no se
limitan a repetir el nombre del fichero que se ha cambiado?
* [ ] ¿Los mensajes de commit siguen el formato estándar y buenas prácticas?
* [ ] ¿Se ha hecho una revisión real del código para comprobar que todos
los atributos y funciones creadas están respaldadas por una HU?
* [ ] ¿Todos los issues creados están asignados a una HU?
* [ ] ¿Ha asignado el propietario/la propietaria del repositorio todos los
issues planteados al *milestone* correspondiente?
* [ ] ¿Todos los cambios en el código están asignados a un issue al que se
referencia en un commit? Los issues sobre los que estoy trabajando, ¿han
sido asignados al primer milestone?
* [ ] ¿Se ha asignado al mismo milestone el PR que se ha hecho?
* [ ] ¿Son los milestones sobre los que estoy trabajando productos
mínimamente viables? ¿O tengo que solicitar al product manager que
cree milestones adicionales o precise de qué producto se trata?
* [ ] ¿Se ha comprobado que el código entregado sea sintácticamente
correcto?
Los tests automáticos serán un requisito para poder entregar el material evaluable correspondiente a este objetivo, que estará superado si:
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.
Salvo que se trate de aclaraciones sobre el milestone en el que se enmarca el objetivo o aclaraciones de qué significan las historias de usuario, la persona sobre cuyo repositorio estás trabajando no tiene que contestar a ninguna pregunta. Sólo tiene que evaluar el trabajo que realices cuando hagas el pull request, aprobándolo u orientándolo para que cubra las necesidadesd de los usuarios. No tiene que contestar qué tenía pensado, porque eres tú quien tiene que plantear los diferentes problemas a partir de las historias de usuario, y comenzar a resolverlo. La modelización, y, en general, el desarrollo, no tiene más diálogo que el que hay sobre la calidad del código, y en ese contexto. Si quien haya creado el repo y las HUs tiene que contestar a cada pregunta sobre cómo hacer algo, acaba antes haciéndolo.
El alcanzar este objetivo avanzará, en principio, 15% del apartado correspondiente de la asignatura.
Si has terminado, comienza con el siguiente.