Scrum (desarrollo de software)

Véase también: medio scrum

Ciclos de desarrollo.

Archivo:Ficha scrum.png

Ficha sinóptica

Marco de Trabajo SCRUM

Scrum es el nombre con el que se denomina a los marcos de desarrollo ágiles caracterizados por:

• Adoptar una estrategia de desarrollo incremental, en lugar de la planificación y ejecución completa del producto.
• Basar la calidad del resultado más en el conocimiento tácito de las personas en equipos auto organizados, que en la calidad de los procesos empleados.
• Solapamiento de las diferentes fases del desarrollo, en lugar de realizar una tras otra en un ciclo secuencial o en cascada.

Historia

Este modelo fue identificado y definido por Ikujiro Nonaka e Hirotaka Takeuchi a principios de los 80, al analizar cómo desarrollaban los nuevos productos las principales empresas de manufactura tecnológica: Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M y Hewlett-Packard (Nonaka & Takeuchi, The New New Product Development Game, 1986).

En su estudio, Nonaka y Takeuchi compararon la nueva forma de trabajo en equipo, con el avance en formación de melé (scrum en inglés) de los jugadores de Rugby, a raíz de lo cual quedó acuñado el término “scrum” para referirse a ella.

Aunque esta forma de trabajo surgió en empresas de productos tecnológicos, es apropiada para cualquier tipo de proyecto con requisitos inestables y para los que requieren rapidez y flexibilidad, situaciones frecuentes en el desarrollo de determinados sistemas de software.

En 1995, Ken Schwaber presentó “Scrum Development Process” en OOPSLA 95 (Object-Oriented Programming Systems & Applications conference)(SCRUM Development Process), un marco de reglas para desarrollo de software, basado en los principios de Scrum, y que él había empleado en el desarrollo de Delphi, y Jeff Sutherland en su empresa Easel Corporation (compañía que en los macrojuegos de compras y fusiones, se integraría en VMARK, y luego en Informix y finalmente en Ascential Software Corporation).

Características de Scrum

SCRUM es un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto. Los roles principales en Scrum son el 'Scrum Master, que procura facilitar la aplicación de scrum y gestionar cambios, el Product Owner, que representa a los stakeholders (interesados externos o internos), y el Team (equipo) que ejecuta el desarrollo y demás elementos relacionados con él. Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud es definida por el equipo y debe ser lo más corta posible), el equipo crea un incremento de software potencialmente entregable (utilizable). El conjunto de características que forma parte de cada sprint viene del Product Backlog, que es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar (PBI, Product Backlog Item). Los elementos del Product Backlog que forman parte del sprint se determinan durante la reunión de Sprint Planning. Durante esta reunión, el Product Owner identifica los elementos del Product Backlog que quiere ver completados y los hace del conocimiento del equipo. Entonces, el equipo conversa con el Product Owner buscando la claridad y magnitud adecuadas (Cumpliendo el INVEST) para luego determinar la cantidad de ese trabajo que puede comprometerse a completar durante el siguiente sprint.​ Durante el sprint, nadie puede cambiar el Sprint Backlog, lo que significa que los requisitos están congelados durante el sprint.​

Scrum permite la creación de equipos auto organizados impulsando la co-localización de todos los miembros del equipo, y la comunicación verbal entre todos los miembros y disciplinas involucrados en el proyecto.

Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn), y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser completamente entendido o definido, y centrándose en maximizar la capacidad del equipo de entregar rápidamente y responder a requisitos emergentes.

Principales características de Scrum:

• Gestión regular de las expectativas del cliente, resultados anticipados, flexibilidad y adaptación, retorno de inversión, mitigación de riesgos, productividad y calidad, alineamiento entre cliente y equipo, por último equipo motivado.

Cada uno de estos puntos mencionados hacen que el Scrum sea utilizado de manera regular en un conjunto de buenas prácticas para el trabajo en equipo y de esa manera obtener resultados posibles.

Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas amarillas "post-it" y pizarras hasta paquetes de software.

Una de las mayores ventajas de Scrum es que es muy fácil de aprender, y requiere muy poco esfuerzo para comenzarse a utilizar. Así, si se utiliza una pizarra con notas autoadhesivas cualquier miembro del equipo podrá ver tres columnas: trabajo pendiente ("backlog"), tareas en proceso ("in progress") y hecho ("done"). De un solo vistazo, una persona puede ver en qué están trabajando los demás en un momento determinado.​

Roles en Scrum

Roles Principales

Hay tres roles principales en el Framework Scrum, Dueño de Producto (Product Owner), el Equipo de Desarrollo (Development Team) y un Scrum Master. Estos tres roles principales forman el equipo Scrum.

Product Owner

