PDF de programación - Una introducción básica a la teoría y práctica de Scrum - Versión 2.0

Una introducción básica a la teoría y práctica de Scrum

Versión 2.0



Pete Deemer
GoodAgile
www.goodagile.com

Gabrielle Benefield
Evolve
www.evolvebeyond.com



Craig Larman

www.craiglarman.com



Bas Vodde
Odd-e
www.odd-e.com







Nota a los lectores: hay muchas descripciones concisas de Scrum disponibles on-line, y esta
introducción pretende proporcionar el siguiente nivel de detalle sobre sus prácticas. No debe
considerarse como el paso definitivo en el aprendizaje de Scrum: es aconsejable que los equipos que
estén considerando adoptar Scrum adquieran Agile Project Managament with Scrum de Ken Schwaber,
Succeeding with Agile de Mike Cohn y aprovechen cualquiera de las muchas excelentes opciones de
formación y coaching existentes (detalles completos en scrumalliance.org). Nuestro agradecimiento
a Ken Schwaber, Dr. Jeff Sutherland, y Mike Cohn por sus generosas sugerencias.



© 2012 Pete Deemer, Gabrielle Benefield, Craig Larman, Bas Vodde

Traducción al castellano:



Ángel Medinilla

Proyectalis

www.proyectalis.com/AngelMedinilla



2




Más allá del desarrollo tradicional

El desarrollo tradicional basado en grupos especializados, ciclos de feedback débiles o tardíos,
planificación predictiva “a priori” y flujo secuencial desde el análisis hasta las pruebas no está
teniendo mucho éxito en el cambiante mundo de hoy en día. Esta estrategia de desarrollo retarda el
feedback, el aprendizaje y el potencial retorno de inversión debido a una ausencia de software
funcionando hasta las fases finales del proyecto, lo que provoca falta de transparencia, escasez de
posibilidades para mejorar, reducción de la flexibilidad y un incremento de los riesgos técnicos y de
negocio.

Durante décadas ha existido una alternativa – equipos cross-funcionales realizando un desarrollo
iterativo – pero no ha sido tan empleada como el modelo tradicional. Scrum engloba conceptos
simples y comprobados para el desarrollo de productos, en un Framework (marco de trabajo) simple
que incluye auténticos equipos, equipos cross-funcionales, equipos auto-gestionados, ciclos
completos de feedback cortos e iterativos y reducción del coste de los cambios. Estos conceptos
incrementan la agilidad y el feedback, permiten un ROI más temprano y reducen el riesgo.

Visión general

Scrum es un marco de trabajo en el que equipos cross-funcionales pueden crear productos o
desarrollar proyectos de una forma iterativa e incremental. El desarrollo se estructura en ciclos de
trabajo llamados Sprints (también conocidos como iteraciones). Estas iteraciones no deben durar
más de cuatro semanas cada una (siendo dos semanas la duración más habitual) y tienen lugar una
tras otra sin pausa entre ellas. Los Sprints están acotados en el tiempo – finalizan en una fecha
determinada independientemente de si el trabajo ha finalizado por completo o no, y jamás se
prorrogan. Normalmente los equipos Scrum escogen una duración de Sprint y la mantienen para
todos sus Sprints hasta que mejoran y pueden emplear ciclos más cortos. Al principio de cada
Sprint, un Equipo cross-funcional (de en torno a siete personas) selecciona elementos (peticiones del
cliente) de una lista priorizada. El equipo acuerda un objetivo colectivo respecto a lo que creen que
podrán entregar al final del Sprint, algo que sea tangible y que estará “terminado” por completo.
Durante el Sprint no se podrán añadir nuevos elementos; Scrum se adapta a los cambios en el
siguiente Sprint, pero el pequeño Sprint actual está pensado para concentrarnos en un objetivo
pequeño, claro y relativamente estable. Todos los días el Equipo se reúne brevemente para
inspeccionar su progreso y ajustar los siguientes pasos necesarios para completar el trabajo
pendiente. Al final del Sprint, el Equipo revisa el Sprint con los diferentes Stakeholders (interesados
e involucrados en el producto) y realiza una demostración de lo que han desarrollado. Se obtiene
feedback que podrá ser incorporado en el siguiente Sprint. Scrum enfatiza un producto
“funcionando” al final del Sprint que esté realmente “terminado”. En el caso del software, esto
significa un sistema que está integrado, testado, con la documentación de usuario generada y
potencialmente entregable. Los principales roles, artefactos y eventos están resumidos en Figura 1.

Figura 1. Visión General de Scrum



3

