Ensayo métodos agiles para el desarrollo de software

Brayan Fernando Bermeo Ariza

Adsi 581708

Historia:

La definición moderna de desarrollo ágil de software evolucionó a mediados de la década de 1990 como parte
de una reacción contra los métodos de "pico pizado", muy estructurados y estrictos, extraídos del modelo de
desarrollo en cascada. El proceso originado del uso del modelo en cascada era visto como burocrático, lento,
degradante e inconsistente con las formas de desarrollo de software que realmente realizaban un trabajo
eficiente.

Los métodos de desarrollo ágiles e iterativos pueden ser vistos como un retroceso a las prácticas
observadas en los primeros años del desarrollo de software (aunque en ese tiempo no había
metodologías formales). Inicialmente, los métodos ágiles fueron llamados métodos de "peso
liviano".

En el año 2001, miembros prominentes de la comunidad se reunieron en Snowbird, Utah, y

adoptaron el nombre de "métodos ágiles". Poco después, algunas de estas personas formaron la
"alianza ágil", una organización sin fines de lucro que promueve el desarrollo ágil de aplicaciones.
Muchos métodos similares al ágil fueron creados antes del 2000. Entre los más notables se
encuentran: Scrum (1986), Crystal Clear (cristal transparente), programación extrema (en
inglés eXtreme Programming o XP, 1996), desarrollo de software adaptativo, feature driven
development, Método de desarrollo de sistemas dinámicos (en inglés Dynamic Systems
Development Method o DSDM, 1995).

Kent Beck creó el método de Programación Extrema (usualmente conocida como XP) en 1996
como una forma de rescatar el proyecto del Sistema exhaustivo de compensaciones de Chrysler
(C3). Mientras Chrysler cancelaba ese proyecto, el método fue refinado por Ron Jeffries.
 Conceptualización:

Con que fin se crean metodologías

agiles para el desarrollo de software ?

Desarrollar software no es una tarea nada fácil y más en la actualidad donde los conocimientos y
metodologías propuestas en este campo nos llevan a consideran diversas dimensiones de
desarrollo , por una parte vemos los métodos básicos y simples que de alguna forma incurren en lo
tradicional y se centran básicamente en el control del proceso , estableciendo una serie de
herramientas y parámetros para el desarrollo , como son las actividades involucradas , los
artefactos o productos a producir y las herramientas con las cuales llegar a este fin .

Estas propuestas cumplen en parte con el estándar de un gran número de

proyectos y han demostrado ser efectivas , pero sin embargo siguen
incurriendo en fallas por lo que no se puede considerar este mismo tipo de
desarrollo para todos los proyectos , basándose en estos puntos débiles , se
han implementado nuevas herramientas , metodologías y restricciones para el
desarrollo del mismo , el resultado es un proyecto más complejo con un mayor
número de limitaciones , llegando a tal punto que puede limitar al equipo de
trabajo , también podemos concentrarnos en las otras dimensiones como lo
son el factor humano o el producto del software , como no lo indica la filosofía
de metodologías agiles , las cuales dan una mayor importancia al rol de los
actores en el software , con iteraciones cortas, estos métodos han demostrado
su efectividad en creación de proyectos muy cambiantes y con un corto tiempo
de desarrollo , pero manteniendo una buena calidad , estas metodologías
están revolucionando la manera de producir software y generando debate , la
cuestión es que algunas personas no consideran que estas metodologías
vallan entre las metodologías tradicionalmente utilizadas

La parte olvidada de las metodologías agiles

Cuando se habla de metodologías ágiles y quizás porque en el fondo somos programadores y no

