Taller de Proyectos 1

Gestión ágil de proyectos

Sesión 2
Dinámica inicial

Dinámica de inicio seleccionada

por el docente.
Agenda
• Métodos Tradicionales vs. Métodos Ágiles
• El “Manifiesto Ágil”
• Principios "lean" del desarrollo de producto/servicio
• El Producto Mínimo Viable (MVP)
Métodos Tradicionales vs. Métodos Ágiles

 Modelo tradicional de desarrollo de software

Modelo cascada
Métodos Tradicionales vs. Métodos Ágiles
Modelo Cascada:
• Las etapas de desarrollo de software deben cumplirse
una tras otra (en forma secuencial).
• Cada fase tiene como resultado documentos que
deben ser aprobados.
• Debido a que los retrocesos son costosos, se dejan
para su posterior resolución.
• El usuario no utiliza el software hasta que su
desarrollo cumpla con todas las etapas.
Métodos Tradicionales vs. Métodos Ágiles

¿Identificas algún inconveniente en ello?

Métodos Tradicionales vs. Métodos Ágiles

Definición de proceso

“Conjunto de actividades interrelacionadas o

interactivas que usan insumos para entregar un
resultado deseado.”
ISO 9001:2015

ENTRADA SALIDA
PROCESO
Métodos Tradicionales vs. Métodos Ágiles

¿El desarrollo de software es un proceso realmente?

NECESIDADES PRODUCTO DE
INGENIERÍA SOFTWARE
DE
SOFTWARE
Métodos Tradicionales vs. Métodos Ágiles

Fuente: https://www.tutorialspoint.com/agile/agile_primer.htm
Métodos Tradicionales vs. Métodos Ágiles

Framewoks o marcos ágiles

Métodos Tradicionales vs. Métodos Ágiles

Framewoks o marcos ágiles

Scrum: es un marco de trabajo utilizado para desarrollar,

entregar y mantener productos complejos, entre ellos el
software. Comprende roles, eventos y artefactos.
Métodos Tradicionales vs. Métodos Ágiles

Framewoks o marcos ágiles

Lean Software Development:
Metodología iterativa ágil cuyos Eliminate
waste

principios se basan en el See the Amplify

whole learning

movimiento de Lean Enterprise y en

las prácticas de la cía. Toyota. Pone Lean
principles Decide as
Build
en el foco del equipo la entrega de integrity in
late as
possible

valor al cliente y en la eficiencia del Deliver as

“Value Stream” (flujo de valor) y en

Empower
fast as
the team
possible

los mecanismos que entregan valor.

Métodos Tradicionales vs. Métodos Ágiles

Framewoks o marcos ágiles

El método Kanban: Provee un método simple y fácil
de implementar a través de cartas o tickets, con énfasis
en la entrega continua de valor sin sobrecargar al
equipo, para lo cual limita el trabajo en progreso.
Métodos Tradicionales vs. Métodos Ágiles

Framewoks o marcos ágiles

Extreme Programming (XP): Propone un desarrollo de
software enfocado en la excelente aplicación de técnicas
de programación, clara comunicación, alta participación
del cliente y trabajo en equipo.

Fuente: Beck K., Extreme Programming Explained, Figure 3

El “Manifiesto Ágil”
Manifiesto por el
Desarrollo Ágil de Software

Valoramos
Individuos e interacciones
Software funcionando
Colaboración con el cliente
Respuesta ante el cambio
sobre
procesos y herramientas
documentación extensiva
negociación contractual
seguir un plan
12 Principios del Manifiesto Ágil

Ver video

Una descripción gráfica y detallada de los 12 principios

del Manifiesto Ágil.
https://www.youtube.com/watch?v=V5LaKpjcgKQ&t=90s
Dinámica: Armando el árbol ágil
Principios "lean" del desarrollo de
producto/servicio
El pensamiento lean tiene sus orígenes en la producción,
pero los principios lean son ampliamente aplicables a
otras disciplinas.
Eliminate
waste

See the Amplify

whole learning

Lean
Build principles Decide as
integrity late as
in possible

Deliver as
Empower
fast as
the team
possible
Principios "lean" del desarrollo de
producto/servicio
1. Eliminate waste (Eliminar el desperdicio)

Desperdicio es cualquier cosa que no agrega valor a un

producto, desde la perspectiva del cliente, ejemplo:
más funciones desarrolladas de las que se necesitan
inmediatamente.
Se busca ofrecer al cliente lo que realmente quiere de
manera inmediata. Cualquier cosa que se interponga
para satisfacer las necesidades del cliente se considera
desperdicio.
Principios "lean" del desarrollo de
producto/servicio
2. Amplify learning (Amplifica el aprendizaje)

Se debe tener presente que el desarrollo es bastante

diferente a la producción.
El desarrollo es un ejercicio de descubrimiento. Se
espera que se produzcan varias variaciones sobre algo
como parte del proceso de aprendizaje el cual es
continuo y que involucra prueba y error.
El mejor enfoque para mejorar un entorno de desarrollo
es amplificar el aprendizaje hacia todos los miembros
del equipo.
Principios "lean" del desarrollo de
producto/servicio
3. Decide as late as possible (Decida lo más tarde
posible)

Poder contar con opciones frente a la incertidumbre es

