INTRODUCCION A MELTOLOGIAS AGILES

LA GESTION AGIL DE PROYECTOS DE SISTEMAS DE INFORMACION

PROYECTO

Es un servicio temporal, crea un producto o resultado único, tiene un inicio y fin, debe cumplir
con las metas u objetivos.

DEPENDE DE FACTORES:
Entorno -> no sufre modificaciones permanentes y frecuentes.
Cliente -> tiene muy claro lo que necesita y sabe transmitirlo.
Equipo -> profesionales necesarios para atender a esa necesidad.
Fases -> se hacen en forma lineal organizada no sufre problemas durante su realización.
PLANTEAMIENTO DE UN PROYECTO INTERVIENE LOS SIGUIENTES ELEMENTOS:
Cliente -> es el que requiere la solución a un problema específico.
El usuario -> las personas que usaran la solución.
El tiempo -> se ajusta a un plazo de tiempo con una fecha de inicio y fin.
Jefe o responsable del proyecto -> gestiona los recursos, la planificación y seguimiento del
proyecto.

PARA QUE ESTOS ELEMENTOS SE RELACIONEN SE TIENE QUE TOMAR LOS

SIGUIENTES ASPECTOS
• Definición de una estructura organizativa del proyecto tanto del equipo, y las personas
involucradas.
• Definir el enfoque metodológico del proyecto: fases, tareas y actividades que se deben
cumplir.
• Identificar los roles y responsabilidades de cada miembro.
• Determinar los tiempos de las fases, actividades y tareas, los resultados esperados.
• Asignar los recursos técnicos y administrativos.
• Gestionar el desarrollo del proyecto, recursos, tiempo haciendo los ajustes necesarios.

GESTION DE PROYECTOS
Es una disciplina del planteamiento la organización, motivación y control de los recursos con el
propósito de alcanzar varios objetivos.

PDCA (PLAN, DO, CHECK, ACT)

Es una gestión predictiva que pronostica, gracias al conocimiento detallado de lo que se va
hacer, al plan del proyecto, las fechas, costos, recursos necesarios, su principal objetivo que el
proyecto resulte según lo previsto.
CICLO DEMING:
Planificar -> definir el problema, la solución, conformar el equipo, estimar tiempos, costes y
tareas.

Hacer -> poner en práctica la solución y medir su rendimiento.

Verificar ->verificar los resultados, evaluar cumplimiento del plan y objetivos.
Actuar -> decidir qué cambios hacer para mejorar el proceso.

METODOLOGIAS TRADICIONALES
Como el análisis y diseño estructurado, posteriormente las metodologías orientadas a objetos
como RUP son enfoques que surgen como guías para la creación de un software de calidad

La metodología RUP tiene como base una gestión predictiva, parte de unos requisitos iniciales,
con estos requisitos se configura un plan adecuado usando recursos y tiempos necesarios,
durante la fase de desarrollo se ve si hay desviaciones. Esta metodología define un conjunto de
fases de secuencias en las que se indican las operaciones que se van a realizar, el tiempo que
van a tomar y su coste, características:

• Los requisitos son definidos al inicio del proyecto y no sufren cambios drásticos.
• Se basa en los procesos.
• Gestión predictiva.
• Disponen de una documentación exhaustiva.
• El desarrollo se define en fases cuyo conjunto de denomina ciclo de vida.
• Se enfoca en tener el producto en el tiempo y coste estimado.
• El proyecto no va a tener ningún tipo de cambio, no esté sujeto a variables.

fases de una metodología tradicional:

(1) requerimientos del sistema.

(2) análisis.

(3) diseño.

(4) programación.

(5) pruebas.

(6) implantación.

METODOLOGIAS AGILES
Velocidad -> la vida de los productos empieza a ser más breve.
Incertidumbre -> es un escenario rápido e inestable, encajan mal las estrategias de negocios
predictivas, en los entornos rápidos los productos y estrategias que alcanzan el éxito no son los
que se desarrollan sobre palanes preconcebidos sino los que crecen en adaptación y
replanteamiento constante. La incertidumbre es una consecuencia de la velocidad, no
necesitan modelos de gestión predictiva sino adaptable.

