Capítulo 1: Desarrollo Ágil de Software - Enfoques ágiles y planificación

Capítulo 1: Desarrollo Ágil de Software - Enfoques ágiles y planificación

CAPITULO I: Desarrollo agil de software

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Objetivos de aprendizaje

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Introducción

• Existen diferente enfoques ágiles, en diversos negocios.

¿Qué es común a todos los enfoques?

• Se crean historias de usuario en colaboración.
• Se hace uso de la integración continua, y de las retrospectivas.
• Se crea un plan de la entrega (release) completa en cada iteración.
• Aplican los valores del Manifiesto Ágil de forma diferente.
• En este plan de estudio se consideran 3 ejemplos

• Programación Extrema (XP)
• Scrum
• Kanban

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Extreme Programming (XP)

Orígenes

• Introducida por Kent Beck*, es un enfoque ágil del desarrollo de software, caracterizada por valores definidos, principios y prácticas de desarrollo.

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Extreme Programming (XP)

Orígenes Combina diferentes disciplinas de desarrollo de software, implementa las buenas prácticas, estas prácticas son comunes a otros modelos ágiles.

XP promueve cinco valores que guían el desarrollo:

• Comunicación
• Sencillez
• Feedback
• Valentía (encourage)
• Respeto

• http://de.wikipedia.org/wiki/Extreme_Programming

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Programación Extrema (XP)

• 14 principios como guía adicional

1. Visión humanizada.- El ambiente de trabajo está en línea con las necesidades de los miembros del equipo como seres humanos.
2. Economía.- El desarrollo es económicamente viable y debe generar valor.
3. Beneficio mutuo.- El software satisface a todas las partes
4. Auto-similitud.- Las soluciones se utilizan de nuevo en situaciones similares
5. Mejora.- Se mejoran las soluciones y el proceso haciendo uso de un feedback frecuente.
6. Diversidad.- Mejora de la productividad del equipo a través de la diversidad.
7. Reflexión.- Constante reflexión en la identificación de las mejores soluciones.
8. Flujo (trabajando con un gran nivel de concentración constante),el flujo de trabajo ininterrumpido e iteraciones cortas mantienen el proyecto en movimiento
9. Hacer uso de las oportunidades.- Impedimentos y fracasos son vistos como oportunidades.
10. Evitar la redundancia.- Evitar repetir los pasos que se puedan automatizar.
11. Aceptar el fracaso.- No enfadarse por implementaciones que inicialmente no son óptimas o tienen errores, siempre y cuando éstas sean vistas como oportunidades por el equipo
12. Calidad.- Software de alta calidad
13. Pasos pequeños.- Muchas iteraciones cortas, feedback inmediato, rápida compensación de los fallos, flexibilidad en relación con el marco del proyecto
14. Aceptar la responsabilidad.- El equipo asume la responsabilidad, no hay reglas prescritas por la administración.

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Programación Extrema (XP)

• 13 prácticas primarias

1. Sentarse juntos.- Mejor comunicación, optimizada por la disposición de los espacios de trabajo
2. Equipo-completo, un equipo interdisciplinario, auto organizado, la certeza de que el éxito sólo se logra colectivamente
3. Espacio de trabajo informativo.- La información importante debe ser vista desde donde estás sentado.- (Por ejemplo: las tareas actuales, estado del proyecto, ...)
4. Trabajar con ganas.- Trabajo auto motivado en una atmósfera sin presiones, sin horas extras de trabajo
5. Holgura.- Tener tiempo para trabajos no urgentes, pero importantes
6. Programación en parejas.- Promover la auto regulación de los equipos para hacerse cargo de las tareas de programación en parejas y alternando compañeros
7. Historias.- Las historias de usuario describen la funcionalidad que se debe implementar

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Programación Extrema (XP)

• 13 prácticas primarias

8. Ciclo semanal.- Se decide de forma semanal, las historias que se van a implementar 9. Ciclo trimestral.- El plan del proyecto en su conjunto se hace sobre una base de tres meses. 10. Compilación de diez minutos.- Creando una compilación o build (versión de software integrado) y ejecutando pruebas (automatizadas) en un máximo de 10 minutos. Se reducen esfuerzos y costes! 11. Integración continua.- Los programadores adoptan todos los cambios en ciclos cortos y constantemente repetidos 12. Pruebas que guían el desarrollo..- (Desarrollo basado en pruebas / realizar tests permanentemente). Las pruebas deben ser escritas antes de la implementación de la funcionalidad 13. Diseño incremental.- El diseño incremental asegura que el feedback y el aprendizaje (learninngs) se incorporan para la mejora de software.

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Programación Extrema (XP)

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Scrum

