Algunas aclaraciones

documentos/proyecto/1.Planificacion.md

@@ -19,8 +19,8 @@ claros.
 
 ## Prerrequisitos
 
-Se tendrá que haber fusionado por parte del profesor el [objetivo
-0](0.Repositorio.md) antes de poder avanzar a este.
+El [objetivo 0](0.Repositorio.md) deberá haber pasado los tests en el
+repositorio de la asignatura antes de poder avanzar a este.
 
 ## TL;DR
 
@@ -81,29 +81,27 @@ Hay que empezar a planificar la aplicación que resolverá el problema planteand
    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 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
-   los demás y comenzar por abordar una de las historias de usuario,
+   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 basado 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.md).
+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.md).
 
 El proceso, por tanto, que se suele seguir (y el que se tiene que
 seguir para alcanzar este objetivo) es el siguiente:
@@ -120,54 +118,57 @@ seguir para alcanzar este objetivo) es el siguiente:
    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, qué quieren hacer u obtener con la
-   aplicación, 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.
+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 previo a su entrega 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 sabe lo que el
-usuario quiere hacer y ver, no se pueden hacer pruebas para comprobar que
+   (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]` 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.
+* 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; 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 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
@@ -243,10 +244,6 @@ 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).
 
-Los recursos aportados por los estudiantes de la asignatura están
-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
 este material sobre le
 mismo](https://jj.github.io/curso-tdd/temas/revisiones.html).