EL ENFOQUE AGIL
surge como una respuesta a un desarrollo tecnológico acelerado en todas las áreas y que exige
métodos de desarrollo que den una pronta respuesta a sus necesidades.
variantes claves para triunfar en este nuevo escenario son:

• Tomar retroinformación del producto y del entorno en forma continua(feedback).

• Dar el mayor valor innovador al producto.
• En el menor tiempo posible.
• Salir lo mas antes posible al mercado.
• No hay producto terminado, el producto esta en una constante evolución.

de esta forma mas 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 y durante toda la
evolución del proyecto.

DIFERENCIA ENTRE ENFOQUE TRADICIONAL Y EL ENFOQUE AGIL

Desarrollo tradicional
• Fases del desarrollo del proyecto establecidas.
• Especialización del equipo de desarrollo del proyecto.
• Requisitos detallados, especificados al inicio del proyecto con poca tolerancia a
cambios.
• Seguimiento estricto del plan control de plazos y recursos.
• Gestor del proyecto que analiza y supervisa.

Desarrollo ágil
• Solapamiento de fases en actividades y tareas más cortas.
• Equipo multidisciplinar cono conocimientos y competencias diversas.
• Visión del producto los requerimientos surgen durante todo el proyecto.
• Adaptación a los cambios a las nuevas necesidades.
• Equipo autogestionado y auto organizado.

No hay fases están pasan a ser tareas que se ejecutan cuando se necesitan. Las actividades que
se realizan de requisitos, análisis, diseño, programación, pruebas e integración se las realiza
cada desarrollador en cada uno de los requerimientos asignados.
MANIFIESTO AGIL
Un conjunto de cuatro postulados denominados el manifiesto ágil que son los principios sobre
los cuales se basan estos métodos:

• A los individuos y su interacción por encima de los procesos y las herramientas:

la iteración de los miembros del equipo y su aporte creativo es de mas valor que el uso
de herramientas de apoyo, se estimula reuniones frecuentes denominados ciclos de
inspección y adaptación. Aspectos claves entre los miembros del equipo (1) respeto
por el valor de la opinión de cada persona (2) veracidad en cada comunicación (3)
transparencia en todos los datos acciones y decisiones (4) confianza en que cada
miembro respaldara al equipo (5) compromiso con el equipo y los objetivos.
• El software que funciona por encima de la documentación exhaustiva: poder ver
analizar las funcionalidades a implementar antes de que estas sean realizadas proveen
de un feedback de mucha ayuda al desarrollador, la manera de hacerlo es a través de
prototipos o sobre partes elaboradas. En muchas cuestiones legales dispones de una
documentación es obligatorio, principalmente para auditorias informáticas. La
 documentación no puede sustituir la riqueza y generación de lo que se logra con la
comunicación directa entre las personas.
• La colaboración con el cliente por encima de la negociación contractual:
característica fundamental la participación del cliente en las etapas del proyecto.
• La respuesta al cambio por encima del seguimiento de un plan: está orientado a
una evolución permanente y cambios que pueden ser continuos. Los principales
valores de la gestión ágil son la adaptación y anticipación.

LOS PRINCIPIOS DEL MANIFIESTO AGIL

• Principal prioridad satisfacer al cliente con entregas tempranas y continuas
• Bienvenidos a los requisitos cambiantes, incluso si llegan tarde al desarrollo
• Entregar con frecuencia software que funcione
• Las personas del negocio con los desarrolladores deben trabajar juntos
• Individuos motivados, dándoles respaldos y oportunidades que necesitan
• Conversación cara a cara
• El software que funcione es a principal medida del progreso
• Deben mantener un ritmo constante de forma indefinida

EL CICLO DEL DESARROLLO AGIL

CONCEPTO -> se crea la visión del producto o servicio que se quiere obtener. Se decide y
selecciona al equipo de personas.

