7. Problemas clásicos en el
Desarrollo
▪ Cambios de contexto y de alcance
▪ Aparecen retrasos => No hay tiempo para pruebas
▪ Planificaciones poco realistas
▪ Cliente poco involucrado
▪ Falta de comunicación
▪ Equipo poco motivado
▪ No hay flexibilidad
▪ El resultado no es lo esperado por el cliente
Resultado: Equipo y cliente insatisfechos. Tiempo y dinero perdido.
8. Un poco de
Historia
1986
En EEUU y Japón surge el
concepto debido a la
necesidad de salir al
mercado muy rápido con
requisitos muy novedosos.
1993 - 1995
Se documenta y formaliza
el primer documento de
Scrum para desarrollo ágil
de software.
2001
Las personas más
relevantes del desarrollo
ágil escriben el Manifiesto
Ágil donde se recogen sus 4
principios.
… Antes de todo esto
A finales del S. XIX ~ principios del S. XX surge el concepto Lean Manufacturing de la mano
de Toyota.
9. Principios de Lean
- Calidad. Detección de problemas
al principio
- Eliminar lo que no aporte valor
- Mejora continua
- Producir lo necesario
- Flexibilidad
- Compartir información
TOYOTA - Lean Manufacturing
The Seven Wastes
- Sobreproducción
- Tiempo de espera
- Transporte
- Exceso de procesado
- Inventario
- Movimiento
- Defectos
10. “ Individuos e interacciones sobre procesos y herramientas
Manifiesto Ágil
Software funcionando sobre documentación excesiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan
12. Desarrollo en Cascada
▪ Poco flexible. No se puede ir atrás
▪ Muy estricto. No permite cambios de alcance
▪ Pequeños errores causan grandes problemas
▪ No se entrega valor hasta el final
▪ Mucha documentación inservible
16. “ Se dedica mucho esfuerzo a
alcanzar objetivos que aportan
muy poco valor.
Dinero perdido + tiempo perdido = Cliente insatisfecho
17. El gran enemigo
Los cambios
Cambios en el
alcance
Cambios de
funcionalidad
Cambios de
tecnología
18. Otros errores
Típicos
▪ No medir el avance o medirlo mal
▪ Añadir más personas creyendo que se irá más rápido
▪ No hacer pruebas desde el principio
▪ Creer que estamos construyendo una casa en vez de software
▪ No tener una visión global del estado actual
▪ Poca implicación del cliente
▪ Estimaciones sin técnicos
▪ Pérdida del foco
▪ No decir no
▪ No obtener feedback
▪ Herramientas inadecuadas para planificar
21. Beneficios
Metodologías Ágiles
Calidad
Realizando pruebas desde el
principio e iterando sobre el
producto tras recibir el
feedback.
Resultados
Entregando algo tangible y
que aporte valor desde la
primera iteración.
Flexibilidad
Permitiendo cambios de
alcance, estimando y
planificando de manera ágil.
Mantenibilidad
Creando un software de
calidad, con casos de prueba
y una documentación
asumible.
Eliminación de riesgos
Validando cada entrega en
sprints cortos y asegurando
la calidad con casos de
pruebas.
Motivación
Trabajando de manera
conjunta con el cliente,
viendo crecer el producto
final tras cada iteración.
25. Casos de uso
Descripción de todos los pasos
que se deben llevar a cabo para
realizar una acción.
Especificación de interacciones
entre los actores y el sistema.
Casos de uso vs
Historias de usuario
Historias de usuario
Definición corta de una
funcionalidad, que debe poder
escribirse en una nota adhesiva.
Lenguaje sencillo de entender
por el equipo y el cliente.
27. Historias de
Usuario
▪ Siguen el patrón: “Cómo - Quiero - Para”
▪ Sirven para especificar requisitos
▪ Son independientes unas de otras
▪ Son pequeñas
▪ Se pueden estimar
▪ Se pueden verificar una vez implementadas
▪ Son flexibles
▪ Son entendibles y fomentan la comunicación
28. Jefe vs
Líder
▪ Desaparece el jefe autoritario por el
líder con conocimientos que guía al
equipo.
▪ Soluciones vs problemas
▪ Confianza vs miedo
▪ Convencer vs imponer
www.upadpsicologiacoaching.com
31. Qué es
Scrum
▪ Marco de trabajo para desarrollos ágiles
▪ Desarrollo incremental vs planificación y ejecución completa
▪ Equipos auto organizados
▪ Paralelización de las fases de desarrollo vs fases secuenciales
▪ Priorización de los requisitos que más valor aporten
▪ Mejora continua
33. Glosario
Scrum
Product Backlog
Listado dinámico, público y
actualizado con todos los
requisitos del producto.
Debe estar priorizado. Es de
alto nivel, no entra en
detalles de implementación.
Sprint Backlog
Listado de requisitos que se
van a abordar en el sprint.
Cada historia de usuario se
desgrana en tareas
asumibles y se estiman.
Gráfico Burndown
Gráfico que muestra la
cantidad de requisitos
pendientes al comienzo del
sprint junto a los requisitos
completados. Da una visión
global del estado.
Sprint
Iteración de entre 1 y 4 semanas (normalmente 2). Al final del sprint se realiza una entrega
al cliente con las nuevas funcionalidades. Entrega continua de valor.
34. Roles en
Scrum
Product Owner
Participa en la
definición del
producto. Representa
al negocio y prioriza
historias de usuario.
Nexo de unión entre
los implicados. Debe
maximizar el valor del
producto.
Scrum Master
Encargado de que se
cumplan las reglas de
Scrum. Resuelve
posibles conflictos.
Motiva y protege al
equipo. Su tarea es
facilitar el trabajo al
equipo.
Development Team
Equipo
multidisciplinar
autoorganizado
(desarrolladores, QA,
diseño, UX,
arquitectos…)
Encargado del
desarrollo del
producto.
35. Ceremonias de
Scrum
Daily Scrum
Reunión diaria donde sólo los involucrados
pueden hablar. Se responden 3 preguntas:
- ¿Qué hiciste ayer?
- ¿Qué vas a hacer hoy?
- ¿Tienes algún bloqueo?
Sprint Review
Al final del sprint. Se revisa el trabajo que se ha
completado y el que no se ha terminado. Se
hace una demostración y se obtiene feedback.
Sprint Planning
Al inicio de cada sprint. Se selecciona el
trabajo que se va a hacer en este sprint y
se estima.
Sprint Retrospective
Al final del sprint. Se reunen todos los implicados
para analizar qué se ha hecho bien y se debe
seguir haciendo y qué se ha hecho mal y se debe
cambiar.
36. La importancia de
Priorizar
▪ Es una responsabilidad del Product Owner
▪ Se debe priorizar por el valor que aporta cada historia
▪ No se debe priorizar por la complejidad para desarrollarlas
▪ Existen muchas técnicas, como por ejemplo:
▫ Modelo Kano:
▸ Requisitos obligatorios (Básicos)
▸ Requisitos deseados (Esperados)
▸ Requisitos no esperados (Inesperados)
▸ Indiferentes (No aportan valor)
▫ MoSCoW: (Must, Should, Could y Won’t)
37. La necesidad de
Estimar
▪ Es una responsabilidad de todo el equipo
▪ Todas las tareas deben ser estimadas
▪ Estimación basada en el conocimiento y en la experiencia
▪ Estimar en puntos y conocer la velocidad del equipo
▪ Planning Poker:
▫ Se utiliza la secuencia de Fibonacci
▫ Se explica la historia y se resuelven dudas
▫ Se busca unanimidad y consenso
39. Qué es
Kanban
▪ Término japonés: Tarjetas visuales 看板
▪ Proporciona un flujo de trabajo para dividir el proceso en fases
▪ Complementario con Scrum
▪ Los 4 principios básicos de Kanban:
▫ Empieza con lo que haces ahora
▫ Acepta el cambio
▫ Respeta el proceso actual, roles y responsabilidades
▫ Liderazgo en todos los niveles
41. Tablero
Kanban
▪ Se usa para organizar las tareas del sprint en curso
▪ Se puede adaptar a las necesidades
▪ Se van moviendo las tarjetas por las diferentes columnas
▪ Sirve para tener una visión global del estado actual del sprint
DoD: Definition of Done
Antes de empezar es necesario definir qué
significa que una tarea está terminada.
44. Qué es
XP
▪ Metodología ágil de desarrollo software basada en la flexibilidad
▪ Se considera que los cambios de requisitos son un aspecto natural
▪ Valores de XP:
▫ Simplicidad
▫ Comunicación
▫ Retroalimentación
▫ Valentía
▫ Respeto
45. Técnicas y características
XP
TDD
Desarrollo guiado por
pruebas. Antes de
programar se deben escribir
las pruebas que validen cada
funcionalidad.
Pair Programming
Técnica en la que dos
programadores comparten
el mismo ordenador para
desarrollar a la vez.
Integración con cliente
Se recomienda que al menos
una persona del cliente
trabaje de manera conjunta al
equipo de desarrollo.
Refactorización
Sobreescribir ciertas partes
del código para mejorar su
legibilidad y mantenibilidad
sin modificar su
funcionamiento.
Propiedad compartida
Se promueve que todos los
miembros del equipo
puedan tocar cualquier parte
del código.
Simplicidad
Cuanto más simple sea el
sistema que se construya más
fácil será comprenderlo y añadir
nuevas funcionalidades.