Este documento proporciona una introducción al marco ágil Scrum. Explica que Scrum es una metodología ágil para la gestión de proyectos que se basa en iteraciones cortas llamadas "sprints". Describe los principales roles en Scrum como el Propietario del Producto, el Scrum Master y el Equipo, y las prácticas clave como la planificación y revisión de sprints. También cubre conceptos como el Product Backlog y los incrementos de producto.
Este documento proporciona una introducción a los conceptos de agilidad, metodologías ágiles como SCRUM y sus principios y procesos. Explica que SCRUM es un marco de trabajo iterativo e incremental que permite entregar valor al cliente de forma continua a través de iteraciones cortas. Los roles clave de SCRUM son el Product Owner, quien maximiza el valor del producto, el Scrum Master, que guía el proceso, y el Equipo Scrum, que es auto-organizado y responsable del desarrollo.
La metodología Scrum es un enfoque ágil para el desarrollo de software que se basa en iteraciones cortas, equipos auto-organizados y entregas frecuentes de funcionalidad al cliente. Scrum utiliza sprints, reuniones diarias y una lista de producto para priorizar los requisitos y entregar valor al cliente de forma incremental.
Este documento introduce el marco de trabajo Scrum para el desarrollo ágil de software. Describe Scrum como un modelo iterativo e incremental para gestionar equipos de desarrollo auto-organizados. Los componentes clave de Scrum incluyen roles como el Product Owner, Scrum Master y el Equipo Scrum, así como artefactos como el Backlog del Producto y las historias de usuario. Scrum promueve el desarrollo adaptativo de software a través de iteraciones cortas llamadas sprints.
Este documento introduce Scrum, una metodología ágil para el desarrollo de software. Explica los problemas comunes en proyectos de software tradicionales y cómo las metodologías ágiles como Scrum intentan abordarlos a través de enfoques iterativos e incrementales que ponen énfasis en la colaboración del equipo y la satisfacción del cliente. Luego describe los roles, artefactos y eventos clave de Scrum como el Product Owner, el Sprint Planning Meeting y el Sprint Review.
Scrum es una metodología ágil para el desarrollo de software que se basa en iteraciones cortas llamadas sprints para entregar valor al cliente de forma incremental. Los sprints, que duran menos de un mes, dividen el trabajo en tareas que son planificadas y revisadas en reuniones. El objetivo es mejorar la comunicación dentro del equipo, responder rápido al cambio y entregar software funcionando frecuentemente.
Metodología, roles, actividades y artefactos que componen el modelo de proceso ágil SCRUM en el desarrollo de software y cómo lleva a maximizar el retorno de la inversión en la empresa (ROI).
El documento describe los principios, aspectos y procesos de SCRUM. SCRUM es un marco de trabajo ágil para la gestión de proyectos que se basa en iteraciones cortas, inspección y adaptación continua. Los principios centrales de SCRUM incluyen el control de proceso empírico, la auto-organización y la colaboración.
Este documento proporciona una introducción al marco ágil Scrum. Explica que Scrum es una metodología ágil para la gestión de proyectos que se basa en iteraciones cortas llamadas "sprints". Describe los principales roles en Scrum como el Propietario del Producto, el Scrum Master y el Equipo, y las prácticas clave como la planificación y revisión de sprints. También cubre conceptos como el Product Backlog y los incrementos de producto.
Este documento proporciona una introducción a los conceptos de agilidad, metodologías ágiles como SCRUM y sus principios y procesos. Explica que SCRUM es un marco de trabajo iterativo e incremental que permite entregar valor al cliente de forma continua a través de iteraciones cortas. Los roles clave de SCRUM son el Product Owner, quien maximiza el valor del producto, el Scrum Master, que guía el proceso, y el Equipo Scrum, que es auto-organizado y responsable del desarrollo.
La metodología Scrum es un enfoque ágil para el desarrollo de software que se basa en iteraciones cortas, equipos auto-organizados y entregas frecuentes de funcionalidad al cliente. Scrum utiliza sprints, reuniones diarias y una lista de producto para priorizar los requisitos y entregar valor al cliente de forma incremental.
Este documento introduce el marco de trabajo Scrum para el desarrollo ágil de software. Describe Scrum como un modelo iterativo e incremental para gestionar equipos de desarrollo auto-organizados. Los componentes clave de Scrum incluyen roles como el Product Owner, Scrum Master y el Equipo Scrum, así como artefactos como el Backlog del Producto y las historias de usuario. Scrum promueve el desarrollo adaptativo de software a través de iteraciones cortas llamadas sprints.
Este documento introduce Scrum, una metodología ágil para el desarrollo de software. Explica los problemas comunes en proyectos de software tradicionales y cómo las metodologías ágiles como Scrum intentan abordarlos a través de enfoques iterativos e incrementales que ponen énfasis en la colaboración del equipo y la satisfacción del cliente. Luego describe los roles, artefactos y eventos clave de Scrum como el Product Owner, el Sprint Planning Meeting y el Sprint Review.
Scrum es una metodología ágil para el desarrollo de software que se basa en iteraciones cortas llamadas sprints para entregar valor al cliente de forma incremental. Los sprints, que duran menos de un mes, dividen el trabajo en tareas que son planificadas y revisadas en reuniones. El objetivo es mejorar la comunicación dentro del equipo, responder rápido al cambio y entregar software funcionando frecuentemente.
Metodología, roles, actividades y artefactos que componen el modelo de proceso ágil SCRUM en el desarrollo de software y cómo lleva a maximizar el retorno de la inversión en la empresa (ROI).
El documento describe los principios, aspectos y procesos de SCRUM. SCRUM es un marco de trabajo ágil para la gestión de proyectos que se basa en iteraciones cortas, inspección y adaptación continua. Los principios centrales de SCRUM incluyen el control de proceso empírico, la auto-organización y la colaboración.
Proyecto de la asignatura convergencia tecnologicaNicole Escamilla
Las metodologías ágiles como Scrum se basan en ciclos iterativos cortos para el desarrollo de software, promoviendo el trabajo en equipo, la adaptación continua a cambios de requisitos y la entrega frecuente de software funcional. Scrum utiliza sprints de 30 días, reuniones diarias y roles como Product Owner y Scrum Master para gestionar eficientemente los proyectos y satisfacer al cliente.
El documento describe varias metodologías para el desarrollo de proyectos de software, incluyendo metodologías ágiles y tradicionales. Explica que las metodologías ágiles valoran la interacción entre individuos, entregas funcionales rápidas y respuesta al cambio, mientras que las metodologías tradicionales se enfocan más en la planificación y documentación. También describe dos metodologías ágiles específicas: Scrum, la cual se basa en iteraciones cortas llamadas sprints, y eXtreme Programming, c
Curso introducción a Scrum, unión de diversas experiencias, wiki y otros cursos para conocer en detalle la metodología Scrum.
- Donde se ubica Scrum dentro de las metodologías agiles
- ¿Qué es Scrum?
- Roles en scrum
- Procesos en Scrum
- Ceremonias
SCRUM es una metodología ágil para el desarrollo de software que se basa en iteraciones cortas llamadas sprints para entregar funcionalidades al cliente de forma incremental. Los componentes clave de SCRUM son los roles de product owner, scrum master y scrum team, así como las reuniones de planificación, seguimiento y revisión que se realizan en cada sprint.
Este documento presenta la composición de un equipo Scrum y describe conceptos clave de la metodología ágil Scrum como sprints, artefactos, eventos y roles. En particular, destaca la importancia de entregas frecuentes de software, la colaboración entre equipos multidisciplinarios y la capacidad de respuesta al cambio.
Una presentación del marco de trabajo de Scrum. Apunta a establecer en breves imágenes los roles, procesos y artefactos necesarios para la agilidad de proyectos de desarrollo de software o tecnologías de información.
El documento describe las metodologías ágiles de desarrollo de software, incluyendo el Manifiesto Ágil, métodos como Scrum y Kanban, y ventajas como la adaptación al cambio y el trabajo en equipo. Explica que Scrum es una metodología ágil basada en iteraciones cortas llamadas sprints, con eventos como la planificación del sprint y la revisión del sprint para revisar el progreso.
El documento presenta la agenda de un curso de desarrollo web que incluye la presentación del profesor Oscar Caicedo, las reglas del curso como la comunicación entre estudiantes y profesor, y la metodología ABP y Scrum que se utilizará. El curso se dividirá en sprints semanales donde los estudiantes trabajarán en equipo en la creación de una aplicación web siguiendo las historias de usuario y entregando incrementos al final de cada sprint.
La ingeniería de software ágil combina una filosofía y lineamientos de desarrollo que enfatizan la satisfacción del cliente, entregas incrementales rápidas, equipos pequeños y motivados, y simplicidad general en el desarrollo. Algunas metodologías ágiles populares son Scrum y eXtreme Programming (XP), las cuales se basan en valores como comunicación, retroalimentación y coraje.
Este documento proporciona una introducción a Scrum, un marco ágil para el desarrollo de software. Explica que Scrum utiliza un enfoque iterativo e incremental para permitir que equipos auto-organizados creen software. Describe los roles clave, componentes y ventajas de Scrum, como la entrega frecuente de funcionalidad, la capacidad de adaptarse a cambios y la colaboración entre el equipo y el cliente.
Este documento resume los fundamentos de Scrum. Explica brevemente qué es la agilidad y Scrum, y describe los principios, aspectos y procesos de Scrum, incluyendo el flujo general de Scrum con fases como inicio, planeación, implementación y revisión.
Metodología scrum-Ingeniería de Software 2Germán Aguilar
Este documento describe la metodología SCRUM, una de las más conocidas metodologías ágiles para la gestión de proyectos. SCRUM se basa en iteraciones cortas llamadas "sprints" para entregar versiones funcionales del producto de forma incremental. Ofrece beneficios como la satisfacción del cliente, la adaptación a cambios, una mayor productividad y calidad del software. Define roles clave como el Product Owner, ScrumMaster y el equipo de desarrollo.
Este documento describe Scrum, un marco de trabajo ágil para el desarrollo de software. Explica los principios, roles, artefactos y eventos de Scrum. Los principios incluyen control de proceso empírico, auto-organización, colaboración, priorización basada en valor, tiempo definido y desarrollo iterativo. Los roles son el propietario del producto, scrum master y equipo scrum. Los artefactos son el product backlog, sprint backlog y burndown chart. Los eventos son sprint, sprint planning, daily scrum, sprint review y
Describe la metodologia de trabajo en latino america
es un marco de gestión de proyectos de metodología ágil que ayuda a los equipos a estructurar y gestionar el trabajo mediante un conjunto de valores, principios y prácticas.
Este documento presenta los conceptos y principios de la gestión ágil de proyectos. Explica brevemente el método tradicional en cascada y contrasta con el enfoque ágil. Luego describe los principios del Manifiesto Ágil y los roles, artefactos y eventos clave de Scrum, una de las metodologías ágiles más populares. Finalmente, menciona otras metodologías ágiles y algunas malas prácticas a evitar.
La presentación cubre:
-Pequeño repaso sobre el desarrollo de software siguiendo la metodología waterfall
Agile y Lean Startup
- Los pilares de Scrum;
---- Roles: Product Owner, Scrum Master y Equipo de Desarrollo.
---- Eventos: Planning Meeting, Daily Stand-up, Grooming/Refinement, Demo y Retrospectiva.
---- Herramientas: Product Backlog, Historias de usuario, Definition of Done, Sprint Backlog, Sprint Dashboad.
---- Informes: Fin de Sprint, Inicio de Sprint, Burn-up/Burn-down, Informe de producto.
Este documento proporciona una introducción a la metodología Scrum para el desarrollo de software. Explica que Scrum es un proceso ágil que se basa en iteraciones cortas llamadas sprints para entregar incrementos de valor al cliente. Describe los principales roles como el Product Owner, el Scrum Master y el equipo de desarrollo, y las actividades clave como las reuniones diarias y las reuniones de revisión. También resume algunas ventajas y desventajas de Scrum.
Qué es SCRUM
Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, 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.
Proyecto de la asignatura convergencia tecnologicaNicole Escamilla
Las metodologías ágiles como Scrum se basan en ciclos iterativos cortos para el desarrollo de software, promoviendo el trabajo en equipo, la adaptación continua a cambios de requisitos y la entrega frecuente de software funcional. Scrum utiliza sprints de 30 días, reuniones diarias y roles como Product Owner y Scrum Master para gestionar eficientemente los proyectos y satisfacer al cliente.
El documento describe varias metodologías para el desarrollo de proyectos de software, incluyendo metodologías ágiles y tradicionales. Explica que las metodologías ágiles valoran la interacción entre individuos, entregas funcionales rápidas y respuesta al cambio, mientras que las metodologías tradicionales se enfocan más en la planificación y documentación. También describe dos metodologías ágiles específicas: Scrum, la cual se basa en iteraciones cortas llamadas sprints, y eXtreme Programming, c
Curso introducción a Scrum, unión de diversas experiencias, wiki y otros cursos para conocer en detalle la metodología Scrum.
- Donde se ubica Scrum dentro de las metodologías agiles
- ¿Qué es Scrum?
- Roles en scrum
- Procesos en Scrum
- Ceremonias
SCRUM es una metodología ágil para el desarrollo de software que se basa en iteraciones cortas llamadas sprints para entregar funcionalidades al cliente de forma incremental. Los componentes clave de SCRUM son los roles de product owner, scrum master y scrum team, así como las reuniones de planificación, seguimiento y revisión que se realizan en cada sprint.
Este documento presenta la composición de un equipo Scrum y describe conceptos clave de la metodología ágil Scrum como sprints, artefactos, eventos y roles. En particular, destaca la importancia de entregas frecuentes de software, la colaboración entre equipos multidisciplinarios y la capacidad de respuesta al cambio.
Una presentación del marco de trabajo de Scrum. Apunta a establecer en breves imágenes los roles, procesos y artefactos necesarios para la agilidad de proyectos de desarrollo de software o tecnologías de información.
El documento describe las metodologías ágiles de desarrollo de software, incluyendo el Manifiesto Ágil, métodos como Scrum y Kanban, y ventajas como la adaptación al cambio y el trabajo en equipo. Explica que Scrum es una metodología ágil basada en iteraciones cortas llamadas sprints, con eventos como la planificación del sprint y la revisión del sprint para revisar el progreso.
El documento presenta la agenda de un curso de desarrollo web que incluye la presentación del profesor Oscar Caicedo, las reglas del curso como la comunicación entre estudiantes y profesor, y la metodología ABP y Scrum que se utilizará. El curso se dividirá en sprints semanales donde los estudiantes trabajarán en equipo en la creación de una aplicación web siguiendo las historias de usuario y entregando incrementos al final de cada sprint.
La ingeniería de software ágil combina una filosofía y lineamientos de desarrollo que enfatizan la satisfacción del cliente, entregas incrementales rápidas, equipos pequeños y motivados, y simplicidad general en el desarrollo. Algunas metodologías ágiles populares son Scrum y eXtreme Programming (XP), las cuales se basan en valores como comunicación, retroalimentación y coraje.
Este documento proporciona una introducción a Scrum, un marco ágil para el desarrollo de software. Explica que Scrum utiliza un enfoque iterativo e incremental para permitir que equipos auto-organizados creen software. Describe los roles clave, componentes y ventajas de Scrum, como la entrega frecuente de funcionalidad, la capacidad de adaptarse a cambios y la colaboración entre el equipo y el cliente.
Este documento resume los fundamentos de Scrum. Explica brevemente qué es la agilidad y Scrum, y describe los principios, aspectos y procesos de Scrum, incluyendo el flujo general de Scrum con fases como inicio, planeación, implementación y revisión.
Metodología scrum-Ingeniería de Software 2Germán Aguilar
Este documento describe la metodología SCRUM, una de las más conocidas metodologías ágiles para la gestión de proyectos. SCRUM se basa en iteraciones cortas llamadas "sprints" para entregar versiones funcionales del producto de forma incremental. Ofrece beneficios como la satisfacción del cliente, la adaptación a cambios, una mayor productividad y calidad del software. Define roles clave como el Product Owner, ScrumMaster y el equipo de desarrollo.
Este documento describe Scrum, un marco de trabajo ágil para el desarrollo de software. Explica los principios, roles, artefactos y eventos de Scrum. Los principios incluyen control de proceso empírico, auto-organización, colaboración, priorización basada en valor, tiempo definido y desarrollo iterativo. Los roles son el propietario del producto, scrum master y equipo scrum. Los artefactos son el product backlog, sprint backlog y burndown chart. Los eventos son sprint, sprint planning, daily scrum, sprint review y
Describe la metodologia de trabajo en latino america
es un marco de gestión de proyectos de metodología ágil que ayuda a los equipos a estructurar y gestionar el trabajo mediante un conjunto de valores, principios y prácticas.
Este documento presenta los conceptos y principios de la gestión ágil de proyectos. Explica brevemente el método tradicional en cascada y contrasta con el enfoque ágil. Luego describe los principios del Manifiesto Ágil y los roles, artefactos y eventos clave de Scrum, una de las metodologías ágiles más populares. Finalmente, menciona otras metodologías ágiles y algunas malas prácticas a evitar.
La presentación cubre:
-Pequeño repaso sobre el desarrollo de software siguiendo la metodología waterfall
Agile y Lean Startup
- Los pilares de Scrum;
---- Roles: Product Owner, Scrum Master y Equipo de Desarrollo.
---- Eventos: Planning Meeting, Daily Stand-up, Grooming/Refinement, Demo y Retrospectiva.
---- Herramientas: Product Backlog, Historias de usuario, Definition of Done, Sprint Backlog, Sprint Dashboad.
---- Informes: Fin de Sprint, Inicio de Sprint, Burn-up/Burn-down, Informe de producto.
Este documento proporciona una introducción a la metodología Scrum para el desarrollo de software. Explica que Scrum es un proceso ágil que se basa en iteraciones cortas llamadas sprints para entregar incrementos de valor al cliente. Describe los principales roles como el Product Owner, el Scrum Master y el equipo de desarrollo, y las actividades clave como las reuniones diarias y las reuniones de revisión. También resume algunas ventajas y desventajas de Scrum.
Qué es SCRUM
Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, 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.
Los puentes son estructuras esenciales en la infraestructura de transporte, permitiendo la conexión entre diferentes
puntos geográficos y facilitando el flujo de bienes y personas.
Estilo Arquitectónico Ecléctico e Histórico, Roberto de la Roche.pdfElisaLen4
Un pequeño resumen de lo que fue el estilo arquitectónico Ecléctico, así como el estilo arquitectónico histórico, sus características, arquitectos reconocidos y edificaciones referenciales de dichas épocas.
2. Indice
Temario
(1)
Introducción. ¿Cómo surge?. Metodologías ágiles.
Lean SDLC. ¿Cuando un método es ágil?. Diferencias
entre metodologías.
(4)
Prácticas para la gestión del proyecto y del producto.
(2)
Introducción a SCRUM.
Principios. Características.
(5)
Conclusiones. Plataforma requerida. Fortalezas de
SCRUM. Reflexiones.
(3)
Practica SCRUM
Propietario del Producto. El Scrum Master. El Equipo.
Interdependencias de los roles. Historias de usuario.
Product Backlog. Sprint. Planificación del Sprint.
Estimación de póquer. Ejecución del Sprint. Fin del
sprint: Sprint review. Sprint retrospective. Daily Scrum
(Comenzar / Parar / Continuar). Incremento
(6)
Caso practico
3. • Requerimientos fuera de control
• No cumplimiento de los tiempos planificados (desvíos)
• Estimaciones deficientes
• Re trabajo excesivo
• Baja calidad
• Costos excedidos
• Insatisfacción del Cliente
• Insatisfacción de los profesionales participantes
¿Cómo surge?
4. ¿Cuando un método es ágil?
• Simple pero duro. No se basa en el seguimiento de un plan
sino en la adaptación continua a la evolución del proyecto.
El desarrollo de software es:
– Incremental
• liberaciones pequeñas y ciclos rápidos.
– Cooperativo
• clientes y desarrolladores trabajando juntos.
– Simple y Directo
• el método es fácil de aprender y modificar.
– Adaptativo
• es posible realizar cambios de último momento.
5. Diferencias entre metodologías
Metodologías Ágiles
• Basadas en heurísticas
provenientes de prácticas de
producción de código
• Especialmente preparados
para cambios durante el
proyecto
• Impuestas internamente (por
el equipo)
• Proceso mucho más
controlado, con numerosas
políticas/normas
• No existe contrato tradicional
o al menos es bastante flexible
Metodologías tradicionales
• Basadas en normas
provenientes de estándares
• Seguidos por el entorno de
desarrollo
• Cierta resistencia a los
cambios
• Impuestas externamente
• Proceso menos controlado,
con pocos principios
• Existe un contrato prefijado
6. • El cliente interactúa con el
equipo de desarrollo
• Grupos pequeños (<10
integrantes) y trabajando en el
mismo sitio
• Pocos artefactos
• Pocos roles
• Menos énfasis en la
arquitectura del software
• El cliente es parte del equipo
de desarrollo mediante
reuniones
• Grupos grandes y
posiblemente distribuidos
• Más artefactos
• Más roles
• La arquitectura del software
es esencial y se expresa
mediante modelos
Metodologías Ágiles Metodologías tradicionales
8. Introducción a SCRUM
• La palabra SCRUM procede del vocabulario del rugby y significa melé; es
decir, que los compañeros del equipo se amontonan, forman una piña y
empujan todos en la misma dirección.
• SCRUM es una estrategia de gestión donde se aplican de manera regular
un conjunto de prácticas para mejorar el trabajo colaborativo y obtener el
mejor resultado posible en la gestión de un proyecto software.
9.
10. • Scrum es un proceso ágil que nos permite centrarnos
en ofrecer el más alto valor de negocio en el menor
tiempo.
• Nos permite rápidamente y en repetidas ocasiones
inspeccionar software real de trabajo (cada dos
semanas o un mes).
• El negocio fija las prioridades. Los equipos se auto-
organizan a fin de determinar la mejor manera de
entregar las funcionalidades de más alta prioridad.
• Cada dos semanas o un mes, cualquiera puede ver el
software real funcionando y decidir si liberarlo o seguir
mejorandolo en otro sprint.
Scrum en 100 palabras
11. • El Manifesto Ágil – una declaración de valores. Aunque los elementos a la derecha tienen
valor, nosotros valoramos por encima de ellos los que están a la izquierda.
Fuente: www.agilemanifesto.org
Individuos e
iteraciones
Sobre Procesos y herramientas
Software funcionando Sobre Documentacion
extensiva
Colaboracion con el
cliente
Sobre Negociación contractual
Respuesta ante el
cambio
Sobre Seguir un plan
12. – Al individuo y las interacciones del equipo de desarrollo sobre el
proceso y las herramientas.
• Es más importante construir un buen equipo.
– Desarrollar software que funciona más que conseguir una buena
documentación.
• No producir documentos a menos que sean necesarios de forma inmediata para tomar un decisión importante.
– La colaboración con el cliente más que la negociación de un contrato.
• Se propone que exista una interacción constante entre el cliente y el equipo de desarrollo. Esta colaboración
entre ambos será la que marque la marcha del proyecto y asegure su éxito.
– Responder a los cambios más que seguir estrictamente un plan.
• Se debe ser hábil en responder a los cambios y a los fracasos, la planificación no debe ser estricta sino flexible y
abierta.
13. • Scrum es un proceso iterativo e incremental que puede ser utilizado para
desarrollar cualquier producto o administrar cualquier trabajo. Sus
principales atributos son:
– Un enfoque orientado a que los equipos desarrollen productos de manera
iterativa e incremental cuando los requerimientos cambian de manera rápida
– Un proceso que controla el caos de conflictos de intereses y necesidades
– Una manera de mejorar las comunicaciones y maximizar la cooperación
– Una manera de maximizar la productividad
– Escalable a múltiples proyectos y la organización
– Una forma que todos se sientan bien con su trabajo,
entendiendo que cada uno con sus contribuciones
hizo lo mejor que podía hacer
14. En lugar de hacer todo
de una cosa a la vez ...
...los equipos Scrum
hacen un poco de todo
todo el tiempo
Requisitos Diseño Código Test
• Desarrollo secuencial vs. superpuesto
15. Principios
• Nuestra mayor prioridad es satisfacer al cliente a través de la entrega temprana y continua de
software con valor.
• Aceptamos requisitos cambiantes, incluso en etapas avanzadas.
• Entregamos software frecuentemente.
• Los responsables de negocio y los desarrolladores deben trabajar juntos permanentemente.
• Construimos proyectos con profesionales motivados.
• Conversación cara a cara.
• Software que funciona es la principal medida de progreso.
• Los procesos ágiles promueven el desarrollo sostenible.
• La atención continua a la excelencia técnica y los buenos diseños
mejoran la agilidad.
• Simplicidad es esencial.
• Las mejores arquitecturas, requisitos y diseños surgen de
equipos que se auto-organizan.
• A intervalos regulares el equipo reflexiona sobre cómo ser más
efectivo.
16. Características
• Equipos auto-organizados
• El producto progresa en una serie de “sprints” que duran un mes
• Los requerimientos se encuentran en el “product backlog” reunidos en una lista
• No contiene practicas de ingeniería pre-descriptas
• Utiliza reglas generales para crear un ambiente ágil para la liberación de los proyectos
• Usado para proyectos complejos con requerimientos cambiantes
• Basado en un control de proceso empírico
• No hay prácticas de ingeniería prescritas
• Metodología de trabajo ágil
• Diseñada para acortar el ciclo de desarrollo
• Conseguir una mejor aproximación entre las funcionalidades del software y los requerimientos del cliente
• Evitar la burocracia innecesaria
• Mayor versatilidad frente a los cambios
• Comenzar el trabajo lo más rápidamente posible
• Manejo más eficiente de los requerimientos cambiantes en un proyecto
• Mejorar la comunicación entre el cliente y el equipo desarrollador
• No dice Qué hacer sino Cómo hay que hacer las cosas
17. • Trazabilidad
– Establece de forma precisa e inequívoca el seguimiento de un producto y/o servicio
durante todo su ciclo de vida.
– Formado por un conjunto de acciones, medidas y procedimientos técnicos que permite
identificar y registrar cada requerimiento de manera que se pueda seguir su ciclo de vidas
tanto para atrás, desde su origen, como hacia delante, en la entrega del producto.
– Toda la documentación, códigos y guiones de prueba deberán apuntar a su fuente de
origen para permitir saber en todo momento el origen, la implementación y las pruebas
que se hagan a cualquier requerimiento
– Bidireccional: A partir de un requisito se llega al código que lo implementa y a partir de
un determinado código saber el o los requisitos a los que corresponde.
– Vertical: Garantiza que todos los requerimientos serán diseñados y que todos los diseños
serán codificados y probados.
– Horizontal: Permite detectar si hay conflictos entre requerimientos, diseño, lógica de
codificación y/o casos de prueba
18. Practica SCRUM
• Scrum es una a practica de desarrollo muy simple, no se basa en el
seguimiento de un plan, sino en la adaptación continua a las circunstancias
de la evolución del proyecto.
Es un modo de
desarrollo de
carácter adaptable
más que predictivo.
Orientado a las
personas más que a
los procesos.
Emplea la
estructura de
desarrollo ágil
incremental basada
en iteraciones y
revisiones.
19. Cancel
Gift wrap
Return
Sprint
2-4 semanas
Objetivo del Sprint
Sprint
Backlog
Incremento del producto
potencialmente entregable
Product
Backlog
Daily Scrum
24 horas
Responsable del producto:
“Product Owner”
Responsables del
desarrollo: “Scrum Team”
Responsable del
funcionamiento de Scrum:
“ScrumMaster”
Roles
•Planificación del Sprint
•Seguimiento del Sprint
•Revisión del Sprint
•Scrum diario
Reuniones
•Product Backlog
•Sprint Backlog
•Incremento
•Graficos “Burndown”
Artefactos
Incremento en
el Producto
20.
21. Propietario del Producto
• Persona conocedora del entorno de negocio del cliente y de la visión del producto.
Representa a todos los interesados en el producto final. Sus responsabilidades son:
– Define las funcionalidades del producto
– Decide sobre las fechas y contenidos de los releases
– Es responsable por la rentabilidad del producto (ROI)
– Prioriza funcionalidades de acuerdo al valor del mercado/negocio
– Ajusta funcionalidades y prioridades en cada iteración si es necesario
– Acepta o rechaza los resultados del trabajo del equipo
– Financiación del proyecto
– Define funcionalidad requerida
– Retorno de la inversión del proyecto
– Lanzamiento del proyecto
– Representa a la gestión del proyecto
– Toma las decisiones de priorización
– Representa a todos los interesados en el producto final
22. El Scrum Master
• Sus responsabilidades son:
– Responsable de promover los valores y prácticas de Scrum
– Se asegura de que el equipo es completamente funcional y productivo
– Permite la estrecha cooperación en todos los roles y funciones
– Escudo del equipo de interferencias externas
– Garantiza el funcionamiento de los procesos y metodologías que se emplean. Formación y entrenamiento
de procesos.
– Incorporación de Scrum en la cultura del equipo
– Garantía de cumplimiento de roles y responsabilidades
– Remueve impedimentos. Facilitador.
– Es un role flexible:
• Dirección de la empresa, con el conocimiento de gestión y desarrollo ágil y facilitando los recursos necesarios
• Responsables del Departamento
• Responsables del área de gestión de proyectos
23. El Equipo
• Responsable de transformar la pila del sprint en un incremento de la
funcionalidad del software. Sus características son:
– Equipo multidisciplinar que cubre todas las habilidades necesarias para generar el
resultado
– Se auto-gestiona y auto-organiza
– Dispone de atribuciones suficientes para toma de decisiones sobre cómo realizar su
trabajo
– Típicamente de 5 a 9 personas
– Los miembros deben ser preferentemente full-time.
– Los equipos son Auto – gestionado y Auto – organizado
– Solo puede haber cambio de miembros entre los
sprints
– Transforman los requerimientos en funcionalidad en
cada incremento
24. Interdependencias de los roles
Interesados PO PM SM Equipo
>> Asegura que el proyecto cumple objetivos
>> Administra al equipo Auto-organizado
>> Administra el alcance y el presupuesto
>> Administra la comunicación entre involucrados
>> Gestiona riesgos y elimina obstáculos
>> Administra el proceso
>> Gestiona la visión Mejora continua
>> Investigación de mercado. Visión, Voz del Cliente
<< Asegura que el proyecto logra los objetivos
<< Negocia el trabajo con el equipo
<< Gestiona el alcance, cronograma, y presupuesto
<< Gestiona la comunicación con los interesados
>> Visualiza y distribuye información
>> Remueve impedimentos
25. • Otros roles:
– Propietario de la arquitectura: es el encargado de realizar las decisiones de la arquitectura para el
equipo.
– Especialista: en la mayoría d equipos agiles no existe especialistas, sin embargo en
– proyectos a gran escala es necesario de conocimientos específicos.
– Experto de dominio: es parte del equipo de trabajo del propietario del producto, el cual ayudara a
definir los requerimientos del sistema.
– Expertos técnicos: Son parte del equipo de manera temporal, los cuales ayudan a superar problemas
con altas dificultades, así mismo transfieren parte de sus habilidades a los desarrolladores.
– Tester independiente: En algunas ocasiones se utilizan equipos de pruebas independientes, para
ayudar a validar el trabajo realizado a lo largo del ciclo de vida.
– Integrador: es en el cargado de adaptar y construir todo el sistema desde los diversos subsistemas.
26. Historias de usuario
Historia de
Usuario (2)
Como <Tipo de
Usuario>, Quiero,
<Hacer algo>,
Para <Propósito>
Personas (1)
Personas, Usuarios
o consumidores
finales,
Interesados,
Patrocinadores,
Equipo de
desarrollo, Equipo
de soporte
Contexto (4)
Necesidad origen, Escenarios de uso de la historia, Dominio del
negocio, qué áreas del negocio usan o se impactan por la historia,
Reglas del negocio que afectan la historia, Épica origen. No todas las
historias provienen de una épica en particular pero si es así, es bueno
conocerla, Alcance de la historia
Definición de Preparado (5)
Que se debe cumplir para que la
historia se pueda construir?
Definición de Terminado (6)
Condiciones de Terminado
especificas a la historia
Criterios de
Aceptación (3)
Resultado Esperado (7)
Solución esperada, Que se
quiere cumplir con la
Historia?, Valor a ganar
Métricas (8)
Puntos, Esfuerzo, Numero de
iteraciones, Valor, Ganado, Calidad,
Progreso, Numero de usuarios
Retroalimentación (9)
Nivel o Grado de Satisfacción de las
personas, Nivel de Felicidad del usuario
Impacto generado, Qué hacer para mejorar
Importancia (10)
Desde el punto de vista del negocio. Definido por Dueño de Producto.
Categoría (12)
Categorización básica de la historia.
Estimación (11)
Valoración inicial del Equipo del esfuerzo necesario para implementar la historia, comparada con otras historias.
27. • El acrónimo INVEST para describir las características de una buena historia:
– Independiente: las historias pueden completarse en cualquier orden.
– Negociable: los detalles de la historia son co-creados por los programadores y los clientes
durante el desarrollo.
– Valiosa: la funcionalidad es valiosa para los clientes o los usuarios del software.
– Estimable: los pgoramadores pueden encontrar una estimación razonable para construir la
historia.
– Pequeña: las historias deberían construirse en poco tiempo, generalmente alrededor de
"días/persona". Se tienen que poder construir muchas historias en una iteración.
– Testeable: se debe poder escribir pruebas que verifiquen que el software de la historia
funcione adecuadamente.
• Una forma habitual de escribir las historias es "Como <rol>.... Quiero
<característica>... Para <valor>". La parte del "Como..." se refiere a la persona que
quiere la historia. La parte "Quiero..." describe la funcionalidad de la historia, y la
parte "Para..." describe el motivo por el cual se pide esa funcionalidad.
28. • Técnicas de priorización de historias de usuario:
– MoSCoW se basa únicamente en dividir las funcionalidades en cuatro grupos en función de su
prioridad. Es conveniente que el número de funcionalidades esté equilibrado en cada grupo.
MoSCoW es un pseudo-acrónimo formado por las cuatro categorías en las que se tienen que dividir
todas las funcionalidades:
• Must Have (Imprescindibles): son funcionalidades que deben ser incluidas antes de que el producto pueda ser
puesto en producción. En el contexto de gestión lean, se denomina Mínimo Producto Viable (MVP por sus
siglas en inglés) a aquel que contiene únicamente este conjunto de características. Sin alguna de ellas, el
producto no tendría sentido.
• Should Have (Importantes): son funcionalidades importantes y de gran valor para el usuario pero que no
impiden poner el proyecto en marcha si no se tienen. Obviamente, son las siguientes en la lista de prioridad y
deberían incluirse justo después de haber finalizado el Mínimo Producto Viable.
• Could Have o (Buenas): son funcionalidades que sería deseable tener y podrían incluirse en caso de que
hubiese recursos para ello. No obstante, en caso de que sea necesario, se podrían descartar.
• Won’t Have o (Excluidas): son funcionalidades que el cliente ha solicitado inicialmente pero que se descartan
por falta de recursos (tiempo, dinero, etc). Como la priorización debe realizarse de forma iterativa a lo largo del
proyecto, algunas de estas funcionalidades pueden considerarse en el futuro.
29. – Theme Scoring es una técnica que permite determinar la prioridad de las funcionalidades como una combinación de
diferentes criterios, a los que se puede dar diferente importancia. A cada historia de usuario se le asigna un peso de 1
a 5 en cada una de las características. Para ello, por cada característica se elige una historia de usuario de referencia,
que tenga un valor medio de 3. A las demás historias de usuario se les asigna el peso en cada característica en
comparación con la historia de usuario de referencia. La estimación de una característica por comparación es siempre
mucho más sencilla y rápida que la estimación de una medida absoluta.
– WSJF es una técnica que prioriza en función del valor, coste y riesgo equitativamente y de forma sencilla. Consiste en
sumar el valor al usuario, el valor de tiempo (necesidad de un plan B) y la reducción del riesgo que aporta la historia y
dividirlo por el tiempo que llevaría realizarla. Es un algoritmo optimizado económicamente para la priorización y
programación del trabajo en un ambiente en el que el coste de la demora y la duración de los elementos de trabajo
varían.
• WSJF = (Valor de Negocio/Usuario + Valor del Tiempo + Reducción de Riesgo & Valor de Oportunidad) / Tamaño
del trabajo
30. • Donde los anteriores significan…
– Valor de Negocio/Usuario: Es el valor que da la empresa o el usuario. Aquí también hay que incluir los
costes de penalización si los hubiera así como los ingresos. Para darle un valor podemos escoger una
escala de 1,2,3,5,8,13, siendo 1 lo más bajo y 10 lo más alto.
– Valor de tiempo: En esta medida, lo que intentamos medir es la necesidad de un “plan B” por si las
cosas salen mal, ya sea por la pérdida de contratos, clientes o ingresos. Podemos usar la misma escala
de antes, en la que 1 sea una necesidad baja de este plan b, y el 13 una necesidad total el tenerlo.
– Reducción de Riesgo & Valor de Oportunidad: En esta parte damos un valor a la necesidad de la
empresa de reducir riesgos o el potencial de las nuevas oportunidades de negocio que se derivan del
trabajo actual. Como antes, usaremos la misma escala.
– Tamaño del trabajo: Estimación del tiempo necesario para poner una nueva característica o función del
producto en producción. Podemos usar como antes la misma escala, o tomar una que sea en semanas,
por ejemplo.
– El resultado que nos de la fórmula con los datos anteriores nos prioriza las tareas, pasando a hacer
primero las de un valor más alto.
31. Product Backlog
• Listado con los requisitos del sistema. Una lista de todos los trabajos deseados en el proyecto
– Priorizadas
– Documento "vivo"
– Accesible a todos los roles
– Todos pueden contribuir y aportar elementos
– El propietario del producto es su responsable:
• Representa los intereses del cliente dentro de la empresa.
• Es el nexo entre el cliente y el equipo.
• Tiene la visión global del producto buscado.
• Es el encargado de armar y priorizar el Product Backlog (Lista priorizada de
requerimientos).
• Cada tema tiene valor para el usuarios o el cliente (desde el punto de vista del
negocio)
• Repriorizada al comienzo de cada Sprint
• Es dinámico.
• Mientras exista un producto, el Product Backlog también existe.
32. Pila de producto
-- Requisitos priorizados.
-- Listado con los requisitos
del sistema.
Selección de la
Pila de producto
(Product Backlog)
-- Funcionalidades
Pila del sprint Nueva
funcionalidad
• Product Owner
(modificar cuidando la
inversión).
• Stakeholders (usuario,
soporte técnico,
administradores,etc )
33. Sprint
• Cada iteración se llama sprint y se realiza una revisión de los requisitos con todas las personas
involucradas en el proyecto
• Dentro de cada sprint, SCRUM gestiona la evolución del proyecto mediante reuniones breves
de seguimiento en las que se revisa el trabajo realizado desde el hito anterior y los planes para
el hito siguiente
• Las reuniones de seguimiento de cada sprint deben ser diarias
• La duración típica es 2–4 semanas o a lo sumo un mes calendario
• La duración constante conduce a un mejor ritmo
• El producto es diseñado, codificado y probado en el Sprint
• No hay cambios en un sprint. Planee la duración del sprint en
torno a cuánto tiempo usted puede comprometerse a
mantener los cambios fuera del sprint.
• El objetivo del Sprint. Una breve declaración de cual será el
foco del trabajo durante el sprint.
34. Planificación del Sprint
• El equipo selecciona los temas a partir del Product Backlog que pueden
comprometerse a completar
• Los Sprints duran, idealmente, menos de un mes.
• Se seleccionan los requerimientos del Product Backlog que entrarán en el sprint.
• Se hace un listado de todas las tareas necesarias para terminar el sprint backlog,
indicando el esfuerzo de cada una.
• Se asignan responsables a las tareas
• El diseño de Alto Nivel es considerado
35. Sprint Planning meeting
Priorización
• Analizar y evaluar el Product
Backlog
• Seleccionar el objetivo del
Sprint
Planificación
• Decidir como alcanzar el
objetivo del Sprint (diseño)
• Crear el Sprint Backlog (tareas)
en base a los temas del
Product Backlog (user stories /
features)
• Estimar Sprint Backlog en
horas
Objetivo
del Sprint
Sprint
Backlog
Condiciones
del Negocio
Capacidad
del Equipo
Product
Backlog
Tecnología
Producto
Actual
36. • Primera reunión (Las primeras cuatro horas se dedican al Product Owner):
– Se establece la meta del Sprint
– Se identifica la funcionalidad que se va a construir en el Sprint
• Segunda reunión (Las segundas cuatro horas el equipo planea su propio Sprint):
– Se identifican y estiman las tareas para satisfacer
– Se crea un Sprint Backlog
– Las tareas son distribuidas por decisión de los miembros del equipo
– Los miembros del equipo se comprometen a cumplir con la meta del Sprint
• Entradas:
– Backlog del producto actualizado
– Retorno del ultimo Sprint
– Rendimiento del equipo en los Sprints anteriores
• Salida:
– Pila del sprint (Sprint Backlog)
37. • Pila del sprint (Sprint Backlog)
– Trabajo o tareas determinadas por el equipo para realizar en un sprint
y lograr al final del mismo un incremento de la funcionalidad.
– Se recomienda que las tareas reflejadas tengan una duración
comprendida entre las 4 y las 16 horas de trabajo.
– Las de mayor duración deben intentar descomponerse en sub-tareas
de ese rango de tiempo.
38. • Gestión del Sprint Backlog
– Los individuos eligen las tareas
– El trabajo nunca es asignado
– La estimación del trabajo restante es actualizada diariamente
– Cualquier miembro del equipo puede añadir, borrar o cambiar
el Sprint Backlog
– El trabajo para el Sprint emerge
– Si el trabajo no está claro, definir un tema del Sprint Backlog
con una mayor cantidad de tiempo y subdividirla luego.
– Actualizar el trabajo restante a medida de que más se conoce
39. Estimación de póquer
• La estimación no la realiza el cliente / Product Owner, por que no es él quien se va
a “ensuciar las manos” y luchar por cumplir con fechas.
• Todo el equipo realiza la estimación para:
– Reforzar el compromiso de todo el equipo respecto a las fechas que dan al cliente.
– Reforzar el compromiso de cada miembro del equipo respecto al resto.
– Hacer que todo el mundo se sienta oído.
• Estimar usando una unidad:
– Días ideales: los días necesarios para que el equipo
pueda completar un objetivo, sin considerar
interrupciones. Para pasar a días reales hay que aplicar
un factor de corrección que puede ir del 60 % al 70 %
de dedicación real al proyecto. Asimismo, habrá que
tener en cuenta un margen para imprevistos.
40. – Puntos de historia de usuario: la complejidad que tiene cada historia de usuario. Un equipo en un
proyecto determinado es capaz de completar un número semi-regular de puntos de historia cada
iteración (“velocidad”).
• Es una práctica ágil, para conducir las reuniones en las que se estima el esfuerzo y la duración
de tareas. El modelo consta de 8 cartas: ½, 1, 2, 3, 5, 6, 7 e infinito.
• El funcionamiento es muy simple: cada participante dispone de un juego de cartas, y en la
estimación de cada tarea, todos vuelven boca arriba la combinación que suma el esfuerzo
estimado.
• Cuando se considera que éste es mayor de x horas ideales (el tamaño máximo considerado
por el equipo para una tarea), se levanta la carta “infinito”. Las tareas que exceden el tamaño
máximo deben descomponerse en sub tareas de menor tamaño
• Cada equipo u organización puede utilizar un juego de cartas con las numeraciones
adecuadas a la unidad de esfuerzo con la que trabajan, y el tamaño máximo de tarea que se
va a estimar.
41. • Procedimiento
– Cada participante de la reunión tiene un juego de cartas.
– Para cada tarea (historia de usuario o funcionalidad, según sea el nivel de requisitos que
se va a estimar) el cliente, moderador o propietario del producto expone la descripción
empleando un tiempo máximo.
– Hay establecido otro tiempo para que el cliente o propietario del producto atienda a las
posibles preguntas del equipo.
– Cada participarte selecciona la carta, o cartas que representan su estimación, y las
separa del resto, boca abajo.
– Cuando todos han hecho su selección, se muestran boca arriba.
– Si la estimación resulta “infinito”, por sobrepasar el límite máximo establecido, la tarea
debe dividirse en sub-tareas de menor tamaño.
42. – Si las estimaciones resultan muy dispares, quien asume la responsabilidad de gestionar
la reunión, con su criterio de gestión, y basándose en las características del proyecto,
equipo, reunión, nº de elementos pendientes de evaluar, puede optar por:
• Preguntar a las personas de las estimaciones extremas: ¿Por qué crees que es necesario tanto tiempo?, y ¿por
qué crees que es necesario tan poco tiempo? Tras escuchar las razones, repetir la estimación.
• Dejar a un lado la estimación de esa tarea y retomar al final o en otro momento aquellas que hayan quedado
pendientes.
• Pedir al cliente o propietario del producto que descomponga la funcionalidad y valorar cada una de las
funcionalidades resultantes.
• Tomar la estimación menor, mayor, o la media.
• Este protocolo de moderación, evita en la reunión los atascos de análisis circulares en ping-pong entre diversas
opciones de implementación, hace participar a todos los asistentes, reduce el cuarto de hora o la media hora
de tiempo de estimación de una funcionalidad, a escasos minutos, consigue alcanzar consensos sin discusiones,
y además resulta divertido y dinamiza la reunión.
• Es frecuente emplear una carta con un símbolo de duda o interrogación para indicar que, por
las razones que sean, no se puede precisar una estimación. También es posible incluir otra
carta con alguna imagen alusiva, para indicar que se necesita un descanso
43. Ejecución del Sprint
• Periodo fijo de tiempo durante el cual el equipo desarrolla un
incremento de funcionalidad (no mas de 30 dias)
• No se aceptan cambios a los requerimientos acordados.
• El producto es diseñado, codificado, probado durante el Sprint.
• Solo el Scrum Master puede cancelar el Sprint cuando:
– La tecnologia no funciona
– Las circunstancias del negocio cambiaron
– El equipo tuvo interferencias
• Las iteracciones cortas permiten reducir los riesgos
44. • Es el periodo de tiempo durante el que se desarrolla un incremento de
funcionalidad. Constituye el núcleo de Scrum, que divide de esta forma el
desarrollo de un proyecto en un conjunto de pequeñas “carreras”.
• Duración máxima: 30 días.
• Durante el sprint no se puede modificar el trabajo que se ha acordado en el
Backlog.
• Sólo es posible cambiar el curso de un sprint, abortándolo, y sólo lo puede hacer el
Scrum Master si decide que no es viable por alguna de las razones siguientes:
– La tecnología acordada no funciona.
– Las circunstancias del negocio han cambiado.
– El equipo ha tenido interferencias.
• Diariamente se realiza una reunión diaria llamada Daily Scrum, y al final del Sprint,
se realiza una reunión de revisión de Sprint, llamada Sprint Review
45. Fin del sprint: Sprint review
• Reunión donde se presenta al product owner y a los implicados todas las funcionalidades implementadas.
• Normalmente adopta la forma de una demo de las nuevas características o la arquitectura subyacente
– Informal
– Duracion de 4 horas. Regla de 2 hs preparación.
– No usar diapositivas
– Todo el equipo participa
– Se invita a todo el mundo
• El Product owner trata con los asistentes y con el team las posibles modificaciones en la pila de producto.
• Al final de la reunión se interroga individualmente a todos los asistentes para
recabar impresiones, sugerencias de cambio y mejora, y su relevancia.
• Después del Sprint review y antes de la proxima Sprint planning meeting,
el ScrumMaster convoca a una Sprint retrospective del Sprint con el Team.
46. • Objetivo:
– Presentar el Product Owner y demas involucrados del proyecto el trabajo realizado (incremento del
producto) durante el Sprint.
• Participan:
– Equipo, Scrum Master, Product Owner, todas las personas involucradas en el proyecto.
• Reglas:
– El Equipo no invierte mas de una hora en preparar el Sprint Review
– Las funcionalidades no finalizadas completamente no se presentan
– Los miembros del equipo presentan las funcionalidades
– Las demostraciones se realizn en el equipamiento de los miembros del equipo
– Al finalizar la reunion se piden opiniones a los participantes, los cuales pueden sugerir cambios y mejoras.
• Al finalizar:
– El Product Owner decide si la funcionalidad presentada cumple con los objetivos del Sprint
– Se actualiza y vuelve a priorizar el Product Backlog
– El Scrum Master anuncia el lugar y la fecha de la proxima revision del Sprint.
47. Sprint retrospective
• Periódicamente, se echa un vistazo a lo que funciona y lo que no.
• Normalmente 30 a 90 minutos
• Se realiza luego de cada sprint
• Todo el equipo participa: ScrumMaster, Product owner, Equipo,
Posiblemente clientes y otros
• El ScrumMaster hace que el Team revise, su proceso de desarrollo
Scrum, para hacerlo más eficaz y eficiente para el próximo Sprint.
• El ScrumMaster no proporciona respuestas, sino que ayuda al equipo a
encontrar la mejor forma de trabajar con Scrum.
• En conjunto, Sprint planning meeting, Daily Scrum, Sprint review, y el
Sprint retrospective, constituyen la inspección empírica y prácticas de la
adaptación del Scrum.
48. • Objetivo:
– Identificar que cosas se pueden cambiar para hacer el trabajo mas agradable y productivo en las proximas
iteraciones.
– Se realiza al finalizar el Sprint
• Participan:
– Team, Scrum Master, Product Manager (opcional)
• Reglas:
– Dos preguntas que todos deben responder:
• Que cosas hicimos bien?
• En que cosas podemos mejorar?
– Todo aquello que afecte como el equipo construye se debe debatir.
– Permite al equipo evolucionar continuamente mejorando durante el proyecto.
• Al finalizar:
– Lista de oportunidades de mejora.
49. Daily Scrum (Comenzar / Parar /
Continuar)
• Breve reunión diaria para repasar cada una de las tareas y el trabajo previsto de la jornada.
Dura 15 minutos
• Sólo interviene el equipo de desarrollo
• No para la solución de problemas. No es dar un reporte de estado al Scrum Master, se trata
de compromisos delante de pares
– Todo el mundo está invitado
– Sólo los miembros del equipo, ScrumMaster y Product Owner, pueden hablar
– Ayuda a evitar otras reuniones innecesarias
• Cada miembro responde a tres questiones: Trabajo realizado desde la reunión anterior,
Trabajo que se va a realizar hasta la próxima reunión de seguimiento, Problemas que se
deben solucionar para realizar el trabajo propuesto
• Todo el equipo se reúne y discute lo que les gustaría: Comenzar a hacer, Dejar de hacer,
Continuar haciendo
50. Incremento
• Demostración de los objetivos alcanzados en cada sprint
• Asistencia de todos los roles, “Product Owner” e incluso usuarios
• Sólo el Scrum Master puede abortar un Sprint debido a una de las
siguientes razones:
– La tecnología seleccionada no funciona o es incompatible con los objetivos
definidos
– Han cambiado las circunstancias de negocio
– El Scrum Team ha tenido inferencias
51. Prácticas para la gestión del proyecto
• Revisión de las iteraciones: al final de cada sprint
• Desarrollo incremental: Al final de cada sprint debe haber una parte del
producto operativa que se pueda inspeccionar y evaluar
• Desarrollo evolutivo: No se define la estructura final, la arquitectura o el
diseño final del producto ya que los requisitos son cambiantes. Se utilizan
técnicas de refactorización en las fases de diseño y codificación
• Auto-organización: Los equipos son auto-organizados con márgenes de
decisión suficientes para tomar las decisiones que se consideren oportunas
en los sucesitos sprint
• Colaboración: Se apuesta por una colaboración abierta entre todos los
integrantes según sus conocimientos y capacidades, no según su rol o
puesto.
• Veremos como estructurar un proyecto ágil …
52.
53. • Estudio de viabilidad y de negocio. Las dos primeras fases son secuenciales.
– Estudio de viabilidad:
• Calcular los costes
• Ver si es técnicamente viable
• Asegurarse de que DSDM sea el enfoque adecuado
– Estudio de negocio:
• Modelado del proceso del negocio
• Fuerte colaboración cliente-equipo de desarrollo.
• Iteración funcional del modelo e Iteración de diseño y construcción:
– Iteración funcional del modelo:
• Refinar aspectos funcionales del negocio.
– Iteración de diseño y construcción:
• El producto se vuelve apto para los usuarios.
54. – Las dos fases consisten en ciclos de 4 actividades:
• Identificación
• Planificación
• Producción
• Validación
• Implementación:
– Implementación, entrenamiento, revisión y aceptación de usuarios y revisión del negocio.
– Al final puede ocurrir:
• Falta una parte técnica
– Iteración de diseño y construcción
• Se ha descubierto una nueva funcionalidad
– Estudio del negocio
• Falta una funcionalidad secundaria
– Iteración funcional del modelo
• Todos los requerimientos cumplidos
– Fin
55.
56.
57.
58. Cliente
Equipo
• Control empírico: interactivo e incremental
Hacer entregas cortas y regulares del
producto final (2-4s) para obtener feedback e
irse acercando a las expectativas del cliente.
Participación del cliente,
transparencia para que pueda guiar
de manera regular los resultados del
proyecto.
59. • La planificación ágil parte de
la idea de planificar en
función de objetivos de
negocio en lugar de tareas (a
diferencia de la planificación
tradicional), priorizando los
que aportan más valor, y
esperando a dar detalle a
objetivos y tareas conforme
se va acercando el momento
de construcción de estos
objetivos, cuando la
indeterminación se va
reduciendo, de manera que
se amortiza el esfuerzo de
planificar de manera
detallada.
60.
61. • La planificación ágil toma
como base el control
empírico de la construcción
de producto (inspección y
adaptación)
62. Cliente Entregas de los
objetivos más
importantes
Entrega final
Equipo
• Priorización por valor de negocio
Proporcionar resultados
anticipados (“time to
market”)
Orientar el proyecto a objetivos para el cliente, no a
tareas, priorizando según el valor de negocio vs
esfuerzo y riesgo.
63. • Herramientas: Gráfico Burn-Up. Utilizado por el Product Owner. Muestra: las versiones
previstas de un producto, funcionalidades de cada una de ellas, velocidad estimada, fechas
probables para cada versión, margen de error previsto en las estimaciones, y avance real
64. • Herramientas: Gráfico Burn-Down. Utilizado por el Scrum Team para
seguimiento del trabajo de cada Sprint
65. • Pruebas
– Test Driven Development
• Diseño e implementación de las pruebas antes de programar la funcionalidad
• El programador crea sus propios tests de unidad
– Integración continua (Integración diaria, Disponer de una máquina para integración)
– Tests funcionales (Cliente)
• Semana de 40 horas
– El desarrollo de software es un ejercicio creativo
• hay que estar fresco y descansado
– Sin “héroes”
– Se reduce la rotación de personal
– Mejora la calidad del producto
– Se permiten excepciones, con cuidado
• más de una semana de horas extra: problema
66. • Propiedad colectiva del código
– Cualquier integrante del grupo tiene autoridad para cambiar cualquier parte del código fuente
– Todos son dueños del código
– Siempre se utilizan estándares
– Los tests siempre deben funcionar al 100%
– Se integra con todo el sistema permanentemente
– Manejo de configuración
• Diseño simple, entregas pequeñas
– Se debe mantener el diseño lo mas simple posible (YAGNI): “No vas a necesitarlo”
– Tarjetas CRC
– Design for change vs Design for today
• Características útiles en términos del negocio
• No implementar características que no son necesarias
– Poner en producción lo antes posible
– Unas pocas semanas por entrega
67. • Refactorización
– Si el código se está volviendo complicado
• modificar el diseño, volver a uno más simple
– Refactoring: modificar la forma del código sin cambiar su funcionamiento
• Ejemplos: extraer método, renombrar (clase, método, variable, etc.), reemplazar
– Hay herramientas
• C#Refactory (Xtreme Simplicity)
• Conciliar el enfoque ágil y contratos de precio fijo. Es posible ofrecer al Cliente: a) cambio de
alcance dinámico gratis, b) generación de valor y c) riesgo compartido (evitando juego de suma
cero). Simultáneamente, la organización mejora su flujo de caja, contiene sobre costos y el disparo
del alcance.
– Aceptar cambios, de la siguiente forma
• Sobre lo no desarrollado, de lo contrario tiene costo
• Sobre lo no desarrollado, substituir requerimientos registrados por los nuevos, que tengan una
estimación de esfuerzo similar, o de lo contrario tiene costo
68. – Aplicar tarifas diferenciales
• Aplicable por cumplimiento de cronograma: 100%
• Aplicable por incumplimiento de cronograma: 90%
• Aplicable por mejora de cronograma: 115%
– Permitir la cancelación anticipada
• Penalidad del +20% luego de que el 85% del proyecto sea entregado.
• Luego de que avance el proyectos, y se podrá re estimar los sub entregables en base a cambios,
riesgos descubiertos.
– Armado y entrega de paquete por funcionalidad
• Descomponer SOW en sub entregables, y pagar por paquete
• Considerar fijar dos alcances: a) prueba de concepto, al que se le aplica un metodología ágil y
b) desarrollo, el que se realiza de forma también ágil o a través de un contrato fijo.
69. • Dividir las historias
– Datos
– Casos especiales
– Operaciones (ABM “Altas, Bajas y Mantenimiento” o CRUD “Crear, Leer, Actualizar y Borrar”)
– Temas transversales y no funcionales: seguridad, log, manejo de errores, performance, volumen
– Prioridad
• No dividir
– Por debajo de 2/5 días
– En tareas
– Y no agregar trabajo no priorizado…
• Sprint 0, permite identificar los objetivos y reducir la incertidumbre respecto al alcance,
definir viabilidad, o plataforma tecnológica. El objetivo último es obtener una visión clara de:
– Qué queremos implementar, en forma de Product Backlog y prototipos.
70. – Cómo lo queremos implementar, en forma de Arquitectura técnica.
– Y cuánto (tiempo y dinero) aproximadamente nos va a costar llegar a cada una de las posibles fases
principales de la implementación del proyecto.
Dentro de ese Product Backlog es habitual encontrar clasificadas las Épicas en estos tres grupos:
MVP (Producto Mínimo Viable), MMP (Producto Mínimo Comercializable) y Funcionalidades futuras.
Evidentemente, las Épicas de los dos primeros grupos se habrán descompuesto en Historias de Usuario y
se habrá estimado su complejidad lo que ha permitido priorizarlas, apoyadas además por Prototipos y
Propuesta Gráfica (desde el punto de vista de Usabilidad) y por una Arquitectura propuesta e,
incluso, Pruebas de Concepto de aquellos elementos tecnológicos más innovadores.
Pero, dado que en este punto ya se tiene una orientación de alcance (MVP y MMP) lo que permite a
“Negocio” obtener una visión muy aproximada de cuál será el resultado del proyecto, también es posible
minimizar las inquietudes tanto de la Gerencia (orientación en cuanto a Costes y Plazos), como de los
equipos de Tecnología (cuándo se estima que deberán estar disponibles los entornos y equipos que
sustenten el nuevo producto, qué personas formarán el equipo, que recursos harán falta, qué nuevos
productos o frameworks se introducen en el ecosistema a mantener, etc).
71. Prácticas para la gestión del producto
• Técnica para entender y planear una entrega incremental de MVPs. La técnica
organiza ideas y recursos en un modelo que busca entender la finalidad principal
del producto, considerando las jornadas de los usuario para realizar las entregas
incrementales de productos viables. Como un libro de recetas, con una secuencia
de actividades, rápidas y eficaces, la técnica va a permitir que el equipo:
– Describa la visión del producto. El producto Es - No es - Hace - No hace
– Priorize los objetivos del producto. Entendiendo los trade-offs.
– Describa los principales usuarios, sus perfiles y sus necesidades
– Entienda las principales funcionalidades
– Comprenda los niveles de incertidumbre, esfuerzo y valor de
negocio por uncionalidad
– Describa las jornadas más importantes de los usuarios
– Cree un plan de entrega incremental del producto, impulsado
por el concepto de MVP
– Estime el esfuerzo por muestreo
– Calcule los costos y especifique fechas en el cronograma de
entrega
23:28 71
72. • El Canvas MVP
– Es una herramienta para validar ideas de productos. Es un marco visual que ayuda a los
empresarios para alinear y ajustar la estrategia del MVP (Minimum Viable Product, en inglés).
Se divide en siete bloques:
• MVP Visión general – ¿Cuál es la visión de este MVP?
• Métricas para validar el modelo de negocio – ¿Cómo podemos medir los resultados de este MVP?
• Resultado esperado – ¿Qué esperamos como aprendizaje o resultado de este MVP?
• Características – ¿Qué vamos a construir en este MVP? ¿Qué acciones se simplificarán / mejorarán en
este MVP?
• Personas y Plataformas – ¿Para quién es el MVP? ¿En qué plataforma estará disponible?
• Historias – ¿Qué historias se cumplen o mejoran con este MVP?
• Costo y horario – ¿Cuál es el costo y la fecha prevista para la entrega de este MVP?
– Al usar el Canvas MVP, ponemos los dos bucles uno al lado del otro. De “Lean startup”, el
bucle de construir-medir-aprender. Del Design Thinking, el bucle de usuario-journey-acción.
En ambos bucles, la respuesta a qué construir: las funcionalidades del MVP.
23:28 72
73. • Cuando una composición de funcionalidades alcanza una versión simple del producto que podría estar
disponible? Usted debe planear una secuencia de ondas para agrupar las funcionalidades de manera que lo ayude
a organizar la producción, considerando limites de funcionalidad, nivel de riesgo, esfuerzo y valor de negocio.
• El MVP debe de ser factible, usable, valioso. El Canvas MVP, permite validar ideas de productos. Es un marco
visual que relaciona dos bucles. De “Lean startup”, el bucle de construir-medir-aprender. Del Design Thinking, el
bucle de usuario-journey-acción. En ambos bucles, la respuesta a qué construir: las funcionalidades del MVP.
23:28 73
Personas y plataformas
Usuario
Visión de MVP Resultado Esperado
Aprender
Funcionalidad
Jornadas de usuario Métrica (validación hipótesis)
Costo y Cronograma de
Entrega
Medir
Aprende
r
Construir
Usuario
Experiencia
Acción
74. Proceso de desarrollo del producto por etapas
Evaluación de
conceptos
Valida ideas, planifica y
especifica
Desarrollo Evaluación y pruebas Lanzamiento
Prospección.
Investigación
preliminar de cada
uno de los proyectos
o ideas generados en
la fase de
descubrimiento y se
selecciona un
subconjunto de ellos.
Construir el modelo
de negocio.
Mediante una
investigación minuciosa
por parte de los equipos
técnicos y comerciales
definiendo y justificando
el producto desarrollando
el plan de proyecto.
Desarrollo
Establece el
diseño y
desarrollo de
nuevo producto y
el plan de
producción y
lanzamiento al
mercado.
Pruebas y validación.
Se efectúa una
prueba extensa del
nuevo producto en el
mercado, en el
laboratorio, o en la
planta.
Lanzamiento.
Como inicio de la
producción y
comercialización se
establecen revisiones
periódicas de post –
lanzamiento.
Visión Producto e
EPICs
Fundación
técnica/negocio.
Experiencia del usuario.
Priorización de funciones.
Estructura del
proyecto.
MVP
Funciones básicas y
validación UX.
Supuestos validados.
UAT.
MMP
Retorno primario.
Mejoras dirigidas por
la visión del usuario.
Adopción continúa.
75. Infraestructura requerida
• Plataforma para la implementación de tableros KAMBAN, fomentar el
trabajo colaborativo, gestión de incidencias y automatización de QA/QC.
76. • Lugar de trabajo
– Sala amplia (mejor, sin divisiones)
• Centro: pares de programadores
• Periferia: máquinas individuales
– Ventajas del espacio abierto:
• Mayor comunicación
• Agenda dinámica
• Cliente en el sitio
– Interacción continua
– No siempre se consigue
• muy junior, no sirve
• muy senior, no quiere
– Actualmente se pide un “analista”
77. Gestión regular de expectativas del cliente Priorización de requisitos
Resultados anticipados (“time to market”)
Demostración del proyecto en cada Sprint
Priorización de requisitos por valor/coste
Flexibilidad y adaptación Re planificación en el inicio de cada iteración
Retorno de inversión (ROI) Priorización de requisitos
Mitigación de riesgos Desarrollo iterativo e incremental
Productividad de calidad
Mejora continua
Comunicación diaria del equipo
TimeBoxing
Equipo multidisciplinar
Estimación de esfuerzo conjunta
Compromiso del equipo
Demostración de resultados
Alineamiento entre cliente y equipo Reuniones en cada itinerario (Sprint)
Equipo motivado
Equipo autosugestionado
Reuniones diarias y en cada Sprint
Fortalezas de SCRUM
78. Reflexiones
• Highsmith & Cockburn 2001
– “lo que es nuevo en los procesos ágiles no son las prácticas que usan, sino
que reconozcan a las personas como primeros implicados en el éxito de un
proyecto, además de un intenso foco en la efectividad y la manejabilidad.
Esto genera una nueva combinación de valores y principios que definen
una visión ágil del mundo.”
• Hawrysh & Ruprecht 2000
– Una sola metodología no puede funcionar para todo el espectro de
proyectos, en vez de eso el administrador de cada proyecto debería
identificar la naturaleza especifica de cada proyecto y seleccionar la
mejor metodología de desarrollo aplicable.
• McCauley 2001
– Hay una necesidad de ambos métodos [ágiles y orientados a procesos] ya
que no hay un modelo de desarrollo que se ajuste a todos los propósitos
imaginables.
79. Caso practico
• Un cliente se pone en contacto con una empresa que fabrica robots.
• El cliente les realiza el pedido.
Quiero un robot que me
sirva de escolta
80. • El Cliente se reune con el Dueño de producto, que toma nota
de lo que tiene en su cabeza.
Cliente Dueño de Producto
81. • El Duelo de Producto divide el proyecto en historias que son las que
componen la pila de producto.
Dueño de Producto
Pila de Producto
82. • El Scrum Master es un miembro del equipo que tiene el papel de
comunicar y gestionar las necesidades del Dueño de Producto y la pila de
Sprint.
• El Dueño de Producto le entrega la pila de producto para que estimen el
coste de creación del producto.
Dueño de Producto Scrum Manager
83. • El equipo se reune para estimar el coste de cada historia de la
pila de producto.
• En este caso utilizan Planning Poker.
Equipo
84. • El cliente, una vez aprobado el presupuesto, reordena la pila de producto
para que el equipo vaya trabajando según la prioridad del cliente.
Cliente
Menos imporantes
Urgentes
85. • El equipo comienza su trabajo desglosando la primera historia de la pila de
producto, la cual subdividen en tareas menores para crear la pila de sprint.
86. • La pila de sprint tiene como utilidad fraccionar el trabajo de un periodo de
15 días en tareas mas pequeñas, que tarden como mucho dos días.
87. • Estas tareas se colocan en una pila, la cual prioriza el Dueño de Producto,
que ha consultado con el cliente, antes de comenzar el sprint.
Dueño de Producto
Menos imporantes
Urgentes
88. • El equipo comienza el sprint tomando las tareas priorizadas.
• Una vez concluida una se toma la siguiente de la lista.
• Se convoca todos los días una reunión del equipo donde se cuenta las tareas realizadas el día
anterior y cuales se van a realizar ese día.
89. • Una vez finalizado el sprint, el Dueño de Producto le muestra al cliente el
resultado del trabajo realizado.
• El cliente ya tiene el primer contacto con su encargo y además puede
volver a priorizar la pila de producto antes de que comience otro sprint.
Cliente
Dueño de Producto
Buen trabajo
90. • El equipo de trabajo celebra su buen hacer con una reunión de
retrospectiva, donde se analiza lo ocurrido durante el sprint.