search

Laboratoria / curriculum

El bootcamp de @Laboratoria es un programa de aprendizaje inmersivo de 6 meses enfocado en los perfiles de Web Developer y UX Designer.
https://curriculum.laboratoria.la
Creative Commons Attribution Share Alike 4.0 International
491 stars 462 forks source link

Renombrar `Parte Obligatoria` a `Criterios de Aceptación del Proyecto` #789

Closed lizzie136 closed 5 years ago

lizzie136 commented 5 years ago

En el espíritu de orientar en la medida de lo posible a los t´Erminos que se usan en el espacio de trabajo, Criterios de Aceptación es el mínimo obligatorio que tenemos por proyecto para ser aceptado por el cliente. Habría que tener la conversación al respecto, ya que en las historias de usario en muchos casos se definen también Criterios de aceptación para la historia en específico. /. cc. @diegovelezg

florenciasilva commented 5 years ago

Considero que el lenguaje es una parte muy importante en como las estudiantes afrontan y ven un reto. Palabras definitvas como "Parte Obligatoria" podría, en mi opinión personal, convertir el reto en una 'tarea' y desviar el foco hacia "hay que terminar esto sí o sí para seguir" a "necesito aprender los temas de este reto para poder avanzar".

FabianBravoA commented 5 years ago

Una de las cosas que hemos estado luchando en Santiago, para poner como prioridad el que las estudiantes aprendan y no traten de llegar al objetivo bajo cualquier medio, es que se olviden de lo "Obligatorio". De los puntos de "Completitud" en la rúbrica. Es súper complejo, toda su vida académica han luchado por notas más que por aprender, entonces sacar ese chip debería ser una de nuestras metas en el principio del proceso de Laboratoria. Me gusta criterios de aceptación, va de la mano con tener un cliente, pero iría más allá y definiría la importancia de cada uno de ellos, para que, en caso de no llegar a completarlos todos, puedan priorizar correctamente y llegar a un proyecto quizá no al 100%, pero que funciona, y en el que sus autoras hayan aprendido lo que necesitan para las siguientes etapas y luego su trabajo.

On Tue, Feb 26, 2019, 23:18 Florencia Silva Olivera < notifications@github.com> wrote:

Considero que el lenguaje es una parte muy importante en como las estudiantes afrontan y ven un reto. Palabras definitvas como "Parte Obligatoria" podría, en mi opinión personal, convertir el reto en una 'tarea' y desviar el foco hacia "hay que terminar esto sí o sí para seguir" a "necesito aprender los temas de este reto para poder avanzar".

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Laboratoria/curricula-js/issues/789#issuecomment-467696461, or mute the thread https://github.com/notifications/unsubscribe-auth/AHcp2FVRKywfJP81OXSYv0_PGvmxX3Yxks5vRer8gaJpZM4aw03- .

diegovelezg commented 5 years ago

De acuerdo!!! Podríamos replantearlos como "Criterios de aceptación del proyecto" (?)

lizzie136 commented 5 years ago

Gracias @florenciasilva y @FabianBravoA ! Me hace sentido lo que menciona Fabian de explicar más el porqué necesitaríamos cada criterio y que ellas prioricen. Voy a renombrar el issue @diegovelezg :D, porque si bien la parte obligatoria son "Criterios de Aceptación" , también las historias de usuario tienen Criterios de Aceptación/DOD

diegovelezg commented 5 years ago

Creo que vale la pena ampliar la discusión a todxs lxs coaches y TMs.

Lo que comenta @FabianBravoA no es menor. Muchas veces, la combinación de mindset "cascada" + "parte obligatoria" + no self paced hacen que llegue el final del proyecto y hayan logrado una experiencia/aprendizaje sólo parcial. Me explico con DL:

Termina el proyecto y logran filtrar, ordenar y cálculos pero sin tests, con poco o cero feedback y mejoras basadas en pruebas de usabilidad, un responsive a medias, etc. ¿No preferiríamos que completen dos historias (filtrar y ordenar) pero con todo completo y bien hecho?

