Metodologia de Desarrollo de Software

PROPUESTA METODOLOGIA DE DESARROLLO DE SOFTWARE
Fecha elaboración: 21-Septiembre-2016

EQUIPO DESARROLLO DE
Fecha impresión: : 21-Septiembre-2016
SOFTWARE
Pagina - 1/ 31
Propuesta Metodología para el desarrollo de software

Versión 1.0
Fecha Versión Descripción Autores

21/09/2016 1.0  Generalidades y
caracterizaciones para la Carlos Alberto Loaiza Guerrero
metodología de desarrollo y César Augusto López García
mantenimiento de software.
Objetivos
 Estudiar y analizar la evolución que han tenido las metodologías de gestión de

proyectos clásica o predictiva frente a la metodología adaptativa o ágil, y de esta
manera comprender la necesidad de adaptarnos a la evolución de nuestro
entorno, donde la velocidad y la incertidumbre nos obligan a buscar mejores
prácticas en la gestión de nuestro trabajo para alcanzar una mayor productividad,
excelencia y calidad.
 Implantar una metodología para la gestión y desarrollo de software en el equipo

de Desarrollo Transfiriendo en la ciudad de Manizales, basada en procesos ágiles,
iterativos e incrementales donde se aplican de manera regular un conjunto de
mejores prácticas para trabajar en equipo obteniendo así una mayor eficiencia y
eficacia en cada uno de los proyectos.
SOFTWARE
Pagina - 1/ 31
TABLA DE CONTENIDO
FACTORES ASOCIADOS A LA AUSENCIA DE METODOLOGIA DE DESARROLLO ................................... 4
EVOLUCION DE LA GESTION DE PROYECTOS ...................................................................................... 4
DIFERENCIAS DE LA METODOLOGIA DE DESARROLLO RAPIDO FRENTE AL DESARROLLO CLASICO ... 6
PROPUESTA METODOLOGIA DE DESARROLLO AGIL IMPLEMENTADA Y ADAPTADA POR EQUIPO DE
DESARROLLO TRANSFIRIENDO ............................................................................................................ 9
EL MODELO SCRUM .......................................................................................................................... 10
El origen ............................................................................................................................. 10
Introducción al modelo ....................................................................................................... 10
Beneficios de Scrum ............................................................................................................ 10
Fundamentos de Scrum....................................................................................................... 11
Características generales de Scrum ...................................................................................... 11
ROLES SCRUM ..................................................................................................................... 12
Product Owner .......................................................................................................................... 12
ScrumMaster (o Facilitador) ...................................................................................................... 12
Equipo ....................................................................................................................................... 12
Usuarios..................................................................................................................................... 13
Stakeholders (Clientes, Proveedores, Inversores) .................................................................... 13
Managers................................................................................................................................... 13
FUNCIONAMIENTO SCRUM ................................................................................................. 13
Actividades ......................................................................................................................... 14
Lista de objetivos / requisitos priorizada (Product Backlog) .................................................. 15
Definición de completado ................................................................................................... 16
Descripción general de la planificación del Sprint ................................................................. 16
Pre-condiciones: ........................................................................................................................ 17
Entradas: ................................................................................................................................... 17
Resultados: ................................................................................................................................ 17
Formato de la reunión:.............................................................................................................. 18
Ejecución de la iteración (Sprint) ......................................................................................... 19
Recomendaciones ..................................................................................................................... 19
Monitorización del Sprint .................................................................................................... 20
SOFTWARE
Pagina - 1/ 31
Pre-condiciones ......................................................................................................................... 20
Entradas..................................................................................................................................... 20
Resultados ................................................................................................................................. 21
Formato de la reunión............................................................................................................... 21
Beneficios .................................................................................................................................. 21
Restricciones ............................................................................................................................. 22
Revisión del Sprint .............................................................................................................. 22
Objetivos ................................................................................................................................... 22
Pre-condiciones ......................................................................................................................... 23
Entradas..................................................................................................................................... 23
Formato de la reunión............................................................................................................... 23
Retrospectiva (Sprint Retrospective) ................................................................................... 23
Beneficios .................................................................................................................................. 24
Restricciones ............................................................................................................................. 24
Replanificación del proyecto ............................................................................................... 24
Beneficios .................................................................................................................................. 25
RESPONSABILIDADES .......................................................................................................... 25
Las responsabilidades del Cliente ............................................................................................. 25
Facilitador (Scrum Master) ........................................................................................................ 26
Equipo (Team) ........................................................................................................................... 27
DOCUMENTOS O ARTEFACTOS ............................................................................................ 29
Product backlog ......................................................................................................................... 29
Sprint backlog ............................................................................................................................ 29
Burn down ................................................................................................................................. 29
SOFTWARE
Pagina - 1/ 31
FACTORES ASOCIADOS A LA AUSENCIA DE METODOLOGIA DE DESARROLLO
Cuando no se cuenta con una metodología para la gestión y desarrollo de software, es

difícil gestionar y medir los proyectos en cualquier línea del tiempo.
Algunos de los problemas que se evidencian por la carencia de una metodología de

trabajo son las siguientes:
 No existe una forma clara de ver el estado y controlar lo que está sucediendo en la
evolución de un proyecto.
 Los cambios organizativos afectan negativamente el proceso de desarrollo
 Deficiencias en la asignación y control de tareas sobre los miembros del equipo.
 Sobre carga de actividades.
 No hay una eficiencia y eficacia optima en los proyectos.
 No hay una documentación clara ni relevante al proyecto.
 Se tiende a caer en reuniones poco efectivas.
EVOLUCION DE LA GESTION DE PROYECTOS
La gestión de proyectos nació para ofrecer previsibilidad en la construcción de grandes

sistemas, con garantías de que el producto final se obtendrá en el tiempo y con el costo
previamente estimado.
La gestión de proyectos desarrollada a finales del siglo pasado se basa en la planificación

del trabajo, y en el posterior seguimiento y control de la ejecución. La planificación se
realiza sobre un análisis detallado del trabajo que se quiere efectuar y su descomposición
en tareas.
Sobre esa información se desarrolla un plan apropiado a los recursos y tiempos

disponibles, y durante la construcción se sigue de cerca la ejecución para detectar posibles
desviaciones, y en su caso, tomar medidas que las enmienden, o adaptar el plan inicial. Es
una gestión “predictiva”, que pronostica, gracias al conocimiento detallado de lo que se va
a hacer, y al plan del proyecto, las fechas, costos y recursos necesarios; así como la
secuencia y coordinación de las operaciones.
Su principal objetivo es conseguir que el desarrollo resulte según lo “previsto”; y basa el

éxito del proyecto en los tres puntos señalados: agendas, costos y calidad. (PMI, 2005):
Dos variables que modificaron el escenario del desarrollo de nuevos productos, a finales
del siglo pasado fueron: Velocidad e Incertidumbre.
SOFTWARE
Pagina - 1/ 31
Por estas razones en un escenario rápido e inestable, encajan mal las estrategias de
negocio predictivas, que diseñan un proyecto y trazan un plan de negocio.
En los entornos que evolucionan con rapidez las empresas que invierten trabajo y análisis
para trazar estrategias y planes, deben cambiarlos constantemente para poder sobrevivir.
En los entornos rápidos los productos y estrategias que alcanzan el éxito no son los que se
desarrollan sobre planes pre-concebidos, sino los que crecen en adaptación y
replanteamiento constante guiados por la evolución del propio entorno.
Las variables claves para triunfar en el nuevo escenario son:

 Tomar retro-información del producto y del entorno de forma continua.
 Dar el mayor valor innovador al producto.
 En el menor tiempo posible.
 Para salir lo antes posible al mercado
 No hay producto “terminado” el producto está en continua evolución
