Proyectos Ágiles: Conceptos Clave

Metodologías de Desarrollo Ágil: Scrum

• Scrum es una metodología ágil para el desarrollo de productos
• Se centra en la entrega rápida de valor al cliente
• Se basa en una serie de "sprints" (iteraciones) cortas
• Se auto-organiza el desarrollo por el equipo

Origen de Scrum

• Takeuchi and Nonaka (Harvard Business Review) identificaron un enfoque de "carrera de relevos" en el desarrollo de productos que puede entrar en conflicto con la velocidad y la flexibilidad.
• En cambio, un enfoque holístico, al estilo "rugby", donde un equipo se mueve como una unidad, puede servir mejor a los requisitos competitivos actuales de las empresas.
• Scrum (palabra proveniente del rugby) se describe como una forma de reiniciar el juego en el rugby.

Melé

• Scrum es una forma de reiniciar el juego en el rugby. En scrum del rugby los jugadores de cada equipo se juntan y empujan contra el resto de jugadores.
• Es una técnica que se utiliza para empezar a jugar de nuevo al rugby.

Scrum en 100 palabras

• Scrum es un proceso ágil centrado en la entrega de valor al negocio en el menor tiempo.
• El equipo inspecciona el software real frecuentemente
• El negocio fija las prioridades
• Los equipos se auto-organizan para entregar funciones prioritarias
• Cada dos semanas o un mes, cualquiera puede ver el producto real funcionando y decidir si liberarlo o seguir evolucionando el producto en el siguiente sprint

Origen (Personas clave)

• Jeff Sutherland: Inició Scrum en Easel Corp. en 1993. Implementado en IDX (GE Healthcare) con 500 personas.
• Ken Schwaber: Desarrolló ADM (Advanced Development Methods). Presentación de Scrum en OOPSLA'95.
• Mike Beedle: Contribuyó con patrones Scrum en PLOP'04 (Pattern Languages of Programs Conference).
• Ken Schwaber y Mike Cohn: Fundaron conjuntamente la Scrum Alliance en 2002.

¿Para qué proyectos es posible usar Scrum?

• Scrum es aplicable a una amplia gama de proyectos, desde proyectos críticos de vida hasta tareas de menor importancia.
• Scrum cubre una escala de complejidad y tamaño para proyectos que van de muy pequeños hasta muy grandes.

¿Quién usa Scrum?

• Empresas como Microsoft, Yahoo, Google, Electronic Arts, Banco Santander, Lockheed Martin, Phillips, Siemens, Nokia, BBVA, BBC, Telefónica, Repsol, Nielsen Media, NASA, Facebook, Volkswagen, John Deere, Lexis Nexis, Amazon, Salesforce.com, Time Warner, Turner Broadcasting, e Intel.

Scrum ha sido usado para...

• Desarrollo de software comercial, desarrollo interno, desarrollo bajo contrato, proyectos con presupuesto cerrado, aplicaciones financieras, aplicaciones certificadas ISO, sistemas embebidos, sistemas con requisitos 7x24, y aviones de combate.

Principales características de Scrum

• Equipos auto-organizados
• Desarrollo progresivo en sprints semanales o mensuales
• Requisitos capturados como elementos de una lista llamada "Product Backlog"
• Prácticas de Ingeniería prescritas (no aplicadas)
• Normas generativas para entornos ágiles de entrega de proyectos.

Roles técnicos

• Propietario del producto
• Scrum Master
• Equipo de desarrollo

Gestión de Roles

• Tres roles principales: Product Owner, Scrum Master, y Equipo de desarrollo.
• El equipo de desarrollo está comprometido con el proyecto, su éxito depende de ellos.
• Los stakeholders del proyecto (usuarios) tienen un vínculo de involucramiento, pero no la misma responsabilidad o compromiso.

Rol técnico: Propietario del Producto