más valioso que comprometerse en forma temprana.
Retrasar las decisiones es de gran utilidad ya que no se
basa en especulaciones sino en hechos.
Una estrategia clave para lograr retrasar los
compromisos mientras se construye un sistema
complejo es crear una capacidad de cambio en el
sistema.
Principios "lean" del desarrollo de
producto/servicio
4. Deliver as fast as possible (Entregue lo más
rápido posible)

En desarrollo, el ciclo de descubrimiento es

fundamental para el aprendizaje: diseñar, implementar,
retroalimentar, mejorar. Cuanto más cortos son estos
ciclos, más se puede aprender. La velocidad ​asegura
que los clientes obtengan lo que necesitan ahora, no lo
que necesitaban ayer. Les permite demorarse en
decidir lo que realmente quieren hasta que sepan más.
Comprimir el flujo de valor es una estrategia
fundamental para eliminar el desperdicio.
Principios "lean" del desarrollo de
producto/servicio
5. Empower the team (Empoderar al equipo)

Las personas que hacen el trabajo son los que

realmente conocen los detalles. Involucrar a los
desarrolladores en los detalles de las decisiones
técnicas es fundamental para lograr la excelencia. Con
la experiencia necesaria y guiados por un líder,
tomarán mejores decisiones técnicas y de proceso.
Lean se apoya en técnicas pull para programar el
trabajo y así entregar versiones cada vez más refinadas
de software funcionando a intervalos regulares.
Contienen mecanismos de señalización locales para
informarse sobre lo que se debe hacer.
Principios "lean" del desarrollo de
producto/servicio
6. Build integrity in (Integre la integridad)

La integridad conceptual significa que los conceptos

centrales del sistema funcionan juntos como un todo
sin fisuras y cohesivo, y es un factor crítico en la
creación de la integridad percibida (“Es exactamente
lo que quiero”). El software requiere un nivel adicional
de integridad; debe mantener su utilidad a lo largo del
tiempo. El software con integridad tiene una
arquitectura coherente, alta usabilidad y idoneidad
para el propósito, y es mantenible, adaptable y
extensible.
Principios "lean" del desarrollo de
producto/servicio
7. See the whole (Ver todo)

La integridad en sistemas complejos requiere una

profunda experiencia en áreas diversas. Uno de los
problemas más difíciles de resolver con el desarrollo
de productos es que los expertos de área (por ejemplo,
base de datos o GUI) tienden a maximizar rendimiento
de la parte del producto que representa su propia
especialidad en lugar de centrarse en el rendimiento
general del sistema. Cuando los individuos u
organizaciones se miden en su contribución
especializada en lugar del rendimiento general, es
probable que se produzca una suboptimización.
El Producto Mínimo Viable (MVP)

Fuente: http://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp#more-7646
El Producto Mínimo Viable (MVP)

• Es lo mínimo ofrecido al cliente que hará que pruebe

las cosas y nos dé su opinión.

• La entrega iterativa e incremental sin retroalimentación

es arriesgado y no ágil.

• Pregunta clave: ¿Cuál es la forma más económica y

rápida en que podemos empezar a aprender?
(…)
El método MoSCoW
Es una técnica de priorización utilizada en gestión y análisis de negocios.

Must have Son los requisitos críticos y obligatorios.

(Debe tener) Es lo mínimo utilizable.

Should have Son requisitos importantes pero no necesarios para la

(Debería tener) entrega actual. Pueden postergarse.

Could have Son requisitos deseables pero no necesarios.

(Podría tener) Pueden mejorar la experiencia del usuario o satisfacción del
cliente pero con un pequeño costo adicional.
Se incluyen si el tiempo y los recursos lo permiten.

Won't have (this time) Requisitos menos críticos o de menor retorno de la inversión.
No tendrá (esta vez) No son apropiados por el momento.
Dinámica: Definiendo el MVP
¿Preguntas?
Bibliografía
Beck, Grenning, Martin et al. (2001) Manifiesto por el Desarrollo Ágil de Software
(Angel Medinilla, Andrés Giné y Esther Gómez, trad.),
En: http://agilemanifesto.org/iso/es/manifesto.html

Beck, Grenning, Martin et al. (2001) Principios del Manifiesto Ágil (Angel Medinilla,
Andrés Giné y Esther Gómez, trad.),
En: http://agilemanifesto.org/iso/es/principles.html

Pablo Tortorella (2013) Kleer - Principios Ágiles (by @pablitux), En:

https://www.youtube.com/watch?v=V5LaKpjcgKQ&t=90s

Anderson D. (2010) Kanban: Successful Evolutionary Change for Your Technology

Business.

Beck K. & Andres C. (2005) Extreme Programming Explained: embrace change.

Poppendieck M. & Poppendieck T. (2003) Lean Software Development An Agile

Toolkit.
Bibliografía
Henrik Kniberg (2016) Making sense of MVP (Minimum Viable Product) – and why I
prefer Earliest Testable/Usable/Lovable, En:
http://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp#more-7646

Wikipedia (2017) MoSCoW method, En:

https://en.wikipedia.org/wiki/MoSCoW_method
Requisitos para la siguiente clase
 Leer la Guía de Scrum y otros materiales en el AV.

 Leer el material MTA.

 Resolver los foros individuales.

Retrospectiva

Retrospectiva seleccionada
por el docente.
GRACIAS