ESPECULACION -> el equipo especula y construye hipótesis sobre la información de la visión,

se determina las limitaciones impuestas por el entorno de negocio. Actividades que se realizan
(1) desarrollo revisión de los requisitos generales del producto (2) desarrollo de una lista con
las funcionalidades esperadas (3) construcción de un plan de entrega (4) estrategias o planes
para la gestión de riesgos.

EXPLORACION -> consiste en el desarrollo de las funcionalidades que construirá el siguiente

incremento del producto de acuerdo a lo planificado, para cada funcionalidad se aplica de
manera traslapada el análisis, el diseño la implementación y pruebas.

REVISION -> se revisa todo lo que se ha construido y se contrasta con los objetivos. En esta
etapa es importante el feedback del cliente cualquier recomendación es tomada en cuenta.

CIERRE -> no quiere decir necesariamente que se ha terminado el proyecto. Lo que para un
ciclo de desarrollo seria un mantenimiento en un entorno ágil es la continuidad del proyecto
en ciclos incrementales hacia la siguiente versión.
 MODELO SCRUM
INTRODUCCION
Es una metodología de desarrollo muy simple flexible y adaptable a todo tipo de desarrollo de
software, sin embargo, no es fácil su aplicación requiere de una disciplina y compromiso de sus
integrantes, es una metodología ágil:

(1) es un modo de desarrollo de carácter adaptable.

(2) orientado a las personas antes que a los procesos.

(3) emplea desarrollo ágil: iterativo e incremental.

PROCESO SCRUM
• Se inicia con una visión del producto por parte del cliente.
• Se elabora el poduct backlog.
• Se efectúa la planificación inicial, donde se prioriza los requerimientos del Product
Backlog en sprints o iteraciones.
• Se realiza la planificación de la iteración SP al inicio.
• Se desarrolla el sprint.
• Se cumple con los scrums diarios de seguimiento del sprint.
• A la conclusión del Sprint se hace la revisión del Sprint o Sprint Review.
• Se efectúa la revisión retrospectiva del sprint concluido Sprint Retrospective, antes de
comenzar al siguiente Sprint.

ROLES
se clasifican en dos grupos comprometidos e implicados:

EL ROL DEL PRODUCT OWNER-PROPIETARIO DEL PRODUCTO

Representante de los usuarios. Competencias que debe tener:

• Capacidad de organización, planificación y gestión del proyecto

• Buena capacidad de comunicación
• Capacidad de decisión en la organización, que se permita tomar decisiones
• Conocimiento solido y experiencia en los procesos del negocio
• Noción sobre la aplicación y uso de las tecnologías de información

Responsabilidades:
• Encargado de administrar el PB el se encarga de definir las prioridades
• Único interlocutor entre los usuarios y el equipo de desarrollo
• Todos los miembros de la organización deben acatar sus decisiones
• Decide en última instancia como será el resultado final
• Conoce el plan del producto sus posibilidades y plan de inversión
• Se encarga de viabilizar el financiamiento del proyecto
• Facilita el apoyo logístico y administrativo del equipo de desarrollo

ROL DEL SCRUM MASTER

es la persona que lidera el desarrollo del proyecto. Competencias que debe tener:
 • Amplio conocimiento de la metodología scrum
• Capacidad de liderazgo manejo de equipos de trabajo
• Alto nivel de comunicación
• Conocimientos de organización, planificación y seguimientos de proyectos
• Experiencia previa en proyectos de desarrollo

EL ROL DEL SCRUM MASTER

• Es el intermediario del equipo de trabajo con el PO
• Coadyuva en la elaboración del PB
• Coadyuva en la definición de los S o iteraciones
• Solicita y hace seguimiento a los historiales de los usuarios
• Se encarga de coordinar la entrega de los resultados de los S
• Se encarga de recabar retroalimentación de los usuarios para mejoras o cambios en S
posteriores
• Coordina el soporte administrativo y logístico con el PO
• Coordina todas las reuniones con el PO