gestores, siempre se habla de cosas como la reunión diaria, las entregas frecuentes, los tableros
Scrum, los test automáticos, etc, etc. Sin embargo, hay otro punto realmente importante y del que
no se suele hablar, la intervención directa del cliente a lo largo de todo el proceso.
Afortunadamente, he tenido oportunidad de practicar con este último punto y ahí va la experiencia.
Pongámonos primero en contexto El proyecto es un proyecto pequeño para lo que estamos
acostumbrados, un solo desarrollador, yo mismo, durante algo más de seis meses y con la suerte
de poder dedicarme al 100% al proyecto (cosas de la crisis, no hay demasiado trabajo). Hay
también un jefe de proyecto, pero su única gestión es básicamente el tema económico y alguna
reunión o charla esporádica con los "jefes" del cliente. El proyecto es un proyecto Web, en el que
sólo hay software implicado, el servidor está desde el principio en las instalaciones del cliente, con
su dominio público en internet y al que tengo acceso de administración con una VPN (red privada
virtual) En este contexto, tengo contacto diario y directo, por teléfono y email, con los usuarios
finales del proyecto, los que van a estar usando esa web día a día, así que pensé que es una
situación ideal para metodologías ágiles. Al ser yo el único desarrollador y estar el cliente en otra
ciudad a más de 400 km de distancia, todo eso de las "demos" y reuniones al estilo Scrum no me
parecía adecuado, así que opté por una opción más al estilo Kanban. Me di de alta en
https://kanbanflow.com , hice un tablero con cuatro columnas : to-do, in-progress, verification y
done, copié los requisitos iniciales en la columna to-do y le mostré el tablero a los clientes, así
como una explicación del funcionamiento general de Kanban y metodologías ágiles, en lo que a
ellos les afecta. Les pareció una idea estupenda y es lo que estamos usando. Ellos ordenaron y
matienen ordenada la columna de "to-do", además de añadir más tareas cuando les viene en gana,
en el orden en que quieren que se desarrolle. Yo siempre saco la primera tarea de arriba del todo y
la muevo a la columna "in-progress", teniendo como máximo 3 tareas simultáneas en desarrollo.
Cuando termino de probarla en mi entorno de pruebas y la subo al servidor, la muevo a "en
verficacion" y ellos, tras probarla, la mueven a "done" o la devuelven a la primera columna con más
cosas que quieren o bugs que han encontrado. En fin, nada que no sepamos ya del
funcionamiento de un tablero Kanban. ¿Y cuales son las consecuencias de todo esto?. Pues bien,
como nada es blanco ni negro, hay cosas buenas y otras no tan buenas. Empecemos con las
primeras. Lo mejor de todo es que el cliente está encantado. No es solo que me lo digan cuando
les pregunto, es también el "feedback" que me da nuestro jefe de proyecto cuando habla con ellos
o lo que yo mismo oigo a los clientes hablar entre ellos cuando nos hemos reunido cara a cara. Lo
primero que les gusta, por supuesto, es que el producto, aparte de no tener grandes fallos, cumple
exactamente lo que necesitan, como no puede ser de otra forma, puesto que los mismos usuarios
finales lo ven evolucionar día a día y deciden sobre lo que se debe hacer y cómo. Y lo segundo
que les encanta es la excelente gestión de sus peticiones (mérito de un mecanismo como Kanban),
ellos tienen total control sobre lo que piden y cuándo se aborda, así como total visibilidad de lo que
se está haciendo y lo que tarda en hacerse. Ninguna de sus tareas lleva un tiempo estimado de
más de 3 ó 4 días, pero la mayoría son de 1 ó 2 días, por lo que ven progresos de forma continua.
Si alguna tarea lleva mucho más, hablo con ellos y tratamos de partirla, creando una tarea más
pequeña con lo que realmente es importante para ellos y otras con lo menos importante y que
puedan poner más abajo en la lista. Y ahora viene la parte no tan buena. Aunque se deja claro al
principio que pueden añadir, modificar y ordenar tareas a su gusto, también se deja claro que el
proyecto tiene una fecha de terminación y que toda modificación que hagan o tarea que añadan,
no debería afectar a esa fecha, sino simplemente hacer más probable, si no seguro, que las tareas
al final de la columna to-do se queden sin hacer. Esto, por supuesto es algo que no les gusta oir.
Pero eso no es lo peor, porque la ventaja de controlar el desarrollo día a día les convence frente a
la posibilidad de que alguna tarea poco importante para ellos se quede sin hacer y de alguna
forma, lo aceptan. Lo peor es que en el día a día se "emocionan" con las tareas que se van
realizando y tienden a no acabarse nunca. Cuando terminas una tarea y ellos la prueban, se les
ocurren mejoras que inmediamente hacen que la tarea vuelva a la columna "to-do", con añadidos
para hacer y, normalmente, al principio para que se aborde inmediatamente. Hay que estar
continuamente pidiéndoles verificación, como sutil indirecta de que nos estamos eternizando en los
detalles, de si están seguros que ese nuevo añadido es más prioritario que las siguientes tareas en
la lista. Hay otro detalle, no sé si bueno o malo, y es el "pequeño estrés" que causa este método al
desarrollador (yo). Al ver ellos el progreso día a día y ser tareas de tan poco tiempo estimado (1, 2,
3 días), "canta" mucho si un día me distraigo con cualquier cosa. Si tengo alguna reunión ajena al
proyecto, si acabo de volver de vacaciones y tengo el típico día perezoso que te pasas
"güeveando" en internet o con el email … Se ve agravado por el hecho de que para tener mejor
visibilidad de cómo va el proyecto, llevamos un pequeño excel compartido que se actualiza todos
los Viernes, en él aparecen las tareas, el tiempo que yo estimo para cada una de ellas en días y
sumando esos días, la fecha prevista de terminación de cada una de ellas … y por tanto la fecha
prevista de terminación del proyecto si se hacen todas las tareas. Si una tarea se complica más de
lo previsto, ya me causa un pequeño "estrés" actualizar el excel y ver cómo la fecha de finalización
se va alargando a la vista de todos. Pero me causa mucho más "estrés" si encima ese retraso va
causado por la típica pereza que todos tenemos algún día que otro. Puedo asegurar que nunca he
trabajado tanto y tan seguido como en este proyecto, en parte por el "estrés" que me causa perder
el tiempo, en parte por tener en todo momento perfectamente claro qué es lo que tengo que hacer
y cómo. Ojo, no he echado ni una sola hora de más, es simplemente que apenas pierdo el tiempo
a lo largo del horario laboral tratando de que el flujo de tareas de "to-do" a "done" sea lo más fluído
posible. Ahora nos estamos acercando a la fecha prevista de finalización, por supuesto, con
requisitos iniciales que el cliente no ha considerado importantes al final de la lista to-do y
totalmente fuera de plazo, pero con otros requisitos que han añadido sobre la marcha y que han
considerado más importantes hechos a su gusto, con el cliente bastante contento en general.
Veremos qué tal va el cierre final