Orígenes y diferencias con XP Es el principal marco ágil, introducido por Mike Beedle y Ken Schwaber, los equipos que siguen SCRUM, a menudo incorporan prácticas de XP. En SCRUM no hay descripciones técnicas de software y no existen pautas para realizar las pruebas.

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Scrum

Instrumentos y prácticas en la gestión de proyectos

*Sprint Scrum divide un proyecto en iteraciones cortas de longitud constante (sprints), que duran por lo general entre dos y cuatro semanas. *Incremento del producto Cada sprint crea un producto que podría ser entregado al cliente (entregable). El rango de funcionalidad crece con cada iteración (incremental). *Backlog del producto El propietario del producto es responsable de una lista priorizada de funcionalidad llamada “backlog del producto”. Muestra la funcionalidad prevista del producto. Evoluciona de sprint a sprint. Estos cambios se conocen como “refinamiento del backlog“. *Backlog del sprint En la reunión de planificación del sprint, el equipo selecciona una lista de elementos prioritarios del backlog del producto. El equipo se compromete a implementarlos según lo descrito. Debido a que el equipo Scrum selecciona los requisitos de la lista es un pull-principle (pedir) en lugar de un push-principle (recibir).

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Scrum

Instrumentos y prácticas en la gestión de proyectos

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Scrum

Instrumentos y prácticas en la gestión de proyectos

*Definición de hecho El equipo analiza y define los criterios que determinan si una tarea se ha completado o no. Esta discusión ayuda a comprender mejor los requisitos del producto y sus criterios de aceptación. *Time boxing Time boxing, o tiempo establecido (caja de tiempo), es una cantidad fija de tiempo. El time boxing implica discutir acerca de en qué elementos se va a centrar el equipo, evitando discutir cosas innecesarias o problemas innecesariamente detallados. Las funcionalidad del producto que no se pueden terminar durante un sprint, se sacan fuera del mismo y se incluyen de nuevo en la backlog del producto. En Scrum, el time boxing se aplica no sólo a las tareas, sino también a muchas situaciones en las que existe un principio y un fin, por ejemplo, en qué momento se iniciará y terminará una reunión. *Transparencia El estado del sprint se actualiza y se informa de él a diario (en el Scrum diario, reunión diaria de estado del equipo). El contenido y el progreso del sprint actual, incluyendo los resultados de las pruebas, se hacen visibles para el equipo, los gestores y todas las partes interesadas (stakeholders) - por ejemplo mediante el uso de un tablero Scrum (tablero de tareas) para mostrar el estado del sprint.

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Scrum

Ejemplo de un proceso SCRUM

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Scrum

Roles en Scrum

*Scrum Master (SM) El Scrum Master es responsable de asegurar que se aplican y siguen las prácticas y reglas de Scrum. Cualquier violación, problemas de recursos, u otros impedimentos que hagan al equipo no seguir las prácticas y normas deben ser resueltos por el Scrum Master. Sin embargo, el Scrum Master no es un líder del equipo, es más bien un entrenador. *Propietario del producto (PO: Product Owner) El propietario del producto es responsable de la gestión del backlog del producto y representa al cliente o clientes en el equipo; no es un jefe de equipo. El propietario del producto genera, mantiene y da prioridad a las funcionalidad de los productos que figuran en la backlog del producto. *Equipo de desarrollo El equipo de desarrollo es auto-organizado y desarrolla y prueba el producto. El equipo en su conjunto toma las decisiones y no hay ningún líder de equipo. El equipo también es multidisciplinar (véanse los capítulos II/3.2 - El rol de tester en un equipo ágil y III/1.4 - El rol de tester).

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Kanban

Orígenes y funcionalidad especiales

*Es un enfoque de gestión que a veces se utiliza en proyectos ágiles de desarrollo de software. *El objetivo general es visualizar y optimizar el flujo de trabajo y su cadena de valores añadidos mediante un Tablero Kanban (transparencia). *Las tareas no están programadas, están esperando en el backlog y se mueven al Tablero Kanban en cuanto hay espacio disponible. *Iteraciones/sprints y time boxing son opcionales, los resultados pueden ser lanzados elemento a elemento en lugar de trabajar con entregas (raleases). *Reduce el número de tareas paralelas y alcanza un rendimiento más rápido ya que los problemas y cuellos de botella son fácilmente visibles.

