Flashcards

Experimentando con métodos ágiles de software

Valentina Coggan Spanish 103 cards

Cards in this deck (103)

1Software Development Lifecycle ModelsUn ciclo de vida cubre todas las etapas del software desde su inicio con requisitos de definición hasta la puesta en producción y el mantenimiento.
2Categoría 1Software que proporciona funcionalidad de back-end. Por lo general, este es un software que brinda un servicio a otras aplicaciones.
3Categoría 2Software que proporciona un servicio a un usuario final o a una aplicación de usuario final. Por lo general, este sería un software que encapsula la lógica comercial o da formato a los datos para que sean más comprensibles para un usuario final.
4Categoría 3Software que proporciona una interfaz visual a un usuario final. Por lo general, esta es una aplicación frontal que es una interfaz gráfica de usuario (GUI).
5Cascada y Cascada con retroalimentaciónLineal
1
Requisito de documentación.
Impulsado por la especificación.
6Modelo BLineal
1
Cascada + Ciclo de mantenimiento
7Modelo incrementalCombinado
Modelo de cascada iterativo (Los comentarios de iteraciones anteriores se pueden incorporar en la iteración actual)
8Modelo en VLineal
1
Modelo de cascada en forma de V doblada por la mitad en el nivel más bajo de descomposición
9Modelo en espiralIterativo
1 (podría adaptarse para las demás)
4 cuadrantes: Determinar objetivos, Evaluar alternativas, e identificar y resolver riesgos, Desarrollar y probar y Planificar la siguiente iteración.
Cada ciclo dentro de la espiral, se construye un prototipo.
La gestión de riesgos se utiliza como una herramienta para controlar los costos de cada ciclo.
10Modelo de rueda y radiosIterativo
1 y 2
Es un enfoque de abajo hacia arriba que retiene la mayoría de los elementos del modelo en espiral al comprender múltiples iteraciones.
11RUP 4 fases: las fases de inicio, elaboración, construcción y transición.Combinado
2 y 3
Encapsula siete mejores prácticas dentro del modelo:
1. Desarrollar iterativamente utilizando la gestión de riesgos para impulsar la iteraciones
2. Gestionar requisitos.
3. Emplee una arquitectura basada en componentes.
4. Usa modelos visuales.
5. Verificar la calidad continuamente.
6. Controla los cambios.
7. Usa la personalización.
Cada fase puede comprender cualquier número de iteraciones al comprometerse con seis disciplinas centrales (business modeling, requerimientos, análisis y diseño, implementación, test y puesta en producción). Estas disciplinas están respaldadas por otras tres disciplinas: gestión de cambios y configuración, gestión de proyectos y medio ambiente.
12Extreme Programming (XP)Iterativo
2 y 3
Los nuevos requisitos se contabilizan en pasos en espiral cortos y rápidos y el desarrollo se lleva a cabo con programadores que trabajan en parejas.
13Joint Application Development (JAD)Iterativo
Desarrollo colaborativo con el usuario final o cliente involucrándolo durante las fases de diseño y desarrollo a través de talleres
14Lean Development (LD)Iterativo
Entregar un proyecto temprano con una funcionalidad mínima
15ScrumIterativo
2 y 3
El desarrollo se lleva a cabo a lo largo de una serie de iteraciones cortas, o sprints, y el progreso se mide diariamente.
16ProcesoConjunto de actividades interrelacionadas
Roles y competencias
Productos y subproductos (entradas y salidad de las actividades)
Fases
Iteraciones
Disciplinas
Medidas y métricas
Técnicas y herramientas
17¿Por qué son importantes los procesos?tienen las BEST PRACTICES
coordinacion (sabemos lo que estamos haciendo y lo que debemos estar haciendo)
optimiza recursos
repetible
permite comparación (medidas)
18¿Por qué no existe EL método de desarrollo de software?depende del contexto (proyecto, gente, riesgos, cultura organizacional)
sería un método muy complejo con muchas formas distintas de realizar adaptaciones (process tailoring)
no existe tal cosa, es imposible lograrlo, el contexto es todo y varía demasiado
aún es una disciplina muy joven
19¿Qué método seguimos?el que mejor se adapte a lo que necesitas
uno que nos sirva
normalmente es un proceso híbrido -> adaptación de procesos de software
20¿Debe estar definido el método? para que?saber cómo se hacen las cosas en esta empresa/equipo
poder mejorar
aumentar la calidad de los productos que desarrollamos
facilitar el entendimiento entre las personas y la comunicación
proveer soporte automático al proceso
21Gestionar un ProyectoLa gestión de proyectos es la disciplina del planeamiento, la organización, la motivación, y el control de los recursos con el propósito de alcanzar uno o varios objetivos.
Las limitantes o restricciones primarias son el alcance, el tiempo, la calidad y el presupuesto.
22Gestión tradicional de proyectosEl alcance no se negocia
23Gestión Agile de “proyectos”Enfocarse en el Cliente y el Producto o Servicio, en vez de en la Gestión de Proyecto
El alcance es lo único que se negocia
Gestionar el alcance del producto frecuentemente para reducir la incertidumbre
24Manifiesto ÁgilIndividuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan
2512 principios ágiles DESCRIBE + SETSDesarrollo sustentable
Entregar frecuentemente
Software útil
Comunicación cara a cara
Reflexión periódica
Individuos motivados
Bienvenidos los cambios
Excelencia técnica
Simplicidad
Equipos autoorganizados
Trabajamos juntos
Software funcionando es progreso
26AgileEs la habilidad para adaptarse a los cambios
Gestionar el alcance frecuentemente para reducir la incertidumbre
Implica transformación
27Pilares Scrm TIATransparencia
Inspección
Adaptación
28Valores Scrum FRACCiónFoco
Respeto
Apertura
Coraje
Compromiso
29Pilares Kanban SOSSupervivencia
Orientación al servicio
Sostenibilidad
30Valores Kanban FLAT + CECEFlujo de la cadena de valor
Liderazgo
Acuerdo de personas
Transparencia
Colaboración
Equilibrio
Comprensión del proceso
Enfoque en el cliente
31Valores XP FRESCCOFeedback
Respeto
Simplicidad
Comunicación
Coraje
32Principios Lean CEDE + VEAConstrucción integradora
Eliminar desperdicio
Decidir lo más tarde posible
Entregar lo más rápido posible
Ver el todo
Empoderar al equipo
Amplificar el aprendizaje
33Principios Kanban GEGestión del cambio
Entrega de servicio
34Prácticas Kanban CIVIL + GMCrea políticas explícitas
Implementa feedback loops
Visualizar tu trabajo
Limita el trabajo en curso
Gestiona el flujo
Mejora colaborativamente
35ScrumEs un marco de trabajo simple para gestionar proyectos, donde las personas involucradas en el proyecto utilizan soluciones adaptativas para resolver problemas complejos, lo hacen de forma creativa y productiva, entregando frecuentemente valor de negocio al cliente.
36Scrum TeamDevelopment Team
Product Owner
Scrum Master
37ArtefactosProduct Backlog
Sprint Backlog
Incremento
38EventosSprint
Sprint planning
Daily scrum
Sprint review
Sprint retrospective
39Scrum Development Team caracteristicas3-9 integrantes técnicos
construyen producto
auto-gestionado
multidisciplinario
40Scrum Development Team actividadesorganizar el trabajo interno
estimar las tareas
coordinar entre ellos y con los equipos
definir cómo hacer las tareas
ejecutar todas las actividades necesarias para desarrollar cada ítem del product backlog. Incluyendo actividades para comprender mejor cada ítem
41Scrum Product Owner caracteristicasuna única persona
maximiza el valor del producto
responsable de QUE hay que construir NO de como
Genera una comunidad de trabajo entorno al producto
42Scrum Product Owner actividadesExpresar las necesidades del producto (product backlog)
Definir prioridades en función de la misión del negocio
Colaborar en la optimización del trabajo del Development Team
Asegurar transparencia del Product Backlog
Asegurar que el development team entiende los ítems del PB al nivel necesario.
43Scrum master caracteristicasun única persona
responsable de que Scrum se use bien
No controla, ni administra
Está al servicio del Product Owner, el Development Team y la Organización toda
44actividades del scrum master con el POEncontrar técnicas para gestionar eficientemente el Product Backlog
Ayudar a entender la planificación en función del desarrollo empírico
Asegurar que el Product Owner conozca cómo ordenar el Product Backlog para maximizar el valor del negocio
Facilitar los eventos Scrum
45Actividades del scrum master con el dev. teamGuiarlos para que aprendan a ser más auto-organizados
Eliminar impedimentos que el equipo pueda tener durante el sprint
Facilitar los eventos Scrum
Guiar al equipo para que pueda trabajar productivamente según la madurez de la Organización en el uso de Scrum
46Actividades del scrum master en la organizaciónLiderar la adopción de Scrum en la organización
Planificar las diferentes implementaciones de Scrum en la organización
Ayuda a los colaboradores de la organización a entender Scrum y el trabajo basado en empirismo
Motiva cambios que ayuden a incrementar la productividad de los equipos Scrum
Trabaja en equipo con otros Scrum Masters para hacer más efectiva la aplicación de Scrum
47Product backlog -> Product goalEs una lista ordenada de todo lo que podría ser necesario en el producto, y es la única fuente de requisitos para cualquier cambio a realizarse en el producto. El Dueño de Producto (Product Owner) es el responsable de la Lista de Producto, incluyendo su contenido, disponibilidad y ordenación.
48Sprint backlog -> Sprint goalPorción del Product Backlog
Solo PBIs que permitan alcanzar el Sprint Goal
Es el plan de trabajo del development Team para el sprint
49Increment -> Definition of doneEs software funcionando
Cada incremento contiene lo hecho en el sprint anteriores
Características:
los ítems deben estar “terminados” (cumplir con DoD)
el incremento debe funcionar, es decir, debe poder ser utilizado
debe tener la calidad necesaria para ponerse en producción si el Product Owner así lo quisiera
50SprintEvento conformado por un espacio de tiempo, contenedor de otros eventos.
51Un sprint rara vez se cancelaEl único rol de Scrum que puede decidir cancelar un sprint es el Product Owner
Lo hace únicamente cuando la meta del negocio (sprint goal) es obsoleta
52Timeboxmáximo tiempo que te puede llevar una tarea
53Sprint Planninginspección y adaptación: qué y cómo vamos a trabajar para alcanzar otro incremento de producto
54Sprint PlanningParticipantes: Development Team, Product Owner y Scrum Master
Input: Product Backlog
Output: Sprint Backlog, Sprint Goal, definition of done
Pasos:
Definir valor del sprint (Product Goal)
Selección de BPIs
Development Team hace un plan para alcanzar el Sprint Goal.
Timebox: 8 horas máximo por mes de sprint
55¿Cuál es el valor del Sprint? —> Sprint GoalEl PO explica cómo el Producto podría incrementar su valor en este Sprint.
El dev team busca entender el beneficio del negocio.
Juntos identifican el Sprint Goal.
Se comunica este a los stakeholders.
56¿Qué se puede hacer en el Sprint? —-> Definition of doneEntre ambos buscan PBIs que puedan estar relacionados al Sprint Goal.
El Dev Team puede descomponer en ítems más pequeños.
El Dev Team recurre a su Criterio de Terminado, capacidad y datos de velocidad del Sprint anterior para generar una mejor predicción.
57¿Cómo se hará el trabajo elegido? —-> Sprint BacklogEl dev team definirá un conjunto de tareas que debe hacer para finalizar cada PBI.
Cada una de estas tareas debe ser hecha cómo máximo en un día o menos.
Dando lugar al Sprint Backlog, que junto con el Sprint Goal es el plan de trabajo del Dev Team para todo el Sprint.
58Daily scruminspección y adaptación: trabajo en curso
59Daily scrumparticipantes: development team
Input: sprint goal, sprint backlog, definition of done
Output: sprint backlog (con asaptaciones necesarias en las tareas)
pasos:
El Development Team evalúa el progreso para llegar al Sprint Goal.
Sincroniza el trabajo y las tareas del Sprint Backlog.
Timebox: 15 minutos por dia
60Sprint reviewinspección y adaptación: sobre qué hicimos
No es para testear el producto.
Más allá de haber completado o no el 100% del Sprint Goal el PO debe identificar si se ha cumplido con el Product Goal.
Un cumplimiento del 80% del Sprint Goal suele considerarse exitoso
61Sprint reviewParticipantes: Development Team, Product Owner y Scrum Master
Input: Product goal, Increment
Output: todo el feedback obtenido va al product backlog
Pasos:
El Dev Team usa el Increment para mostrarle al PO.
El PO chequea el cumplimiento del Product Goal.
El PO da feedback y acepta o rechaza ítems construidos.
Timeboxing: 4 horas máximo por mes de sprint
62Sprint retrospectiveinspección y adaptación: sobre cómo lo hicimos
Evento especial enfocado en aprender a experimentar cómo trabajamos
Con cuatro reglas esenciales
Con una estructura de cinco fases
Objetivo: Mejorar la productividad y la efectividad en el siguiente Sprint
63Sprint retrospectiveParticipantes: Development Team, Product Owner y Scrum Master (se puede invitar a alguien más si todo el equipo está de acuerdo)
Input: Proceso, definition of done
Output: plan de acción para el sprint backlog (a ejecutar si o si en el próximo sprint)
Pasos:
Analizar:
Personas y relaciones
Proceso y herramientas
Discutir causas de problemas.
Lograr entendimiento compartido.
Elaborar un plan de acción para aplicar en el siguiente sprint.
Timeboxing: 3 horas máximo por mes de sprint
64Sprint retrospective ReglasSeguridad: Garantizar un ambiente seguro para todos sus participantes
Entender: Chequear que exista un entendimiento compartido para todos los participantes
Incluir: Buscar soluciones/experimentos que incluyan diferentes puntos de vista
Responsabilidad: Todos los integrantes de un Equipo Scrum son igualmente responsable de mejorar la forma de trabajo
65Sprint retrospective FasesPreparar el escenario
Obtener datos
Indagar/Analizar
Generar ideas
Cerrar
66Principios Lean developmentmejorar el flujo
hacer el trabajo más fluido y magro
PULL -> voy haciendo a medida que me piden
67Kanbanframework que me permite poner en práctica los principios de lean
tecnica para cambiar el paradigma del management y deja que un equipo administre su flujo
todos los integrantes deben visualizar el flujo de trabajo y administrarlo ellos mismos
68kanban se basa en Kaizencomenzar con lo que tengas
agrega valor con cambios poco a poco
respeta las categorías, roles y responsabilidades
da poder a las personas en todas las áreas implicadas
69WIPWork in Progress, limitación del trabajo en progreso. Número de tareas que se atienden simultáneamente.
70LeadTimeTiempo desde que se solicita una tarea hasta que es entregada.
71CycleTimeTiempo desde el inicio en el proceso hasta el final del proceso.
72TouchTimeTiempo de trabajo efectivo de la tarea. Tiempo en las columnas de “trabajo en curso”.
73TouchTime/CycleTimeEfectividad del flujo e inactividad.
74Componentes de un tablero KanbanEstados del flujo de trabajo
Límites del trabajo en progreso
Condición de transición entre estados
Bloques de división
Tarjetas
75XP RolesProgramador
Cliente
Encargado de pruebas
Encargado de seguimiento
Entrenador
Gestor
76XP Roles ProgramadorEl programador escribe las pruebas unitarias y produce el código del sistema.
Debe existir una comunicación y coordinación adecuada entre los programadores y otros miembros del equipo.
77XP Roles Clienterepresentado por una única persona
escribe las user stories y pruebas funcionales para validar la implementación
asigna prioridades, centrándose en maximizar el valor del negocio
78XP Roles Encargado de pruebasayuda al cliente a escribir las pruebas funcionales
ejecuta las pruebas regularmente y comparte los resultados en el equipo de desarrollo
es responsable de las herramientas de soporte para prueba (Infraestructura de testing)
79XP Roles Encargado de seguimientoverifica el grado de acierto en las estimaciones y comunica los resultados para mejorar
realizar seguimiento del proceso y evalúa si los objetivos son alcanzables de acuerdo al tiempo y recursos presentes
80XP Roles Entrenadorresponsable del proceso global de IS
debe conocer XP a fondo y servir de guía a los miembros del equipo
81XP Roles Gestorsu labor esencial es de coordinación
actúa de vínculo entre clientes y programadores
ayuda al equipo creando las condiciones de trabajo adecuadas
82Fases XPFase de Exploración
Fase de Planificación de entregas
Fase de Iteraciones
Fase de Producción
Fase de Mantenimiento
Fase de Muerte del proyecto
83Fase de ExploraciónEl cliente plantea las User Stories (a grandes rasgos) que son de interés para la primer entrega de producto.
Mientras el equipo de desarrollo se familiariza con las herramientas, tecnologías y prácticas que utilizarán en el proyecto y se exploran las posibilidades de la arquitectura del sistema construyendo un prototipo.
Se arman Spikes y se escribe la Metáfora del Sistema.
84Fase de Planificación de entregasSe plantea un juego buscando acortar barreras emocionales entre el negocio y los desarrolladores.
El objetivo es poner el mayor valor posible de User Stories en producción durante la vida del juego.
Participan los representantes del negocio y desarrolladores.
Las personas del negocio escriben User Stories asignándoles valor de negocio.
Los programadores estiman.
Se arma el Release Plan del proyecto (20 a 80 stories) y comienzan las Iteraciones.
85Fase de IteracionesCada iteración dura entre 1 y 3 semanas.
En la primera iteración se puede intentar establecer la arquitectura, escogiendo las User Stories que fuercen esto.
Pero esta decisión la toma el Cliente en base al valor de negocio.
Daily meeting
Se sigue desarrollando sin parar hasta que algo falle
Si algo falla, allí nos juntamos para reflexionar
Planificacion
Diseño
Codificacion
Pruebas
86Fase de ProducciónEs posible modificar el tiempo de las iteraciones a una semana.
Se realizan pruebas adicionales y revisiones de rendimiento antes de trasladar al entorno del cliente.
Todas las ideas que surjan en este periodo serán documentadas para su posterior implementación en la siguiente fase: Mantenimiento.
87Fase de MantenimientoLuego de haber salido a producción, se debe mantener el sistema en funcionamiento para eso se propone aplicar nuevamente una fase de Planificación y otro ciclo de Iteraciones.
Al requerir tareas de soporte, puede variar la velocity y también la composición del equipo de desarrollo.
Cuando ya no hay más User Stories a incluir pasamos a la última fase: Muerte del Proyecto.
88Fase de Muerte del proyectoSe prevé esta fase para cuando se detecta que mantener el sistema ya no genera beneficios o no hay más presupuesto.
Se genera la documentación que pueda faltar dado que aunque el equipo de desarrollo ya no le dedique tiempo es posible que el sistema siga estando en producción.
89Diferencias scrum vs xpno tiene fases
el flujo de proceso está dado por un sprint seguido inmediatamente de
90que hay en Scrum antes del primer sprintNo hay sprint 0
visión de producto
91Hay release plan en scrum como en xp?No se define nada al respecto del release plan
92Actividad de scrum para planificarSprint planning (una única vez por iteración)
93¿Qué propone Scrum en cuanto a diseño?nada -> fue pensado para gestión no solo para software
si tengo un equipo auto-organizado que definan ellos
94¿Qué propone scrum en cuanto a construcción?no define nada al respecto
es agnóstico a la disciplina que se utilice para construir el producto
95scrum prevé que el cliente valide el producto?únicamente en el sprint review
No es un momento de testing pero si de retroalimentación del producto.
en XP es en todas las pruebas
96¿Cómo se reflexiona en Scrum?Evento: Sprint Retrospective.
Más allá si algo falló o no, hay una Retro en cada Sprint.
97¿Scrum en producción/mantenimiento?No se propone cambios si estamos en producción/mantenimiento
98AGILE Estimating & planning ActividadesRefinement: para preparar stories que puedan ser estimadas.
Sprint planning: para ver cuáles y cuántas stories desarrollaremos para cumplir el Product Goal y generar el Sprint Backlog.
99RefinamientoCuidar la “salud” del Product Backlog para ser más eficientes
Participan El PO y el Equipo de Desarrollo
no tiene que participar todo el Dev Team pero si o si tiene que estar el PO
baja la incertidumbre invirtiendo como máximo el 10% de capacidad del Dev Team
100Refinamiento actividadesanalizar las primeras stories del backlog
intentar estimar cada una
Agregar detalles
Responder preguntas incluidas en los comentarios
Intentar definir el criterio de aceptación
Dividir stories
Agregar, eliminar o modificar stories
101Planning PokerComenzar con la primer story del backlog.
Preguntar: ¿Alguno quiere explicar qué hay que hacer para construirla?
Recordar: explicar sin influir a los demás.
Cada miembro elige una carta que represente el tamaño.
Alguien dice “poker” y todos muestran su carta de estimación al mismo tiempo.
Si hay estimaciones muy opuestas, ambos explicarán por qué estimaron así.
Luego de explicar, se hace otra ronda de estimación.
Se repite este proceso para el resto de las stories.
102Sprint PlanningEl plan para alcanzar el Sprint Goal y cumplir el Product Goal
103Planning a Nivel de ReleaseUsamos Story Mapping para estimar éste nivel. Es una técnica visual para organizar y discutir los objetivos que el producto le permitirá cubrir a un usuario en función de su flujo de actividades

Information

Description: Flashcards on Experimentando con métodos ágiles de software, created by Valentina Coggan on 31/07/2023.
Created by: Valentina Coggan
Views: 1
Rating