SPRINTSCRUMDIARIOSIN CAMBIOS EN EL OBJETIVODE UNA A CUATRO SEMANASDUEÑO DE PRODUCTOPRODUCTBACKLOGREVISIÓNDEL SPRINTEQUIPOTRABAJOBACKLOG DEPRODUCTOPRODUCTBACKLOGBACKLOG DESPRINTELEMENTOSINCREMENTO DE PRODUCTOPOTENCIALMENTEENTREGABLEPLANIFICACIÓNDE SPRINTPRIMERA Y SEGUNDA PARTEREFINAMIENTO DELA PILA DE PRODUCTORETROSPECTIVASCRUMMASTERSCRUM


Un lema recurrente en Scrum es “inspección y adaptación”. Dado que el desarrollo conlleva de
forma inevitable aprendizaje, innovación y sorpresas, Scrum enfatiza dar pequeños pasos en el
desarrollo, inspeccionando tanto el producto resultante como la eficacia de las prácticas actuales, y a
continuación adaptar los objetivos respecto al producto y las prácticas de los procesos. Repetir
indefinidamente.

Roles en Scrum

En Scrum existen tres roles: Dueño de Product, Equipo y ScrumMaster. Todos ellos forman lo que
se conoce como el Equipo Scrum.

El Dueño de Producto es responsable de maximizar el retorno de inversión (ROI) a base de
identificar las funcionalidades de producto, trasladarlas a una lista priorizada, decidir cuáles deberían
estar al principio de la lista para el siguiente Sprint, y repriorizar y refinar continuamente dicha lista.
El Dueño de Producto es responsable a nivel ganancias y pérdidas del producto, asumiendo que se
trata de un producto comercial. En el caso de aplicaciones internas, el Dueño de Producto no es
responsable del ROI en el mismo sentido que en un producto comercial (que generaría ingresos),
pero aun sería responsable de maximizar el ROI en el sentido de escoger – en cada Sprint – los
elementos que más valor aportan. En la práctica, “valor” es un término muy difuso, y la
priorización puede verse influenciada por el deseo de satisfacer a los clientes clave, la alineación con
los objetivos estratégicos, atacar riesgos, mejorar y otros factores. En algunos casos el Dueño de
Producto y el cliente son la misma persona; esto es frecuente en el caso de desarrollos internos. En
otros, “el cliente” pueden ser millones de personas con necesidades muy variadas, en cuyo caso en
muchas organizaciones el rol del Poduct Owner es similar al de Product Manager (Director de
Producto) o Product Marketing Manager (Director de Marketing de Producto). Sin embargo, el rol
del Dueño de Producto es algo distinto del Product Manager tradicional, ya que interactúa de forma
activa y regular con el Equipo, prioriza trabajando con todos los stakeholders y revisa los resultados
de cada Sprint, en lugar de delegar las decisiones de desarrollo a un Jefe de Proyecto. Es importante
hacer notar que, en Scrum, hay una y sólo una persona que sirve como Dueño de Producto y ejerce
la autoridad final como tal, y él o ella es responsable del valor del trabajo realizado, aunque dicha
persona no tiene por qué trabajar sola.

El Equipo (también llamado Equipo de Desarrollo) construye lo que el Dueño de Producto
indica: por ejemplo, una aplicación o un sitio Web. El Equipo en Scrum es “cross-funcional” –
engloba toda la experiencia y conocimiento necesarios para desarrollar un producto potencialmente
entregable en cada Sprint – y es “auto-organizado” (auto-gestionado), con un amplio margen de
autonomía y responsabilidad. El Equipo decide cuántos elementos (del conjunto que ofrece el
Dueño de Producto) va a desarrollar durante el Sprint y cuál es la mejor manera de lograr dicho
objetivo.

Cada miembro del Equipo es simplemente un miembro de equipo. Nótese que no hay títulos fijos
especializados en un grupo que adopta Scrum: no hay analistas de negocio, administradores de
bases de datos, arquitectos, líderes de equipo, diseñadores / especialistas en UX, programadores…
Los miembros del Equipo trabajan juntos durante cada Sprint de cualquier manera que sea
apropiada para lograr el objetivo que se han marcado ellos mismos.

Dado que solo hay miembros de equipo, el Equipo no es sólo cross-funcional, sino que además
muestra aprendizaje múltiple: cada persona indudablemente tendrá ciertas fortalezas, pero también
continuará aprendiendo otras especialidades. Cada persona tendrá habilidades principales,
secundarias e incluso terciarias, y se espera de ellos que “vayan a por el trabajo”: que emprendan
tareas con las que se sienten menos familiarizados con el objetivo de ayudar a completar un
elemento. Por ejemplo, una persona cuya habilidad principal es el diseño de interacción de usuario
(UX) podría tener habilidades secundarias en automatización de pruebas; una persona con habilidad
principal en redacción técnica podría también ayudar con el análisis y la programación.

El Equipo Scrum tiene siete más/menos dos personas, y en el caso del Software el Equipo podría
incluir a personas con habilidades en análisis, desarrollo, pruebas, diseño de interfaz, diseño de
bases de datos, arquitectura, documentación y demás. El Equipo desarrolla el producto y
proporciona ideas al Dueño de