El Kanban (del japonés: kanban, donde kan significa "visual," y ban "tarjeta" o "tablero"). Es una técnica originada en la línea de producción del fabricante de automóviles Toyota, con lo que el volumen de almacenamiento se reduce y se crea un flujo de fabricación constante. Es especialmente las ideas de Don Reinertsen, quien presentó diferentes técnicas para el desarrollo de productos en mucho menos tiempo, que hizo famosa a Kanban. La aplicación de Kanban a la producción de TI, David Anderson presentó un concepto integrado en el 2007 para el público y es visto como el "fundador" de Kanban. Aunque Kanban implica la cultura de un proceso de mejora continua (CIP) como parte integral, no proporciona prácticas detalladas para ello. Fuente: http://de.wikipedia.org/wiki/Kanban_(Softwaredevelopment)

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Kanban

Los tres instrumentos de Kanban

Se hace visible la cadena de valor que se va a gestionar. Cada columna muestra un puesto de trabajo, que es un conjunto de actividades relacionadas (por ejemplo, de desarrollo o de prueba). Las tareas a procesar o los elementos que deben producirse están escritos en tarjetas (tickets) que se mueven de izquierda a derecha por todo el tablero a través de los puestos de trabajo. La cantidad de tareas activas es estrictamente limitada. Es controlada por el número de entradas permitidas para ser trabajadas en paralelo en una estación y/o en el tablero en general. Cada vez que una estación tiene capacidades libres, se toma una tarea de un puesto de trabajo anterior. A través de un flujo continuo de tareas, la cadena de valor se optimiza al minimizar (en promedio) el tiempo de espera necesario para completar un flujo de valor.

1. Tablero Kanban

2. Límite de tareas en curso

3. Tiempo de entrega

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Ejemplo de un Tablero Kanban

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Creación conjunta de Historias de Usuario.

• La mala calidad de las historias de usuario a menudo conlleva al fracaso del proyecto.
• Los clientes carecen del conocimiento de sus verdaderas necesidades.
• No hay una visión global del sistema.
• Descripción de funcionalidad redundantes o contradictorias.
• Comunicación insuficiente o mala.
• No hay una revisión suficiente de los requisitos.

Causas de fracaso y riesgos

Evitar las causas del fracaso en las historias de usuario

• Describir los requisitos en una visión compartida entre todas las personas involucradas.
• Las historias y los criterios de aceptación son creados en colaboración.
• La visión compartida de una funcionalidad se consigue a través de revisiones informales durante la descripción de los requisitos.
• Las historias de usuario abordan requisitos funcionales y no funcionales.
• Para cada característica se definen los criterios de aceptación.
• La colaboración ayuda a programadores y testers a entender lo que quieren los representantes del negocio (business representatives).

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Creación conjunta de Historias de Usuario.

La perspectiva del tester

• Mejorará la Historia de usuario identificando detalles que faltan.
• Identifica los requisitos no funcionales que faltan y los completa
• Puede hacer preguntas abiertas a los representantes del negocio, sobre las historias de usuario, propone formas de hacer pruebas a las mismas y confirma los criterios de aceptación.
• Brainstorming (tormenta de ideas) y mind-mapping (mapas mentales) son técnicas para crear historias de usuario.

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Creación conjunta de Historias de Usuario.

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Ejemplo de Historia de Usuario

El desarrollador escribirá la funcionalidad descrita en la historia de usuario y el tester la probará. Una prueba usa el criterio de aceptación para comprobar la interoperabilidad y explicar mejor las necesidades del cliente.

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Creación conjunta de historias de usuario

El concepto 3C, conjunción de tres elementos Tarjeta La tarjeta es el agente físico que describe una historia de usuario. Identifica el requisito, su criticidad, el desarrollo esperado y duración de la prueba, así como los criterios de aceptación de la historia. Debe tener una descripción precisa, ya que será utilizada en la backlog del producto. Ejemplo:

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Creación conjunta de Historias de Usuario.