El Product Owner se asegura de que el equipo Scrum trabaje de forma adecuada desde la perspectiva del negocio. El Product Owner ayuda al usuario a escribir las historias de usuario, las prioriza, y las coloca en el Product Backlog.

ScrumMaster (o Facilitador)

El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan.

Equipo Scrum

El equipo tiene la responsabilidad de entregar el producto. Es recomendable un pequeño equipo de 5 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (análisis, diseño, desarrollo, pruebas, documentación, etc).

Roles Auxiliares

Los roles auxiliares en los "equipos Scrums" son aquellos que no tienen un rol formal y no se involucran frecuentemente en el "proceso Scrum", sin embargo deben ser tomados en cuenta. Un aspecto importante de una aproximación ágil es la práctica de involucrar en el proceso a los usuarios, expertos del negocio y otros interesados ("stakeholders"). Es importante que esa gente participe y entregue retroalimentación con respecto a la salida del proceso a fin de revisar y planear cada sprint.

Stakeholders (Clientes, Proveedores, Vendedores, etc)

Son las personas que hacen posible el proyecto y para quienes el proyecto producirá el beneficio acordado que justifica su desarrollo. Sólo participan directamente durante las revisiones del "sprint".

Administradores (Managers)

Son los responsables de establecer el entorno para el desarrollo del proyecto.

Ceremonias en Scrum

Daily Scrum o Stand-up meeting

Cada día de un sprint, se realiza la ceremonia sobre el estado de un proyecto. Esto se llama daily standup o Stand-up meeting. El scrum tiene unas guías específicas:

• La ceremonia comienza puntualmente a su hora.
• Todos son bienvenidos, pero sólo los involucrados en el proyecto pueden hablar.
• La ceremonia tiene una duración máxima de 15 minutos, de forma independiente del tamaño del equipo.
• La ceremonia debe celebrarse idealmente, en la misma ubicación y a la misma hora todos los días.

Durante la ceremonia, cada miembro del equipo contesta a tres preguntas:​

• ¿Qué has hecho desde ayer?
• ¿Qué es lo que haré hoy?
• ¿Has tenido algún problema que te haya impedido alcanzar tu objetivo? (el papel del ScrumMaster es eliminar estos impedimentos).

El objetivo último de las ceremonias diarias es que cada miembro del equipo sepa si se están cumpliendo los plazos marcados para el "sprint".

Scrum de Scram

Estas ceremonias, por lo general, se realizan cuando en la organización existan varios equipos Scrum, y les permiten discutir su trabajo, enfocándose especialmente en áreas de solapamiento e integración. Se hace normalmente cada día después del “Daily Scrum” o, como máximo, cada dos días. Asiste una persona asignada por cada equipo Scrum.

La agenda será la misma que la del Daily Scrum, añadiendo, además, las siguientes cuatro preguntas:

• ¿Qué ha hecho tu equipo desde nuestra última reunión?
• ¿Qué hará tu equipo antes que nos volvamos a reunir?
• ¿Hay algo que demora o estorba a tu equipo?
• ¿Estás a punto de poner algo en el camino del otro equipo?

Planificación del Sprint (Sprint Planning)

Al inicio de cada ciclo de Sprint (de acuerdo a la duración definida de los sprints), se lleva a cabo una ceremonia de planificación del Sprint. Se pretende:

• Seleccionar qué trabajo se hará.
• Preparar, con el equipo completo, el Sprint Backlog que detalla el tiempo y el esfuerzo que llevará hacer el trabajo.
• Identificar y comunicar cuánto del trabajo es probable que se realice durante el actual Sprint.
• Se toma como medida de tiempo para esta ceremonia una hora por cada semana de duración del sprint, teniendo un máximo posible de ocho (8) horas como límite.

Al final del ciclo Sprint se celebran dos ceremonias más: la revisión del Sprint y la retrospectiva del Sprint.

Revisión del Sprint (Sprint Review)

• Revisar el trabajo que fue completado y no completado
• Presentar el trabajo completado a los interesados, puede ser a través de una demostración o de un ambiente para tal fin (sin que esto constituya una tarea adicional al equipo)
• El trabajo incompleto no puede ser demostrado
• Se toma como medida de tiempo una hora por cada semana de duración del Sprint.

Retrospectiva del Sprint (Sprint Retrospective)

Después de cada sprint, se lleva a cabo una retrospectiva del propio sprint, en la cual todos los miembros del equipo dejan sus impresiones sobre el sprint recién superado. El propósito de la retrospectiva es realizar una mejora continua del proceso. Aplicando las mismas medidas de tiempo antes descritas para las otras ceremonias.

Sprint

