Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Scrum: una retrospectiva

No description
by

Carlos Cámara

on 20 May 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Scrum: una retrospectiva

Carlos Cámara Menoyo
Drupal Dreamer y Product Owner en Ymbra
Scrum: una retrospectiva
@carlescamara
http://carloscamara.es

Disclaimer
SCRUM en un vistazo
No tenemos stakeholders ni Managers
Recursos:
Fases:
Backlog
Grooming
Roles:
Valoración y committment
Definición
Taskboard
+ Burndown

Sprint
Burndown, Wiki
Retrospectiva
Entregable
Demostración
Daily Standup
PO, Equipo desarrollo, Scrum máster
Product Owner
Equipo de desarrollo
PO, Equipo desarrollo, Scrum máster
Cliente, PO,
(Equipo desarrollo, Scrum máster)
Retrospectiva
¿Preguntas?
¿Utilizáis scrum? ¿Por qué?
¿Qué problemas os habéis encontrado?
¿Cuáles han sido vuestros mayores logros?
¿y aspectos mejorables?
¿Cómo lo transmitís al cliente? ¿Cómo reacciona? ¿Cómo es vuestra relación?
Funciones
Valora las historias de usuario
Elige las historias de usuario a realizar en un sprint (Compromiso)
¡Desarrolla!


Características
Todos los miembros de Ymbra son desarrolladores en algún proyecto
Equipo cambia en cada sprint
Intentamos tener equipos de backend/frontend en 1 sprint
dedicación completa a un solo sprint (90% de las veces)

Equipo de desarrollo
Funciones
Crea las historias de usuario
Prioriza y Propone las historias de usuario a realizar en un sprint
Enlace con el cliente
Acepta o rechaza el trabajo del equipo de desarrollo
Características
Tenemos 2 personas que hacen de PO en uno o más proyectos a la vez

Product Owner
Funciones
Convoca y dirige reuniones (daily, definición, retrospectivas)
Redacta actas
Hace que las reglas se cumplan (duración, periodicidad...)


Características
Siempre es la misma persona

Scrum máster
¿Qué?:
Revisión del backlog
Creación de historias de usuario suficientes
Correcta priorización de historias de usuario
¿Quién? :
El Product Owner
¿Cuando?
No tenemos fecha específica
Cuando no hay historias de usuario suficientes
Después de un cambio/feedback del cliente


¿Qué?:
Preparación del trabajo que se hará en el sprint
Creación de tareas para cada historia de usuario
(Clarificar historias de usuario)
Valoración de historias de usuario
Compromiso de historias de usuario
¿Quién? :
El Product Owner y equipo de desarrollo
¿Cuando?
Antes de cada sprint
Lunes después de desayunar


