Traducción al castellano del post “50 Best Scrum Practices for Dream Team” de Kevin Wood

El otro día estábamos compartiendo un post de Kevin Wood, publicado en febrero de este año, que nos habla de las 50 mejores prácticas de Scrum (50 Best Scrum Practices for Dream Team) y nos pareció tan útil y tan relevante para cualquiera que esté involucrado con Scrum que decidimos traducirlo al castellano para que todos los interesados puedan tener acceso a él. Aquí os compartimos nuestra traducción:

Batman y Robin

Scrum es uno de los frameworks más populares para implementar Agile. De hecho, muchas personas creen que Scrum y Agile son la misma cosa, aunque definitivamente no lo son. Agile es un grupo de metodologías de desarrollo de software basado en el desarrollo iterativo, y Scrum es un subconjunto de Agile pero con sus propias peculiaridades debido al compromiso con iteraciones cortas.

Con Scrum, los productos se construyen en una serie de iteraciones de longitud fija (sprints). Esto permite a los equipos entregar software a intervalos regulares, recibir retroalimentación rápida y adaptarse rápidamente a los requisitos cambiantes.

Aquí se presenta una lista de las mejores prácticas de Scrum que han demostrado su efectividad para ayudar a mejorar la calidad y aumentar la productividad, para entregar un producto que aporte valor y que cumpla con los objetivos de negocio.

Equipo

  • Los miembros del equipo trabajan en roles multifuncionales
  • El equipo tiene el equilibrio adecuado entre los desarrolladores y el QA (2: 1 o 4: 1)
  • Los miembros del equipo colaboran para entregar en primer lugar historias de alta prioridad
  • Los miembros del equipo piden ayuda proactivamente
  • Los miembros del equipo se dan feedback constructivo mutuamente y de manera oportuna

Scrum Master (SM)

  • El SM facilita la autoorganización del equipo
  • El SM se enfoca en remover impedimentos (problemas de recursos, problemas o desobediencia en la implementación de prácticas de scrum)
  • El SM protege al equipo de distracciones externas e internas
  • El SM permite una estrecha cooperación en todos los roles
  • El SM interactúa con la alta dirección

Propietario del Producto (PP)

  • El PP interactúa con el equipo y todas las partes interesadas (Stakeholders) para crear el
    backlog
    o la Pila de Producto
  • El PP escribe historias de usuario y criterios de aceptación
  • El PP prioriza la Pila de Producto y decide sobre las fechas de lanzamiento de las diferentes versiones
  • El PP acepta o rechaza historias de usuario
  • El PP cancela el sprint si piensa que el objetivo del sprint ya no tiene sentido

Definición de Hecho o Definition of Done (DoD)

  • Cada historia de usuario cumple los criterios del DoD
  • Todos los miembros del equipo y el PP conocen de memoria el DoD y lo respetan

Estimación

  • El PP obtiene estimaciones a partir del equipo
  • Sólo estima el equipo
  • Cada miembro del equipo participa en la estimación
  • El equipo estima usando la técnica del Planning póker

Reunión de planificación Sprint

  • Todos los miembros del equipo participan
  • El PP presenta las historias de usuario priorizadas al equipo
  • Todas las historias del sprint están estimadas
  • La reunión da como resultado un plan de sprint

Sprint

  • El equipo entrega algo después de cada sprint
  • El equipo sigue las prioridades marcadas por el PP
  • El equipo alerta al PP cuando tienen problemas
  • El equipo trata los problemas cuando ocurren (no más tarde)
  • La longitud de Sprint no cambia después de cada sprint
  • Las historias que se han empezado terminan dentro del mismo sprint

Pila de Sprint (PS)

  • La PS está visible y es de fácil acceso para el equipo
  • La PS se actualiza todos los días
  • Las estimaciones de las tareas se actualizan todos los días
  • Los miembros del equipo actualizan la PS por ellos mismos
  • Las historias están claramente mapeadas

Scrum Diario (SD)

  • El SD tiene ocurre a la misma hora y lugar todos los días
  • El SD comienza y termina puntualmente
  • Todos los miembros del equipo están involucrados
  • El PP participa en la reunión por lo menos unas pocas veces por semana
  • El equipo revisa el gráfico de burndown y toma medidas si van retrasados
  • El SD dura como mucho 15 minutos – todas las discusiones tienen lugar después

Revisión de Sprint

  • La demo formal se realiza después de cada sprint
  • Sólo las historias aceptadas por PP se demuestran
  • Todos los interesados se han invitado para la demo con antelación
  • Se anima a las partes interesadas a dar su opinión durante la demo

Retrospectiva

  • La Retrospectiva tiene lugar después de cada sprint
  • Todos los miembros del equipo y el PP comparten el feedback
  • El equipo analiza los datos y decide que acciones emprender
  • Las acciones se priorizan e implementan en los próximos sprints

Sobre el autor

Kevin Wood es Gerente de Desarrollo de Atlaz y tiene una gran experiencia en finanzas y administración de negocios. Su profunda comprensión de los principios de mercadotecnia y sus excelentes habilidades analíticas, le ayudan a identificar ideas de tendencia, a evaluar riesgos y a encontrar los mejores potenciales para las necesidades y metas de sus socios.

Esperamos que os sea de utilidad y vuestros comentarios

Post escrito conjuntamente por Gertrudis López y Alexander Menzinsky

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s