Scrum – Gestión Ágil de Proyectos III

Scrum – Gestión Ágil de Proyectos III

Características de Scrum

  • Es un marco de trabajo para el que se definen un conjunto de principios y prácticas
  • Se realizan desarrollos interactivos de productos
  • Se hace con ciclos cortos de trabajo
  • El equipo es auto-gestionado y tiene un alto nivel de interacción
  • Se mantiene un contacto continuo con el cliente
  • Se tiene un seguimiento próximo (a diario) lo que mantiene una visibilidad continua del avance
  • El entregable/producto es completo y totalmente operativo: es un desarrollo incremental, con entregables operativos.
  • Se tiene una mejora continua del proceso de trabajo en equipo
  • Es una metodología sostenible, tanto en el ritmo, la continuidad y con foco en el valor
  • Tiene permeabilidad al cambio, es flexible y adaptable

Características de Scrum

Ficha sinóptica de Scrum

Características de Scrum

Perfiles de Scrum

Cerdos Gallinas
¿Quién?

  • Product Owner
  • Scrum Master
  • Equipo de Desarrollo

Comprometido en:

  • El proyecto y el proceso Scrum
  • Construir software de manera regular y frecuente
  • Tiene el “tocino en la sartén”
¿Quién?

  • Usuarios
  • Stakeholders
  • Expertos

Cualquiera que esté involucrado e interesado en el proyecto

No son parte del proceso Scrum.

Sus ideas, deseos y necesidades son tomadas en cuenta, pero no en un sentido en el que puedan afectar o distorsionar el proyecto Scrum

Nombre del Rol Abreviación Cantidad Recomendaciones
Product Owner PO 1 Conocedor del negocio, parte del cliente, en contacto constante con usuarios e interesados
Scrum Master SM 1 x ST Capacitado en la metodología, conocimiento sólido en negocio y tecnología
Scrum Developer (Development Team) SD 4-9 Equipo auto-organizado y multidisciplinario

Mapeando los perfiles de Scrum

Mapeando los roles de Scrum

Product owner

Responsabilidades del Product Owner

Scrum master

Responsabilidades del Scrum Master

El equipo de desarrollo

Derechos

  • La organización tiene que animar al equipo a auto-organizarse, sin entrometerse en su forma de trabajar.
  • Sólo bajo contadas y controladas circunstancias, las tareas del sprint serán modificadas una vez que este ha comenzado.

Deberes

  • El equipo debe ser auto-organizado. Los propios miembros del equipo establecerán la forma de hacer su trabajo.
  • Tiene que ser multifuncional.
  • Todos los miembros deben trabajar con sus habilidades para cumplir el sprint goal.
  • Los equipos de desarrollo deben ser pequeños, de 3 -7 personas.
  • Junto con el Scrum Master, se encargan de establecer los ítems del Sprint Backlog, de planificar el sprint.
  • Estimar las historias de usuario y tareas.
  • Hacer la demo.
  • Implementar pruebas de aceptación y pruebas unitarias.
  • Trabajo de calidad y mejora continua de la calidad (refactorización, por ejemplo)
  • Participar en los Daily meeting, Sprint Planning Meeting, Sprint Review y Sprint Retrospective.
  • Estar motivados.
  • Saber buenas prácticas de programación: pair programming, TDD, integración continua, refactorización, malos olores, patrones de diseño, etc.
  • Identificar posibles obstáculos y comunicárselos al Scrum Master.
  • Actualizar el trabajo en progreso (burndown chart) (es responsabilidad tanto del equipo de desarrollo como del Scrum Master)

Es un equipo ágil auto organizado, no hay perfiles específicos, sino uno único transversal, es un equipo multifuncional y auto-organizado para asumir y auto-asignar tareas definidas en cada Sprint.

Tiene que tener actitud de mosquetero “Todos para uno y uno para todos”, ya que todo el equipo es responsable de la construcción del producto. El equipo debe tener habilidades “T”

Habilidades en T

Interacción entre equipos

En la interacción entre los equipos es importante definir qué perfiles se pueden compartir entre varios proyectos y cuáles no.

Interacción entre equipos Scrum

El Product Owner y el Scrum Master no tienen dedicación exclusiva al proyecto, por lo que pueden compaginar sus tiempos entre varios proyectos diferentes, mientras que los miembros del equipo de desarrollo, no deberían dividirse entre varios proyectos, ya que eso afectaría a los plazos de entrega.

Los artefactos de Scrum

Product Backlog

Product Backlog

El Product Backlog de un proyecto es una lista priorizada y secuencial de características o “historias de usuario”, que está basado en la visión del producto de Product Owner, siendo su responsabilidad. En esta lista, el trabajo más valioso va primero y va más detallado.

Product Backlog

Refinamiento del Product Backlog

Para el refinamiento del Product Backlog, el equipo estima la cantidad de esfuerzo que se debe invertir para completar los elementos del Backlog del Producto y proporciona la información técnica para ayudar al Product Owner a priorizarlos. Los elementos grandes se dividen y se clarifican, teniendo en cuenta temas tanto de negocios como técnicos. A veces, un subconjunto del equipo, junto con el Product Owner y los stakeholders, descomponen y dividen los elementos del Backlog de Producto antes de involucrar a todo el equipo en la estimación.

El refinamiento se compone de tres actividades principales:

  1. La creación y el refinamiento de los PBIs (Product Backlog Items)
  2. La estimación de los PBIs
  3. Lo priorización de los PBIs

Estas actividades se llevan a cabo en todo el esfuerzo de desarrollo del producto

Refinamiento del Backlog de Producto

Esta tarea se hace como un esfuerzo colaborativo

Esfuerzo colaborativo del refinamiento del Backlog de Producto

El Sprint Backlog

El Sprint Backlog consiste en el conjunto de PBIs comprometidos o negociados entre el equipo y el Product Owner durante la Reunión de Planificación del Sprint. El alcance comprometido es fijo durante la ejecución del Sprint. Las tareas iniciales son identificadas por el equipo durante la reunión de planificación del Sprint.

El equipo descubrirá  las tareas adicionales necesarias para cumplir con el compromiso de alcance fijo durante la ejecución del Sprint, Estar tareas serán visibles para todo el equipo y se estarán referenciando durante la Reunión Diaria de Scrum.

Sprint Backlog

Con ayuda de herramientas podemos ver el avance diario del Sprint Backlog, en el que se verá tanto el avance de las historias de usuario, como de las tareas de implementación de las mismas a lo largo del tiempo.

Sprint Backlog

Producto potencialmente entregable

Es una parte o sección del producto construida o “hecha”, esa parte o sección tiene que estar dispuesta a ser liberada aunque la decision de la liberación es una decisión de negocio, no es imperativa su liberación.

Puedes ver más información en este libro

Fundamentos de los Requisitos de Software

Scroll al inicio