El concepto 3C, conjunción de tres elementos *Conversación La conversación explica cómo se utilizará el software. Se puede realizar por escrito o de forma oral. Los testers, que tienen un punto de vista diferente al de los programadores y representantes del negocio, brindan ideas muy valiosas en este intercambio de ideas, puntos de vista y experiencias. La conversación comienza durante la planificación de la entrega (release) y continúa cuando la historia está prevista para su implementación. *Confirmación Los criterios de aceptación que se tratan en la conversación se utilizan para confirmar que la historia se ha completado. Estos criterios pueden abarcar más de una historia de usuario; su cobertura se comprueba mediante ambas pruebas: negativas y positivas. Durante la confirmación, varios participantes juegan el papel de tester. Estos pueden ser programadores o especialistas, cada uno con un enfoque diferente, como el rendimiento, la seguridad, la interoperabilidad y otros aspectos de la calidad. Para confirmar una historia como terminada, primero se deben probar los criterios de aceptación definidos y demostrar que han sido satisfechos. Independientemente de cómo se documenten las historias de usuario, la documentación debe ser concisa, suficiente y necesaria.

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Creación conjunta de Historias de Usuario.

INVEST-Criterios para la evaluación de las historias de usuario Independent – Independiente. Las historias de usuario deben ser independientes entre sí. Negotiable – Negociable. Las historias de usuario son negociables, ofrecen la oportunidad de discutir y aclarar. Valuable – Valioso. Las historias de usuario tienen un valor reconocido por el usuario. Estimable – Estimable. El equipo es capaz de entender las funcionalidad y se puede estimar el esfuerzo. Small – Pequeño. La historia de usuario tiene un tamaño cómodo; si es demasiado grande, se debe dividir. Debe tener un tamaño que pueda ser entregado dentro de una iteración. Testable – Comprobable. Las historias de usuario son comprobables; se han definido los criterios de aceptación de forma inequívoca (no ambigua).

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Retrospectivas

Significado

• Es una reunión del equipo realizada al final de cada iteración.

• Debe incluir al dueño del producto (product owner)

• Debate sobre lo que fue un éxito y lo que se puede mejorar, además de identificar

• cómo incorporar mejoras en futuras iteraciones.

• Cómo mantener hábitos y prácticas satisfactorios.

• Se pone atención a
• El proceso
• Los participantes
• Organizaciones y relaciones
• Herramientas

• El objetivo es la mejora continua, una precondición básica es un entorno profesional y la confianza entre los miembros del equipo.

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Retrospectivas

Resultados

• Las decisiones de mejoras de las pruebas se hacen respecto a

• Eficacia de la prueba
• Productividad de la prueba
• Calidad de los casos de prueba
• Satisfacción del equipo

• Testeabilidad de la aplicación, historias de usuario, funciones, interfaces

• Se limita a unas pocas mejoras en cada iteración, esto permite la mejora continua a un ritmo sostenido.

• Mejora continua a velocidad constante.

• Monitorizando la implementación de las medidas identificadas, las retrospectivas son factor
• clave que contribuye a la auto-organización del equipo
• Las mejoras (por ejemplo, con la ayuda de la técnica análisis causa raíz de los defectos) tienen un impacto en la prueba y en el desarrollo.

Los criterios del éxito de una revisión se describen en el plan de estudios CTFL.

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Retrospectivas

Factores de éxito de las revisiones (contenido de CTFL)