Quizás podemos plantear los proyectos sin parte obligatoria y con un backlog y van completando las historias una a una hasta donde puedan (?). ¿Podría ser esa una manera de lograr esa "modularidad" de la que hemos hablado @lupomontero ?

FabianBravoA commented 5 years ago

Ya partimos en SCL con el proyecto BurgerQueen usando esta forma de presentar lo que queremos que hagan. Las estudiantes después de la presentación mencionaron que les gusta esto puesto que :

FabianBravoA commented 5 years ago

Pueden ver el ejemplo en https://github.com/Laboratoria/SCL007-BurgerQueen

lizzie136 commented 5 years ago

Gracias por probar @FabianBravoA ! De mi lado me gustaría presentarles el concepto y que ellas definan esos "Criterios de aceptación", mas que darle las historias de usuario con esos criterios porque me parece valioso que ellas sigan creandolas.

Punto aparte, me da la sensación que hablamos de varias cosas a la vez. Entonces anotando ambas cosas y para evitar la confusión, qué les parece empezar a usar el término de Requerimientos No Funcionales para lo que suele ser la Parte obligatoria con detalles técnicos del proyecto. Normalmente estos requerimientos tienen un criterio de aceptación medible que se asemeja mucho a la narración que hemos usado en Parte obligatoria Requerimientos funcionales para los que afectan al producto a nivel de usuario como Responsive

Y como tal el Criterios de aceptación la definición de terminado que completan las Historias de Usuario

FabianBravoA commented 5 years ago

Es verdad que acá les estamos haciendo el trabajo y sería bueno que ellas lo hicieran, pero hemos visto que muchas veces tienen dificultad al identificar las historias de usuario y mucho más aun de ir dividiéndolas en tareas más pequeñas.

Entonces, quizá una buena idea es que vayamos intercalando tipos de proyecto, por ejemplo, la red social podría ser uno donde ellas tengan que hacer ese trabajo, pero markdown y Burger queen ya vienen pre-hechos.

diegovelezg commented 5 years ago

@lizzie136 de acuerdo con que estamos hablando de varias (demasiadas) cosas juntas. Esta es mi perspectiva:

  1. La habilidad de escribir tus propias HU con sus DOD y sus CA: 1.1 Esto es algo que debería ser progresivo. 1.2 Definitivamente NO debería comenzar en el Proyecto 1 (cualquiera que sea) y sí en el segundo. 1.3 Pistas. Podríamos darles UNA HU completa en el proyecto 2 (DOD+CA) y que ellas hagan el resto. El desafío es que sea "agnóstica" de la data En el caso de DL)

  2. Recibir proyectos "encargados" y sin tanta libertad para decidir tú. 2.1 Este es el caso de BQ como se va a ejecutar ahora en SCL 2.2 Hemos discutido mil veces sobre motivación intrínseca vs el "rigor" de hacer lo que se te pide. Para mí, en el contexto del aprendizaje de hab técnicas, gana lo primero por goleada (a la luz de lo que observamos) aunque es necesario matizar con lo segundo. Como está BQ ahora en SCL me parece bien para ese objetivo (independientemente de qué tan bien hayan aprendido hasta acá a escribir sus HU completas). Quizás hasta MDL ellas escriben todo y recién en BQ les damos el backlog listo (como está ahora en SCL)

  3. Nomenclatura: 3.1 EN principio creo que tiene todo el sentido lo que dice @lizzie136 aunque me gustaría verlo en un proyecto actual. ¿Te animas a un draft?

  4. "Modularidad" de proyectos orientada al aprendizaje: 4.1 Esto me parece de crucial importancia por todo lo comentado antes @lupomontero y @lalogf . 4.2 Independientemente de las nomenclaturas, ¿podríamos tener como "regla de juego" algo como "releases"? por ejemplo, debes completar el release 1 (2 HU) antes pasar al sgte. La idea es desincentivar que posterguen cosas como TDD y Responsive (estamos viendo que ocurre en DL) y que tengan sprints de aprendizaje que involucran de todo ("completos")