EL ROL CON EL EQUIPO DE DESARROLLO

• Es responsable de la capacitación o formación de ED
• Coordina y supervisa el desarrollo de los S
• Coordina las herramientas usadas en el S
• Supervisa las reuniones diarias del equipo de desarrollo
• Retroalimenta las observaciones de los usuarios al equipo
• Coordina la logística que requiere el ED
• Responsable de llevar adelante el SR
• Responsable de llevar adelante el SR

EL ROL DEL TEAM-EQUIPO DE DESARROLLO

está construido de entre 5 a 9 personas

CARACTERISTICAS:
• Es cross-functional (MULTIFUNCIONAL)todos los miembros tienen múltiples
competencias
• Autoorganizados y autogestionados, definen responsabilidades
• Deben ser de tiempo completo deben estar abocados al proyecto
• Deben tener un solido conocimiento de la metodología

ROL QUE TIENE EL TEAM

• Coadyuva en la elaboración del PB con el PO
• Define las tareas del SB
• Es responsable del desarrollo del incremento del S
• El responsable de la documentación técnica del proyecto
• Es responsable de las pruebas unitarias y de integración del incremento
• Completa la planilla de seguimiento del S y la hoja de trabajo

REUNIONES
característica más destacada del Scrum, razones:
 • Solventan la baja documentación que se maneja, forma de mantener comunicado al
equipo.
• Permite delimitar los hitos de desarrollo del proyecto, a través de reuniones podemos
hacer un feedback.
• Mantener comunicación permanente entre Team, Scrum Master Y Product Owner.
• Permite registrar las herramientas y elementos propios de Scrum.

Tipos de reuniones que hay son:

• Planificación inicial.
• El Sprint Planning.
• Scrum Diarios.
• Sprint Review.
• Sprint Restrospective.

LA SALA DE REUNIONES
previo a detallar las actividades que se realzan en cada reunión, debe haber:

• Audibilidad->cualquier miembro del equipo puede hablar con cualquier otro sin tener
que levantarse de su sitio.
• Visibilidad-> todo el mundo puede ver a los demás.
• Aislamiento-> nadie fuera del equipo esta tan cerca como para molestarlo.

PLANIFICACION INICIAL
consiste:

• Se realiza solo una vez al inicio del proyecto, es recomendable que el PO prepare su
lista de requerimientos.
• Participan: Product Owner, Scrum Master, Team, todos ellos se reúnen para conocer
las necesidades o requerimientos del Product Owner.
• Se determinan los requisitos iniciales y la visión del producto.
• El resultado de esta reunión se consolida el Product Backlog.
• El Product Owner debe tener una lista de los requisitos funcionales del producto.
• El SM hace de moderador de la reunión y orienta al PO sobre la factibilidad técnica y
operativa.
• El Team aporta e la elaboración del Product Backlog.
• Se definen las prioridades de los requerimientos en iteraciones o S con su respectiva
estimación de tiempo.
• Los aspectos técnicos del software a usar.
• Tiempo estimado de esta reunión un día.

SPRINT PLANING (PLANIFICACION DE LA ITERACION)

consiste en:

• Se realiza al inicio de cada iteración o Sprint

• Participan el Product Owner, Scrum Master, TEAM
• Se determina los objeticos que deberá cumplir la iteración
 • El ED con el Product Owner definen las tareas que se realizaran para cada
requerimiento
• El resultado se con consolida el Sprint Backlog.
• La planificación de las tareas de la iteración se realiza en dos partes de un máximo de 4
horas cada una:

Primera parte:

o El Product Owner presenta al Team los requisitos más prioritarios a desarrollar

o El Team hace las consultas necesarias al Product Owner para aclarar dudas
o El Scrum Master y team hacen sugerencias para incorporar funcionalidades

Segunda parte

o Una vez definido los requerimientos del Sprint, el team con la coordinación del
Scrum Master elaboran la lista de requerimientos o historias de usuario
o Se hace una estimación conjunta para realizar cada tarea
o El Team se autoasignan las tareas que van a realizar
o La estimación de cada esfuerzo puede ser de 4-16 horas
o Si una pasa mas de 16 horas deberá ser particionada

