Prácticas y Proyecto

«Me lo contaron y me lo olvidé, lo vi y lo entendí, lo hice y lo aprendí»

Guías prácticas

A continuación les compartimos las guías prácticas que utilizaremos para ejercitar los conceptos iniciales y elementales de la materia:

Proyecto ágil

El proyecto consta de gestionar en equipo el desarrollo de un producto de software a elección. Tener en cuenta que el producto no es el foco de la materia, por lo cual no se evaluará el desarrollo técnico del mismo, sino la manera de gestionarlo mediante la medotología ágil Scrum y la manera de trabajar en equipo. Lo cual involucra las siguientes habilidades blandas para el equipo Scrum:

  • Autogestión:
    • Gestión del tiempo dedicado
    • Distribución de las tareas
  • Participación y compromiso de cada miembro del equipo
  • Comunicación entre todos los miembros del equipo
  • El único concepto técnico que evaluaremos además de la gestión, es la calidad del producto entregado. Para lo cual van a contar con herramientas y técnicas que les permitirán cubrir dicho concepto.
Roles docentes

Como parte del proyecto, los docentes cubriremos 2 roles: el rol docente propiamente dicho y el rol cliente, en el cual vamos a oficiar del/la cliente que va  solicitar nuevas funcionalidades y/o mejorar las existentes. Para esto se contará con un espacio de charla entre el/la cliente y el/la Product Owner antes de iniciar el sprint (durante el coaching).

Equipo Scrum

El equipo Scrum se deberá componer de 1 Product Owner (rol de Scrum),  1 tester y el resto desarrolladres/as. Además durante la review (que será en clase, previo al coaching) 1 persona deberá oficiar de Scrum Master  facilitando así la review con el «cliente» (se sugiere que sea el/la PO o el/la tester). Cada una de estas responsabilidades deberán ir rotando en cada sprint.

 

Especificación del proyecto

Aquí les compartimos la planilla para inscribir los equipos del proyecto.

A continuación les detallamos las instancias correspondientes del proyecto ágil:

1. Presentación inicial

Cada equipo deberá armar un documento de presentación del proyecto, el cual deberá contener al menos la siguiente información:

  • Nombre del proyecto y de sus integrantes
  • Elevator’s pitch
  • Tecnologías y frameworks a utilizar
  • Herramientas de gestión y calidad
  • El MVP definido mediante la técnica de User Story Mapping (una imagen del USM)
2. Kick-off  y Sprint 0

En esta instancia deberán comenzar a configurar el entorno y generar el backlog

Para el coaching deberán:

  • Contar con el entorno mínimo instalado y configurado para las primeras iteraciones
  • Disponer del product backlog con el MVP definido en una herramienta de gestión
  • Armar un documento estilo README que contenga los links al:
    • Product backlog (con incidencias aún sin estimar)
    • Repositorio del producto
    • Reporte de seguimiento (inicialmente vacío)
3. Iteraciones (coaching)

Se realizará un coaching por cada iteración (sprint). Los sprints tendrán una duración de 1 semana. Al finalizar cada uno se realizará una revisión de coaching/review con el docente. La revisión implica 2  momentos, uno para cada rol:

  • Docente: revisión de los conceptos de Scrum aplicados en el proyecto. Esta revisión es individual, y las preguntas serán en función del rol que cumplieron en dicho sprint. En este momento se realizará una evaluación conceptual individual.
  • Cliente: revisión del incremento del producto según lo solicitado en la charla previa al sprint. En este momento el/la cliente «jugará» con el producto para probar las funcionalidades solicitadas. A nivel docente se realizará una evaluación del equipo en base a lo entregado y a su autogestión.

Al finalizar cada sprint, en el coaching / review, el equipo deberá:

  • Presentar un documento de seguimiento. Se trata de un reporte actualizado con la información correspondiente al sprint que acaba de finalizar. Se tomará el presente documento como base para la revisión conceptual del/la docente.
4. Presentación final

Al finalizar el proyecto el equipo deberá realizar una presentación final con un resumen de todos los sprints, compartiendo la experiencia y una conclusión final del proyecto. La presentación si bien debe ser formal, se permite agregar memes o cualquier imagen representativa de la experiencia vivida.

El documento deberá contener al menos:

  • Una tabla comparativa por sprints con los story points comprometidos vs los quemados.
  • Un listado de las acciones más efectivas tomadas a partir de las retros
  • Un cuadro con todos los burndown chart (prints de pantalla) con una conclusión al respecto
  • Un breve resumen que describa la experiencia y lo aprendido durante el proyecto