Entre los métodos más conocidos se

encuentran:

 Adaptive Software Development (ASD).

El método ágil ASD (Adaptive Software Development) traducido en español significa Desarrollo
Adaptable de Software es un modelo de implementación de patrones ágiles para desarrollo de
software. Al igual que otras metodologías ágiles, su funcionamiento es cíclico y reconoceque en
cada iteración se producirán cambios e incluso errores.

El desarrollo de software adaptable (Adaptive Software Development - ASD) es una metodología

de desarrollo que hace énfasis en aplicar las ideas que se originaron en el mundo de los sistemas
complejos, adaptación continua del proceso al trabajo.

DETALLE FASES DE LA METODOLOGIA

ESPECULACIÓN

Compuesta por 5 pasos:

1.- Inicio para determinar la misión del proyecto.

2.- Determinación del marco temporal del

proyecto.

3.- Determinación del nº de iteraciones y la

duración de cada una.

4.- Determinación del objetivo de cada una.

5.- Asignación de funcionalidad a cada iteración.

COLABORACIÓN

 Desarrollo concurrente del trabajo de

 construcción y gestión del producto

APRENDIZAJE

En cada iteración se revisa:

 Calidad, con criterios de cliente.

 Calidad, con criterios técnicos.
 Funcionalidad desarrollada
 Estado del proyecto