LOS SCRUM DIARIOS (SEGUIMIENTO DE SPRINT)

• Seguimiento a las actividades del día anterior y planificar las actividades que se
realizaran en el día presente.
• Participan el Scrum Master y el Team.
• Coordina las reuniones el Scrum Master.
• No debe exceder los 15 min.
• El objetivo es determinar los avances.
• Durante la reunión se actualiza los tiempos de tareas en cursi, se cierran las tareas
concluidas y se inician nuevas tareas, se realiza en la pizarra de trabajo.
• No es una reunión para resolver problemas.
• El resultado de la reunión es a la actualización de la planilla de seguimiento del Sprint.
• Se realizan todos los días a la misma hora.
• Se recomienda que sea la primera actividad del día.
• Deben estar todos los miembros del equipo.
• Todos parados.
• El SM realiza las siguientes preguntas: que hiciste ayer, que harás hoy, que obstáculos
tienes.

EL SPRINT REVIEW (SPRINT DE REVISION)

• Se realiza al final de cada Sprint.
• Participan al Product Owner, Scrum Master, Team y según se requiera usuarios.
• Se presenta lo construido durante el Sprint al Product Owner.
• Dura 4 horas.
• El PO identifica el cumplimiento del objetivo respecto del Product Backlog.
• El ED obtiene retroalimentación por parte del cliente.
• Están prohibidas las presentaciones en diapositivas o PowerPoint se hace una demo.
• La demo del incremento desarrollado en la iteración.
 • La demo debe ser usando un entorno e información lo las real y próximo a lo que usara
el cliente.

La presentación del incremento debe seguir un protocolo como el siguiente:

• El Scrum Master expone el objetivo del Sprint.

• El Team hace una introducción general al Sprint y demuestra el funcionamiento.
• Se abre un turno de preguntas y respuestas por parte del Po y clientes.
• El Scrum Master anota las recomendaciones de mejoras o cambios.
• El Scrum Master de acuerdo a la agenda del Product Owner y Team fija la convocatoria
para la reunión del siguiente Sprint.

Una demo de S bien ejecutada, aunque parezca poco espectacular tiene un efecto muy
profundo:

• El equipo obtiene reconocimiento por sus logros.

• Otras personas se enteran de lo que está haciendo el equipo.
• La demo consigue feedback vital de los interesados.
• Las demos son un evento social.
• Hacer una demo fuerza al equipo a acabar realmente las cosas.

SPRINT RETROSPECTIVE (RETROSPECTIVA DEL SPRINT)

• se realiza después del Sprint Review y antes del próximo Sprint Planning.
• participan el Scrum Master, Team opcionalmente el Product Owner.
• el propósito de la retrospectiva es revisar la forma en que se desarrolló el ultimo
Sprint.
• dura 4 horas.
• permite mejorar la forma de trabajo, el marco de trabajo.
• sin retrospectiva el Team sigue cometiendo los mismos errores.
• si el Team está teniendo dificultades de trabajo de equipo, se debe tratar de
solucionarlos.
• todos responden: que cosas hicieron bien en el ultimo Sprint, que cosas se podría
mejorar.
• el SM anota las respuestas.
• el equipo prioriza las mejoras posibles.
• las acciones de mejoras se deben implementar en el siguiente Sprint.

LOS ELEMENTOS DEL SCRUM

PRODUCT BACKLOG -> ES LA LISTA DE REQUISITOS O NECESIDADES DEL USUARIO, TAMBIÉN DENOMINADA PILA
DEL PRODUCTO.

SPRINT BACKLOG -> ES LA LISTA DE TAREAS QUE DEBEN REALIZARSE DURANTE UN SPRINT PARA OBTENER UN
INCREMENTO DEL PRODUCTO

INCREMENTO -> ES UNA PARTE DEL PRODUCTO, DESARROLLADO DURANTE UN S, TERMINADA Y TOTALMENTE
OPERATIVA

