CUR : Agregar atributo de tiempo estimado de desarrollo a cada proyecto

[mfdebian]

Como parte del esfuerzo por entender y expresar mejor el concepto de self-paced dentro del marco de tiempo finito que tiene el Bootcamp, es necesario agregar una sección de tiempo estimado de desarrollo para cada proyecto de la currícula.

[diegovelezg]

Recomendaciones "desde la trinchera": Insumo: https://datastudio.google.com/s/rusH-a0xO2M

• Tarjeta de crédito y cifrado : 1 - 3 sprints
• Datalovers y memory match : 3 - 4 sprints
• Red social : 4 - 5 sprints
• MDL : 4 -5 sprints
• BQ : 3 - 5 sprints
• BQ client API : 3-5 sprints
• BQ node.js (TBD)

relacionado: https://github.com/Laboratoria/bootcamp/issues/1282

[mfdebian]

@diegovelezg ¿Cómo te lo imaginas tú? Como un punto más en el apartado de consideraciones generales del proyecto que diga algo como:

"La cantidad de sprints sugeridos para este proyecto es de X sprints"

Por ejemplo? Pregunto porque creo que justo en este caso probablemente queremos ser muy específicxs con el lenguaje que ocupemos, no sé si sugeridos es el verbo más correcto? :grin:

[diegovelezg]

"Rango de tiempo estimado para completar el proyecto:"

@mfdebian si es un rango (y siempre lo será) y vamos a querer usar este dato para "monitorear" progreso, (por ejemplo), en realidad debverían ser dos enteros que determinan el intervalo, ¿cierto?

[mfdebian]

Diría que eso nos facilitará siempre la vida, pero también en la realidad del BC pasa que muchas veces terminan el proyecto y piden PF, pero por temas de tiempo, o para esperar el dia de ceremonias/demos/cambio de proyectos se suman un par de días y a veces pasan de un sprint a otro. La duda que me queda es, ese tiempo que se demoraron en total en el proyecto, lo responden ellas en un project checkout o cómo lo estamos pensando? Diría que el cómo levantemos esa data va a ser importantísimo para luego saber si estamos o no sacando conclusiones correctas con respecto a ella.