Agile / Scrum

Sobre mi

Qué entendemos por Agile

  • Diferencias con Waterfall
  • Desarrollo en ciclos / iteraciones
    • Entrega de valor en cada iteración
  • Visibilidad del desarrollo constante
    • Entre nosotros
    • Y para las personas encargadas de la gestión del proyecto
  • Mejora de comunicación
  • Identificación trabas o bloqueos
  • Capacidad de reacción / amigo de los cambios

Scrum

Conceptos Scrum / Agile

  • Product Owner
  • Product Backlog
  • Scrum Master
  • Definition of DONE
  • Sprint
    • Sprint Planning
      • User Stories
    • Daily
    • Sprint Review
      • Burn-down chart
    • Retrospective

Product Backlog

  • Este backlog es propiedad del Product Owner y contiene todos los posibles elementos de trabajo que podrían agregarse al producto en el futuro.
  • Los elementos en el Product Backlog se clasifican en función de su valor para el cliente o usuario, y el Product Owner es responsable de la priorización.
  • La priorización puede cambiar a medida que se obtiene más información o cambian las necesidades del cliente.

La gestión efectiva del backlog es fundamental para el éxito de los proyectos ágiles, ya que ayuda a garantizar que el equipo esté trabajando en las tareas más importantes y de mayor valor en cualquier momento dado.

  • Cuando un User Story está "hecho"
  • Depende del equipo y el proyecto decidir cuando algo está "hecho".
  • Puede incluir, Unit Tests, Documentación, Revisiones de código, etc

Es importante que el equipo y las partes interesadas acuerden y comprendan la Definition of Done para cada elemento del trabajo antes de comprometerse a completarlo durante un Sprint.

Definition of DONE

  • Es la parte más importante de todo el proceso
  • Un buen proceso de planificación, garantiza entrega de valor al final del Sprint
  • El Product Owner establece la prioridad de los User Stories a implementar
  • Muy importante definir la Capacidad del equipo en Azure Devops
  • Hay que intentar definir todas las tareas para cada User Story y estimar tiempo de las mismas
  • Si una tarea lleva más de una jornada de trabajo, dividirla en 2

Puede participar todo el equipo en el sprint planning, o bien los desarrolladores seniors

Sprint Planning

  • Puede dirigir las dailys una persona siempre, o podemos ir turnándonos
  • No deben de durar más de 15 minutos
  • Antes de las dailys hay que actualizar las tareas en las que estemos trabajando
  • Si no hemos terminado una tarea debemos indicar el tiempo que hemos invertido en la misma, y el tiempo que creemos que aun queda para terminarla
  • Cada miembro del equipo dice que ha hecho el día anterior y que va a hacer hoy, y si tiene algún bloqueo por parte de otro miembro del equipo
  • Importante guardar las dailys para mostrar transparencia a los managers

No dejemos que la Daily nos lleve demasiado tiempo. Es únicamente un tiempo que nos tomamos para actualizar el estado del proyecto

Daily

  • Depende de:
    • la capacidad del equipo
    • las tareas que vayamos cerrando
    • del ajuste de tiempo que hagamos en nuestras tareas
  • Esta gráfica muestra como vamos avanzando en el Sprint
  • Es un buen indicativo de ver como vamos el día a día
  • También es bueno revisarla durante el Sprint Review

Burn-down chart

  • Revisión de Sprint Burn-down chart
  • Es importante que asista el equipo de Product Management
  • Hay que revisar lo que se haya implementado con Demos a PM
  • Es importante entregar valor siempre al final de cada Sprint
  • Es importante implementar un proceso de continuous deployment para sacar a PROD los user stories que hayamos cerrado durante el Sprint

Sprint Review

En el Sprint Review hay que lucirse, es decir, es el momento de mostrar a los stake holders que entregamos valor y en consecuencia la valía del equipo

  • Identificar que se ha hecho bien durante el sprint
  • Identificar que se ha hecho mal durante el sprint
    • Aportar ideas y tomar medidas para mejorar en el siguiente sprint

Retrospectiva

Se trata de identificar entre todos posibles mejoras y aplicarlas entre un sprint y otro. Adaptarse a los cambios

Scrum / Azure devops

DEMO

Made with Slides.com