Muestra las diferencias entre dos versiones de la página.
Próxima revisión | Revisión previa | ||
ps:metodologias_agiles [2024/01/31 18:19] – creado thejuanvisu | ps:metodologias_agiles [2024/01/31 18:56] (actual) – thejuanvisu | ||
---|---|---|---|
Línea 1: | Línea 1: | ||
- | ====== Proyecto Integral del Software: Metodologías Ágiles ====== | + | ====== Proyecto Integral del Software: Metodologías Ágiles |
===== Reuniones y roles ===== | ===== Reuniones y roles ===== | ||
==== Tipos de Reuniones ==== | ==== Tipos de Reuniones ==== | ||
Línea 9: | Línea 9: | ||
==== Roles ==== | ==== Roles ==== | ||
- | | + | <WRAP align right> |
- | * Scrum Master | + | {{drawio> |
- | * Se encarga de que todo funcione para poder poner en marcha la agilidad | + | </ |
+ | * **Product Owner**: Representa la voz del cliente y de los interesados no implicados en el proyecto. Se encarga de definir los objetivos del proyecto y garantizar que el equipo trabaja de modo adecuado par alcanzar los objetivos | ||
+ | | ||
+ | | ||
* Time Boxing: El scrum master debe tener todas las partes de srcum limitadas por tiempo. | * Time Boxing: El scrum master debe tener todas las partes de srcum limitadas por tiempo. | ||
- | * Equipo de desarrollo | + | |
- | * StakeHolders | + | |
+ | |||
+ | Lo que se busca con estos roles es que "El que más sabe de algo que sea el que lo haga" | ||
+ | |||
+ | ==== Desperdicios ==== | ||
+ | |||
+ | * Velocidad: entendida como la suma de los items que se terminan en un trozo de tiempo y que había pedido el product owner, se ve condicionada especialmente por lo que solemos llamar desperdicio | ||
+ | * Desperdiciós típicos: Interrupciones, | ||
+ | * Desperdicios en los tableros: Postit que se quedan estancados en el DOING, columnas de test con demasiadas tareas acumuladas. | ||
+ | |||
+ | Para evitar estos desperdicios son importantes las retrospectivas utilizando técnicas como la de la estrella de mar para localizar cosas que se deben hacer más o menos, además de las cosas que se están haciendo bien. | ||
+ | |||
+ | ===== Estimación y puntos de historia ===== | ||
+ | Se utilizan para calcular la velocidad del equipo de trabajo. Hay 2 principales tipos de estimación: | ||
+ | * **Estimación general**: Estimamos lo que podemos hacer basándonos en sprints anteriores | ||
+ | * **Estimación por Planning poker**: Se utilizan unas cartas con la sucesión de fibonacci (1, 2, 3, 5, 8, 13, 20, 40 y 100). Cuando se selecciona la tarea a realizar los participantes toman las cartas en base a la complejidad que creen que tienen una tarea. Tras eso cada miembro muestra la carta y se selecciona a los miembros que han tomado la carta más alta y más baja y se les pide que expliquen por que consideran que puede ser más fácil o más difícil la tarea en cuestión, lo que resulta en un debate que finaliza con una votación y un consenso entre los miembros del equipo. | ||
+ | |||
+ | ==== Pasos para estimar ==== | ||
+ | * Ver el product backlog | ||
+ | * Tamaño unidad: complejidad en puntos historia (Algunos los traducen en horas) | ||
+ | * Tiempo ideal: puntos de historia por sprint (Velocidad) | ||
+ | * Tiempo Real | ||
+ | |||
+ | ===== Priorizando el product backlog ===== | ||
+ | * Técnica de MoSCoW y Kano: | ||
+ | * Se utiliza para clasificar y priorizar requisitos en función de los que satisfaán al usuario. | ||
+ | * 4 tipos: | ||
+ | * Requisitos obligatorios (Básicos) | ||
+ | * Necesidades (Esperados) | ||
+ | * No esperados (Inesperados pero que interesan) | ||
+ | * Indiferentes (El cliente no está interesado en estos) | ||