Embed Size (px)
Citation preview
Agilidad/SCRUMCharla tecnológica
https://es.linkedin.com/in/benitezcarlos
2
• Metodologías
• Agile
• Las personas
• Inception
• Historias de usuario
• Las reglas de Scrum
• Planificación ágil
• Scrum nunca viene solo
• Deuda técnica
• Testing ágil
• Escalar Scrum
• Contratos ágiles
• Recursos
• Coloquio
Agenda
3
Metodologías – Ciclo de vida iterativo, cascada y ágil
No existe una metodología de desarrollo software única, mejor y universal; existe una mejor metodología por tipo de proyecto. La predictibilidad, ciclo de vida en cascada o desarrollo tradicional.
4
Metodologías – La moda
En 1950 se incorporó por primera vez el desarrolloiterativo incremental para el software del X-15.
El nacimiento de la ingeniería del software 1968,
en la primera conferencia organizada por la OTAN en Alemania. “Los diseñadores de software están en una posición similar a los arquitectos de ingenierías civiles” Naur.
Rational Unified Process es un proceso de desarrollo de software utilizado junto con UML y que constituye una metodología para el análisis, diseño, implementación y documentación de proyectos software orientados a objetos.Métrica v3 es una metodología de planificación, desarrollo y mantenimiento de sistemas de información, mayormente promovida y utilizada en el ámbito de las administraciones públicas.
El nacimiento de Scrum en el 95 Shutterlandy Schwaber, en el 98 Takeuchi y Nokana.
El “hype cycle” representa cómo
se mueve la adopción de una tecnología.
5
Metodologías – Firmantes del manifiesto agil
6
Metodologías – Valores y Principios Manifiesto Ágil
Valores del Manifiesto Ágil
• Los individuos y su interacción, por encima de los procesos y las herramientas.
• El software que funciona, frente a la documentación exhaustiva.
• La colaboración con el cliente, por encima de la negociación contractual.
• La respuesta al cambio, por encima del seguimiento de un plan.
1.- Satisface a tu cliente
2.- Adáptate al cambio
3.- Entrega frecuentemente
4.- Trabajad juntos cotidianamente
5.- Motiva al equipo
6.- Conversa cara a cara
7.- Mide el software funcionando
8.- Desarrollo sostenible
9.- Excelencia técnica
10.- Simplicidad
11.- Diseño emergente
12.- Retrospectiva
7
• Metodologías
• Agile
• Las personas
• Inception
• Historias de usuario
• Las reglas de Scrum
• Planificación ágil
• Scrum nunca viene solo
• Deuda técnica
• Testing ágil
• Escalar Scrum
• Contratos ágiles
• Recursos
Contenido
Agile - ¿Por qué usar ágil?
Maximizar el valor del cliente
• Entregar incrementos pequeños
• Entregar frecuente
• Entrega de lo “que está hecho”
Aumento de la visibilidad
• Iteraciones demos/revisiones
• Alto compromiso del cliente
• Realimentación continua
• Radiadores de información visuales
Disminución del riesgo
• Visibilidad frecuente de “lo que está hecho”
• Detección de problemas y riesgos
• Automatización de pruebas
• Foco en la calidad
• Inspección y adaptación del plan
Adaptación a necesidades
• Foco en entregar lo de más valor
• Enfoque “just-in-time”
8
Combate uno de los enemigos de un proyecto software, la incertidumbre.Producto perfecto: se entiende que es imposible definir el producto perfecto de antemano, sin que se haya ido validando y puliendo, gracias al contacto con el entorno real.
Agile – El cono de incertidumbre
9
El cono de Incertidumbre describe la evolución de la medida de incertidumbre durante la realización de un proyecto. La incertidumbre no solo se reduce conforme pasa el tiempo, sino que también disminuye su impacto en la gestión de riesgos y toma de decisiones.
Agile - ¿Cuándo usar ágil?
10
en entornos complejos
donde:
• Se necesitan resultados pronto.
• Los requisitos son cambianteso pocos definidos.
• Importancia de la simplicidad,eliminando trabajo innecesario.
• La innovación, lacompetitividad, la flexibilidad yla productividad sonfundamentales.
• Se requiere mejora continua delos procesos y del equipo dedesarrollo.
para resolver situaciones
donde:
• no se está entregando al clientelo que necesita
• las entregas se alargandemasiado
• los costes se disparan o lacalidad no es aceptable
• se necesita capacidad dereacción ante la competencia
• la moral de los equipos es baja yla rotación alta
11
• Metodologías
• Agile
• Las personas
• Inception
• Historias de usuario
• Las reglas de Scrum
• Planificación ágil
• Scrum nunca viene solo
• Deuda técnica
• Testing ágil
• Escalar Scrum
• Contratos ágiles
• Recursos
Contenido
12
Las personas – Productividad
Valores del Equipo de alto rendimiento:
• Buscar a los miembros más adecuados y retenerlos.
• Trabajar en un entorno de productividad, sin interrupciones.
• Conocer el impacto de la “no calidad”.
• Equipos pequeños.
• Equipos multifuncionales.
Trabajar en más de un proyecto genera pérdida de tiempo y disminuye la productividad (desperdicio). “Quality Software Management Volume 1. Systems Thinking” escrito porWeinberg en 1992.
13
Las personas – Productividad
Interrumpir al que realiza cualquier actividad intelectual hace que caiga su productividad (procrastinación y la técnica pomodoro).
Cuando el tamaño del equipo crece más allá de un número de personas , el tiempo del proyecto no se reduce. Putnam 2003.
Quemar y saturar de trabajo al equipo no se traduce en mayores resultados (slack).
El entorno físico y la productividad (música, organización de la sala).
14
Las personas – Motivación de equipos
Los responsables de empresas tienen claro que las personas son el factor más determinante para el éxito o fracaso de un proyecto, y la motivación es la base de la productividad. Hay listas de muchos autores, Jurgen Appelo elaboró en su libro “#Workout: Games, Tools & Practices to Engage People, Improve Work, and Delight Clients (Management 3.0)”una lista de motivadores intrínsecos a la que llamó “Champfrogs Checklist”:
• La curiosidad, conocer cosas nuevas, buscar y absorber información motiva.
• El honor atrae a cierta gente y crea lealtad.
• La Aceptación y la asociación al éxito.
• El aprender motiva a la gente y la gente con conocimiento atrae.
• Poder e Influencia.
• Libertad, Independencia y Autonomía.
• El establecer relaciones motiva.
• Claridad y sinceridad.
• Tener un objetivo y un propósito.
• Estatus.
15
Las personas – Transición de equipos
El modelo de madurez de equipos ágiles.
16
• Metodologías
• Agile
• Las personas
• Inception
• Historias de usuario
• Las reglas de Scrum
• Planificación ágil
• Scrum nunca viene solo
• Deuda técnica
• Testing ágil
• Escalar Scrum
• Contratos ágiles
• Recursos
Contenido
17
Agile Inception es una reunión para preparar a todas las personas implicadas “antes”
del proyecto.
Esta reunión se compone de 10 preguntas y ejercicios, son técnicas que nos ayudarán
a contextualizar y a focalizar a todos los stakeholders.
Así conseguiremos la esencia y la visión compartida para el equipo, teniendo
alineadas a todas las personas que de forma conjunta han establecido sus
expectativas (conseguir que el proyecto no muera antes de empezar).
Definición del Done (DoD)
Inception – Agile Inception
18
1- ¿Por qué estamos aquí? ¿Por qué se necesita/queremos este producto?
2- The Elevator Pitch (1 min).
Explicación de nuestro producto (venta)
Para (persona que se beneficia)
Que (descripción del problema o necesidad)
El (nombre de producto) Es un (categoría del proyecto)
Que (beneficio o razón para comprarlo) A diferencia de (alternativa competitiva)
Nuestro producto (declaración de diferenciación con otros productos)
3- Diseña la caja del producto. Eslogan
4- Lista NOs (que no es mi producto)
5- Conoce a tus vecinos (quién nos puede ayudar, quién compite)
6- Muestra la solución (herramientas, tecnología, arquitectura)
7- Riesgos ¿Qué te quita el sueño?
8- Tamaño (XS, S,.... XXL)
9- Muestra con claridad lo que se va a dar. Prioridad (Quality: Scope, Cost, Time)
Inception – Técnica preguntas y ejercicios
19
El primer paso para escribir las historias de usuario es entender a los usuarios. Las
historias de usuarios hablan sobre aquello que los usuarios harán con el producto…
parece razonable complementar la creación de historias de usuario con “Personas”.
Inception – Técnica Personas
20
• Metodologías
• Agile
• Las personas
• Inception
• Historias de usuario
• Las reglas de Scrum
• Planificación ágil
• Scrum nunca viene solo
• Deuda técnica
• Testing ágil
• Escalar Scrum
• Contratos ágiles
• Recursos
Contenido
21
En las metodologías ágiles la descripción de las necesidades se realiza a partir de
las historias de usuario (user story) que son, lo que el cliente o el usuario quiere que
se implemente; son una descripción breve, de una funcionalidad software tal y como
la percibe el usuario.
El “product owner” (o propietario del producto) es aquella persona con una visión
muy clara del producto que se quiere desarrollar, que es capaz de transmitir esa visión
al equipo de desarrollo y, además, está totalmente disponible para transmitirla.
La figura del product owner es clave en un proyecto ágil, en su planificación y
seguimiento. Es una figura que cuando no realiza correctamente su función el
proyecto tiene un serio riesgo, y problema, llegando incluso a dejar de ser ágil, o
incluso dejando de ser proyecto.
La mayoría de las ocasiones, el negocio, los usuarios, etc., van proporcionando una
cantidad de ideas a implementar, que se van convirtiendo en historias de usuario, muy
superiores en número. La función del product owner es vital, debe ser quien decida
que historias de usuario entran en el product backlog, cuáles no, y además la
prioridad de las historias del product backlog.
Historias de usuario - origen
22
El concepto de historia de usuario tiene sus raíces en la metodología XP
“eXtremeProgramming” o programación extrema. Esta metodología fue creada por
Kent Beck y descrita por primera vez en 1999 en su libro “eXtreme Programming
Explained”. No obstante, las historias de usuario se adaptan de manera apropiada a la
mayoría de las metodologías ágiles, teniendo por ejemplo, un papel muy importante
en la metodología Scrum.
Una historia de usuario debería ser pequeña, memorizable, y que pudiera ser
desarrollada por un par de programadores en una semana. Debido a su brevedad, es
imposible que una historia de usuario contenga toda la información necesaria para
desarrollarla, en tan reducido espacio no se pueden describir aspectos del diseño, de
las pruebas, normativas, convenciones de codificación a seguir, etc.(regla 3c)
Historias de usuario – definición
23
El contenido de la historia de usuario depende del proyecto, pero los más habituales y
necesarios son los siguientes:
Historias de usuario – contenido de tarjeta
24
Según el nivel de detalle, podemos organizar el roadmap de nuestro proyecto en:
• Temas. Grandes proyectos, peticiones globales sin más análisis ni detalles.
• Epics. “Super” historias de usuario, más concretas que los temas.
• Historias de usuario. Una manera simple de describir una tarea concisa con valor.
• Tareas. La división de historias de usuario por necesidades técnicas.
Historias de usuario - tipología
25
Los ítems del Product backlog, deben estar priorizados, es decir, deben tener
asignados un valor por el Product Owner.
Una manera rápida de asignar valor a las historias es dividirlas en 3 grupos, según
sean imperativas, importantes o prescindibles.
Otra método de dar valor es MoSCoW
Must, Should, Could, Won´t
Estimación Planning Poker, por talla de camisetas …
Historias de usuario – valor
26
• Metodologías
• Agile
• Las personas
• Inception
• Historias de usuario
• Las reglas de Scrum
• Planificación ágil
• Scrum nunca viene solo
• Deuda técnica
• Testing ágil
• Escalar Scrum
• Contratos ágiles
• Recursos
Contenido
Scrum – El framework
SCRUM es un marco iterativo ágil diseñado para entregar software funcionando (valor al
cliente) de forma frecuente. Se puede adoptar de forma técnica, aplicando reglas definidas,
o pragmática, adoptando los valores originales de scrum con reglas personalizadas.
27
Roles (3)
• Cliente:
define los requerimientos que conforman el producto. Es la voz del cliente en el proyecto
• Scrum master: facilitador; asegura que el equipo es funcional y productivo. Vela por el cumplimiento de la metodología
• Equipo: auto-organizado para llevar a cabo el trabajo
Artefactos (3)
• Product backlog: • lista de funcionalidades
ordenada y priorizada por el cliente y estimadas por el equipo.
• Deben ser simples para no generar complejidades ni retrabajo.
• Sprint backlog: • Conjunto de trabajo que el
equipo aborda en un Sprint
• No se modifica durante la iteración
• Incremento de producto:
• Entregable, producto de la iteración
Ceremonias (5)
• Planificación de la iteración
• Revisión diaria
• Revisión de la iteración
• Retrospectiva
• Refinamiento de la pila de producto (antes grooming)
Scrum - Roles
28
Scrum - Roles
29
Scrum - Roles
30
Scrum – Reglas
31
Scrum – Proceso
32EST
PLA
REQ
DTE
PPT
PPF
CONS
DEPL
Definirpuntos de
historia
Estimación de tareas
Equipo: ARQ, AT, PR, INT
Scrum master
PRU
Tester
Product Owner
Equipo
Definirhistorias de
usuario
Definir alcance iteración y tareas
a realizar
Seguimiento diario
Product Owner
Scrum Master
DFU
Tareas ADM DW
Calidad e integración
continua
Product owner
Scrum Master
Equipo
Equipo
Equipo
Equipo Equipo
Equipo
Equipo
Scrum Master
33
• Metodologías
• Agile
• Las personas
• Inception
• Historias de usuario
• Las reglas de Scrum
• Planificación ágil
• Scrum nunca viene solo
• Deuda técnica
• Testing ágil
• Escalar Scrum
• Contratos ágiles
• Recursos
Contenido
34
En la actualidad el desarrollo software sigue afectado por graves problemas que
suelen ser algunos de estos:
• Los proyectos no se ajustan al presupuesto inicial.
• El software no cumple las especificaciones.
• Existe una baja calidad del software generado.
• Son entregados fuera de plazo.
• El código a veces es inmantenible.
Planificación ágil – problemas frecuentes
35
Y los errores que se producen más a menudo están relacionados con los aspectos de
estimación, como pueden ser los siguientes:
• Calendario optimista
• Expectativas no realistas
• Confundir estimaciones con objetivos (compromisos)
• Omisión de estimar tareas necesarias
Estos problemas dificultan la gestión, planificación y evolución de los proyectos. Las
prácticas ágiles no escapan a este problema y de hecho, por estar asociadas a
requisitos cambiantes el desafío es mayor.
Planificación ágil – errores frecuentes
36
Históricamente, la unidad clásica de estimación del “tamaño” de un requisito ha sido
el Punto Función. Pero, en los últimos años, los puntos historia se han convertido en
una unidad de tamaño muy usada, principalmente en proyectos ágiles.
Un punto historia es una fusión de
• La cantidad de esfuerzo que supone desarrollar la historia de usuario
• La complejidad de su desarrollo
• El riesgo inherente
Pero, hoy en día, existe la postura mayoritaria de que los puntos historia no son tanto
“complejidad”, sino más bien “esfuerzo ideal” medido en jornadas. Y normalmente se
selecciona una historia de las más pequeñas y asignarle 1 punto historia.
La velocidad es la suma de puntos de historia terminados por Sprint.(Histórico)
Planificación ágil – unidad de estimación punto historia
37
El Planning Poker es una técnica que se utiliza para asignar los puntos historia a las
historias de usuario. Esta técnica recibe el nombre de Planning Poker ya que cada una
de las personas implicadas en el proceso de estimación toma un mazo de cartas que
suelen estar numeradas con alguna de las secuencias que vimos antes (por ejemplo la
de Fibonacci).
La técnica de Planning Poker está basada en el consenso y es utilizada para estimar el
esfuerzo o el tamaño relativo de las tareas de desarrollo de software.
Los pasos a seguir en el Planning Poker son los siguientes:
• Presentación de requisitos
• Elección de la carta (estimación)
• Publicación
• Consenso
Planificación ágil – Planning Poker
38
Algunas métricas típicas de seguimiento de proyectos son las siguientes:
• Tradicional.
Tiempo real vs Tiempo estimado
% Avance
• Ágil con estimaciones
Velocidad (trabajo completado por Sprint)
Puntos de historia
Burn down/up
• Ágil #noEstimates
Valor entregado
Historias de usuario completadas
Planificación ágil – #noEstimates
39
• Metodologías
• Agile
• Las personas
• Inception
• Historias de usuario
• Las reglas de Scrum
• Planificación ágil
• Scrum nunca viene solo
• Deuda técnica
• Testing ágil
• Escalar Scrum
• Contratos ágiles
• Recursos
Contenido
40
Uno de los principales focos de aplicación de las metodologías ágiles son los proyectos
tecnológicos. Cada una de ellas tiene sus fortalezas y sus debilidades, pero no son excluyentes.
En cada proyecto podemos adoptar una, o varias, en función de las características del propio
proyecto y del equipo.
Entre las modelos ágiles más usadas se encuentran:
• LEAN: síntesis de principios alrededor de eliminar desperdicios.
• SCRUM: nos proporciona una serie de herramientas y roles para, de una forma
iterativa, poder ver el progreso y los resultados de un proyecto.
• KANBAN: se basa en una idea muy simple. Ésta es que el trabajo en curso (Work In
Progress, WIP) debería limitarse y sólo deberíamos empezar con algo nuevo cuando
un bloque de trabajo anterior haya sido entregado o ha pasado a otra función
posterior de la cadena. (lead y cycle time)
• XP: centrada en potenciar las relaciones interpersonales como clave d éxito en
desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el
aprendizaje de los desarrolladores y propiciando un buen clima de trabajo.
Frameworks
41
El objetivo del método KANBAN es gestionar de manera general cómo se van completando
tareas.
Las principales ventajas de esta metodología es que es muy fácil de utilizar, actualizar y
asumir por parte del equipo.
Además, destaca por ser una técnica de gestión de las tareas muy visual, que permite ver a
golpe de vista el estado de los proyectos, así como también pautar el desarrollo del trabajo
de manera efectiva.
Frameworks - KANBAN
El método Kanban es especialmente
indicado para aquellos proyectos que
requieran de flexibilidad en la entrada de
tareas, así como en el seguimiento de
estas, la priorización, la supervisión del
equipo de trabajo y los informes de
dedicación.
42
Frameworks – Estrategia KANBAN
Se prioriza el trabajo que está encurso en vez de empezar nuevastareas. el trabajo en curso debeestar limitado y, por tanto, existe unnúmero máximo de tareas a realizaren cada fase.
La metodología Kanban no seaplica a un único proyecto,sino que mezcla tareas yproyectos. Se trata demantener a los trabajadorescon un flujo de trabajoconstante, las tareas másimportantes en cola para serdesarrolladas y un seguimientopasivo.
Tablero donde cada una de lascolumnas corresponderá a unestado concreto del flujo detareas, que nos servirá para saberen qué situación se encuentracada proyecto. Debe seraccesible para los miembros delequipo.
4- Control del Flujo
3- Stop Starting, start finishing
Kanban se basa en el principio dedesarrollo incremental, dividiendo eltrabajo en distintas partes. Cada una deesas partes se escribe en un post-it y sepega en el tablero, en la fase quecorresponda
2- Visualizar las fases del ciclode producción
1- Definir el flujo de trabajo de losproyectos
43
Design Thinking – Proceso para resolver problemas
Comenzarás recolectando mucha información, generando una gran cantidad de
contenido, que crecerá o disminuirá dependiendo de la fase en la que te
encuentres.
44
• Metodologías
• Agile
• Las personas
• Inception
• Historias de usuario
• Las reglas de Scrum
• Planificación ágil
• Scrum nunca viene solo
• Deuda técnica
• Testing ágil
• Escalar Scrum
• Contratos ágiles
• Recursos
Contenido
45
Metáfora aplicada al desarrollo software, introducida por Ward Cunningham en el 92, para explicar a los “no
técnicos” la necesidad de refactorizar. Desde entonces, la deuda técnica se ha utilizado para describir
muchos otros tipos de deudas o males del desarrollo de software. La principal causa de la deuda técnica es la
presión en fechas y planes. Sin embargo, hay otras causas, como la falta de cuidado, falta de educación,
procesos pobres, la no verificación de la calidad, o la incompetencia. (Calidad interna y externa)
En agilidad buscamos mayor velocidad (evitando procesos, papeleos, que no aportan valor y frenan);
buscamos entregar valor a los usuarios (a producción), en forma de software, de manera fiable (tener unos
mínimos de calidad, testing, etc.) y constante, para con esas entregas frecuentes, aprender qué quiere y
realmente necesitan los usuarios. Razones de la importancia de la calidad:
• Calidad del producto software, no es lo mismo que funcione.
• La calidad del proceso, no garantiza la calidad del producto.
• La mala calidad del producto siempre tiene un coste.
• El cliente puede detectar la mala calidad del producto software.
• Las buenas prácticas no aseguran calidad del producto.
Deuda técnica – Calidad del software
46
Deuda técnica – Medir la deuda
47
• Metodologías
• Agile
• Las personas
• Inception
• Historias de usuario
• Las reglas de Scrum
• Planificación ágil
• Scrum nunca viene solo
• Deuda técnica
• Testing ágil
• Escalar Scrum
• Contratos ágiles
• Recursos
Contenido
48
No se puede ser ágil si se prueba en cascada, lo clásico es que las pruebas queden fuera del
equipo, en otro departamento o equipo externo. Esto indica que el equipo no es
multifuncional, no contiene todas las competencias para de manera autónoma completar
un requisito (los equipos modernos de desarrollo son multifuncionales, así disparan la
velocidad y la productividad).
El “movimiento ágil” recomienda que más que personas de pruebas, debiera haber tareas
de pruebas, que pudieran ser desarrolladas por casi cualquiera del equipo.
Testing Ágil – Tarea dentro del Sprint
Hay un tipo de prueba que suele escaparse a
este tipo de recomendación; son las pruebas
globales de aceptación. Aquellas pruebas
finales antes de pasar algo grande a
producción, aquellas que buscan probar la
integración de los trabajos desarrollados por
varios equipos diferentes.
49
BDD es un proceso de desarrollo software y se relaciona principalmente con el Testing.
Busca un lenguaje común para unir la parte técnica y la de negocio, y que sea desde ese
lenguaje común desde donde arranque el Testing y, desde ahí, el desarrollo.
En BDD, las pruebas de aceptación se escriben usando historias de usuario.(Gherkin
lenguaje de negocio)
“Como [rol ] quiero [ característica ] para que [los beneficios].”
“Dado [contexto inicial], cuando [se produce el evento], entonces [resultados]”
Given [initial context], when [event occurs], then [ensure some outcomes].
El ciclo básico de BDD:
• Escribir las historias de usuario.
• Escribir los escenarios.
• Automatizar las pruebas de aceptación.
Testing Ágil – Behaviour Driven Development
50
• Metodologías
• Agile
• Las personas
• Inceptio
• Historias de usuario
• Las reglas de Scrum
• Planificación ágil
• Scrum nunca viene solo
• Deuda técnica
• Testing ágil
• Escalar Scrum
• Contratos ágiles
• Recursos
Contenido
51
Para ayudar a implementar la agilidad en la empresa a nivel de la
organización existen varios enfoques.
• Nexus. Iniciativa de Ken Schwager
• SAFe (Scaled Agile Framework). Iniciativa de Ivar Jacobson
• LeSS (Large-scale Scrum – Scrum a gran escala. Spotify). Craig Larman
• DAD (Disciplined Agile Delivery). IBM. Iniciativa de Scott Ambler
Escalar Scrum– Alternativas
52
Escalar Scrum– Modelo de fluidez ágil – 4 estados
1.- Equipos que crean valor de negocio
2.- Equipos que entregan en plazos de mercado
3.- Equipos que optimizan valor
4.- Equipos que optimizan la empresa
53
Nexus es un marco de trabajo que consiste en roles, eventos, artefactos y técnicas que
vinculan y entrelazan el trabajo de aproximadamente tres a nueve equipos de Scrum que
trabajan en una sola Lista de Producto para construir un Incremento Integrado que cumpla
un objetivo.
Nexus – Objetivo
54
El objetivo de SAFe es ayudar a implementar la agilidad en la empresa a nivel de la
organización. Cada nivel posee un Backlog (team Backlog, program Backlog y portafolio
Backlog), en los que se incluyen“historias” a distinto nivel de abstracción en función de
cada nivel: Historias de usuario (a nivel de equipo) – Features (a nivel de programa) –
Epopeyas (a nivel de portafolio).
SAFe – Objetivo
55
• Metodologías
• Agile
• Las personas
• Inception
• Historias de usuario
• Las reglas de Scrum
• Planificación ágil
• Scrum nunca viene solo
• Deuda técnica
• Testing ágil
• Escalar Scrum
• Contratos ágiles
• Recursos
Contenido
56
No hay nada recomendado, todo depende del grado de confianza entre proveedor y cliente. (Funcionalidad var.)
• Proyecto Cerrado. Fixed Everything. (colchón y petición decambio)
• Fixed Everything + Collaboration
• Fixed Everything Progresivo (UCR3)
• Spring Competitivo (Lean Approach)
• Inception
• Money for nothing, change for free
• Time & Materials
• Bolsa de horas
• Time & Materials iterativo e incremental(True Agile)
• Precio por punto función
• Puntos + horas
• IDIQ (T&M con estimación demanda y plazos)
• Compromiso Ágil
Contratos – Alternativas
http://www.coactivate.org/projects/agile-contracts/money-for-nothing-change-for-freehttp://coactivate.org/projects/agile-contracts/sample-fixed-price-agile-contract
57
• Metodologías
• Agile
• Las personas
• Inception
• Historias de usuario
• Las reglas de Scrum
• Planificación ágil
• Scrum nunca viene solo
• Deuda técnica
• Testing ágil
• Escalar Scrum
• Contratos ágiles
• Recursos
Contenido
Recursos - Bibliografía
• Libros
• Certificación
• Blog
58
http://www.proyectalis.com/angelmedinillahttp://www.javiergarzas.com/https://proyectosagiles.org/
59
Recursos – Gestión del cambio organizativo
60