• Las revisiones deben estar orientadas a la realización de objetivos, por ejemplo: la desviación del objeto revisado se debe indicar de manera imparcial.
• Se debe motivar de forma positiva al autor del objeto revisado con la revisión ("el
• documento será mejor todavía" en lugar de "el documento es de mala calidad").
• Uso sistemático de las técnicas y plantillas introducidas.
• El uso de listas de verificación (check lists) o roles mejorará la eficiencia de una revisión.
• Se necesita un presupuesto suficiente para llevar a cabo una revisión adecuada .
• Hacer uso de las lecciones aprendidas, utilice el feedback para implementar un proceso de
• mejora continua.
• Formación en técnicas de revisión, especialmente para las más formales.
• La gestión soporta un buen proceso de revisión.

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Retrospectivas

• Duración y organización

• De acuerdo con el método ágil seguido.
• Un moderador/facilitador organiza la reunión y la ejecuta.
• Los representantes del negocio (business representatives) y el equipo toman parte en
• la retrospectiva
• El equipo puede invitar a otras personas a participar.

• Rol de tester

• Los testers deben desempeñar un papel importante en la retrospectiva.
• Los testers:

• Son parte del equipo.
• Traen su perspectiva única (véase el capítulo I/5)
• Hacen una contribución sustancial para alcanzar el éxito.

• Las pruebas se realizan en todos los sprints

• Las pruebas también se benefician de la contribución de otros miembros del equipo.

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Integración continua

Proceso

• Entrega de un incremento del producto fiable al final de cada sprint - presentación de un software funcional

• La integración continua aborda el reto de ofrecer un software funcional, seguro, fiable, e integrado en pasos rápidos

• Se fusionan todos los cambios realizados y se integran todos los componentes de software
• De forma regular, al menos una vez al día.

• Envuelto en un solo proceso, repetible y automatizado:

• Gestión de la configuración
• Compilación y construcción de software (software build)
• Implementación
• Ejecución de la prueba

• Los programadores integran su trabajo constantemente: integración / compilación / prueba.

• Los defectos en el código se detectan pronto y con mayor rapidez.

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Integración continua

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Integración continua

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Integración continua

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Integración continua

En la práctica

• A diario se realiza un proceso automatizado de compilación y pruebas para detectar errores de integración de forma temprana y rápida, esto permite a los probadores ejecutar pruebas automatizadas y obtener un feedback rápido de la calidad del código.

• Los resultados de estas pruebas son visibles para todos a través de los informes

• Las pruebas de regresión se pueden integrar a ese proceso, cuando se automatizan las pruebas de regresión los probadores quedan libres para concentrar sus pruebas manuales en nuevas funcionalidades, cambios y confirmación de defectos corregidos.

• Unas buenas pruebas de regresión automatizadas cubren el máximo de funcionalidades, incluyendo Historias de Usuario entregadas en iteraciones anteriores.

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Integración continua

Herramientas de compilación (build tools)

• Se utilizan para el control continuo de la calidad
• Además de test unitarios y pruebas de integración, se pueden ejecutar pruebas estáticas y dinámicas para para medir el rendimiento , extraer formatear documentación del código fuente; y facilitar procesos de aseguramiento de calidad manuales.

• Esta aplicación continua de los controles de calidad, mejora de la calidad del producto y reduce el tiempo necesario para la entrega, de esta manera se sustituye la práctica tradicional de la aplicación de control de calidad después de que el desarrollo haya sido completado.

Herramientas de despliegue Las Herramientas de compilación pueden estar vinculadas a herramientas de despliegue automático, que localizan el software compilado y lo despliegan en uno o más entornos de desarrollo, pruebas o producción, restando la dependencia de personal especializado para instalar las entregas en estos entornos.

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Integración continua

Herramientas de compilación (build tools)

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Integración continua

Ventajas

• Permite una detección precoz y fácil análisis de la causa raíz de los problemas de integración y los cambios conflictivos.
• El equipo de desarrollo recibe un feedback frecuente sobre si el código está
• funcionando.
• Reduce los riesgos de regresión debido a la rápida refactorización del código, Retest y pruebas de regresión se realizan tras un pequeño conjunto de cambios.
• Proporciona confianza sobre una base sólida para el trabajo diario.
• Hace que el progreso hacia la realización de un incremento del producto sea visible,
• animando a los programadores y testers.
• Elimina los riesgos asociados a la programación de una integración big-bang.
• Un software ejecutable está constantemente disponible durante todo el sprint para pruebas, demostración o con fines educativos.
• Reducción de las actividades de pruebas manuales repetitivas.
• Rápido feedback sobre las decisiones tomadas para las mejora de la calidad y para las pruebas.

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Integración continua

Riesgos y desafíos

• Introduce las herramientas y mantenimiento necesarios
• El proceso de integración continua debe definirse y establecerse.
• La Automatización de pruebas requiere especialistas en el equipo, puede ser muy complejo de establecer.

• Una cobertura exhaustiva de las pruebas es esencial para lograr las ventajas esperadas de las pruebas automáticas
• Los equipos tienen la tendencia a depender demasiado de las pruebas unitarias y a realizar muy pocas pruebas de integración/sistema y aceptación.
• Requiere el uso de herramientas:
• Herramientas para las pruebas
• Herramientas para la automatización del proceso de construcción
• Herramientas para el control de versiones.

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Planificación de la entrega y de la iteración

Significado

• La planificación es una actividad en curso en los enfoques tradicionales o ágiles
• En los ciclos de vida ágiles están la planificación de la entrega (release) y la planificación de la iteración.

• Reunión para la planificación de la entrega (release).
• Reunión para la planificación de la iteración.

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Planificación de la entrega y de la iteración

Planificación de la entrega (release)

• Con vistas a la entrega (release) de un nuevo producto o versión del mismo.
• Se entregará a menudo de aquí a unos meses.
• La Planificación de la entrega (reléase) define y redefine el backlog del producto, puede implicar la redefinición de historias de usuario grandes en una colección más pequeña.
• Proporciona la base para el enfoque de las pruebas y un plan de pruebas para todas las iteraciones (Plan de alto Nivel, y Estimación de alto nivel del esfuerzo necesario).
• En la Planificación de la entrega, los representantes del negocio establecen y priorizan las Historias de usuario en colaboración con el equipo, estas son la base para la identificación de riesgos de proyectos y riesgos de calidad.
• Estimación del esfuerzo de alto nivel.

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Planificación de la entrega y de la iteración

• Planificación de la entrega (release)

Participación de los testers

• Definición de historias de usuario comprobables, así como los criterios de aceptación
• Participación en el análisis de riesgos de la Calidad (producto) y Riesgos del Proyecto
• Estimación del esfuerzo necesario para las pruebas asociadas con las historias de usuario.
• Definición de los niveles de prueba necesarios.
• Planificación de las actividades de prueba para la entrega (release).

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Planificación de la entrega y de la iteración

Plan de la iteración

• Una vez realizada la planificación de la entrega, se inicia la planificación de la primera iteración. (una sola iteración).
• El equipo selecciona las historias de usuario del backlog priorizado de la entrega (release)

• Elaboración de historias de usuario
• Realizar un análisis de riesgos para las historias de usuario
• Estimación del trabajo relacionado con cada historia de usuario
• Comprender qué es necesario implementar y cómo probar cada historia
• Los representantes del negocio deben responder a las preguntas del equipo sobre las historias de usuarios específicas

• Si los intentos para aclarar una historia de usuario vaga fallan, el equipo puede rechazarla y pasar a la próxima historia de usuario con mayor prioridad en el backlog

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Planificación de la entrega y de la iteración

Plan de la iteración

• Después de que los contenidos de la iteración estén claros, las historias de usuario se dividen en tareas que llevarán a cabo los miembros apropiados del equipo
• El número de historias de usuario seleccionadas depende la velocidad establecida para el equipo y del tamaño de las mismas.

Participación de los testers

• Participación en el análisis detallado de riesgos.
• Determina su testeabilidad (capacidad de prueba).
• Definición de las pruebas de aceptación.
• División de las historias de usuario en tareas, especialmente las tareas de pruebas.
• Estimación del esfuerzo de las pruebas en todas las tareas de pruebas.
• Identificación de los aspectos funcionales y no funcionales.
• Apoyo a la automatización en múltiples niveles de pruebas.

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Planificación de la entrega y de la iteración

• El plan de la entrega (release) puede cambiar durante el transcurso del proyecto, las historias de usuario individuales del backlog del producto pueden cambiar debido a factores internos o externos:
• Factores internos: velocidad, cuestiones técnicas, capacidades de entrega
• Factores externos: nuevos mercados y oportunidades, nuevos competidores, amenazas de negocio a consecuencia de cambio de objetivos y/o plazos
• Además cambios en el plan de la iteración, ej.- se puede deber a una historia de usuario que se estime menos compleja de lo que es.

Desafíos de los testers

• Entender el panorama general de la entrega (release)
• Debe tener una base de pruebas y un oráculo de pruebas adecuados para cada iteración (ver ISTQB-CTFL).
• La información necesaria debe estar disponible pronto, sin embargo, los cambios deben ser aceptados de buen grado (es un principio ágil). Este dilema requiere decisiones cuidadosas acerca de las estrategias de las pruebas y su documentación.

CAPITULO I: DESARROLLO AGIL DE SOFTWARE

2. Aspectos de los enfoques agiles

Planificación de la entrega y de la iteración

Planificación no sólo para las pruebas, también para el desarrollo

• En cuanto las Pruebas se deben abordar los siguientes temas:
• El alcance de las pruebas, objetivos, intensidad (grado) , incluyendo las razones de las decisiones tomadas
• Los miembros del equipo que llevarán a cabo las pruebas.
• Entorno y datos de prueba, qué se necesita y cuándo, cambios que se esperan/necesitan antes o durante el proyecto.
• Duración (timing), secuenciación, dependencias, prerrequisitos para pruebas funcionales y no funcionales, por ejemplo: frecuencia de las pruebas de regresión, actividades relacionadas y dependientes entre pruebas y desarrollo.
• Los riesgos del proyecto y del producto que deben ser abordados.
• Las estimaciones globales de tiempo y esfuerzo de todo el equipo debe incluir el tiempo y el esfuerzo necesarios para completar las actividades de prueba

¡Te enseña fácil!