¿Me excedí?

lalogf commented 5 years ago

Me uno a la conversación.

Primero diría que está bien que probemos este approach en Santiago y veamos cómo nos va.

Luego, como he comentado en otros foros, me preocupa un poco la percepción que se llevan a lo largo del common core algunas estudiantes de que una HU es como una gran tarea que "aparece de cualquier lado" y que el siguiente paso es la implementación. Esto puede confundir luego cómo es la dinámica de un equipo de desarrollo de productos. Me gustaría que reforzáramos que:

La idea es evitar que pasen de HU a tareas de código. Podríamos agregar esto desde la redacción. En este caso, en lugar de decir:

El product owner del proyecto ha conversado con el cliente y luego de una reunión con el project manager han logrado crear el siguiente backlog:

Podríamos decir:

El product owner, el cliente y el equipo de desarrollo (Project Manager, Lead Developer, UX Designer) han revisado las historias de usuario provenientes del UX research que se hizo previamente, las han priorizado y han creado el siguiente backlog.

Lo de los requerimientos funcionales y no funcionales me pareció un poco confuso. Quizás para que se entiendan más fácil crearía una historia alrededor de ellos. Como lo que hacemos cuando les hablamos de las tablets. Por ej:

Dado que el stack de los otros productos de la empresa están basados en JS, nos han pedido que este producto sea también usando a,b y c tecnología. Dado que hay muchos Frameworks últimamente la empresa no tiene problemas entre usar React o Angular, así que tú puedes proponer el que te parezca mejor para esta implementación.

¿Qué opinan?

@diegovelezg sobre la modularidad estoy seguro que se podría aplicar en UX, pero déjanos darle una vuelta primero con los coaches de UX para ver cómo sería.

diegovelezg commented 5 years ago

Respecto a las HU

Conversando con @lalogf, pensamos que "by default" deberíamos incentivar una mecánica que junte mundo real y sirva de catalizador para el aprendizaje. Podría ser algo así.

Sobre "requerimientos..."

Yo prefiero, quizás, una combinación de ambas propuestas (@lalogf y @lizzie136 ) como para que "tenga sentido en idioma humano" pero que también vayan acostumbrándose un poco a los términos (lo que me recuerda nuestro abandonado glosario).

CC @gaposx @Gabx04 @camargozzini @bosqueinvierno @SegamanDI @denimux @merunga @lupomontero @juanjordan etc etc etc

gaposx commented 5 years ago

Super de acuerdo con el resumen de @diegovelezg sobre las HU y creo se plantean bien estos conceptos en la presentación "Planificando, organizando y trabajando. Data Lovers".

lupomontero commented 5 years ago

Hola todxs,

Por ahora, se han renombrado todas las secciones de Parte obligatoria a Criterios de aceptación mínimos del proyecto (ver v2.x).

Por otro lado, en el caso de Burger Queen se ha re-escrito esa sección como una serie de Historias de Usuario...

https://github.com/Laboratoria/curricula-js/tree/v2.x/projects/04-burger-queen#5-criterios-de-aceptaci%C3%B3n-m%C3%ADnimos-del-proyecto

Como dice @diegovelezg, son varias cosas distintas... y creo que necesitamos ejemplos o propuestas (PRs) concretos sobre algún proyecto en concreto para ir apuntando en alguna dirección y en base a eso repartirnos el trabajo de propagar los cambios que acordemos en el resto de proyectos... aunque cada uno tiene su propia naturaleza.

Creo que lo más importante es que estamos de acuerdo en lo siguiente:

Quién se anima a hacer una propuesta concreta para cipher y/o data-lovers?

lupomontero commented 5 years ago

Me tomo la libertad de cerrar este issue por inactividad, y además las secciones de Parte obligatoria ya han sido renombradas a Criterios de aceptación mínimos del proyecto.

Si alguien quiere proponer algún cambio concreto sobre los Criterios de aceptación y/o historias de usuario de algún proyecto porfa abran nuevos issues o PRs :wink: