Metodologias Agiles

September 23, 2024 | Author: Anonymous | Category: N/A
Share Embed Donate


Short Description

Download Metodologias Agiles...

Description

Gestión Ágil de Proyectos: Scrum, Kanban y XP

ÍNDICE

➜ ➜ ➜ ➜ ➜

Metodologías ágiles Metodologías ágiles vs tradicionales Scrum Kanban eXtreme Programming

1. Metodologías Ágiles Qué son. Por qué surgen. El Origen.

#AGIL

E

Las metodologías ágiles son un conjunto de técnicas para gestionar y desarrollar proyectos en contraposición a las técnicas clásicas.

Metodologías Ágiles

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.

Un poco de Historia 1986

1993 - 1995

2001

En EEUU y Japón surge el concepto debido a la necesidad de salir al mercado muy rápido con requisitos muy novedosos.

Se documenta y formaliza el primer documento de Scrum para desarrollo ágil de software.

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.

TOYOTA - Lean Manufacturing

The Seven Wastes - Sobreproducción - Tiempo de espera - Transporte - Exceso de procesado - Inventario - Movimiento - Defectos

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



Manifiesto Ágil Individuos e interacciones sobre procesos y herramientas

Software funcionando sobre documentación excesiva Colaboración con el cliente sobre negociación contractual Respuesta ante el cambio sobre seguir un plan

2. Metodologías ágiles vs tradicionales Qué aporta el agilismo, beneficios, cambios...

Desarrollo en Cascada ▪ Poco flexible. No se puede ir atrás ▪ Muy estricto. No permite cambios de alcance ▪ Pequeños errores causan grandes problemas ▪ Mucha documentación inservible ▪ No se entrega valor hasta el final

Cascada vs Agile

www.crmsearch.com

Plan inicial vs Realidad

A.J. Juliani

Importancia del Feedback



Se dedica mucho esfuerzo a alcanzar objetivos que aportan muy poco valor.

Dinero perdido + tiempo perdido = Cliente insatisfecho

El gran enemigo Los cambios

Cambios de funcionalidad

Cambios en el alcance

Cambios de tecnología

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

¿Existe alguna alternativa?

Gestión Ágil

Principios Metodologías Ágiles

Participar y

En todas las

definir el

direcciones. Tanto con

producto de

el cliente como con el equipo

manera

Comunicación

Optimizar

Equipo

Flexibilidad

Colaborar Entregas rápidas

Respuesta ante los cambios

conjunta

Calidad

Aportar Valor Tener algo funcionando desde el principio

Beneficios Metodologías Ágiles Calidad

Resultados

Flexibilidad

Realizando pruebas desde el principio e iterando sobre el producto tras recibir el feedback.

Entregando algo tangible y que aporte valor desde la primera iteración.

Permitiendo cambios de alcance, estimando y planificando de manera ágil.

Mantenibilidad

Eliminación de riesgos

Motivación

Creando un software de calidad, con casos de prueba y una documentación asumible.

Validando cada entrega en sprints cortos y asegurando la calidad con casos de pruebas.

Trabajando de manera conjunta con el cliente, viendo crecer el producto final tras cada iteración.

Definición del Producto ¿Cómo funciona? ¿Qué es?

¿Qué necesidades cubre? ¿Por qué es útil?

¿A quién va dirigido?

Construcción Iterativa

¿Quién las usa?

Casos de uso vs Historias de usuario Casos de uso

Historias de usuario

Casos de uso vs Historias de usuario Casos de uso

Historias de usuario

Descripción de todos los pasos que se deben llevar a cabo para realizar una acción.

Definición corta de una funcionalidad, que debe poder escribirse en una nota adhesiva.

Especificación de interacciones entre los actores y el sistema.

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

3. Scrum ¿Qué es? Roles, prácticas...

¿Qué es?

SCRUM

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

Glosario Scrum Product Backlog

Sprint Backlog

Gráfico Burndown

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.

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 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.

El proceso de Scrum

El proceso de Scrum

Ceremonias de Scrum Daily Meeting

Sprint Review

Reunión diaria donde sólo los involucrados pueden hablar. Se responden 3 preguntas:

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.

-

¿Qué hiciste ayer? ¿Qué vas a hacer hoy? ¿Tienes algún bloqueo?

Sprint Planning

Sprint Retrospective

Al inicio de cada sprint. Se selecciona el trabajo que se va a hacer en este sprint y se estima.

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.

Roles en Scrum Product Owner

Scrum Master

Participa en la Encargado de que se definición del cumplan las reglas de producto. Representa Scrum. Resuelve al negocio y prioriza posibles conflictos. historias de usuario. Motiva y protege al Nexo de unión entre equipo. Su tarea es los implicados. Debe facilitar el trabajo al maximizar el valor del equipo. producto.

Development Team Equipo multidisciplinar autoorganizado (desarrolladores, QA, diseño, UX, arquitectos…) Encargado del desarrollo del producto.

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)

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

4. kanban Veamos algún ejemplo

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

Principios básicos de Kanban

Visualizar el flujo de trabajo

Limitar el Trabajo en curso

Gestionar el flujo

Tener reglas claras

Mejorar en equipo

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.

Kanban board

Ejemplo

4. eXtreme Programming Qué es XP. Técnicas más comunes.

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

Técnicas y características XP TDD

Pair Programming

Integración con cliente

Desarrollo guiado por pruebas. Antes de programar se deben escribir las pruebas que validen cada funcionalidad.

Técnica en la que dos programadores comparten el mismo ordenador para desarrollar a la vez.

Se recomienda que al menos una persona del cliente trabaje de manera conjunta al equipo de desarrollo.

Refactorización

Propiedad compartida

Simplicidad

Sobreescribir ciertas partes del código para mejorar su legibilidad y mantenibilidad sin modificar su funcionamiento.

Se promueve que todos los miembros del equipo puedan tocar cualquier parte del código.

Cuanto más simple sea el sistema que se construya más fácil será comprenderlo y añadir nuevas funcionalidades.

I am Jose A. Dorado Cerón Product Owner & Software Architect en Emergya @jadoradoce / [email protected]

View more...

Comments

Copyright ©2017 KUPDF Inc.
SUPPORT KUPDF