Un modelo operativo es una representación conceptual del estado deseado de una organización que trabaja bajo una estructura, patrones y principios ágiles. Esta presentación contiene los elementos y principios operativos más relevantes de un modelo ágil (Building Blocks).
SCRUM Framework de desarrollo ágil, Iterativo, dispuesto al cambio, que favorece la satisfacción del cliente y se basa en principios de inspección y adaptación
Diseño de Centro de Excelencia en Ágil (CoEs)Johnny Ordóñez
Un CoE es un grupo de personas con habilidades y conocimientos especializados cuyo trabajo es proporcionar liderazgo y difundir deliberadamente ese conocimiento dentro de la organización. Tiene como propósito el desarrollar, gobernar y asegurar la excelencia en el ejercicio de una determinada disciplina en los equipos del Delivery y en toda la organización.
Del Triángulo de Hierro a la gestión de Sistemas Complejos Adaptativos.Óscar R. Onrubia
El planteamiento no pretende ser un axioma, más bien un meme, una herramienta de ayuda en la facilitación del cambio por parte de los "Agentes de cambio" de las organizaciones que quieren implantar modelos de gestión y desarrollo ágil.
Partiendo del conocido "Triángulo de las restricciones" para la administración de proyectos, trato de mostrar las áreas de gestión de los 'Sistemas Complejos Adaptativos' para maximizar las posibilidades de éxito en los desafíos acometidos en las organizaciones.
Un modelo operativo es una representación conceptual del estado deseado de una organización que trabaja bajo una estructura, patrones y principios ágiles. Esta presentación contiene los elementos y principios operativos más relevantes de un modelo ágil (Building Blocks).
SCRUM Framework de desarrollo ágil, Iterativo, dispuesto al cambio, que favorece la satisfacción del cliente y se basa en principios de inspección y adaptación
Diseño de Centro de Excelencia en Ágil (CoEs)Johnny Ordóñez
Un CoE es un grupo de personas con habilidades y conocimientos especializados cuyo trabajo es proporcionar liderazgo y difundir deliberadamente ese conocimiento dentro de la organización. Tiene como propósito el desarrollar, gobernar y asegurar la excelencia en el ejercicio de una determinada disciplina en los equipos del Delivery y en toda la organización.
Del Triángulo de Hierro a la gestión de Sistemas Complejos Adaptativos.Óscar R. Onrubia
El planteamiento no pretende ser un axioma, más bien un meme, una herramienta de ayuda en la facilitación del cambio por parte de los "Agentes de cambio" de las organizaciones que quieren implantar modelos de gestión y desarrollo ágil.
Partiendo del conocido "Triángulo de las restricciones" para la administración de proyectos, trato de mostrar las áreas de gestión de los 'Sistemas Complejos Adaptativos' para maximizar las posibilidades de éxito en los desafíos acometidos en las organizaciones.
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.
Estrategia y métodos para adoptar agilidad en áreas de negocioGiovanny Cifuentes
Marco conceptual para adoptar agilidad en áreas fuera de Ti, presentando la estrategia de acompañamiento con el respectivo roadmap de adopción de los diferentes métodos que permiten habilitar la agilidad en las áreas de negocio.
Conjunto de preguntas y ejercicios que brindan la posibilidad de mejorar las oportunidades para que los proyectos software sean exitosos, haciendo que todos los implicados tengan los mismos objetivos en relación al proyecto.
Devops Adoption Roadmap v 2.7 Agiles Colombia 2020Javier Dominguez
DevOps suele verse como una implementación de herramientas cuando en realidad es la adopción de un mindset, unas prácticas y la generación de todo un nuevo contexto cultural para lograr romper silos y poner exitosamente en producción los desarrollos ágiles y también por qué no los tradicionales como lo veremos en esta charla y conversatorio con Javier Domínguez y Julio Chacón.
Es notable el interés de diferentes industrias y áreas de negocio de dar una oportunidad a agilidad con el fin de buscar mejores resultados para buscar su excelencia operativa, pero ¿ realmente necesito agilidad para ello ?
Un vistazo a unos de los frameworks más populares y controversiales para la adopción Agile a nivel empresarial, y algunas reflexiones sobre la experiencia de aplicarlo en el mundo real.
Agile IT Operatinos - Getting to Daily ReleasesLeadingAgile
Getting to Daily Releases with Agile IT Operations. Devin Hedge, Enterprise Transformation Consultant talks to a group at Triagile about the Six Key Areas to focus on when attempting to transform IT Operations with Lean and Agile principles. The talk covers Service Engineering, IT Operations, and the Tier 1 Support/NOC organizations. Kanban, Service Management (ITSM), and what it means to have a DevOps orientation.
Una transformación Agile tiene impacto en multitud de ámbitos: organización, procesos, cultura, ingeniería, gestión de producto, …
¿Cómo aclararse en la multitud de actividades variopintas a realizar? ¿Cómo saber qué priorizar? ¿Cómo avanzar y no quedarse atascado? ¿Cómo clasificar nuevas ideas y experimentos? ¿Cómo conseguir que la transformación sea “de todos”, compartida, inclusiva y colaborativa? ¿Cómo saber si lo que estás haciendo tiene resultados?
En esta presentación verás diversos “tips” basados en experiencias reales que pueden ayudarte a plantear mejor tu transformación, articular la gestión y a comunicar su estado de manera sencilla.
Video de la presentación: https://www.youtube.com/watch?v=O3eWtj_LYUM
What are the Agile Metrics That Matter Most? Are they at the team-level? project/project? What about the people-side of agile (the "soft stuff"). What are common pitfalls to avoid? We categorize agile metrics into those about Value, Flow, Quality & Culture, and identify the most frequently used (and misused) in each of those areas.
Estimación, Priorización y Seguimiento de un Proyecto Ágil Empleando el User ...Jorge Hernán Abad Londoño
Charla compartida en el V congreso de gerencia internacional de proyectos del PMI Colombia 2016, en donde se comparten los principios realizar la planeación y seguimiento de un proyecto ágil usando la técnica de User Story Map de Jeff Patton
Treating Your Pipeline as a Product - Full Day WorkshopManuel Pais
On completion of the workshop, you should have practical experience of techniques to treat your delivery chain as a first class citizen in your value stream, including testing, monitoring and recovering your delivery system.
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.
Estrategia y métodos para adoptar agilidad en áreas de negocioGiovanny Cifuentes
Marco conceptual para adoptar agilidad en áreas fuera de Ti, presentando la estrategia de acompañamiento con el respectivo roadmap de adopción de los diferentes métodos que permiten habilitar la agilidad en las áreas de negocio.
Conjunto de preguntas y ejercicios que brindan la posibilidad de mejorar las oportunidades para que los proyectos software sean exitosos, haciendo que todos los implicados tengan los mismos objetivos en relación al proyecto.
Devops Adoption Roadmap v 2.7 Agiles Colombia 2020Javier Dominguez
DevOps suele verse como una implementación de herramientas cuando en realidad es la adopción de un mindset, unas prácticas y la generación de todo un nuevo contexto cultural para lograr romper silos y poner exitosamente en producción los desarrollos ágiles y también por qué no los tradicionales como lo veremos en esta charla y conversatorio con Javier Domínguez y Julio Chacón.
Es notable el interés de diferentes industrias y áreas de negocio de dar una oportunidad a agilidad con el fin de buscar mejores resultados para buscar su excelencia operativa, pero ¿ realmente necesito agilidad para ello ?
Un vistazo a unos de los frameworks más populares y controversiales para la adopción Agile a nivel empresarial, y algunas reflexiones sobre la experiencia de aplicarlo en el mundo real.
Agile IT Operatinos - Getting to Daily ReleasesLeadingAgile
Getting to Daily Releases with Agile IT Operations. Devin Hedge, Enterprise Transformation Consultant talks to a group at Triagile about the Six Key Areas to focus on when attempting to transform IT Operations with Lean and Agile principles. The talk covers Service Engineering, IT Operations, and the Tier 1 Support/NOC organizations. Kanban, Service Management (ITSM), and what it means to have a DevOps orientation.
Una transformación Agile tiene impacto en multitud de ámbitos: organización, procesos, cultura, ingeniería, gestión de producto, …
¿Cómo aclararse en la multitud de actividades variopintas a realizar? ¿Cómo saber qué priorizar? ¿Cómo avanzar y no quedarse atascado? ¿Cómo clasificar nuevas ideas y experimentos? ¿Cómo conseguir que la transformación sea “de todos”, compartida, inclusiva y colaborativa? ¿Cómo saber si lo que estás haciendo tiene resultados?
En esta presentación verás diversos “tips” basados en experiencias reales que pueden ayudarte a plantear mejor tu transformación, articular la gestión y a comunicar su estado de manera sencilla.
Video de la presentación: https://www.youtube.com/watch?v=O3eWtj_LYUM
What are the Agile Metrics That Matter Most? Are they at the team-level? project/project? What about the people-side of agile (the "soft stuff"). What are common pitfalls to avoid? We categorize agile metrics into those about Value, Flow, Quality & Culture, and identify the most frequently used (and misused) in each of those areas.
Estimación, Priorización y Seguimiento de un Proyecto Ágil Empleando el User ...Jorge Hernán Abad Londoño
Charla compartida en el V congreso de gerencia internacional de proyectos del PMI Colombia 2016, en donde se comparten los principios realizar la planeación y seguimiento de un proyecto ágil usando la técnica de User Story Map de Jeff Patton
Treating Your Pipeline as a Product - Full Day WorkshopManuel Pais
On completion of the workshop, you should have practical experience of techniques to treat your delivery chain as a first class citizen in your value stream, including testing, monitoring and recovering your delivery system.
Al tomar la decisión de adoptar Scrum como medio para construir productos exitosos, muchas organizaciones concentran sus esfuerzos en las iteraciones, las reuniones y los roles; postergando un factor mucho más importante y sin el cual la transformación generalmente falla: que Scrum no es una herramienta, es todo un modelo relacional.
Para que su semilla eche raíces fuertes y brinde frutos poderosos necesitamos sembrarla en un terreno fértil, amigable, con relaciones fuertes, de lo contrario morirá. Por esto es preciso conocer qué es "ese Scrum" que hay escondido detrás de Scrum. Inclusive, desde la perspectiva del autor, este es el ámbito de acción e intervención de un Coach.
Exploraremos por qué muchas adopciones de Scrum pueden fracasar y qué puedes hacer como Coach para evitarlo.
Charla de SCRUM impartida por el Ing. Jhon Alexander Holguín Barrera a los estudiantes de Ingeniería del Software de la Universidad Católica de Pereira, 2011.
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.
La priorización de historias de usuario (versión reducida)Micael Gallego
Presentación del meetup de Madrid Ágil del 29 de Enero de 2014.
Tenéis una versión ampliada en: https://www.slideshare.net/micaelgallego/la-priorizacin-de-historias-de-usuario2
Mañana empiezo un nuevo proyecto: ¿qué metodología ágil me pongo?
El ecosistema ágil está formado por un conjunto de organismos “vivos” llamados “métodos y prácticas ágiles” (biocenosis) y el medio físico donde se relacionan, llamados Organizaciones (biotopo). Estas últimas están conformadas por personas y estas personas usan distintas clases de biocenosis, es decir, de métodos y prácticas ágiles, según sus necesidades.
Como todo ecosistema, el ágil tiene barreras que a veces impiden su normal evolución. Barreras físicas, como la falta de entornos adecuados dentro de las Organizaciones para albergar equipos que respiren “agilidad”. Barreras culturales y hasta emocionales, arraigos y miedos que se dan entre las personas, quienes experimentan temores muchas veces infundados debido a la falta de información o de acompañamiento efectivo por parte de expertos, de conocedores de ese ecosistema ágil en formación.
Pero, ¿cuáles son esos métodos y prácticas ágiles? ¿Para qué sirve cada uno de ellos? En esta sesión exploraremos, a manera de introducción, las metodologías más usadas, como Scrum, eXtreme Programming (XP), Kanban, Lean; y algunas de las técnicas necesarias en un primer esfuerzo por implementar la Cultura Ágil en una Organización: User Story Mapping, Product Vision Board, User Persona, User Stories, TDD, BDD, para mencionar solo algunas.
Y lo más importante, ¿para qué sirve cada uno de estos especímenes ágiles? ¿Alguno de ellos es adecuado para el proyecto que inicio mañana? ¿Varios de estos? ¿Son complementarios? ¿Qué problemas puedo encontrar si elijo mal? Y en el fondo, ¿cuáles son las razones por las que debo permitir el nacimiento y expansión de un nuevo ecosistema aun si el actual me está rindiendo beneficios? Y hablando de utilidades, ¿cuáles puedo obtener al implementar la “agilidad” en mi Organización?
Finalmente, sabemos que los ecosistemas están gobernados principalmente por eventos estocásticos (azar), por las reacciones que estos eventos ocasionan en sus componentes y por las respuestas de los organismos a las condiciones que los rodean. ¿Cómo controlar estos eventos y sobrevivir en el intento? Una mirada Darwiniana nos ayudará a entender cómo, mediante la inspección y la adaptación, nos iremos adecuando a los cambios que ocurren en todo proceso de evolución y entenderemos que la cultura ágil es el siguiente paso en la evolución de la inteligencia.
Charla introductoria a las metodologías ágiles, específicamente al mundo de las Historias de Usuario como herramienta para recopilación de requerimientos y a SCRUM como marco de trabajo para el Desarrollo de Software
Centralización de logs con Elasticsearch + Logstash + Kibana
y Recolección de métricas con statsd/collectd, con multiples storages y visualizadores de métricas
Repositorio con infraestructuras automatizadas + un symfony que se integra
https://github.com/felixcarmona/detras-del-backend
(vagrant up)
Argentesting 2017 - Performance testing 101 con jmeterArgentesting
Este taller será una introducción a los conceptos de Performance Testing y a la utilización de JMETER para armar planes de pruebas de performance.
Los requerimientos de las máquinas de los asistentes son:
Procesador Intel i3 o Superior con 2GB y 1 GB de espacio Libre.
SO: Linux, MacOs, Windows
JAVA 1.8 Instalado
Expositor: Sebastián Lallana
Presentación de Alfonso Tienda (@afoone) en las IX Jornadas de gestión de proyectos del PMI Valencia @PMI_Valencia.
Alfonso Tienda es Socio Director en @iProcuratio Consultores, una empresa dedicada a la consultoría de Tecnologías de Información especializada en el sector Salud y en la gestión de Proyectos. Implantamos metodologías y algunas herramientas como Microsoft Project Server.
Meetup TestingUy 2019 - ¿Test cases? ¿Son siempre necesarios?TestingUy
Expositor: Edgardo Crovetto
Resumen: ¿Cuántas veces pasa que hay que hacer tests cases por el hecho de hacerlos y además hechos para ayer porque no hay tiempo?¿Qué podemos hacer para mantener el máximo cubrimiento de prueba y mínima documentación?
El objetivo es realmente enfocarnos en hacer entrega de un producto de calidad, sin la obligación de crear documentación innecesaria por el hecho de hacerlo. Al mismo tiempo, poder mostrar cubrimiento de pruebas apropiado y hacer los informes necesarios para poder estar confiados que se está entregando con calidad.
En esta charla trataremos de dar un enfoque para poder elegir una buena estrategía en base a algún caso práctico.
Agile People - Habilitando la agilidad desde Gestión de talentoJohnny Ordóñez
Les comparto mi presentación en Ágiles Colombia 2019; con algunas técnicas y enfoques que me han servido durante estos años colaborando con áreas de Gestión de Talento.
An excerpt of my proposal to the implementation and management of Corporate Innovation portfolio based on Tendayi Viki's book: The Corporate StartUp and Lean Management principles.
'agility enablement' - desbloqueando la agilidad empresarialJohnny Ordóñez
agilidad está siempre presente en la organización. En lugar de tratar de alcanzar el 'ser Ágil’ como una meta, enfocarse en identificar los límites y remover las restricciones que dan forma a la capacidad organizacional de poder percibir, adaptarse y responder.
Nuestro trabajo es identificar los límites y remover las restricciones que la rodean para potenciarla.
Esta es mi propuesta.
'agility' is always present within the organization. Instead of trying to achieve ‘to be Agile' as a goal, focus on identifying boundaries and removing the constraints that shape the organizational capacity of sensing, adapting and responding. Our job is to identify the boundaries and remove the constraints that surround 'agility' to enhance it.
This is my proposal.
Anna Lucia Alfaro Dardón, Harvard MPA/ID.
Opportunities, constraints and challenges for the development of the small and medium enterprise (SME) sector in Central America, with an analytical study of the SME sector in Nicaragua. - focused on the current supply and demand gap for credit and financial services.
Anna Lucía Alfaro Dardón
Dr. Ivan Alfaro
Guía para hacer un Plan de Negocio para tu emprendimiento.pdfpppilarparedespampin
Esta Guía te ayudará a hacer un Plan de Negocio para tu emprendimiento. Con todo lo necesario para estructurar tu proyecto: desde Marketing hasta Finanzas, lo imprescindible para presentar tu idea. Con esta guía te será muy fácil convencer a tus inversores y lograr la financiación que necesitas.
El análisis PESTEL es una herramienta estratégica que examina seis factores clave del entorno externo que podrían afectar a una empresa: políticos, económicos, sociales, tecnológicos, ambientales y legales.
1. Entendiendo
el
Tríangulo
de
Hierro
en
Agile
Guía
tenta3va
para
el
manejo
de
Propuestas
y
Es3mación
de
Features
Un enfoque para manejar una propuesta de desarrollo de software a
través de varios equipos.
Johnny Ordóñez
4. En Ágil el foco se encuentra en priorizar aquellas
características que aportan mayor Valor y que el Cliente
puede pagar.
5. Aproximadamente, sólo entre el 20% - 30% de la funcionalidad del sistema agrega valor a
las actividades del usuario. Las funciones restantes casi no se usan.
- Standish Group Chaos Report 2011
“
”
Porcentaje de Uso de la Funcionalidad de un Sistema Típico
7,0%
13,0%
16,0%
19,0%
45,0%
Siempre
A
menudo
Regularmente
Raramente
Nunca
Fuente: Standish Group Chaos Report 2011: http://www.projectsmart.co.uk/docs/chaos-report.pdf
A menudo / Siempre
usado
20%
Raramente / Nunca
usado
64%
6. Caracterís4cas
usadas
en
un
Sistema
de
So7ware
9pico
7,0%
13,0%
16,0%
19,0%
Chaos Report 2011, Standish Group
Always
Often
45,0% Regularly
Rarely
Never
80% del Valor de
Negocio está ubicado en
el 20% de las Features
(Pareto).
20% Busque el 20%
A menudo /
Siempre usado
Raramente /
Nunca usado
64%
Fuente: Standish Group Chaos Report 2011: http://www.projectsmart.co.uk/docs/chaos-report.pdf
7. En Ágil el foco se encuentra en la entrega de lo que el
Cliente percibe sobre lo que es Valor y la Calidad.
10. Product Backlog
Project
Planning
Release
Planning
Sprint
Planning
EPIC EPIC EPIC EPIC
Feature Feature Feature Feature
User
Story
User
Story
User
Story
User
Story
User
Story
Task Task Task Task Task
Task Board
Alto Nivel
Tallas (XS, S, M, L, XL)
Bajo Nivel
Story Points (Fibonacci)
Muy Bajo Nivel
Horas (duración < 1 día)
Niveles
de
Abstracción
de
un
Backlog
Nivel Medio
Tallas y equivalencias
12. Niveles
de
Es4mación
para
Features
Fuente: Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise
http://www.amazon.com/Agile-Software-Requirements-Enterprise-Development/dp/0321635841
http://bit.ly/1HS7lHH
13. Niveles
de
Es4mación
Estimación Preliminar (﴾Preliminary Relative Estimate)﴿
Estimación inicial realizada por el equipo de Producto (Product Managers, Technical Account Managers,
Arquitectos, etc.). Alto nivel de entendimiento. Se usa para comprender la “magnitud” de una Feauture
frente a otra. Dependiendo de la complejidad puede ser estimada por PMs o necesitar feedback adicional
de Arquitectos de Sistema, Equipos de Desarrollo. Se usan Tallas y Planning Poker.
Estimación Refinada (﴾Gross Absolute Estimate)﴿
Siguiente nivel de fidelidad de estimación. Sirve para realizar una aproximación de costos y tiempos
potenciales. Se usan comparaciones históricas con Features similares ya realizadas obteniendo puntos de
historia relativos.
Estimación Final (﴾Derived Relative Estimate)﴿
Estimación refinada realizada por los equipos a través de la comprensión más granular de la complejidad y
desafíos de la implementación. Cuando se trata de muchos equipos se puede armar un comité e incluir a
Arquitectos, Operaciones y representantes de varios equipos. Es posible descomponer en Historias y
estimarlas individualmente, donde la suma de las historias será el valor de estimación de la Feature. A nivel
de Features se usan Tallas con una equivalencia en puntos que sirve como referencia. (La tabla de
equivalencia se revisa periódicamente frente a las heurísticas de las organización).
15. Ley
de
LiDle
Número promedio
Tiempo de items en cola
promedio de
espera
Tasa promedio de
atención de un
item en un tiempo
=
Lq
Wq
=
16. Ley
de
LiDle
aplicada
a
un
Backlog
Número de Items
Tiempo en el Backlog
promedio de
espera
Promedio de Items
entregados por
Iteración
=
Lq
Wq
=
17. Ley
de
LiDle
aplicada
a
un
Backlog
Lq
Wq
=
Tiempo 100 historias
promedio de
espera
= = 12,5 iteraciones
8 historias /
iteración
*
18. Ley
de
LiDle
aplicada
a
un
Backlog
• Mismos miembros de equipo juntos durante 3 sprints al menos
• Velocidad estable de los equipos asigandos (﴾Varianza de los últimos 3 sprint ≤
20% -‐ Heurística)﴿
• Batch-‐size / Tamaño de las historias relativamente constante (﴾en lo posible)﴿
Tiempo 100 historias
promedio de
espera
= = 12,5 iteraciones
8 historias /
iteración
*
*
19. Op4mizando
el
Flujo
• Incrementar Lambda (﴾Story completion ratio)﴿
• Buen mapa de dependencias (﴾Program Board)﴿
• Buen entendimiento de la Historia y criterios de aceptación
• Grooming del Backlog
• Criterio de Readiness de las Historias
• Manejo de la Densidad de Soportes y Bugs por Sprint (﴾heurísticas)﴿
• Mejorar el Throughput
• Reducir el tamaño del batch-‐size / historias
• Reducir el tamaño de la cola
• Aplicar WIPs
• Gestión de Riesgos e Impedimentos
22. Manejo
de
una
Oportunidad
RFP
GAP
Análisis
Feature
1
Feature
2
Feature
3
Feature
4
Feature
5
Feature
N
1
Descomponer
en Features
Alcance
23. Manejo
de
una
Oportunidad
RFP
GAP
Análisis
Feature
1
Feature
2
Feature
3
Feature
4
Feature
5
Feature
N
1
Descomponer
en Features
2
Estimar
las
Features
Alcance
Es4mación
del
Costo
de
Espera
Es4mación
del
Esfuerzo
24. Manejo
de
una
Oportunidad
RFP
GAP
Análisis
Feature
1
Feature
2
Feature
3
Feature
4
Feature
5
Feature
N
1
Descomponer
en Features
2
Estimar
las
Features
Alcance
Es4mación
del
Costo
de
Espera
Es4mación
del
Esfuerzo
25. Criticidad de
Tiempo
Es4mación
del
Costo
de
la
Espera
Valor Usuario |
Valor de Negocio
Costo de la
Espera
Reducción de
Riesgos |
Habilitación de
Oportunidad
= + +
26. Es4mación
del
Costo
de
la
Espera
Equipo
de
Producto
7 +/-‐ 2 personas
Product Managers
Product Owners
Business Owners (﴾opcional)﴿
PM
PO
PO
BO
PM
Uso
de
Puntos
de
Valor
de
Negocio
Planning Poker
Serie de Fibonacci
1 pts
2 pts
3 pts
5 pts
8 pts
13 pts
30 pts
27. Manejo
de
una
Oportunidad
RFP
GAP
Análisis
Feature
1
Feature
2
Feature
3
Feature
4
Feature
5
Feature
N
1
Descomponer
en Features
2
Estimar
las
Features
Alcance
Es4mación
del
Costo
de
Espera
Es4mación
del
Esfuerzo
28. Es4mación
del
Esfuerzo
(Job
Size)
Comité
de
Es4mación
7 +/-‐ 2 personas
Representantes de los equipos
Representantes de Arquitectura
Representantes de Operaciones
Team
Team
Team
Architect
DevOps
Uso
de
Tallas
(T-‐Shirt
Sizes)
Nivel de Abstracción Medio
Planning Poker
Equivalencia a Story points
(ajustable en el tiempo)
XS => 5 pts
S
=> 8 pts
M => 13 pts
L
=> 30 pts
XL => 40 pts
XXL => 100 pts
29. Es4mación
del
Esfuerzo
(Job
Size)
Comité
de
Es4mación
7 +/-‐ 2 personas
Representantes de los equipos
Representantes de Arquitectura
Representantes de Operaciones
Team
Team
Team
Architect
DevOps
Uso
de
Tallas
(T-‐Shirt
Sizes)
Nivel de Abstracción Medio
Planning Poker
Equivalencia a Story points
(ajustable en el tiempo)
XS => 5 pts
S
=> 8 pts
M => 13 pts
L
=> 30 pts
XL => 40 pts
XXL => 100 pts
Alto nivel de
Incertidumbre
(Sugerencia:
Descomponer)
30. Manejo
de
una
Oportunidad
RFP
GAP
Análisis
Feature
1
Feature
2
Feature
3
Feature
4
Feature
5
Feature
N
1
Descomponer
en Features
Alcance
100
40
13
30
100
40
Ej: 1000 pts
2
Es4maciones
de
Esfuerzo
Job Sizes
Equivalencia de las Tallas
31. 2
Alcance en Story Points
Manejo
de
una
Oportunidad
RFP
GAP
Análisis
Feature
1
Feature
2
Feature
3
Feature
4
Feature
5
Feature
N
1
Descomponer
en Features
Alcance
100
40
13
30
100
40
Ej: 1000 pts
Es4maciones
de
Esfuerzo
Job Sizes
Equivalencia de las Tallas
33. Interpretando
el
Triángulo
de
Hierro
en
Agile
Story
Points
Tamaño del Backlog
# Sprints
Alcance
# Equipos
Duración
1 mes = 2 sprints
6 meses = 12 sprints
#Equipos
#Personas por Equipo
Costos
40. Escenario
3:
Tiempo
Fijo,
Costo
Fijo
Variables
Alcance
= ??
#Sprints
= 10
#Equipos
= 2
Velocidad por Sprint
= Velocidad Histórica Equipo 1 + Velocidad Histórica Equipo 2
(Equipos conocidos)
= 20 pts/sprint + 35 pts/sprint
= 55 pts/sprint
Proyecciones
Velocidad por Sprint
= Velocidad Histórica Referencial Organizacional x #Equipos
(Equipos desconocidos)
= 25 pts/sprint x 2 equipos = 50 pts/sprint
Alcance proyectado
= Velocidad por Sprint de los Equipos x #Sprints
= 55 pts/sprint x 10 sprints
= 550 pts
41. Fijo
Variable
Escenario
4:
Alcance
Fijo,
Tiempo
Fijo,
Costo
Fijo
# Sprints
Alcance
# Equipos
Cómo manejar un
contrato con todas las
restricciones fijas?
42. Fijo
Variable
Escenario
4:
Alcance
Fijo,
Tiempo
Fijo,
Costo
Fijo
# Sprints
Alcance
# Equipos
Cómo manejar un
contrato con todas las
restricciones fijas?
Riesgo muy Alto
43. Fijo
Variable
Escenario
4:
Alcance
Fijo,
Tiempo
Fijo,
Costo
Fijo
3
# Sprints
Alcance
2
# Equipos
Cómo manejar un
contrato con todas las
restricciones fijas?
1
Traduzca los costos en
equipos y determine con
cuántos equipos trabajar
Negocie el Alcance
Priorice el Alcance
44. Escenario
4:
Alcance
Fijo,
Tiempo
Fijo,
Costo
Fijo
Variables
Alcance
= 1000 pts
#Sprints
= 10
Costo|Presupuesto = USD $100.000,00
#Equipos
= ??
1
Traduzca los costos en
equipos y determine con
cuántos equipos trabajar
Presupuesto por Sprint
= Costo|Presupuesto ÷ #Sprints
= USD $ 100.000,00 ÷ 10 sprints = 10.000 USD/sprint
Costo por Sprint Equipo
= Σ (﴾Valor por Hora * #Horas asignadas al Sprint)﴿ de cada Rol
= USD $ 5.272,50
Proyecciones
Presupuesto por Sprint
#Equipos requeridos
= Σ
≈ 2 equipos
k=1
Costo por Sprint por Equipo
45. Escenario
4:
Alcance
Fijo,
Tiempo
Fijo,
Costo
Fijo
Variables
Alcance
= 1000 pts
#Sprints
= 10
Costo|Presupuesto = USD $100.000,00
#Equipos
= 2
2
Negocie el Alcance
Velocidad por Sprint
= Velocidad Histórica Equipo 1 + Velocidad Histórica Equipo 2
(Equipos conocidos)
= 20 pts/sprint + 35 pts/sprint
= 55 pts/sprint
Proyecciones
Velocidad por Sprint
= Velocidad Histórica Referencial Organizacional x #Equipos
(Equipos desconocidos)
= 25 pts/sprint x 2 equipos = 50 pts/sprint
Alcance proyectado
= Velocidad por Sprint de los Equipos x #Sprints
= 55 pts/sprint x 10 sprints
= 550 pts
46. Escenario
4:
Alcance
Fijo,
Tiempo
Fijo,
Costo
Fijo
Variables
2
Negocie el Alcance
Alcance proyectado
= Velocidad por Sprint de los Equipos x #Sprints
= 55 pts/sprint x 10 sprints
= 550 pts
Nuevo
alcance
(Sugerencia:
Fase
1:
550
pts,
Fase
2:
450
pts)
Alcance
= 1000 pts
#Sprints
= 10
Costo|Presupuesto = USD $100.000,00
#Equipos
= 2
Velocidad por Sprint
= Velocidad Histórica Equipo 1 + Velocidad Histórica Equipo 2
(Equipos conocidos)
= 20 pts/sprint + 35 pts/sprint
= 55 pts/sprint
Proyecciones
Velocidad por Sprint
= Velocidad Histórica Referencial Organizacional x #Equipos
(Equipos desconocidos)
= 25 pts/sprint x 2 equipos = 50 pts/sprint
47. Escenario
4:
Alcance
Fijo,
Tiempo
Fijo,
Costo
Fijo
Feature
1
Feature
2
Feature
3
Feature
4
Feature
5
Feature
N
3
Priorizar
Backlog
Alcance
Es4mación
del
Costo
de
Espera
Es4mación
del
Esfuerzo
100
40
13
30
100
40
Ej: 1000 pts
WSJF =
Alcance
Priorizado
Feature
4
Feature
2
Feature
1
Feature
3
Feature
5
Feature
N
30
40
100
13
100
40
Ej: 1000 pts
Fase 1
550 pts
Fase 2
450 pts
49. Costo
de
un
Sprint
(enfoque
aproximado)
Rol
%
Asignación
al
Sprint*
Horas
asignadas
al
Sprint
Sueldo*
Valor
por
Hora
Valor
en
el
Sprint
por
Rol
Team
Member
1
100%
80
$
1.500,00
$
9,38
$
750,00
Team
Member
2
100%
80
$
1.500,00
$
9,38
$
750,00
Team
Member
3
100%
80
$
1.500,00
$
9,38
$
750,00
Team
Member
4
100%
80
$
1.500,00
$
9,38
$
750,00
Team
Member
5
100%
80
$
1.500,00
$
9,38
$
750,00
Scrum
Master
33%
26,4
$
1.500,00
$
9,38
$
247,50
Product
Owner
50%
40
$
1.500,00
$
9,38
$
375,00
Product
Manager
25%
20
$
1.500,00
$
9,38
$
187,50
Arquitecto
20%
16
$
1.500,00
$
9,38
$
150,00
Operaciones
1
25%
20
$
1.500,00
$
9,38
$
187,50
Operaciones
2
25%
20
$
1.500,00
$
9,38
$
187,50
Release
Manager
25%
20
$
1.500,00
$
9,38
$
187,50
COSTO
POR
SPRINT
EQUIPO
AAA
$
5.272,50
50. Estructura
de
Costos
de
un
Sprint/Release
(Estructura
aproximada)
Otros costos: Capacitación, Lunches, movilización, estadías, viajes, etc.
Costos de Ventas, Gerencia del Proyecto, otros.
Costo distribuido de Hardware, licencias de software, hosting, etc.
Costo de Puesta en Producción: Migración, Instalación, Configuración.
Costos de Roles asignados
(﴾Construcción ~60-70% del Producto)﴿
(Depende de la
Organización)
Private
&
Confiden3al
50
~10-20%
(Depende de la
Organización)
Volver
52. Velocidad
histórica
de
Referencia
–
Evolución
del
Equipo
EQUIPO 1
Sprint
Story
Points
Aceptados
Sprint
1
8
Sprint
2
5
Sprint
3
3
Sprint
4
5
Sprint
5
6
9
8
7
6
5
4
3
2
1
0
Sprint
1
Sprint
2
Sprint
3
Sprint
4
Sprint
5
Story
Points
Aceptados
53. Velocidad
histórica
de
Referencia
–
Evolución
del
Equipo
EQUIPO 1
Sprint
Story
Points
Aceptados
Sprint
1
8
Sprint
2
5
Sprint
3
3
Sprint
4
5
Sprint
5
6
9
8
7
6
5
4
3
2
1
0
Sprint
1
Sprint
2
Sprint
3
Sprint
4
Sprint
5
Promedio = 5 pts
Story
Points
Aceptados
Promedio
= 5 pts
54. Velocidad
histórica
de
Referencia
–
Evolución
del
Equipo
EQUIPO 1
Sprint
Story
Points
Aceptados
Sprint
1
8
Sprint
2
5
Sprint
3
3
Sprint
4
5
Sprint
5
6
9
8
7
6
5
4
3
2
1
0
Sprint
1
Sprint
2
Sprint
3
Sprint
4
Sprint
5
Promedio = 5 pts
Story
Points
Aceptados
2 pts
2 pts
Promedio
= 5 pts
Desviación estándar
= 2 pts
55. Velocidad
histórica
de
Referencia
–
Evolución
del
Equipo
EQUIPO 1
Sprint
Story
Points
Aceptados
Sprint
1
8
Sprint
2
5
Sprint
3
3
Sprint
4
5
Sprint
5
6
9
8
7
6
5
4
3
2
1
0
Sprint
1
Sprint
2
Sprint
3
Sprint
4
Sprint
5
Promedio = 5 pts
Story
Points
Aceptados
2 pts
2 pts
Promedio
= 5 pts
Desviación estándar
= 2 pts
Mejor velocidad
= 7 pts
Velocidad esperada
= 5 pts
Peor velocidad
= 3 pts
Mejor caso = 7 pts
Peor caso = 3 pts
56. Velocidad
histórica
de
Referencia
–
Evolución
del
Equipo
EQUIPO 1
Sprint
Story
Points
Aceptados
Sprint
1
8
Sprint
2
5
Sprint
3
3
Sprint
4
5
Sprint
5
6
Promedio
= 5 pts
Desviación estándar
= 2 pts
Mejor velocidad
= 7 pts
Velocidad esperada
= 5 pts
Peor velocidad
= 3 pts
Story
points
7 pts
Tiempo
Fijo
Semana 1
Semana 2
5 pts
3 pts
57. Velocidad
histórica
de
Referencia
–
Evolución
del
Equipo
EQUIPO 1
Sprint
Story
Points
Aceptados
Sprint
1
8
Sprint
2
5
Sprint
3
3
Sprint
4
5
Sprint
5
6
Promedio
= 5 pts
Desviación estándar
= 2 pts
Mejor velocidad
= 7 pts
Velocidad esperada
= 5 pts
Peor velocidad
= 3 pts
Story
Points
10 pts
Alcance
Fijo
Semana 2
+ X días
Semana 2
+ X + Y
días
7 pts
Semana 1
Semana 2
58. Velocidad
histórica
de
Referencia
–
Evolución
del
Equipo
EQUIPO 1
Sprint
Story
Points
Aceptados
Sprint
1
8
Sprint
2
5
Sprint
3
3
Sprint
4
5
Sprint
5
6
Promedio
= 5 pts
Desviación estándar
= 2 pts
Mejor velocidad
= 7 pts
Velocidad esperada
= 5 pts
Peor velocidad
= 3 pts
Story
Points
Sprint 1
Sprint 2
Sprint 3
Sprint 4
Velocidad
en
el
4empo
59. Velocidad
histórica
de
Referencia
–
Evolución
del
Equipo
EQUIPO 1
Sprint
Story
Points
Aceptados
Sprint
1
8
Sprint
2
5
Sprint
3
3
Sprint
4
5
Sprint
5
6
Promedio
= 5 pts
Desviación estándar
= 2 pts
Mejor velocidad
= 7 pts
Velocidad esperada
= 5 pts
Peor velocidad
= 3 pts
Seleccione
una
velocidad
dependiendo
del
escenario
Escenarios: Op9mista,
Esperado
o
Pesimista
Velocidad Real = 5 pts (﴾Esperado)﴿
60. Velocidad
histórica
de
Referencia
–
Evolución
del
Equipo
EQUIPO 1
Sprint
Story
Points
Aceptados
Sprint
1
8
Sprint
2
5
Sprint
3
3
Sprint
4
5
Sprint
5
6
Promedio
= 5 pts
Desviación estándar
= 2 pts
Mejor velocidad
= 7 pts
Velocidad esperada
= 5 pts
Peor velocidad
= 3 pts
Seleccione
una
velocidad
dependiendo
del
escenario
Escenarios: Op9mista,
Esperado
o
Pesimista
Velocidad Real = 5 pts (﴾Esperado)﴿
Agregue
una
perspec4va
de
Riesgos
Factor
de
Dispersión
o
Riesgos:
Rotación, Vacaciones, Enfermedad
Factor de Dispersión = Pérdida (﴾points)﴿ * % Probabilidad
= 2 pts * 30 % = 0,6 pts
61. Velocidad
histórica
de
Referencia
–
Evolución
del
Equipo
Seleccione
una
velocidad
dependiendo
del
escenario
Escenarios: Op9mista,
Esperado
o
Pesimista
Velocidad Real = 5 pts (﴾Esperado)﴿
Velocidad para
Proyecciones = Velocidad real – Factor de Dispersión
= 5 – 0.6 pts = 4.4 => 4 pts
EQUIPO 1
Sprint
Story
Points
Aceptados
Sprint
1
8
Sprint
2
5
Sprint
3
3
Sprint
4
5
Sprint
5
6
Promedio
= 5 pts
Desviación estándar
= 2 pts
Mejor velocidad
= 7 pts
Velocidad esperada
= 5 pts
Peor velocidad
= 3 pts
Agregue
una
perspec4va
de
Riesgos
Factor
de
Dispersión
o
Riesgos:
Rotación, Vacaciones, Enfermedad
Factor de Dispersión = Pérdida (﴾points)﴿ * % Probabilidad
= 2 pts * 30 % = 0,6 pts
62. Velocidad
histórica
de
Referencia
–
Evolución
del
Equipo
Seleccione
una
velocidad
dependiendo
del
escenario
Escenarios: Op9mista,
Esperado
o
Pesimista
Velocidad Real = 5 pts (﴾Esperado)﴿
Velocidad para
Proyecciones = Velocidad real – Factor de Dispersión
= 5 – 0.6 pts = 4.4 => 4 pts
Velocidad para
Proyecciones = 4 pts
EQUIPO 1
Sprint
Story
Points
Aceptados
Sprint
1
8
Sprint
2
5
Sprint
3
3
Sprint
4
5
Sprint
5
6
Promedio
= 5 pts
Desviación estándar
= 2 pts
Mejor velocidad
= 7 pts
Velocidad esperada
= 5 pts
Peor velocidad
= 3 pts
Agregue
una
perspec4va
de
Riesgos
Factor
de
Dispersión
o
Riesgos:
Rotación, Vacaciones, Enfermedad
Factor de Dispersión = Pérdida (﴾points)﴿ * % Probabilidad
= 2 pts * 30 % = 0,6 pts
63. Estabilidad
de
la
Velocidad
de
un
Equipo
Varianza de los 20%
últimos 3 sprints
Velocidad
Estable*
≈ ≤
Volver
• Mismos miembros de equipo (﴾ juntos durante 3 sprints al menos)﴿
• Misma tecnología
• Mismo producto o dominio
*
65. Factores
que
influyen
en
el
desempeño
de
un
equipo
• Conocimientos previos
• Capacidad de aprendizaje
• Habilidades y Experiencia
• Impedimentos y perturbaciones externas
• Dinámica del equipo (﴾interrelaciones)﴿
• Reasignaciones
• Foco
• Nuevos integrantes
• Tiempo trabajando en el mismo proyecto o tecnología
• Ambiente de trabajo, disposición física
• Moral del equipo / Felicidad
66. Factores
que
influyen
en
el
compromiso
de
un
equipo
Auto-‐
organización
Autonomía
Peer-‐to-‐ Liderazgo
Peer
Toma
de
Decisiones
Delegación
Team
Engagement
Empoderamiento
67. Análisis
de
los
Criterios
para
la
asignación
de
equipos
Skills
Experiencia Previa
Co-‐localización
# Iteraciones ejecutadas
Velocidad estable
Atención de Bugs y Soportes
Disponibilidad general
Cohesión de Equipo
Criticidad
Estabilidad de
Requerimientos
Riesgos
Costos
Cumplimiento general
Del Equipo
Del Proyecto
Disponibilidad y
Readiness de
Ambientes
68. Criterios
para
la
asignación
de
Equipos
a
un
Proyecto
CRITERIO
DESCRIPCIÓN
Skills
Comprensión general de las habilidades y conocimientos que
representan la fortaleza del equipo. Por ejemplo: Java, VB, HTML 5,
etc.
Experiencia previa
Conocimientos y experiencia del equipo sobre la tecnología,
arquitectura, negocio y Cliente del proyecto a asignar.
Co-‐localización
Si los miembros del equipo trabajarán en una misma ubicación física,
incluyendo el Product Owner y Scrum Master. También sirve para
identificar si se trabaja en las instalaciones de un Cliente o no.
Iteraciones ejecutadas
Comprensión general de si los miembros del equipo han trabajado
juntos durante varios periodos.
Velocidad estable
Entendimiento general sobre la estabilidad de equipo. Se puede tomar
la varianza de la velocidad real de las últimas tres iteraciones (﴾<= 20%)﴿
69. Criterios
para
la
asignación
de
Equipos
a
un
Proyecto
CRITERIO
DESCRIPCIÓN
Atención de Bugs y
Soportes
Comprensión general del volumen de bugs y de soportes externos que
atiende el equipo históricamente. Se puede revisar las métricas de
Densidad de Bugs y Densidad de Soportes por Sprint (﴾al menos 3 sprints)﴿.
Disponibilidad general
Comprensión general de la disponibilidad de los miembros del
equipo para el período que será asignado al proyecto (﴾vacaciones
programadas, permisos anticipados, etc.)﴿
Cumplimiento general
Comprensión general del cumplimiento histórico del equipo sobre los items
planificados del backlog. Se puede revisar las métricas Ratio de Completitud
de Puntos de Historia, Ratio de Completitud de Historias (﴾al menos 3 sprints)﴿.
Cohesión de Equipo
Percepción general de la unidad y solidez del equipo, de su dinámica
trabajando juntos, interelación, resolución de problemas y toma de
decisiones como equipo. Evaluación del nivel de autorganización y
motivación.
70. Criterios
para
la
asignación
de
Equipos
a
un
Proyecto
CRITERIO
DESCRIPCIÓN
Criticidad
La criticidad del Proyecto desde el punto de vista de negocio. Asociado a
la variable Time Criticality del WSJF. El valor de este campo es la respuesta
a la pregunta: Qué tan crítico es este proyecto para el negocio?
Estabilidad de
Requerimientos
Nivel de claridad y de definición de las características, objetivos y
necesidades del Proyecto. Si el alcance no es claro, entonces falta
estabilidad.
Riesgos
Asociado a la variable Risk Reduction del WSJF. Responde a los
riesgos conocidos asociados al Proyecto. Puede evaluarse con el
mecanismo RAID: Risks, Assumptions, Issues and Dependencies.
Costos
El criterio de costos es de utilidad para acotar la asignación de los equipos en
función de su costo por sprint. Si los equipos cumplen los demás criterios, pero
sobrecargan los costos, debe considerarse este criterio para la reasignación.
Disponibilidad y
Readiness de Ambientes
Si se cuenta o se puede contar con los ambientes necesarios para el
desarrollo y tomando el tiempo en el que este puede estar disponibles a
los equipos en cada sprint.
76. Velocidad
histórica
de
Referencia
–
Evolución
del
Equipo
DESEMPEÑO
ORGANIZACIONAL
Sprint
Story
Points
Aceptados
Sprint
1
15
Sprint
2
25
Sprint
3
18
Sprint
4
20
Sprint
5
23
30
25
20
15
10
5
0
Sprint
1
Sprint
2
Sprint
3
Sprint
4
Sprint
5
Promedio = 20 pts
Story
Points
Aceptados
Promedio
= 20 pts
Desviación estándar
= 4 pts
Mejor velocidad
= 24 pts
Velocidad esperada
= 20 pts
Peor velocidad
= 16 pts
Mejor caso = 24 pts
Peor caso = 16 pts
77. Velocidad
histórica
de
Referencia
–
Evolución
del
Equipo
DESEMPEÑO
ORGANIZACIONAL
Sprint
Story
Points
Aceptados
Sprint
1
15
Sprint
2
25
Sprint
3
18
Sprint
4
20
Sprint
5
23
30
25
20
15
10
5
0
Sprint
1
Sprint
2
Sprint
3
Sprint
4
Sprint
5
Promedio = 20 pts
Story
Points
Aceptados
Promedio
= 20 pts
Desviación estándar
= 4 pts
Mejor velocidad
= 24 pts
Velocidad esperada
= 20 pts
Peor velocidad
= 16 pts
Mejor caso = 24 pts
Peor caso = 16 pts
Velocidad Organizacional
Referencial ≈ 20 pts / Sprint
78. Velocidad
histórica
de
Referencia
–
Evolución
del
Equipo
DESEMPEÑO
ORGANIZACIONAL
Sprint
Story
Points
Aceptados
Sprint
1
15
Sprint
2
25
Sprint
3
18
Sprint
4
20
Sprint
5
23
Promedio
= 20 pts
Desviación estándar
= 4 pts
Mejor velocidad
= 24 pts
Velocidad esperada
= 20 pts
Peor velocidad
= 16 pts
Story
Points
Sprint 1
Sprint 2
Sprint 3
Sprint 4
Velocidad
de
la
Organización
en
el
4empo
15
25
18
20
Volver
79. Estabilidad
de
la
Velocidad
de
una
Oranización
Varianza de los 27%-‐??%*
últimos 3 sprints
Velocidad
Estable*
≈ ≤
• Mismos equipos durante 3 sprints al menos
• Cada equipo trabajando con su misma tecnología
• Cada equipo trabajando con su mismo producto
• Reasignaciones mínimas o no-‐reasignaciones
• Gestión de riesgos
• Tasa de soportes predecibles
• Manejo de Bugs
• Integración y Operaciones
*
Volver
• Análisis de la Varianza para
determinar comportamiento
estable
• Es complejo definir estabilidad
organizacional, existe un sin
número de factores.
• Se evalúa estabilidad de
equipos por programa.
*