En modelo predictivo el objetivo es lograr lo planificado: en un modelo de negocio

predictivo el objetivo es producir el producto diseñado, con los costos y las ventas
previstas en el plan de negocio. En un modelo adaptativo el objetivo es dar al producto el
mayor valor posible de forma constante.
Como el escenario es muy rápido es inestable no es realista pensar que se podrá

mantener el plan de negocio trazado al empezar. Es más realista pensar que se podrá
mantener el producto con el mayor valor posible. El plan de negocio pasa a ser plan de
valor. El objetivo es el valor, y el negocio la consecuencia lógica si se dispone de un
producto que mantiene su valor de forma continua.
El modelo adaptativo no pide por tanto la predictibilidad de que el plan inicial se ejecute
en las fechas y con los costos previstos, sino poder disponer en el menor tiempo posible
de valor para el cliente, y mantener el producto o servicio en evolución continua para
incrementarlo, o al menos mantenerlo.
El ciclo de desarrollo clásico, en el caso del software, es el denominado secuencial o en

cascada, que comienza con la fase de requisitos, que una vez cerrados, da paso al diseño,
posteriormente la codificación, las pruebas y la integración.
Los desarrollos secuenciales puros suelen ser más teóricos que prácticos y en realidad
quienes los adoptan generalmente producen ciclos “secuenciales con solapamiento”, en
los que cada fase puede comenzar con el material aún no terminado por completo en la
fase anterior. Así no es raro que partes de diseño de la arquitectura, por ejemplo, se
comiencen cuando los requisitos aún no se han cerrado por completo; de igual forma, con
SOFTWARE
Pagina - 1/ 31
partes de análisis aún pendientes de concretar, el equipo de codificación puede disponer

ya de partes de diseño que permiten comenzar la codificación, etc.
Pero en el nuevo modelo de desarrollo no se trata de un cierto solapamiento entre fases,

sino de un solapamiento tan amplio que durante la práctica total del desarrollo concurren
todas las actividades.
De esta forma, más que fases que se realizan de forma secuencial, pasan a ser
actividades que se ejecutan en el momento que se requieren. Requisitos, análisis,
codificación, pruebas, integración se van realizando en cada momento según las
necesidades en la evolución del proyecto.
DIFERENCIAS DE LA METODOLOGIA DE DESARROLLO RAPIDO FRENTE AL DESARROLLO

CLASICO
En el modelo de desarrollo ágil, el proyecto no lo desarrollan equipos diferentes con

especialistas en distintas áreas. Hay un sólo equipo, formado por personas muy
competentes, con perfiles y conocimientos que cubren las disciplinas necesarias para
construir el producto.
No hay fases. Éstas pasan a ser tareas que se ejecutan cuando se necesitan. No se hace
primero el diseño del concepto o los requisitos, más tarde el análisis, luego el desarrollo,
etc.
SOFTWARE
Pagina - 1/ 31
Lo que en el software serían las fases de requisitos del sistema, requisitos del software,
análisis, diseño, construcción, pruebas e integración, y se ejecutarían de forma secuencial,
pasan a ser tareas que se llevan a cabo cada vez que hacen falta. Normalmente a lo largo
de pequeñas iteraciones durante todo el desarrollo.
Otras veces el mercado es tan rápido, que a mitad de trabajo las tendencias o la
competencia obligarán a modificar el producto.
La participación de todo el equipo en el diseño aporta mucho más talento innovador y

diferencial; un valor clave en el mercado de productos y servicios TIC.
Características de las metodologías de desarrollo rápido:
1. La incertidumbre como elemento consustancial y asumido en el entorno y en la

cultura de la organización.
2. Equipos de desarrollo auto-organizados.
3. Fases de desarrollo solapadas
4. Control sutil
5. Difusión y transferencia del conocimiento
1.- Incertidumbre
2.- Auto-organización.
Son equipos auto-organizados. No hay roles de gestión que marquen pautas o asignación
de tareas.
No se trata de equipos auto-dirigidos, sino auto-organizados. La gestión marca la

dirección, pero no la organización. Parten de cero. Deben empezar por crear su propia
organización y buscar el conocimiento que necesitan.
Para que los equipos puedan conseguir auto-organizarse deben reunir tres características:
 Autonomía: son libres para elegir la estrategia de solución.
 Auto-superación. El equipo va desarrollando soluciones que evalúa analiza y

mejora.
 Auto-enriquecimiento: La multi-disciplinaridad de los componentes del equipo

favorece el enriquecimiento mutuo y la adopción de soluciones valiosas y
complementarias.
SOFTWARE
Pagina - 1/ 31
3.- Fases de desarrollo solapadas.
En el desarrollo ágil las “fases” pasan a ser “actividades”. El concepto de fase implica
sucesión secuencial de unas a otras. En las metodologías de desarrollo ágil los trabajos
que se llevan a cabo pierden el carácter de fase y son actividades que se realizan en
cualquier momento, de forma simultánea, o a demanda según las necesidades en cada
iteración.
4.- Control sutil
El equipo trabaja con autonomía en un entorno de ambigüedad, inestabilidad y tensión. La

gestión establece puntos de control suficientes para evitar que el ambiente de
ambigüedad, inestabilidad y tensión del equipo derive hacia descontrol. Pero la gestión no
ejerce un control rígido que impediría la creatividad y la espontaneidad. El término
“control sutil” se refiere a generar el ecosistema adecuado para un “auto-control entre
iguales,” consecuencia de la responsabilidad y del gusto por el trabajo que se realiza.
5.- Difusión del conocimiento
Tanto a nivel de proyecto como de organización. Los equipos son multidisciplinares; todos
los miembros aportan y aprenden tanto del resto del equipo como de las investigaciones,
innovaciones de su producto y de la experiencia del desarrollo. Las personas que
participan en un proyecto, con el tiempo van cambiando de equipo en la organización, a
otros proyectos; de esta forma se van compartiendo y comunicando las experiencias en la
organización.
Los equipos y las empresas mantienen libre acceso a la información, herramientas y

políticas de gestión del conocimiento.
Las circunstancias de los mercados y de las empresas no se pueden cambiar, y es la

gestión de proyectos la que debe adaptarse y responder a las nuevas necesidades.
Ahora es necesario desarrollar y construir el producto a la par de la investigación y del
descubrimiento de los requisitos, y hacerlo con la capacidad de adaptarse a los cambios
dictados por el entorno.
Quizá ya no hay “productos finales”, sino productos en evolución, revisión mejora o

incremento continuo a partir de la versión beta.
Por la dinámica del entorno, los cambios y la innovación, los desarrollos de software en
nuestros días tienen una vida útil corta, por lo cual, se hace necesario tener una evolución
continua sobre estos.
SOFTWARE
Pagina - 1/ 31
La forma de gestión puede y debe adaptarse a las circunstancias del proyecto: Puede
documentar la visión del producto como “historias de usuario” con post-it’s en una pared,
como lista de desarrollo en un fichero Excel, etc. Puede construir incrementos de
producto en iteraciones de dos o de seis semanas, etc., Puede admitir cambios a mitad de
un incremento (como Extreme Programming) o no (como Scrum).
De estos argumentos surge el interrogante. Qué modelo de gestión usar, ¿predictiva o