{
Historias de usuario
}
Valoración
Se mide en "puntos", unidad abstracta
Valoramos el esfuerzo, no la dificultad
No estimamos en tiempo
{
Estado
Solo tenemos estos estados:
New: no empezada
Doing: alguien está trabajando en ella
Done: lista para revisar por el PO
Closed: Cuando el PO considera que está terminada
Las crea el product owner
Tantas como sea necesario (son gratis)
Misma estructura siempre:
Título: Como “usuario” quiero “acción” para “resultado”
Contenido:
Descripción
Enlace a documentación
Criterios de validación
Tareas a llevar a cabo
Deben ser realizables en un sprint
Evitar bloqueos (feedbaks, bloqueos)
Evitar historias muy largas
Separar tareas de visualización y creación de contenido
Trocear tareas largas
Deben tener una o más tareas
Tres variaciones
Historia de usuario
[Technical story]
Feedback
No usamos Epic (módulos, funcionalidades complejas) ni features (pantallas, menús...)
Contiene un listado de historias de usuario que debe tener el producto final, priorizadas
Solo puede ser modificado por el Product Owner
Se deberán incluir en sprints por orden
En caso de que se acaben las tareas de un sprint, se cogerá la primera del backlog
¿Qué?
Compromiso del equipo de historias de usuario a cerrar durante el sprint

¿Quién?
Miembros del equipo de desarrollo

¿Cómo?
Se eligen las historias en función de:
Orden en el backlog
Valoración de historias de usuario
Dedicación al proyecto
Team committment
¿Qué es?
Reunión diaria, breve (15' aprox) y siempre a la misma hora.
Cada miembro debe responder a:
Qué hizo el día anterior
Qué hará durante el día
Qué bloqueos tiene
¿Quién?
Equipo de desarrollo, PO y Scrum Master
¿Cuando?
Cada día, a las 9:30. Antes del desayuno
Observaciones:
Funcionan mejor cuando el equipo lleva trabajando juntos durante un tiempo y de forma estable
Se alargan mucho (2h de media)
Temas recurrentes:
Discutir si una historia es una o deberían ser varias
Aspectos positivos:
Duración aprox de 15min
Lo hacemos de pie y con hangout para implicar a los que trabajan en remoto
Aspectos mejorables:
No somos demasiado puntuales (esperamos a estar todos → aunque estamos mejorando)
Encontrar un equilibrio entre ser demasiado generalistas (trabajaré en X proyecto) y demasiado detallistas
Historias de usuario
Características
Las crea el product owner
Tantas como sea necesario (son gratis)
Misma estructura siempre:
Título: Como “usuario” quiero “acción” para “resultado”
Contenido:
Descripción
Enlace a documentación
Criterios de validación
Tareas a llevar a cabo

A tener en cuenta:
Deben ser realizables en un sprint
Evitar bloqueos (feedbaks, bloqueos)
Evitar historias muy largas
Separar tareas de visualización y creación de contenido
Trocear tareas largas
Deben tener una o más tareas

Tres variaciones
Historia de usuario
[Technical story] : las pueden crear los desarrolladores
Feedback: modificación de una historia existente cerrada (no se "resucitan" historias de usuario)
No usamos Epic (módulos, funcionalidades complejas) ni features (pantallas, menús...)
¿Qué?:
Desarrollo de las historias de usuario del sprint
Validación de historias de usuario
(Feedback)

¿Quién? :

Equipo de desarrollo (desarrollo)
PO (validación)
Duración:
Una semana -> permite tener:
equipo estable
no interrupciones


Modelo de referencia de desarrollo ágil, incremental e iterativo que define prácticas asumidas por distintos roles
Beneficios para cliente
Flexibilidad a cambios. No ceñido a un roadmap estricto.
Reducción del Time to Market. El cliente puede empezar a utilizar las características más importantes del proyecto antes de que esté completamente terminado.
Mayor calidad del software. -> resultado del trabajo metódico
Beneficios para desarrolladores
Mayor productividad resultado de mayor motivación del equipo y menor burocracia
Predicciones de tiempos a través de la velocidad media.
Burdnown
Muestra los puntos comprometidos para un sprint, la velocidad ideal/uniforme para cerrarlos y el estado real del proyecto
Permite ver:
Velocidad del trabajo (estimar duración del proyecto)
Se añaden nuevas historias en mitad del sprint
¡Casi se consigue el compromiso!
...O sí
(Más rápidos de lo previsto)
Calidad
¡Gracias!
@carlescamara
http://carloscamara.es

http://ymbra.com
#DrupalCampEs

Carlos Cámara Menoyo
Taskboard
Instantánea (visual) del estado actual del sprint, mostrando:
historias de usuario y tareas
Estado de la tarea/historia
Persona que está haciéndolo (con colores)
Orden de las historias de usuario
Valoración
bloqueos (y su estado)
Tareas que bloquean a otras
(por suerte están cerradas)
Cuando se integren en staging (gerrit) se moverán aquí
Tarea lista en el entorno del desarrollador (no integrada aún)
El PO considera que falta algo, o bien
El PO debe pedir info al Cliente
Historias de usuario
Tarea terminada, integrada y verificada
Beneficios: +Productividad, Predicción tiempo, + Calidad, +Flexibilidad, -Time to market
Proveedores
Clientes
Sobre la presentación
No es una sesión sobre Scrum. Es una sesión de cómo utilizamos scrum en nuestra empresa (no siempre según la definición)
Sobre Ymbra
Empezamos a incorporar Scrum “en serio” desde hace 5 meses (año nuevo, vida nueva: antes usábamos una versión descafeinada)
Llevamos 6 proyectos utilizando Scrum. Y 44 sprints realizados
Experiencia relativa (podéis cuestionarnos cosas)
No somos unos expertos en Scrum (aunque algo empezamos a saber algo)
Tenemos primeros resultados positivos
Todavía tenemos que mejorar (bastante)
El cliente puede empezar a usar la aplicación antes (aunque no esté terminada)
No hay roadmap estricto. Cada sprint es independiente
+ Implicación + Revisión
Puntuación permite estimar velocidad media
Objetivos claros, compromiso del equipo
¿Qué?:
Revisión del estado del proyecto al cierre del sprint
Tareas terminadas
Tareas no terminadas (¿impedimentos?)
Análisis de situación
Aspectos positivos
Aspectos mejorables
Mover tareas incompletas al backlog
¿Quién?
Product Owner y equipo de desarrollo
Duración:
Unas 2 horas media (4h max)


¿Qué?:
Demostración de las historias de usuario terminadas
Entorno específico (staging)
¿Quién?
Product Owner y equipo de desarrollo y/o cliente)
Duración:
Varía


(git: feature, módulo...)
No hay mejoras en aspecto técnico
ayuda a tener una buena base para implementar metodologías que mejorar la calidad (gerrit, behat...)

Mejoras significativas en relación al cliente:
Se les ofrecen demos y resultados antes
(somos nosotros quienes les "perseguimos")
Hay menos feedback de cambios del cliente
Plazos de entregas
No hay cambios significativos
No somos más rápidos ni más lentos que antes

Tenemos un mejor control del tiempo:
Número de sprints, fechas y objetivos de cada uno
Burndown
Puntuación y velocidad media de cierre
Motivación equipo
Mayor implicación del equipo
Motivación
Buen ambiente
Autonomía del equipo <=> plazos de entrega
Calidad
Resultados
Aspectos positivos
Aspectos mejorables
Mayor control del proyecto, por parte de PO y equipo de desarrollo -> seguridad -> mayor implicación
Metodología y forma de trabajar compartida por todos -> facilita trabaja en equipo
Métricas -> capacidad de toma de decisiones
Conocimiento
Transmisión entre miembros
Estructura
Agilidad
Definición de "done"
¿Qué?
Asignar puntos / historia
Puntos miden esfuerzo, no dificultad
No estimamos la duración
¿Quién?
Miembros del equipo de desarrollo
¿Cómo?
Scrum Poker Cards (app Android)
Puntuación media de los votos individuales
Se justifican las puntuaciones discrepantes y se vuelve a votar
Valoración historias de usuario
Ser más estrictos con la metodología
Sobretodo con fechas y entregables,
compromisos sprints
objetivos sprints
Integración más amplia con herramientas
de mejora de la calidad
testing.
Hacer presupuestos realistas en consonancia con la metodología
Alcance historias de usuario
Extender el proceso más allá del desarrollo
Full transcript