scrum, kanban y xp gestión Ágil de proyectos · existen muchas técnicas, como por ejemplo:...
TRANSCRIPT
Hello!I am Jose A. Dorado CerónProduct Owner & Software Architect en Emergya@jadoradoce / [email protected]
➜ Metodologías ágiles➜ Metodologías ágiles vs tradicionales➜ Scrum➜ Kanban➜ eXtreme Programming
ÍNDICE
#AGILELas metodologías ágiles son un conjunto de técnicas para gestionar y desarrollar proyectos en contraposición a las técnicas clásicas.
Problemas clásicos en elDesarrollo
▪ 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.
Un poco deHistoria
1986En EEUU y Japón surge el concepto debido a la necesidad de salir al mercado muy rápido con requisitos muy novedosos.
1993 - 1995Se documenta y formaliza el primer documento de Scrum para desarrollo ágil de software.
2001Las personas más relevantes del desarrollo ágil escriben el Manifiesto Ágil donde se recogen sus 4 principios.
… Antes de todo estoA finales del S. XIX ~ principios del S. XX surge el concepto Lean Manufacturing de la mano de Toyota.
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
“ 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
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
Plan inicial vsRealidad
A.J. Juliani
“ Se dedica mucho esfuerzo a alcanzar objetivos que aportan muy poco valor.
Dinero perdido + tiempo perdido = Cliente insatisfecho
Otros erroresTí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
Principios Metodologías Ágiles
Comunicación
Aportar Valor
Flexibilidad Colaborar
Equipo
Calidad
Optimizar
Entregas rápidas
Respuesta
ante los
cambios Tener algo
funcionando
desde el
principio
Participar y
definir el
producto de
manera
conjunta
En todas las
direcciones. Tanto con
el cliente como con el
equipo
BeneficiosMetodologías Ágiles
CalidadRealizando pruebas desde el principio e iterando sobre el producto tras recibir el feedback.
ResultadosEntregando algo tangible y que aporte valor desde la primera iteración.
FlexibilidadPermitiendo cambios de alcance, estimando y planificando de manera ágil.
MantenibilidadCreando un software de calidad, con casos de prueba y una documentación asumible.
Eliminación de riesgosValidando cada entrega en sprints cortos y asegurando la calidad con casos de pruebas.
MotivaciónTrabajando de manera conjunta con el cliente, viendo crecer el producto final tras cada iteración.
Definición delProducto
¿Qué es? ¿Por qué es útil? ¿A quién va dirigido?
¿Cómo funciona? ¿Qué necesidades cubre?
Casos de usoDescripció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 usuarioDefinición corta de una funcionalidad, que debe poder escribirse en una nota adhesiva.
Lenguaje sencillo de entender por el equipo y el cliente.
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
Jefe vsLí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
Qué esScrum
▪ 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
GlosarioScrum
Product BacklogListado 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 BacklogListado de requisitos que se van a abordar en el sprint. Cada historia de usuario se desgrana en tareas asumibles y se estiman.
Gráfico BurndownGráfico que muestra la cantidad de requisitos pendientes al comienzo del sprint junto a los requisitos completados. Da una visión global del estado.
SprintIteració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.
Roles enScrum
Product OwnerParticipa 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 MasterEncargado 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 TeamEquipo multidisciplinar autoorganizado (desarrolladores, QA, diseño, UX, arquitectos…) Encargado del desarrollo del producto.
Ceremonias deScrum
Daily ScrumReunió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 ReviewAl 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 PlanningAl inicio de cada sprint. Se selecciona el trabajo que se va a hacer en este sprint y se estima.
Sprint RetrospectiveAl 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.
La importancia dePriorizar
▪ 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)
La necesidad deEstimar
▪ 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
Qué esKanban
▪ 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
Tener reglasclaras
Principios básicos de Kanban
Limitar elTrabajo en
curso
Visualizar elflujo de trabajo
Gestionar elflujo
Mejorar enequipo
TableroKanban
▪ 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 DoneAntes de empezar es necesario definir qué significa que una tarea está terminada.
Qué esXP
▪ 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
Técnicas y característicasXP
TDDDesarrollo guiado por pruebas. Antes de programar se deben escribir las pruebas que validen cada funcionalidad.
Pair ProgrammingTécnica en la que dos programadores comparten el mismo ordenador para desarrollar a la vez.
Integración con clienteSe recomienda que al menos una persona del cliente trabaje de manera conjunta al equipo de desarrollo.
RefactorizaciónSobreescribir ciertas partes del código para mejorar su legibilidad y mantenibilidad sin modificar su funcionamiento.
Propiedad compartidaSe promueve que todos los miembros del equipo puedan tocar cualquier parte del código.
SimplicidadCuanto más simple sea el sistema que se construya más fácil será comprenderlo y añadir nuevas funcionalidades.