El Sprint es el período en el cual se lleva a cabo el trabajo en sí. Es recomendado que la duración de los sprints sea constante y definida por el equipo con base en su propia experiencia. Se puede comenzar con una duración de sprint en particular (2 o 3 semanas) e ir ajustándolo con base en el ritmo del equipo, aunque sin relajarlo demasiado. Al final de cada sprint, el equipo deberá presentar los avances logrados, y el resultado obtenido es un producto que, potencialmente, se puede entregar al cliente.

Así mismo, se recomienda no agregar objetivos al sprint o sprint backlog a menos que su falta amenace al éxito del proyecto. La constancia permite la concentración y mejora la productividad del equipo de trabajo.

El tiempo mínimo de un Sprint es de dos (2) semanas y el máximo es de cuatro (4) semanas.

Beneficios de Scrum

• Flexibilidad a cambios. Gran capacidad de reacción ante los cambiantes requerimientos generados por las necesidades del cliente o la evolución del mercado. El marco de trabajo está diseñado para adecuarse a las nuevas exigencias que implican proyectos complejos.
• 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. El trabajo metódico y la necesidad de obtener una versión de trabajo funcional después de cada iteración, ayuda a la obtención de un software de alta calidad.
• Mayor productividad. Se logra, entre otras razones, debido a la eliminación de la burocracia y la motivación del equipo proporcionado por el hecho de que pueden estructurarse de manera autónoma.
• Maximiza el retorno de la inversión (ROI). Creación de software solamente con las prestaciones que contribuyen a un mayor valor de negocio gracias a la priorización por retorno de inversión.
• Predicciones de tiempos. A través de este marco de trabajo se conoce la velocidad media del equipo por sprint, con lo que es posible estimar de manera fácil cuando se podrá hacer uso de una determinada funcionalidad que todavía está en el Backlog.
• Reducción de riesgos El hecho de desarrollar, en primer lugar, las funcionalidades de mayor valor y de saber la velocidad a la que el equipo avanza en el proyecto, permite despejar riesgos efectivamente de manera anticipada.​

Documentos

Product backlog

El product backlog se trata como un documento de alto nivel para todo el proyecto. Es el conjunto de todos los requisitos de proyecto, el cual contiene descripciones genéricas de funcionalidades deseables, priorizadas según su retorno sobre la inversión (ROI) . Representa el qué va a ser construido en su totalidad. Es abierto y solo puede ser modificado por el product owner. Contiene estimaciones realizadas a grandes rasgos, tanto del valor para el negocio, como del esfuerzo de desarrollo requerido. Esta estimación ayuda al product owner a ajustar la línea temporal (KEV) y, de manera limitada, la prioridad de las diferentes tareas. Por ejemplo, si dos características tienen el mismo valor de negocio la que requiera menor tiempo de desarrollo tendrá probablemente más prioridad, debido a que su ROI será más alto.

Sprint backlog

El sprint backlog es el subconjunto de requisitos que serán desarrollados durante el siguiente sprint. Al definir el sprint backlog, se describe el cómo el equipo va a implementar los requisitos durante el sprint. Por lo general los requisitos se subdividen en tareas, a las cuales se asignan ciertas horas de trabajo pero ninguna tarea con una duración superior a 16 horas. Si una tarea es mayor de 16 horas, deberá ser dividida en otras menores. Las tareas en el sprint backlog nunca son asignadas, son tomadas por los miembros del equipo del modo que les parezca adecuado.

Burn down chart

La burn down chart es una gráfica mostrada públicamente que mide la cantidad de requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una línea que conecte los puntos de todos los Sprints completados, podremos ver el progreso del proyecto. Lo normal es que esta línea sea descendente (en casos en que todo va bien en el sentido de que los requisitos están bien definidos desde el principio y no varían nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha terminado (no hay más requisitos pendientes de ser completados en el Backlog). Si durante el proceso se añaden nuevos requisitos la recta tendrá pendiente ascendente en determinados segmentos, y si se modifican algunos requisitos la pendiente variará o incluso valdrá cero en algunos tramos.

Referencias

• (PDF) Rising, L., Janoff, N.S. (2000). The Scrum Software Development Process for Small Teams Retrieved March 15, 2007
• (PDF) Schwaber, K. Advanced Development Methods. SCRUM Development Process Retrieved July 01, 2010
• (video) Jeff Sutherland in Scrum Tuning: Lessons learned from Scrum implementation at Google Retrieved 2007-12-15
• (video) Ken Schwaber in Scrum et al. Retrieved 2008-01-19

Véase también

• Agilmática
• Arquitectura orientada a servicios
• Back office
• Ciclo de vida del producto
• Desarrollo ágil de software
• Desarrollo de software
• Kanban
• Lean software development

Enlaces externos

• Libro gratuito sobre Scrum
• "Scrum y XP desde las trincheras", traducción de "Scrum and XP from the trenches" por Henrik Kniberg
• Artículo de introducción a Scrum