Las características básicas de ASD son:

  Trabajo orientado y guiado por la misión del proyecto.
 Basado en la funcionalidad
 Desarrollo iterativo
 Desarrollo acotado temporalmente

Guiado por los riesgos

 Trabajo tolerante al cambio.

 Agile Unified Process (AUP).

Crystal CleaAgile Unified Process, en español Proceso Unificado Ágil de Scott Ambler o
(AUP) en inglés, es una versión simplificada del Proceso Unificado de Rational (RUP). Este
describe de una manera simple y fácil de entender la forma de desarrollar aplicaciones de
software usando técnicas ágiles y conceptos que aún se mantienen válidos en RUP.r.

Característica de AUP

 Abarca siete flujos de trabajos, cuatro ingenieriles y tres de apoyo: Modelado,

Implementación, Prueba, Despliegue, Gestión de configuración, Gestión de Proyectos y
Ambiente.
 El modelado agrupa los tres primeros flujos de RUP (Modelamiento del negocio,
Requerimientos y Análisis y Diseño).
 Dispone de cuatro fases igual que RUP: Incepción o Creación, Elaboración, Construcción y
Transición.

 Feature Driven Development (FDD).

Definición :

Característica impulsada diseño (FDD) es un iterativo e incremental proceso de desarrollo de

software . Es uno de una serie de métodos ágiles de desarrollo de software y forma parte de la
Alianza Ágil . FDD combina una serie de reconocidas por la industria las mejores prácticas en un
todo coherente. Estas prácticas están todos impulsados desde una funcionalidad de cliente de
valor ( función ) perspectiva. Su principal objetivo es entregar, software de trabajo tangible en
repetidas ocasiones en el momento oportuno.

Historia:

Lean SoFue desarrollada por Jeff De Luca y Peter Coad a mediados de los años 90. Esta
metodología se enfoca en iteraciones cortas, que permiten entregas tangibles del producto
en un periodo corto de tiempo, de como máximo dos semanas. ftware Development (LSD).

Carateristicas :

Se preocupa por la calidad, por lo que incluye un monitoreo constante del proyecto.

Ayuda a contrarrestar situaciones como el exceso en el presupuesto, fallas en el programa o el

hecho de entregar menos de lo deseado.

Propone tener etapas de cierre cada dos semanas. Se obtienen resultados periódicos y tangibles.

Se basa en un proceso iterativo con iteraciones cortas que producen un software funcional que el
cliente y la dirección de la empresa pueden ver y monitoriar.

Define claramente entregas tangibles y formas de evaluación del progreso del proyecto.

No hace énfasis en la obtención de los requerimientos sino en como se realizan las fases de
diseño y construcción.

Ventajas :
 El equipo de desarrollo no malgasta el tiempo y dinero del cliente desarrollando soluciones
innecesariamente generales y complejas que en realidad no son un requisito del cliente.
 Cada componente del producto final ha sido probado y satisface los requerimientos.
 Rápida respuesta a cambios de requisitos a lo largo del desarrollo.
 Entrega continua y en plazos cortos de software funcional.
 Trabajo conjunto entre el cliente y el equipo de desarrollo.
 Minimiza los costos frente a cambios.
 Importancia de la simplicidad, al eliminar el trabajo innecesario.
 Atención continua a la excelencia técnica y al buen diseño.
 Mejora continua de los procesos y el equipo de desarrollo.
 Evita malentendidos de requerimientos entre el cliente y el equipo.

Desventajas :

 Falta de documentación del diseño. El código no puede tomarse como una documentación.
En sistemas de tamaño grande se necesitar leer los cientos o miles de páginas del listado de
código fuente.
 Problemas derivados de la comunicación oral. Este tipo de comunicación resulta difícil de