ágil?
Hay dos formas de gestionar proyectos: una predictiva o clásica y otra adaptativa o ágil.
La gestión predictiva parte de un plan detallado. Sabe exactamente qué es lo que va a
hacer y conoce fechas y costos. Durante el desarrollo gestiona riesgos, evalúa el impacto
que cada modificación supone sobre el plan inicial, toma decisiones frente a los
imprevistos para seguir su cumplimiento; y si no queda más remedio, para replantearlo. La
gestión adaptable parte desde una visión general del objetivo y va dando pequeños pasos
hacia él a través de un ciclo de construcción incremental, y de forma evolutiva contrasta y
va descubriendo el detalle que resulta más adecuado para el producto con los usuarios y
demás participantes, que pueden "tocar" o usar las partes construidas.
PROPUESTA METODOLOGIA DE DESARROLLO AGIL IMPLEMENTADA Y ADAPTADA POR

EQUIPO DE DESARROLLO TRANSFIRIENDO
Con base en los argumentos mencionados en los puntos anteriores, es oportuno

adaptarnos a un enfoque moderno basado en metodologías ágiles, lo cual nos permite
evitar los tortuosos y burocráticos caminos de las metodologías tradicionales.
El propósito, es que el mismo grupo de ingenieros, sea el encargado de adoptar la

metodología que más se adapte al grupo, se propone tomar como base la metodología
SCRUM (Metodología usada por grandes empresas en el mundo como Google, Yahoo,
Microsoft, HP, Novell, SAP, Nokia, Xerox, etc), la cual se detallará más adelante en este
documento y sobre este punto de partida crearemos híbridos con otras metodologías
como XP, RUP,ASD, y lo que el grupo considere pertinente adaptar de experiencias propias
y prototipos tradicionales.
Será un proceso de crecimiento colectivo, autocritico, auto-organizado y motivado por el

equipo, donde el aporte de cada miembro del equipo será de vital importancia para el
éxito de este proyecto.
SOFTWARE
Pagina - 1/ 31
EL MODELO SCRUM
El origen
Scrum es una metodología ágil para gestionar proyectos de software, que toma su nombre
y principios de los estudios realizados sobre nuevas prácticas de producción por Hirotaka
Takeuchi e Ikujijo Nonaka a mediados de los 80 (Ikujiro & Takeuchi, 1986). Aunque surgió
como práctica en el desarrollo de productos tecnológicos, resulta válido en los entornos
que trabajan con requisitos inestables, y necesitan rapidez y flexibilidad; situaciones
habituales en el desarrollo de algunos sistemas de software.
Introducción al modelo
Scrum es una metodología para la gestión y desarrollo de software basada en un proceso
iterativo e incremental donde se aplican de manera regular un conjunto de mejores
prácticas para trabajar en equipo y obtener el mejor resultado posible de un proyecto.
Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la
manera de trabajar de equipos altamente productivos. Scrum es utilizado comúnmente en
entornos basados en el desarrollo ágil de software.
En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el
beneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente
recomendada para proyectos en entornos complejos, donde se necesita obtener
resultados pronto, donde los requisitos son cambiantes o poco definidos, donde la
innovación, la competitividad, la flexibilidad y la productividad son fundamentales.
Beneficios de Scrum
Los principales beneficios que proporciona Scrum son:
 Entrega mensual (o quincenal) de resultados (los requisitos más prioritarios en ese

momento, ya completados) lo cual proporciona las siguientes ventajas:
 Gestión regular de las expectativas del cliente y basada en resultados tangibles.
 Resultados anticipados (time to market).
 Flexibilidad y adaptación respecto a las necesidades del cliente, cambios en el
mercado, etc.
 Gestión sistemática del Retorno de Inversión (ROI).
 Mitigación sistemática de los riesgos del proyecto.
 Productividad y calidad.
 Alineamiento entre el cliente y el equipo de desarrollo.
 Equipo motivado.
SOFTWARE
Pagina - 1/ 31
Fundamentos de Scrum
Scrum se basa en:
 El desarrollo incremental de los requisitos del proyecto en bloques temporales

cortos y fijos (iteraciones de un mes natural y hasta de dos semanas, si así se
necesita).
 La priorización de los requisitos por valor para el cliente y costo de desarrollo en
cada iteración.
 El control empírico del proyecto. Por un lado, al final de cada iteración se
demuestra al cliente el resultado real obtenido, de manera que pueda tomar las
decisiones necesarias en función de lo que observa y del contexto del proyecto en
ese momento. Por otro lado, el equipo se sincroniza diariamente y realiza las
adaptaciones necesarias.
 La potenciación del equipo, que se compromete a entregar unos requisitos y para
ello se le otorga la autoridad necesaria para organizar su trabajo.
 La sistematización de la colaboración y la comunicación tanto entre el equipo y
como con el cliente.
 El timeboxing de las actividades del proyecto, para ayudar a la toma de decisiones
y conseguir resultados.
Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la

