Proyectos Ágiles: Conceptos Clave

Podcast

Play an AI-generated podcast conversation about this lesson

Questions and Answers

¿Cuál de los siguientes roles se considera 'comprometido' con el proyecto según la historia de las gallinas y cerdos?

Scrum Master (correct)

Cliente

Inversor

Tester

En un entorno ágil, ¿qué elemento captura los requisitos del proyecto?

Task board

Release plan

Product backlog (correct)

Sprint backlog

¿Cuál de las siguientes características NO es parte de un equipo auto-organizado?

Emplea normas generativas

Roles jerárquicos definidos (correct)

El producto progresa en sprints

No existen prácticas de ingeniería prescritas

¿Cuál es un tipo de software que no se menciona específicamente en el contexto de desarrollos internos?

Sistemas operativos de escritorio Signup and view all the answers

¿Qué duración se menciona para los sprints en un entorno ágil?

Una semana Signup and view all the answers

De los siguientes tipos de software, ¿cuál se considera un desarrollo bajo contrato?

Grandes aplicaciones Signup and view all the answers

¿Qué tipo de sistema operate bajo requisitos 7x24?

Sistemas críticos de soporte vital Signup and view all the answers

¿Cuál es el propósito principal de la reunión diaria del Daily Scrum?

Revisar el progreso hacia el objetivo del sprint y ajustar el plan si es necesario. Signup and view all the answers

¿Qué beneficios se obtienen de la Daily Scrum?

Promueve la responsabilidad individual y la adaptación temprana ante impedimentos. Signup and view all the answers

¿Qué es fundamental para la realización efectiva de la Daily Scrum?

Debido a su naturaleza breve, se sugiere realizarla de pie. Signup and view all the answers

¿Qué aspectos se evitan en la Daily Scrum para mantener su enfoque?

Discusiones largas sobre el rendimiento individual. Signup and view all the answers

¿Qué pregunta clave se hace en la Daily Scrum para ayudar a identificar impedimentos?

¿Hay algún obstáculo que me impida avanzar? Signup and view all the answers

¿Cuál es la principal responsabilidad del propietario del producto?

Tomar decisiones sobre el valor del producto. Signup and view all the answers

¿Qué característica es esencial para el rol del propietario del producto?

Ser la única persona responsable de las decisiones del cliente. Signup and view all the answers

¿Quién normalmente asume el rol de propietario del producto en desarrollos internos?

El product manager o el responsable de marketing. Signup and view all the answers

¿Cuál de las siguientes afirmaciones sobre los 'stakeholders' es correcta?

Su implicación es menor que la del propietario del producto. Signup and view all the answers

¿Qué aspecto no es esencial que el propietario del producto conozca?

Las dinámicas de trabajo del equipo de desarrollo. Signup and view all the answers

¿Cuál es una de las funciones del propietario del producto durante el desarrollo del proyecto?

Decidir qué se pone y qué se quita de la pila del producto. Signup and view all the answers

Si un cliente requiere delegar decisiones clave en el equipo de desarrollo, ¿quién sigue siendo responsable?

El propietario del producto. Signup and view all the answers

¿Qué rol desempeñan las gallinas en el contexto del proyecto?

Son usuarios involucrados sin un compromiso total. Signup and view all the answers

¿Cuál es un aspecto que el propietario del producto NO maneja directamente?

Decidir sobre la formación del equipo de desarrollo. Signup and view all the answers

¿Qué caracteriza a las estimaciones según la información proporcionada?

Se fundamentan en el esfuerzo relativo percibido por el equipo. Signup and view all the answers

¿Cuál es la importancia de la consistencia en la definición de puntos de historia dentro de un equipo?

Asegura que todos sigan la misma lógica y comprensión. Signup and view all the answers

¿Qué técnica es mencionada como utilizada para estimar el esfuerzo de las tareas en desarrollo de software?

Planning Poker. Signup and view all the answers

¿Cómo se describe el método de Planning Poker en relación a otros métodos?

Es una variación del método Wideband Delphi. Signup and view all the answers

¿Qué tipo de lista se utiliza en el Planning Poker para la estimación?

Una lista de historias de usuario. Signup and view all the answers

¿Qué función cumplen las cartas en el mazo del Planning Poker?

Están numeradas y se utilizan para estimar esfuerzo. Signup and view all the answers

¿Qué aspecto es vital para que el proceso de estimación sea adaptable?

Revisar continuamente las estimaciones basadas en el rendimiento pasado. Signup and view all the answers

¿Cuál de estos no es un beneficio de las estimaciones basadas en esfuerzo relativo?

Facilita el cálculo exacto de tiempos de entrega. Signup and view all the answers

¿Quiénes son los principales responsables de decidir los puntos en el Planning Poker?

Los desarrolladores en consenso. Signup and view all the answers

¿Qué caracteriza a las características en la lista utilizada en Planning Poker?

Describen el software que debe ser desarrollado. Signup and view all the answers

¿Cuál es el objetivo principal del evento de Sprint Planning?

Definir qué trabajo se hará durante el sprint Signup and view all the answers

¿Qué herramienta se menciona como útil para asegurar que un debate sea estructurado?

Un reloj de arena Signup and view all the answers

En la planificación de un sprint, ¿cuál es uno de los principales temas que debe abordarse?

Qué se puede entregar al final del sprint Signup and view all the answers

En el contexto de Planning Poker, ¿qué implica jugar un 6 en lugar de un 5?

Aceptación de una menor incertidumbre Signup and view all the answers

¿Cuál de los siguientes no es un evento clave en Scrum?

Product Planning Signup and view all the answers

¿Qué se espera como resultado del evento de Sprint Planning?

El Sprint Backlog con tareas y objetivos Signup and view all the answers

¿Cuál de los siguientes eventos se lleva a cabo diariamente en un marco de Scrum?

Daily Scrum Signup and view all the answers

Durante la planificación del sprint, ¿quién colabora con el equipo de desarrollo?

El Product Owner Signup and view all the answers

Al usar Planning Poker, ¿qué representa una estimación de 8 en comparación con una de 5?

Una estimación más conservadora de incertidumbre Signup and view all the answers

El Sprint Review se centra principalmente en:

Revisar el trabajo completado y recoger feedback Signup and view all the answers

Study Notes

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

Studying That Suits You

Use AI to generate personalized quizzes and flashcards to suit your learning preferences.

Description

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.