• Toma las decisiones del cliente, responsable del valor del producto.
• Es necesario un rol único para simplificar la toma de decisiones.
• Dentro de una organización puede adoptar la comunicación interna que mejor corresponda.
• Debe tener el conocimiento suficiente del producto.

Rol técnico: Equipo de desarrollo

• Se conforman por profesionales que desarrollan el incremento de cada sprint.
• Se recomiendan equipos de 4 - 8 personas, más que eso vuelve difícil mantener la comunicación.
• La responsabilidad del equipo es la realización del incremento del sprint.
• Se recomienda una auto-organización de los roles, sin un líder designado para cada uno.

Tamaño del equipo de desarrollo

• Two-Pizza Team: 4-8 / 5-9 miembros.
• Se vaguea menos, fomenta interacciones constructivas, menos tiempo en coordinación y todos participan en los roles.

Roles técnicos: Equipo de desarrollo

• Tienen responsabilidades como la auto-organización y el uso de tecnologías ágiles.
• Diferencian a un grupo de trabajo de equipos. Un grupo de trabajo tiene un jefe pero cada uno responde por su trabajo.
• Los equipos tienen que colaborar, y con un propósito común, para obtener el mayor valor posible del cliente.

Equipo de desarrollo - Parte 2

• Todos conocen y comprenden la visión del propietario del producto.
• Aportan y colaboran con el propietario del producto en el desarrollo de la pila del producto.
• Comparten el objetivo de cada sprint y la responsabilidad del logro.
• Todos los miembros participan en las decisiones y se respetan las opiniones.
• Todos conocen el modelo de trabajo con Scrum.

Rol técnico: Scrum Master

• Es el responsable del cumplimiento de reglas del marco de Scrum.
• Asesoramiento al propietario del producto y equipo.
• Proporciona asesoramiento y formación al equipo y apoyo en la gestión del proyecto.
• Moderación de reuniones, resolución de impedimentos y gestión de dinámicas de grupo.

Proporciona

• Configuración, diseño y mejora continua de las prácticas de SCRUM en la organización. Respeto de la organización y las personas involucradas, con las pautas de tiempos y formas de scrum.
• Al crecer la fluidez de la organización, puede eliminarse el rol de Scrum Master cuando esas responsabilidades están institucionalizadas en la organización.

Artefactos

• Pila del producto (Product Backlog): Lista de requisitos de usuario priorizada.
• Sprint: Iteración de desarrollo con un tiempo prefijado.
• Pila del sprint (Sprint Backlog): Lista de trabajos para el sprint, para generar el incremento.
• Incremento: Producto funcional resultado de cada sprint.
• Definición de Hecho (Done): Criterios que definen la finalización de un trabajo.

Artefactos: Product Backlog

• Lista ágil de los requisitos del sistema.
• Requisitos claros, concisos y claros.
• Se utilizan historias de usuario para capturar las funcionalidades.
• Cada requisito tiene una estimación de esfuerzo (puntos de historia o horas).
• Los requisitos están priorizados según su importancia o valor para el propietario del producto.

Historias de Usuario

• Técnica para capturar requisitos desde un punto de vista del usuario final.
• Descripción corta de la funcionalidad deseada; sin detalles técnicos.
• Formato: "Como [rol del usuario], quiero [acción] para [beneficio]".
• Características: Concreta, con valor, negociable y testable.

Historias de Usuario - Ejemplo

• Un usuario sin registrarse quiere registrarse y usar las funciones.
• Un usuario registrado quiere iniciar sesión.

Artefactos: Pila de sprint

• Lista de tareas a realizar para generar el incremento.
• Descripción breve de la tarea.
• Persona asignada a la tarea.
• Esfuerzo pendiente para terminarla.
• Dividir el proyecto en unidades de tamaño adaptable para identificar riesgos y problemas.

Artefactos: Pila de sprint - Parte 2

• ¿Por qué se añaden tareas?
• Facilitar la estimación
• Mejorar el seguimiento del trabajo
• Mejorar la transparencia del progreso