preservar cuando pasa el tiempo y está sujeta a muchas ambigüedades.
 Fuerte dependencia de las personas. Como se evita en lo posible la documentación y los
diseños convencionales, los proyectos ágiles dependen críticamente de las personas.
 Falta de reusabilidad. La falta de documentación hacen difícil que pueda reutilizarse el
código ágil.

Procesos:

Desarrollar un modelo global: Al inicio del desarrollo se construye un modelo teniendo en cuenta la
visión, el contexto y los requisitos que debe tener el sistema a construir. Este modelo se divide en
áreas que se analizan detalladamente. Se construye un diagrama de clases por cada área.

Roles y responsabilidades:
El equipo de trabajo está estructurado en jerarquías, siempre debe haber un jefe de proyecto, y
aunque es un proceso considerado ligero también incluye documentación (la mínima necesaria
para que algún nuevo integrante pueda entender el desarrollo de inmediato).

Cuando usarla:
Toda metodología debe ser adaptada al contexto del proyecto (recursos técnicos y humanos,
tiempo de desarrollo, tipo de sistema).
Exigiendo un esfuerzo considerable para ser adaptadas, sobre todo en proyectos pequeños y con
requisitos muy cambiantes.
Las metodologías ágiles ofrecen una solución casi adecuada para una gran cantidad de proyectos.

 Kanban.

Definición :

¿Qué es Kanban?

Un kanban es un dispositivo de señalización inventando y desarrollado por Toyota, que instruye la

creación o movimiento de partes en un sistema de producción por demanda, generalmente
mediante el uso de una tarjeta física. Antes de entrar en el uso de Kanban para el desarrollo de
software vamos a ver el uso original de Kanban en TPS (Toyota Production System).

El objetivo de Kanban es minimizar el TEP (Trabajo En Progreso), o stock, entre los procesos. Para
lograr esto Kanban se asegura que el proceso superior produzca partes sólo si el proceso inferior
las necesita. "Por demada" significa que los trabajadores del proceso inferior consumen las partes
que necesitan de los procesos superiores.

se puede dividir en dos partes:

 Kanban - Un visual gestión de procesos de sistema que le dice qué producir, cuándo
producirlo, y cuánto producir.

 El método Kanban - Una aproximación a, la mejora del proceso evolutivo gradual para las
organizaciones.

 Ventajas de usar sistemas Kanban

Ventajas en los procesos productivos:

  1.- Aumenta la flexibilidad de los procesos de producción y transporte.

 2.- Si se usa un sistema informatizado, permite conocer la situación de todos los ítems en
cada momento y dar instrucciones basadas en las condiciones actuales de cada área de
trabajo.

 3.- Prevenir el trabajo innecesario y prevenir el exceso de papeleo innecesario.

 Ventajas en las operaciones logísticas:

 1.- Mejor control del stock de material.

 2.- Posibilidad de priorizar la producción: el tipo de producto con más importancia o urgencia
se pone primero que los demás.

 3.- Se facilita el control de material.

Cómo implementar un sistema Kanban:

Esta herramienta se implementa mediante 4 fases:

 Fase 1: Diseñar el sistema Kanban que se usará posteriormente y formar al personal en los
principios de Kanban, y los beneficios de usarlo.

 Fase 2: Implementar Kanban en aquellas líneas de producción y actividades con más

actividad, donde se generan más problemas o donde sea más importante evitar fallos y
retrasos. El entrenamiento con el personal debe continuar en la línea de producción.

 Fase 3: Implementarlo en el resto de actividades. Se deben tomar en cuenta las opiniones de

los trabajadores ya que ellos son los que mejor conocen el sistema.

 Fase 4: En la última fase debe realizar la revisión del sistema Kanban, para mejorarlo en
base a la experiencia previa.
Scrum :
es un marco de trabajo para la gestión y desarrollo de software basada en un proceso iterativo e
incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software.