PRODUCT BACKLOG
Es el inventario de funcionalidades, mejoras, tecnologías y corrección de errores. Representan
todo aquello que esperan los clientes, usuarios y en general los interesados. Nunca se da por
completo está en continuo crecimiento.

FORMATO
• ID: identificador único.
• DESCRIPCION DEL REQUERIMIENTO O FUNCIONALIDAD: texto breve de la funcionalidad
que deberá cumplir la aplicación.
• PRIORIDAD: sistema de priorización del requerimiento.
• ESTIMACION DE ESFUERZO: días que tomara al equipo poder implementar la
funcionalidad.
• SPRINT: iteración en la cual se tiene previsto atender el requerimiento.
• PRUEBA DE ACEPTACION: criterios de validación de que lo implementado satisface el
requerimiento del cliente.
• NOTAS: recomendaciones adicionales que pueden ayudar al desarrollo de la
funcionalidad.

ELABORCION DEL PRODUCTO BACKLOG

Es elaborado básicamente por el PO, coadyuvan el SM y el ED. Se lo realiza en la reunión de
planificación inicial.

PRIMERA ETAPA
• El PO identifica los requerimientos o funcionalidades que deberá tener el producto de
software o sistema.
• Se construye el PB asociado a cada requerimiento un identificador.
• El SM modera las reuniones del equipo.
• Se define la prioridad de cada requerimiento.
• El ED determina la estimación de esfuerzo para su desarrollo o implementación.

SEGUNDA ETAPA
• La lista de requerimientos se ordena según su prioridad.
• Considerando que un S debe tener una duración de 20 días.
• Definidos los S se analiza cada uno para ver la conveniencia de que un requerimiento
se mantenga en el Sprint.
• Se completa los datos de pruebas y notas complementarias.

SPRINT BACKLOG
Es la lista que descompone las funcionalidades del Product Backlog. En el Sprint Backlog para
cada requerimiento se definen las tareas para llevarla a cabo, estimando el tiempo de trabajo
correspondiente, descompone el proyecto en tareas de tamaño adecuado para determinar el
avance diario.

CONDICIONES
• Participan el ED y SM
• Realizando de forma conjunta por todo el equipo
• Cubre todas las tareas identificadas por el equipo
• Solo el equipo lo puede modificar durante el S
• El tamaño de cada tarea esta en un rango de 4 a 16 hrs
 • Es visible para todo el equipo

SOPORTE
• Hoja de calculo
• Pizarra o pared física, papelógrafo
• Herramientas colaborativas o de gestión de proyectos

FORMATO DEL SPRINT BACKLOG, LO APROPIADO

• Incluye la información: lista de tareas, persona responsable estado en que se
encuentra, y tiempo de trabajo que queda
• Solo incluye información necesaria
• El modelo elegido debe ser la opción que más facilite la consulta
• Sirve el tiempo que queda cada tarea
• Debe ser efectuado para cada sprint o iteración
• Se constituye en un documento técnico de iteración

FORMATO DEL SPRINT BACKLOG

• Sprint: número del sprint o su iteración.
• Descripción del sprint: descripción breve del sprint.
• ID: corresponde al identificador del historial del Product Backlog asociado al
requerimiento.
• Requerimientos/ tareas: se indica el requerimiento del PB y asocia al requerimiento de
tareas específicas que se deberán realizar.
• Responsable: indica el nombre de la persona.
• Estado: indica si la tarea esta pendiente en curso o concluida.
• Estimación estimación de esfuerzo para completar la tarea va de 4 a 16 horas.
• Días del Sprint: permite registrar el avance del S en las reuniones diarias.
• Acumulada estimación de esfuerzo: se suma la cantidad de horas estimadas de
esfuerzo.
• Acumulados días: debajo de cada día se acumulan las horas de trabajo reales del día.
• Avance del Sprint: cada responsable indica el avance real de horas trabajadas en las
reuniones diarias.