Artefactos: Pila de sprint - Condiciones

• Realización conjunta por todos los miembros del equipo.
• Cubre todos los objetivos del sprint
• Solo puede ser modificada por el equipo durante el sprint.
• Tareas demasiado grandes deben descom ponerse en otras tareas más pequeñas.
• Visibilidad del trabajo del equipo.

Artefactos: Pila de sprint - Formato

• Se prefiere la comunicación verbal y visual.
• La pila del producto no es sólo un documento de requisitos, sino también una herramienta de referencia.
• Información necesaria (único id de la funcionalidad, historia de usuario, priorización y estimación de esfuerzo).
• Información adicional: observaciones, criterios de validación, persona asignada, módulo del sistema, etc.
• No se deben adoptar formatos rígidos, se adapta a las características del equipo y la organización.

Artefactos: Incremento

• Es la parte del producto finalizado en un sprint.
• Es operativo y listo para ser entregado al cliente.
• No se deben incluir prototipos, módulos o sub-módulos en el incremento.
• Cada elemento de la pila del producto se refiere a funcionalidades, no a trabajos internos como diseño de la base de datos.

Artefactos: Incremento - Parte 2

• En el primer sprint se puede tener como objetivo contrastar las plataformas, el diseño y los prototipos.
• Incremento es la parte del producto realzado en un sprint, potencialmente entregable, terminada y probada.
• Si el proyecto o el sistema requiere documentación, procesos de validación y verificación documentados o procesos con terceros, deben estar dentro del incremento.

Artefactos: Incremento - Parte 3

• Entrega continua: El ritmo de funcionalidades manteniendo un flujo sin cuellos de botella.
• Incremento iterativo: El avance basado en pulsos de tiempo.
• Cada sprint produce un incremento.

Artefactos: Sprint

• Ciclo de tiempo para cada incremento.
• Duración del sprint depende del proyecto y necesidades. (habitualmente entre una semana y un mes)

Gestión de los tiempos: Timeboxing

• Técnica de administración de tiempo en Scrum.
• Trabajo dividido en tareas con asignación de tiempo limitada.
• Priorización y ajuste de tareas y objetivos dentro de un tiempo fijo.

Ventajas del Timeboxing

• Evita la Ley de Parkinson: El trabajo tiende a expandirse para ocupar todo el tiempo disponible.
• Combatir la procrastinación: Establecer plazos cortos definidos ayuda a concentrarse y evita posponer tareas.
• Aumenta la eficiencia: Focalizar en lo más importante y evitar desviarse.

Gestión de los tiempos: Burn-down

• Mide el trabajo pendiente durante un sprint.
• Representa el avance del trabajo hasta finalizar el sprint.
• Diariamente se actualiza con el trabajo restante.
• Ayuda a identificar y gestionar posibles desviaciones en la entrega.

Gestión de los tiempos: Project Burn Down Chart

• Representa el avance del proyecto completo a lo largo de diferentes sprints.
• Muestra el trabajo restante en el proyecto hasta la fecha.
• Ayuda a evaluar si el producto se está desarrollando y entregando de acuerdo con el plan.

Gestión de los tiempos: Burn-up

• Herramienta de planificación de producto.
• Muestra el progreso de trabajo realizado, no lo que resta.
• Cantidad de trabajo completado frente al objetivo general.
• Representa el trabajo completado a través de diferentes sprints.

Velocidad en la gestión ágil

• Cantidad de trabajo realizado en un sprint.
• Se expresa como puntos de historia, como resultado de los sprints.
• Permite predecir la capacidad de trabajo y planificar sprints futuros, usando fórmulas como trabajo completado/tiempo empleado.

Métodos de avance: Iterativo vs. Continuo

• Enfoque iterativo: Trabajo en sprints con definición específica de funciones.
• Enfoque continuo: Flujo constante de trabajo sin puntos muertos ni cuellos de botella

Tiempo real vs. Tiempo ideal