Aunque Scrum estaba enfocado a la gestión de procesos de desarrollo de software, puede ser
utilizado en equipos de mantenimiento de software, o en una aproximación de gestión de
programas: Scrum de Scrums.

Historia

En principio se definió como "una estrategia de desarrollo flexible y holística, donde un equipo de
desarrollo trabaja como una unidad para llegar a una misma meta" contrario a lo que dijo Ikujiro
Nonaka en 1986 en el libro "El nuevo nuevo juego de desarrollo de productos", donde decía: "un
enfoque secuencial y tradicional". Takeuchi y Nonaka difieren en "La compañía creadora de
conocimiento" que es una forma de "creación de conocimiento organizacional, [...] especialmente
bueno trayendo información de innovación continua, incremental y espiralmente.

Los autores describían un nuevo acercamiento al desarrollo comercial de productos que

aumentaría la velocidad y flexibilidad, basado en estudios de casos de empresas manufactureras
en la industrias automotoras, copiadoras e impresoras. Llamaron a esto el enfoque de rugby,
mientras todo el proceso se realiza por un equipo funcional a través de varias fases, donde el
equipo "trata de trabajar como una unidad, pasándose el trabajo unos a otros".

A principios de 1990, Ken Schwaber uso en su compañía lo que se volvería Scrum, los Métodos
Avanzados de Desarrollo, y Jeff Sutherland, junto a John Scumniotales y Jeff McKenna, desarrolló
un enfoque similar en la Corporación Easel, y fueron los primeros en referirse a este con una única
palabra, Scrum. En 1995, Sutherland y Schwaber presentaron juntos un trabajo describiendo la
metodología Scrum por primera vez en la Business Object Design and Implementation Workshop
que fue parte del Object-Oriented Programming, Systems, La guages & Applications '95 (OOPSLA
'95) en Austin, Texas. Schwaber y Sutherland colaboraron los siguientes años para combinar los
escritos anteriores, sus experiencias y las mejores prácticas de la industria en lo que hoy se
conoce como Scrum.

En 2001, Schwaber trabajó con Mike Beedle para describir el método en el libro "Desarrollo de
Software Ágil con Scrum. Su enfoque para planear y manejar proyectos es cambiar la autoridad de
la toma de decisiones al nivel de propiedades de operación.

pesar que la palabra no es un acrónimo, algunas compañías que implementan el proceso han
usado la palabra con letras mayúsculas como SCRUM. Esto puede ser por uno de los primeros
escritos de Ken Schwaber donde el título se escribió de esta forma.

Luego, Schwaber junto a otros fundó la Alianza Scrum y creó los programas Certified Scrum
Master y sus derivados. Ken dejó la Alianza Scrum en otoño de 2009, y fundó Scrum.org para
mejorar aún más la calidad y efectividad de Scrum
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 ScrumMaster, que mantiene los procesos y trabaja
de forma similar al director de proyecto, elProductOwner, que representa a
los stakeholders (interesados externos o internos), y el Team que incluye a los desarrolladores.mi

Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud es definida por el
equipo), 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. 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 Owneridentifica los elementos del Product Backlog que
quiere ver completados y los hace del conocimiento del equipo. Entonces, el equipo determina la
cantidad de ese trabajo que puede comprometerse a completar durante el siguiente
sprint.1 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 autoorganizados 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 llamadorequirements 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.

Las características más marcadas que se logran notar en Scrum serían: 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.

Roles en Scrum

Roles Principales

Product Owner:
El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum trabaje
de forma adecuada desde la perspectiva del negocio. El Product Owner escribehistorias 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 de desarrollo

El equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo de 3 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 Scrum" 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)

Se refiere a la gente que hace posible el proyecto y para quienes el proyecto producirá el
beneficio acordado que justifica su producción. Sólo participan directamente durante las
revisiones del sprint.
Administradores (Managers)
Es la gente que establece el ambiente para el desarrollo del producto.