manera de trabajar de equipos altamente productivos.
Características generales de Scrum
Los roles principales en Scrum son el ScrumMaster, que mantiene los procesos y trabaja
de forma similar al director de proyecto, el ProductOwner, que representa a los
stakeholders (clientes externos o internos), y el Team que incluye a los desarrolladores.
Durante cada sprint, un periodo entre 15 y 30 días (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 Owner identifica 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. Durante el sprint, nadie puede
SOFTWARE
Pagina - 1/ 31
cambiar el Sprint Backlog, lo que significa que los requisitos están congelados durante el
sprint. (Este punto hay que definirlo, o manejarlo como XP con más flexibilidad)
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.
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 SCRUM
Product Owner
El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum
trabaja de forma adecuada desde la perspectiva del negocio. El Product Owner
escribe 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
El equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo de
5 a 9 personas con las habilidades transversales necesarias para realizar el trabajo
(diseñador, desarrollador, etc).
SOFTWARE
Pagina - 1/ 31
Usuarios
Es el destinatario final del producto. Como bien lo dice la paradoja, El árbol cae en
el bosque cuando no hay nadie ¿Hace ruido? Aquí la definición sería Si el software
no es usado ¿fue alguna vez escrito?.
Stakeholders (Clientes, Proveedores, Inversores)

Se refiere a la gente que hace posible el proyecto y para quienes el proyecto
producirán el beneficio acordado que lo justifica. Sólo participan directamente
durante las revisiones del sprint.
Managers
Es la gente que establece el ambiente para el desarrollo del producto.
FUNCIONAMIENTO SCRUM
SOFTWARE
Pagina - 1/ 31
El proceso parte de la lista de objetivos/requisitos priorizada del producto, que actúa

como plan del proyecto. En esta lista el cliente prioriza los objetivos balanceando el valor
que le aportan respecto a su costo y quedan repartidos en iteraciones y entregas. De
manera regular el cliente puede maximizar la utilidad de lo que se desarrolla y el retorno
de inversión mediante la re planificación de objetivos que realiza al inicio de cada
iteración.
Actividades
 lista de objetivos /requisitos priorizada (Product backlog)

o Definición de completado
 Planificación de la iteración (Sprint Planning)

 Ejecución de la iteración (Sprint)
o Monitorización del Sprint
o Revisión del Sprint
 Reunión diaria de sincronización del equipo (Scrum Daily Meeting)

 Demostración de los requisitos completados (Sprint Demostration)
 Retrospectiva (Sprint Retrospective)
 Replanificación del proyecto
SOFTWARE
Pagina - 1/ 31
Lista de objetivos / requisitos priorizada (Product Backlog)
La lista de objetivos/requisitos priorizada representa la visión y expectativas del cliente

respecto a los objetivos y entregas del producto o proyecto. El cliente es el responsable de
crear y gestionar la lista (con la ayuda del Facilitador y del equipo, quien proporciona el
costo estimado de completar cada requisito). Dado que refleja las expectativas del cliente,
esta lista permite involucrarle en la dirección de los resultados del producto o proyecto.
 Contiene los objetivos/requisitos de alto nivel del producto o proyecto, que se

suelen expresar en forma de historias de usuario. Para cada objetivo/requisito se
indica el valor que aporta al cliente y el costo estimado de completarlo. La lista
está priorizada balanceando el valor que cada requisito aporta al negocio frente al
costo estimado que tiene su desarrollo, es decir, basándose en el Retorno de la
Inversión (ROI).
 En la lista se indican las posibles iteraciones y las entregas (releases) esperadas por
el cliente (los puntos en los cuales desea que se le entreguen los
objetivos/requisitos completados hasta ese momento), en función de la velocidad
de desarrollo del (los) equipo(s) que trabajará(n) en el proyecto. Es conveniente
que el contenido de cada iteración tenga una coherencia, de manera que se
reduzca el esfuerzo de completar todos sus objetivos.
 La lista también tiene que considerar los riesgos del proyecto e incluir los
requisitos o tareas necesarios para mitigarlos.
Antes de iniciar la primera iteración, el cliente debe tener definida la meta del producto o
proyecto y la lista de requisitos creada. No es necesario que la lista sea completa ni que
todos los requisitos estén detallados al mismo nivel. Basta con que estén identificados y
con suficiente detalle los requisitos más prioritarios con los que el equipo empezará a
trabajar. Los requisitos de iteraciones futuras pueden ser mucho más amplios y generales.
La incertidumbre y complejidad propia de un proyecto hacen conveniente no
detallar todos los requisitos hasta que su desarrollo esté próximo. De esta manera, el
esfuerzo de recoger, detallar y desarrollar el resto de requisitos (menos prioritarios) está
repartido en el período de ejecución del proyecto. En el caso del desarrollo de un
producto, la lista va evolucionando durante toda la vida del producto (los requisitos
"emergen"). En el caso de un proyecto, conforme éste avance irán apareciendo los
requisitos menos prioritarios que falten. Esto produce varias ventajas:
 Se evita caer en parálisis de análisis al inicio del proyecto, de manera que se

puede iniciar antes el desarrollo y el cliente puede empezar a obtener resultados
útiles.
 Se evita analizar en detalle requisitos no prioritarios que podrían cambiar durante
el transcurso del proyecto, dado que el cliente conocerá mejor cuál ha de ser el
resultado a conseguir, o bien por que podrían ser reemplazados por otros.
SOFTWARE
Pagina - 1/ 31
 Puede llegar a un punto del proyecto en que no valga la pena analizar ni

desarrollar los requisitos restantes, dado el poco retorno de inversión (ROI) que
tienen.
Definición de completado
El cliente y el equipo tienen que acordar la "definición de completado” de los objetivos /

requisitos en el proyecto:
 Debe asegurar que el incremento de producto es potencialmente entregable al

cliente al finalizar cada iteración, que no hay tareas pendientes que puedan
impedir utilizar los resultados del proyecto lo antes posible. De este modo, el
cliente podrá tomar decisiones correctas cuando al final de cada iteración el
equipo le haga una demostración de los requisitos completados: cambiar las
prioridades en función de la velocidad de desarrollo, solicitar una entrega del
producto desarrollado hasta ese momento, etc.
 Debe incluir lo necesario para considerar de manera clara que el cliente obtendrá
lo que necesita según sus criterios de entregables y de calidad (producto
construido, probado, documentado, refactorizado para conseguir calidad
interna/mantenibilidad, etc.).
o Además de esta definición de completado, a cada objetivo hay que
asociarle sus condiciones de satisfacción, preferiblemente en forma de
casos de prueba de aceptación, en el momento de crear la lista de
requisitos priorizada (Product Backlog).
o Notar que la definición de completado también sirve como base para
identificar las tareas necesarias para conseguir cada objetivo/requisito, en
la reunión de planificación de la iteración (Sprint planning). Para cada
objetivo se crearán más tareas que la definición de completado (o menos) y
con más significado. Por ejemplo, respecto a que el objetivo tiene que estar
“construido”, pueden aparecer varias tareas, del estilo “construir el
componente X”, “modificar la pantalla Y”, “modificar la BBDD”, “preparar el
script de carga”, etc.
Descripción general de la planificación del Sprint
La planificación de Sprint es una reunión crítica, probablemente la más importante de

Scrum. Una planificación de Sprint mal ejecutada puede arruinar por completo todo el
Sprint. Por esto es necesaria la participación y el aporte de todo el equipo.
Una planificación de Sprint produce, concretamente:

SOFTWARE
Pagina - 1/ 31
• Una meta de Sprint.

• Una lista de miembros (y su nivel de dedicación, si no es del 100%)
• Una Pila de Sprint (lista de historias incluidas en el Sprint)
• Una fecha concreta para la Demo del Sprint.
• Un lugar y momento definidos para el Scrum Diario.
En esta reunión, tomando como base las prioridades y necesidades de negocio del cliente,
se determinan cuáles y cómo van a ser las funcionalidades que se van a incorporar al
producto con el próximo sprint. En realidad esta reunión consiste en dos: En la primera,
que puede tener una duración de una a cuatro horas, se decide qué elementos del
product backlog se van a desarrollar.
En la segunda se desglosan éstos para determinar las tareas necesarias, estimar el

esfuerzo que necesita cada una y la distribución de estas por el mismo equipo. La
planificación del sprint no debe durar más de un día. Las características de la reunión son:
Pre-condiciones:
 La organización tiene determinados los recursos posibles para llevar a cabo el

sprint.
 El propietario del producto tiene preparado el backlog del producto: con su criterio
de prioridad para el negocio, y un número suficiente de elementos para desarrollar
en el sprint.
 Siempre que sea posible el propietario del producto debe haber trabajado ya
previamente con el equipo. De esta forma su estimación previa de qué cantidad de
pila de producto se puede desarrollar en el sprint será bastante ajustada.
 El equipo tiene un conocimiento de las tecnologías empleadas, y del negocio del
producto suficiente para realizar estimaciones basadas en "juicio de expertos”, y
para comprender los conceptos del negocio que expone el propietario del
producto.
Entradas:
 El backlog del producto
 El producto desarrollado hasta la fecha a través de los sucesivos incrementos
(excepto si se trata del primer sprint)
 Circunstancias de las condiciones de negocio del cliente y del escenario tecnológico
empleado.
Resultados:
 Backlog del sprint.

SOFTWARE
Pagina - 1/ 31
 Duración del sprint y fecha de la reunión de revisión.

 Objetivo del sprint.
Es una reunión conducida por el responsable del funcionamiento de Scrum a la que deben
asistir el propietario del producto y el equipo completo, y a la que también pueden asistir
otros implicados en el proyecto.
La reunión comienza con la presentación del propietario del producto del backlog, en la
que expone los resultados que por orden de prioridad necesita; especialmente los que
prevé que se podrán desarrollar en el siguiente sprint.
Si el product backlog ha tenido cambios significativos desde la anterior reunión; explica
también las causas que los han ocasionado. El objetivo es que todo el equipo conozca las
razones y los detalles con el nivel necesario para poder estimar el trabajo necesario
Formato de la reunión:
Esta reunión marca el inicio de cada sprint. Una persona con la responsabilidad de
procesos en la organización (Scrum Manager) es el responsable de su organización y
gestión. Duración máxima: un día.
Deben asistir: el propietario del producto, el equipo y el Scrum Manager
Pueden asistir: es una reunión abierta a todos los que puedan aportar información útil.
Consta de dos partes separadas por una pausa de café o comida, según la duración.
Primera parte:
Duración de 1 a 4 horas. Propietario del producto: Presenta las funcionalidades del
backlog del producto que tienen mayor prioridad y que estima se pueden realizar en el
sprint. La presentación se hace con un nivel de detalle suficiente para transmitir al equipo
toda la información necesaria para realizar el trabajo.
El equipo Realiza las preguntas y solicita las aclaraciones necesarias. Propone sugerencias,
modificaciones y soluciones alternativas.
Las aportaciones del equipo pueden suponer modificaciones en el backlog. De hecho no es
que “puedan” es que “deben” suponerlas. Esta reunión es un punto caliente del protocolo
de Scrum para favorecer la fertilización cruzada de ideas en equipo y añadir valor a la
visión del producto. Tras reordenar y replantear las funcionalidades de la pila del
producto, el equipo define el “objetivo del sprint” o fase que define de forma sintética
cuál es el valor que se le aportará al producto.
Segunda parte:
En la segunda parte, que puede alargarse hasta el final de la jornada:
El equipo desglosa cada funcionalidad en tareas, y estima el tiempo para cada una de
ellas, determinando de esta forma los elementos del sprint backlog. En este desglose el
equipo tiene en cuenta los elementos de diseño y arquitectura que deberá incorporar el
sistema. Los miembros del equipo se auto-asignan las diferentes tareas teniendo como
criterios sus conocimientos, intereses y distribución homogénea del trabajo.
SOFTWARE
Pagina - 1/ 31
Esta segunda parte debe considerarse como una “reunión del equipo”, en la que deben
estar todos sus miembros y ser ellos quienes descomponen el trabajo en tareas, las
asignan y estiman. El papel del propietario del producto en esta parte es atender a dudas
y comprobar que el equipo comprende y comparte su objetivo. El Scrum Manager actúa
de conductor o moderador de la reunión
Ejecución de la iteración (Sprint)
En Scrum un proyecto se ejecuta en bloques temporales cortas y fijas (iteraciones de un

mes y hasta de dos semanas, o definido por el equipo, se recomienda máximo un mes).
Cada iteración tiene que proporcionar un resultado completo, un incremento de producto
que sea susceptible de ser entregado con el mínimo esfuerzo cuando el cliente (Product
Owner) lo solicite.
 Cada día el equipo realiza una reunión de sincronización, donde cada miembro
inspecciona el trabajo de los otros para poder hacer las adaptaciones necesarias,
comunica cuales son los impedimentos con que se encuentra, actualiza el estado
de la lista de tareas de la iteración (Sprint Backlog) y los gráficos de trabajo
pendiente (Burndown charts).
 El Facilitador (Scrum Master) se encarga de que el equipo pueda cumplir con su
compromiso y de que no se merme su productividad.
o Elimina los obstáculos que el equipo no puede resolver por sí mismo.
o Protege al equipo de interrupciones externas que puedan afectar su
compromiso o su productividad.
Recomendaciones
 Para poder completar el máximo de requisitos en la iteración, se debe minimizar el

número de objetivos/requisitos en que el equipo trabaja simultáneamente (WIP,
Work In Progress), completando primero los que den más valor al cliente.
Esta forma de trabajar, que se ve facilitada por la propia estructura de la lista de
tareas de la iteración, permite tener más capacidad de reacción frente a cambios o
situaciones inesperadas.
Reunión informal donde el equipo presenta al cliente los requisitos completados en la

iteración, en forma de incremento de producto preparado para ser entregado con el
mínimo esfuerzo, haciendo un recorrido por ellos lo más real y cercano posible al objetivo
que se pretende cubrir.
En función de los resultados mostrados y de los cambios que haya habido en el contexto
del proyecto, el cliente realiza las adaptaciones necesarias de manera objetiva, ya desde la
primera iteración, replanificando el proyecto. Se realiza en un timebox de cómo máximo 4
horas.
SOFTWARE
Pagina - 1/ 31
Beneficios
 El cliente puede ver de manera objetiva cómo han sido desarrollados los requisitos
que proporcionó, ver si se cumplen sus expectativas, entender más qué es lo que
necesita y tomar mejores decisiones respecto al proyecto.
 El equipo puede ver si realmente entendió cuáles eran los requisitos que solicitó el
cliente y ver en qué puntos hay que mejorar la comunicación entre ambos.
 El equipo se siente más satisfecho cuando puede ir mostrando los resultados que
va obteniendo. No está meses trabajando sin poder exhibir su obra.
Monitorización del Sprint

Reunión diaria breve, de no más de 15 minutos en la que todos los miembros del equipo
dicen las tareas en las que están trabajando, si se han encontrado o prevén encontrarse
con algún impedimento y actualizan sobre el sprint backlog las tareas ya terminadas o los
tiempos de trabajo que les quedan, y manifiestan las tareas que van a realizar durante el
día.
Pre-condiciones
 La reunión comienza puntualmente a su hora. A menudo hay castigos -acordados

por el equipo- para quien llegue tarde (por ejemplo: dinero, flexiones, llevar
colgando una gallina de plástico del cuello, etc).
 Disponibilidad de un lugar físico en la organización para realizar diariamente la

reunión.
 Sprint backlog actualizado en el soporte que emplee el equipo (dibujado en
pizarra, con post-it’s, sobre hoja de cálculo…)
 Asiste todo el equipo.
 Asiste un responsable con rol de Scrum Manager de la organización.
 Un miembro del equipo (team leader) conduce y garantiza el protocolo, formato y
tiempos de la reunión (Es conveniente rotar el team leader entre los miembros del
equipo, para incentivar la motivación y el compromiso de cada uno sobre la
metodología).
Entradas
Sprint Backlog y gráfico Burn-down (gráfico de avance) actualizados con la información de

la reunión anterior. Información de las tareas realizadas por cada componente del equipo
SOFTWARE
Pagina - 1/ 31
Resultados
Backlog y gráfico de avance (Burn-down) actualizados. Identificación de necesidades e
impedimentos.
Formato de la reunión
Se recomienda realizarla de pie y emplear un formato de backlog o lista de tareas en una
pizarra ,pared o aplicativo, para que todo el equipo pueda verlo, anotar o mover las
tareas, junto con el gráfico de avance del sprint.
En la reunión está presente todo el equipo, y pueden asistir también otras personas
relacionadas con el proyecto o la organización, pero éstas últimas no pueden intervenir.
Uno por uno, los miembros del equipo exponen estas cuestiones:
1.- Tarea en la que trabajaron ayer.
2.- Impedimentos encontrados.
3.- Tarea o tareas en las que trabajarán hoy.
4.- Si van a necesitar alguna cosa especial o prevén algún impedimento para realizar su
trabajo.
Y actualizan sobre el sprint backlog el tiempo de trabajo que queda pendiente a las tareas
en las que están trabajando, o marcan las que hayan podido completar. Al final de la
reunión:
 Con las estimaciones de tiempos actualizadas por el equipo, el team leader
actualiza el gráfico de avance del sprint. (En herramientas como Jira es automático)
 El responsable de la gestión de procesos de la organización (Scrum Manager)
comienza a gestionar las posibles necesidades e impedimentos identificados.
Beneficios
 Aumentar la productividad en el proyecto y potencia el compromiso de equipo,

dado que cada miembro pone de manifiesto delante del resto:
o Las tareas que pueden afectar a otros miembros del equipo, por que
impactan en su trabajo o porque hay dependencias (especialmente si existe
un retraso).
o Los impedimentos con que se encuentra. El resto de miembros del equipo
pueden ofrecer ayuda a otros en la realización de tareas o para resolver
problemas que ya tuvieron anteriormente. El Facilitador (Scrum Master) se
encargará de solucionar los impedimentos que el equipo no puede
solucionar por sí solo o que le quitan tiempo para cumplir con su
compromiso fundamental de desarrollo de requisitos.
o Cada miembro entiende las necesidades de los otros miembros del equipo
respecto a su trabajo, de manera que pueden colaborar y adaptar sus
trabajos para que den el máximo valor y no realizar tareas que no
proporcionan ningún beneficio al resto del equipo.
SOFTWARE
Pagina - 1/ 31
o Se hace visible si de manera continua un miembro del equipo está

realizando tareas por debajo del rendimiento esperado. Se evita que una
persona señale con el dedo a otra, dado que la reunión de sincronización
pone a todos los miembros del equipo en la misma situación de tener que
explicar en qué tareas están trabajando.
o Cuáles son los criterios que está utilizando para realizar sus tareas, de
manera que estén alineados con los objetivos comunes del equipo.
o Fomentar el aprendizaje de los miembros del equipo, ya que pueden ver
cómo trabajan los otros según sus especialidades y experiencias.
o Conocer el estado de la iteración, ver si es posible completar los requisitos
a que se comprometió el equipo, en vista de las desviaciones y de las tareas
pendientes.
Restricciones
 La reunión diaria de estado y sincronización del equipo no es para resolver

problemas, los problemas se resuelven después de la reunión.
o No a todos los miembros del equipo les interesan todos los detalles de cada
tema.
o En la reunión los miembros del equipo programan reuniones entre ellos
donde colaborar sincronizando tareas, ayudando a resolver problemas, etc.
o No puede haber una persona explicando su estado mientras otras "se han
apartado" de la reunión para comentar un tema particular. Si apareciese
alguna conversación de interés común (que debe ser rápida), debe poder
ser escuchada por todo el equipo sin distraer el principal objetivo de que
todos conozcan en qué están trabajando los demás. Si la mini conversación
no es del interés de todos, debe hacerse después de la reunión.
o El equipo debe contar con unos criterios consensuados sobre el proceso de
ejecución de las de tareas
Revisión del Sprint
Reunión realizada al final del sprint en la que, con una duración máxima de 4 horas el
equipo presenta al propietario del producto, clientes, usuarios, gestores… el incremento
construido en el sprint y se genera retro-información entre todos los participantes para
preparar el product backlog para el inicio del siguiente sprint.
Objetivos:
 El propietario del producto obtiene una revisión del progreso del sistema. Esta
reunión le ofrece a intervalos regulares el ritmo de construcción del sistema y la
trayectoria que va tomando la visión del producto.
SOFTWARE
Pagina - 1/ 31
 Al ver el incremento funcionando, el propietario del producto, y el equipo en

general obtienen feedback clave para evolucionar y dar valor al product backlog.
 Otros ingenieros, programadores y directivos de la empresa también pueden
asistir para ver cómo trabaja la metodología empleada.
 El responsable de procesos o calidad de la metodología (Scrum manager) obtiene
feedback sobre buenas prácticas y problemas durante el sprint, necesaria para las
prácticas que se empleen de ingeniería de procesos y mejora continua.
Pre-condiciones
 Se ha concluido el sprint.
 Asiste todo el equipo de desarrollo, el propietario del producto, el responsable de
procesos de la empresa y todas las personas implicadas en el proyecto que lo
deseen.
Entradas
 Incremento terminado.
 Resultados
 Feedback para el propietario del producto: hito de seguimiento de la construcción
del sistema, e información para mejorar el valor de la visión del producto.
 Feedback para el responsable de procesos (Scrum Manager) y miembros del
equipo (team): buenas prácticas y problemas durante el sprint.
 Convocatoria de la reunión del siguiente sprint.
Formato de la reunión
Es una reunión informal. El objetivo es ver el incremento, trabajar en el entorno del
cliente. Lo que se muestra es el resultado final: terminado, probado y operando en el
entorno del cliente (incremento).
Según las características del proyecto puede incluir también documentación de usuario, o
técnica. Es una reunión informativa. NO TIENE UNA MISIÓN ORIENTADA A TOMAR
DECISIONES, NI A CRITICAR EL INCREMENTO. Con la información generada en la
preparación del siguiente sprint se expondrán y tratarán las posibles modificaciones sobre
la visión del producto.
Retrospectiva (Sprint Retrospective)
Con el objetivo de mejorar de manera continua su productividad, el equipo analiza cómo

ha sido su manera de trabajar durante la iteración:
 Qué cosas han funcionado bien.

 Cuales hay que mejorar.
 Qué cosas quiere probar hacer en la siguiente iteración.
SOFTWARE
Pagina - 1/ 31
 Qué ha aprendido.
 Cuáles son los problemas que podrían impedirle progresar adecuadamente. El
Facilitador se encargará de ir eliminando los obstáculos identificados que el propio
equipo no pueda resolver por sí mismo.
Esta reunión se realiza después de la reunión de demostración al cliente de los objetivos

conseguidos en la iteración, para poder incorporar su feedback y cumplimiento de
expectativas como parte de los temas a tratar en la reunión de retrospectiva
Se realiza en un timebox de cómo máximo 1 hora.
Beneficios
 Incrementa la productividad en el proyecto y el aprendizaje del equipo de manera

sistemática, iteración a iteración, con resultados a corto plazo.
 Aumenta la motivación del equipo dado que participa en la mejora de proceso, se
siente escuchado, toma decisiones consensuadas (y más sostenibles) para ir
eliminando lo que le molesta y le impide que sea más productivo.
Restricciones
 Es necesario que el Equipo y el Facilitador dispongan de autoridad, mecanismos y

recursos para ir mejorando su forma de trabajar y el contexto del proyecto. Es
frustrante encontrar sistemáticamente los mismos obstáculos y no poder
solucionarlos.
Replanificación del proyecto
En las reuniones de planificación de entregas y/o durante el transcurso de una iteración, el

cliente va trabajando en la lista de objetivos/requisitos priorizada del producto o
proyecto, añadiendo requisitos, modificándolos, eliminándolos, repriorizándolos,
cambiando el contenido de iteraciones y definiendo un calendario de entregas que se
ajuste mejor a sus nuevas necesidades.
Los cambios en la lista de requisitos pueden ser debidos a:
 Modificaciones que el cliente solicita tras la demostración que el equipo realiza al

final de cada iteración sobre los resultados obtenidos, ahora que el cliente
entiende mejor el producto o proyecto.
 Cambios en el contexto del proyecto (sacar al mercado un producto antes que su
competidor, hacer frente a urgencias o nuevas peticiones de clientes, etc).
 Nuevos requisitos o tareas como resultado de nuevos riesgos en el proyecto.
SOFTWARE
Pagina - 1/ 31
Para realizar esta tarea, el cliente colabora con el equipo:
 Para cada nuevo objetivo/requisito conjuntamente se hace una identificación

inicial de sus condiciones de satisfacción (que se detallarán en la reunión de
planificación de la iteración).
 El cliente obtiene del equipo la re-estimación de costos de desarrollo para
completar los objetivos/requisitos siguientes, según la definición de completado. El
equipo ajusta el factor de complejidad, el costo para completar los requisitos y su
velocidad de desarrollo en función de la experiencia adquirida hasta ese momento
en el proyecto.
 El cliente re-prioriza la lista de objetivos/requisitos en función de estas nuevas
estimaciones.
Hay que notar que el equipo sigue trabajando con los objetivos/requisitos de la iteración
en curso, (que de hecho eran los más prioritarios al iniciar la iteración). No es posible
cambiar los requisitos que se desarrollan durante la iteración. En la reunión de
planificación de la iteración el cliente presentará la nueva lista de requisitos para que sea
desarrollada.
Beneficios
De manera sistemática, iteración a iteración, se obtienen los siguientes beneficios:
 El cliente puede tomar decisiones con tiempo respecto al progreso del proyecto y
posibles desviaciones:
o Replanificar el proyecto para obtener un nuevo calendario de entregas que
cumpla con sus necesidades actuales.
o Incorporar nuevos recursos.
o Cancelar el proyecto con los requisitos completados hasta el momento
plenamente operativos, si el beneficio pendiente de obtener es menor que
el costo de desarrollo.
 El plan de proyecto se actualiza con la velocidad de desarrollo del equipo, se evitan
sorpresas de última hora.
RESPONSABILIDADES
Las responsabilidades del Cliente (que puede ser interno o externo al equipo de
desarrollo) son:
 Ser el representante de todas las personas interesadas en los resultados del

proyecto (internas o externas al equipo, promotores del proyecto y usuarios finales
[idealmente también debería ser un usuario clave] o consumidores finales del
SOFTWARE
Pagina - 1/ 31
producto) y actuar como interlocutor único ante el equipo, con autoridad para
tomar decisiones.
 Definir los objetivos del producto o proyecto.
 Dirigir los resultados del proyecto y maximizar su ROI (Return Of Investment).
o Es el propietario de la planificación del proyecto: crea y mantiene la lista
priorizada con los requisitos necesarios para cubrir los objetivos del
producto o proyecto, conoce el valor que aportará cada requisito y calcula
el ROI a partir del costo de cada requisito que le proporciona el equipo.
o Antes de iniciar cada iteración re planifica el proyecto en función de los
requisitos que aportan más valor en ese momento, de los requisitos
completados en la iteración anterior y del contexto del proyecto en ese
momento.
 Participar en la reunión de planificación de iteración, proponiendo los requisitos
más prioritarios a desarrollar, respondiendo a las dudas del equipo y detallando los
requisitos que el equipo se comprometer a hacer.
 Estar disponible durante el curso de la iteración para responder a las preguntas
que puedan aparecer.
 No cambiar los requisitos que se están desarrollando en una iteración, una vez está
iniciada.
 Participar en la reunión de demostración de la iteración, revisando los requisitos
completados.
Facilitador (Scrum Master)
Lidera al equipo llevando a cabo las siguientes responsabilidades:
 Velar por que todos los participantes del proyecto sigan las reglas y proceso de
Scrum, encajándolas en la cultura de la organización, y guiar la colaboración
intraequipo y con el cliente de manera que las sinergias sean máximas. Esto
implica:
o Asegurar que la lista de requisitos priorizada esté preparada antes de la
siguiente iteración.
o Facilitar las reuniones de Scrum (planificación de la iteración, reuniones
diarias de sincronización del equipo, demostración, retrospectiva), de
manera que sean productivas y consigan sus objetivos.
o Enseñar al equipo a auto gestionarse. No da respuestas, si no que guía al
equipo con preguntas para que descubra por sí mismo una solución.
 Quitar los impedimentos que el equipo tiene en su camino para conseguir el
objetivo de cada iteración (proporcionar un resultado útil al cliente de la manera
más efectiva) y poder finalizar el proyecto con éxito. Estos obstáculos se identifican
de manera sistemática en las reuniones diarias de sincronización del equipo y en
las reuniones de retrospectiva.
SOFTWARE
Pagina - 1/ 31
 Proteger y aislar al equipo de interrupciones externas durante la ejecución de la

iteración (introducción de nuevos requisitos, "secuestro" no previsto de un
miembro del equipo, etc.). De esta manera, el equipo puede mantener su
productividad y el compromiso que adquirió sobre los requisitos que completaría
en la iteración [notar, sin embargo, que el equipo debe reservar tiempo
para colaborar con al cliente en la preparación de la lista de requisitos para la
próxima iteración].
 Que antes de la reunión que el propietario del producto disponga de un backlog
adecuado y suficiente para realizar el sprint.
 Que el diálogo principal de la reunión se realice entre el propietario del producto y
el equipo. Otros asistentes pueden participar, pero su colaboración no puede
implicar toma de decisiones ni limitar el diálogo principal.
 Que al final de la reunión están objetivamente determinados:
 Los elementos de la pila del producto que se van a ejecutar.
 El objetivo del sprint.
 La pila de sprint con todas las tareas estimadas y asignadas.
 La duración del sprint y la fecha de la reunión de revisión
El Scrum Manager modera la reunión para que no dure más de un día. Debe evitar que el
equipo comience a profundizar en trabajos de análisis o arquitectura que son propios del
sprint.
Equipo (Team)
Grupo de personas que de manera conjunta desarrollan el producto del proyecto. Tienen
un objetivo común, comparten la responsabilidad del trabajo que realizan (así como de su
calidad) en cada iteración y en el proyecto.
El tamaño del equipo está entre 5 y 9 personas. Por debajo de 5 personas cualquier
imprevisto o interrupción sobre un miembro del equipo compromete seriamente el
compromiso que han adquirido y, por tanto, el resultado que se va a entregar al cliente al
finalizar la iteración. Por encima de 9 personas, la comunicación y colaboración entre
todos los miembros se hace más difícil y se forman subgrupos.
Es un equipo auto organizado, que comparte información y cuyos miembros confían entre
ellos. Realiza de manera conjunta las siguientes actividades:
 Seleccionar los requisitos que se compromete a completar en una iteración, de

forma que estén preparados para ser entregados al cliente.
 Estimar la complejidad de cada requisito en la lista de requisitos priorizada del
producto o proyecto.
SOFTWARE
Pagina - 1/ 31
 En la reunión de planificación de la iteración decide cómo va a realizar su trabajo:

o Seleccionar los requisitos que pueden completar en cada iteración,
realizando al cliente las preguntas necesarias.
o Identificar todas las tareas necesarias para completar cada requisito.
o Estimar el esfuerzo necesario para realizar cada tarea.
o Cada miembro del equipo se auto asigna a las tareas.
 Durante la iteración, trabajar de manera conjunta para conseguir los objetivos de
la iteración.
 Al finalizar la iteración:
o Demostrar al cliente los requisitos completados en cada iteración.
o Hacer una retrospectiva la final de cada iteración para mejorar de forma
continua su manera de trabajar.
El equipo es multidisciplinar:
 Los miembros del equipo tienen las habilidades necesarias para poder identificar y
ejecutar todas las tareas que permiten proporcionar al cliente los requisitos
comprometidos en la iteración.
 Tienen que depender lo mínimo de personas externas al equipo, de manera que el
compromiso que adquieren en cada iteración no se ponga en peligro.
 Se crea una sinergia que permite que el resultado sea más rico al nutrirse de las
diferentes experiencias, conocimientos y habilidades de todos. Colaboración
creativa.
Los miembros del equipo dedicarse al proyecto a tiempo completo para evitar dañar su
productividad por cambios de tareas en diferentes proyectos, para evitar interrupciones
externas y así poder mantener el compromiso que adquieren en cada iteración.
Todos los miembros del equipo trabajan en la misma localización física, para poder
maximizar la comunicación entre ellos mediante conversaciones cara a cara, diagramas en
pizarras blancas, etc. De esta manera se minimizan otros canales de comunicación menos
eficientes, que hacen que las tareas se transformen en un “pasa pelota” o que hacen
perder el tiempo en el establecimiento de la comunicación (como cuando se llama
repetidas veces por teléfono cuando la persona no está en su puesto).
El equipo debe ser estable durante el proyecto, sus miembros deben cambiar lo mínimo
posible, para poder aprovechar el esfuerzo que les ha costado construir sus relaciones
interpersonales, engranarse y establecer su organización del trabajo.
SOFTWARE
Pagina - 1/ 31
DOCUMENTOS O ARTEFACTOS
Product backlog
El product backlog es un documento de alto nivel para todo el proyecto. Contiene

descripciones genéricas de todos los requerimientos, funcionalidades deseables, etc.
priorizadas según su valor para el negocio (business value) . Es el qué va a ser construido.
Es abierto y cualquiera puede modificarlo. Contiene estimaciones grosso modo, 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 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 menos tiempo de desarrollo tendrá probablemente más prioridad, debido a
que su ROI será más alto.
Sprint backlog
El sprint backlog es un documento detallado donde se describe el cómo el equipo va a

implementar los requisitos durante el siguiente sprint. Las tareas se dividen en horas con
ninguna tarea de duración superior a 16 horas. Si una tarea es mayor de 16 horas, deberá
ser rota en mayor detalle. Las tareas en el sprint backlog nunca son asignadas, son
tomadas por los miembros del equipo del modo que les parezca oportuno.
Burn down
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.
SOFTWARE
Pagina - 1/ 31
GRÁFICOS
SOFTWARE
Pagina - 1/ 31

Metodologia de Desarrollo de Software

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Metodologia de Desarrollo de Software

Uploaded by

Copyright:

Available Formats

PROPUESTA METODOLOGIA DE DESARROLLO DE SOFTWARE

Fecha elaboración: 21-Septiembre-2016

Propuesta Metodología para el desarrollo de software

Fecha Versión Descripción Autores

 Estudiar y analizar la evolución que han tenido las metodologías de gestión de

 Implantar una metodología para la gestión y desarrollo de software en el equipo

FACTORES ASOCIADOS A LA AUSENCIA DE METODOLOGIA DE DESARROLLO

Cuando no se cuenta con una metodología para la gestión y desarrollo de software, es

Algunos de los problemas que se evidencian por la carencia de una metodología de

EVOLUCION DE LA GESTION DE PROYECTOS

La gestión de proyectos nació para ofrecer previsibilidad en la construcción de grandes

La gestión de proyectos desarrollada a finales del siglo pasado se basa en la planificación

Sobre esa información se desarrolla un plan apropiado a los recursos y tiempos

Su principal objetivo es conseguir que el desarrollo resulte según lo “previsto”; y basa el

Las variables claves para triunfar en el nuevo escenario son:

En modelo predictivo el objetivo es lograr lo planificado: en un modelo de negocio

Como el escenario es muy rápido es inestable no es realista pensar que se podrá

El ciclo de desarrollo clásico, en el caso del software, es el denominado secuencial o en

partes de análisis aún pendientes de concretar, el equipo de codificación puede disponer

Pero en el nuevo modelo de desarrollo no se trata de un cierto solapamiento entre fases,

DIFERENCIAS DE LA METODOLOGIA DE DESARROLLO RAPIDO FRENTE AL DESARROLLO

En el modelo de desarrollo ágil, el proyecto no lo desarrollan equipos diferentes con

La participación de todo el equipo en el diseño aporta mucho más talento innovador y

Características de las metodologías de desarrollo rápido:

1. La incertidumbre como elemento consustancial y asumido en el entorno y en la

No se trata de equipos auto-dirigidos, sino auto-organizados. La gestión marca la

 Autonomía: son libres para elegir la estrategia de solución.

 Auto-superación. El equipo va desarrollando soluciones que evalúa analiza y

 Auto-enriquecimiento: La multi-disciplinaridad de los componentes del equipo

3.- Fases de desarrollo solapadas.

4.- Control sutil

El equipo trabaja con autonomía en un entorno de ambigüedad, inestabilidad y tensión. La

5.- Difusión del conocimiento

Los equipos y las empresas mantienen libre acceso a la información, herramientas y

Las circunstancias de los mercados y de las empresas no se pueden cambiar, y es la

Quizá ya no hay “productos finales”, sino productos en evolución, revisión mejora o

De estos argumentos surge el interrogante. Qué modelo de gestión usar, ¿predictiva o

PROPUESTA METODOLOGIA DE DESARROLLO AGIL IMPLEMENTADA Y ADAPTADA POR

Con base en los argumentos mencionados en los puntos anteriores, es oportuno

El propósito, es que el mismo grupo de ingenieros, sea el encargado de adoptar la

Será un proceso de crecimiento colectivo, autocritico, auto-organizado y motivado por el

Los principales beneficios que proporciona Scrum son:

 Entrega mensual (o quincenal) de resultados (los requisitos más prioritarios en ese

Scrum se basa en:

 El desarrollo incremental de los requisitos del proyecto en bloques temporales

Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la

Características generales de Scrum

Scrum permite la creación de equipos auto organizados impulsando la co-localización de

Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes

Stakeholders (Clientes, Proveedores, Inversores)

El proceso parte de la lista de objetivos/requisitos priorizada del producto, que actúa

 lista de objetivos /requisitos priorizada (Product backlog)

 Planificación de la iteración (Sprint Planning)

 Reunión diaria de sincronización del equipo (Scrum Daily Meeting)

Lista de objetivos / requisitos priorizada (Product Backlog)

La lista de objetivos/requisitos priorizada representa la visión y expectativas del cliente

 Contiene los objetivos/requisitos de alto nivel del producto o proyecto, que se

 Se evita caer en parálisis de análisis al inicio del proyecto, de manera que se

 Puede llegar a un punto del proyecto en que no valga la pena analizar ni

El cliente y el equipo tienen que acordar la "definición de completado” de los objetivos /

 Debe asegurar que el incremento de producto es potencialmente entregable al

Descripción general de la planificación del Sprint

La planificación de Sprint es una reunión crítica, probablemente la más importante de