• Tiempo real: Tiempo utilizado para realizar una tarea.
• Tiempo ideal: Tiempo estimado para completar una tarea en condiciones ideales.
• Diferencia entre el tiempo real y el ideal se basa en la capacidad del desarrollador.

Medición del trabajo

• Es esencial registrar el trabajo completado y el que resta.
• Se utilizan puntos de funcionalidad o recursos empleados.
• Las mediciones se basan en unidades relativas al producto.

Estimación del trabajo

• No se puede predecir el tiempo exacto de forma precisa.
• Se utilizan estimaciones aproximadas basadas en el conocimiento del equipo.

Unidades de trabajo

• Dimensionar el trabajo midiendo el producto o el tiempo de ejecución (como COCOMO).
• COCOMO modelo matemático utilizado para estimar los costes de software.

Puntos de Historia en la Gestión Ágil

• Unidad de medida relativa, utilizada en metodologías ágiles.
• Se basa en la complejidad de una tarea.
• Permite estimar el esfuerzo relativo de distintas tareas

¿Cómo se calculan los Puntos de Historia?

• Se basa en la comparación con tamaños relativos de tareas conocidas.
• Depende del contexto de cada equipo.
• Algunos ejemplos son crear un usuario o un mercado para intercambiar jugadores con diferentes grados de complejidad.

Puntos de Historia: Comparación y Estimaciones

• Clave es realizar comparaciones entre tareas.
• Realizar comparaciones con diferentes grados de complejidad.
• Ejemplos: historias de usuario pequeña, mediana y grande.

Consistencia y Adaptación en el Uso de Puntos de Historia

• Definir puntos de historias de manera consistente y que todos los miembros del equipo los comprendan.
• Revisar las estimaciones continuamente, de acuerdo con el rendimiento del equipo.

Planning Poker

• Técnica de estimación basada en consenso.
• Se usa una baraja numérica (secuencia Fibonacci) para estimar el esfuerzo de tareas.
• Un moderador guía la discusión y el consenso.

Reuniones

• Sprint Planning (Planeación del Sprint)
• Daily Scrum (Reunión diaria)
• Sprint Review (Revision del Sprint)
• Sprint Retrospective (Retrospectiva del Sprint)
• Backlog Grooming

Sprint Planning

• Inicia cada sprint estableciendo qué tareas se realizarán y cómo se completarán.
• Recopilación de información para que el equipo entienda qué tarea se llevará a cabo durante el sprint.
• Precondiciones: organización tiene claros los recursos. - Ya están los elementos con suficiente detalle.
• Entrada: información de incrementos anteriores.
• Salida: Pila del sprint, duración del sprint y fecha de la reunión de revisión.

Daily Scrum

• Reunión corta diaria durante el sprint. - Revisar el progreso hacia el objetivo.
• Ajustar el plan si es necesario.

Sprint Review

• El equipo presenta los incrementos completados al propietario del producto y otros stakeholders.
• Recopilación de feedback y ajuste del Product Backlog.

Sprint Retrospective

• Reunión para reflexionar sobre lo que salió bien y lo que se puede mejorar.
• Identificar lo que salió bien/mal y definir cómo hacerlo mejor en el próximo sprint.

Técnicas para facilitar la Retrospectiva

• Start, Stop, Continue
• Mad-Sad-Glad
• Timeline

Backlog Grooming

• Reunión para mantener la pila del producto actualizada.
• Se realiza al comienzo del sprint o antes de él.

Cuestiones de tamaño

• Epic: historia de usuario grande que generalmente abarca múltiples sprints. - Se deben descomponer en historias más pequeñas.
• Ejemplo: Gestión completa de un equipo en una Liga de Fantasy

Este cuestionario te permitirá evaluar tus conocimientos sobre los conceptos fundamentales en proyectos ágiles. Se incluyen preguntas sobre roles, requisitos y características de equipos auto-organizados. Prepárate para profundizar en el mundo de la gestión de proyectos ágiles.