1. SCRUM
1.1. Roles
1.1.1. Product Owner
1.1.1.1. Toma decisiones sobre que funcionalidades se incluyen en el producto
1.1.1.2. Prioriza y gestiona el backlog del producto
1.1.2. SCRUM Master
1.1.2.1. Promueve las mejores practicas de SCRUM
1.1.2.2. Ayuda al equipo a alcanzar sus objetivos
1.1.3. Team Member
1.1.3.1. Toma decisiones tecnicas y se autoorganiza
1.1.3.2. Conformado por profesionales multidiciplinarios
1.2. Artefactos
1.2.1. Product Backlog
1.2.1.1. Documenta todos los elementos necesarios para el producto
1.2.1.2. Prioriza las funcionalidades y caracteristicas en funcion del valor para el cliente
1.2.2. Sprint Backlog
1.2.2.1. Contiene los elementos del Product Backlog seleccionados para el Sprint actual
1.2.2.2. Sirve como una lista diaria para el equipo de desarrollo durante el Sprint
1.2.3. Increment
1.2.3.1. Representa el trabajo final de cada Sprint
1.2.3.2. Añade funcionalidades o mejoras con cada Sprint, construyendo sobre incrementos anteriores
1.3. Ceremonias
1.3.1. Sprint Planning
1.3.1.1. Identificar y seleccionar los elementos del Product Backlog que se abordarán en el Sprint
1.3.1.2. Establecer el objetivo del Sprint y definir qué se espera lograr
1.3.2. Daily Scrum
1.3.2.1. Los miembros del equipo comparten actualizaciones sobre el progreso de su trabajo desde la última reunión
1.3.2.2. Se discuten los posibles obstáculos o impedimentos que podrían estar afectando el avance.
1.3.3. Sprint Review
1.3.3.1. Se muestra al cliente y a los interesados el incremento de producto completado durante el Sprint.
1.3.3.2. Se recopilan comentarios y sugerencias para futuras iteraciones.
1.3.4. Sprint Retrospective
1.3.4.1. El equipo reflexiona sobre su proceso de trabajo durante el Sprint
1.3.4.2. Se discuten los aspectos que funcionaron bien y las oportunidades de mejora en la forma en que trabajan juntos
1.3.5. Backlog Refinement
1.3.5.1. Prioriza y estima elementos del Product Backlog para futuros Sprints
1.3.5.2. Aclara dudas y asegura una comprensión común de los requisitos
1.3.5.3. Detecta dependencias y riesgos para una planificación más eficaz
2. XP
2.1. Valores
2.1.1. Simplicidad
2.1.1.1. Este valor se refiere a la importancia de mantener los procesos y las soluciones lo más simples posible.
2.1.2. Comunicacion
2.1.2.1. Esto es esencial para las pruebas de sofware , ya que permite identificar problemas y soluciones de manera rapida
2.1.3. Retroalimentacion
2.1.3.1. Las metodologias se basan en ciclos de desarrollo iterativos. las pruebas se realizan en cada iteracion, lo que permite retroalimentacion constante
2.1.4. Calidad
2.1.4.1. Las pruebas de sofware son cruciales para que el producto cumpla con los estandares de calidad
2.2. Practicas
2.2.1. Programacion en parejas
2.2.1.1. Esto implica que un tester y un desarrollador trabajen juntos en la implementacion y prueba de una funcionalidad
2.2.2. Juego de Planificacion
2.2.2.1. Ayuda a los equipos a planificar y estimar el trabajo,fomentan la colaboracion
2.2.3. Refactorizacion
2.2.3.1. Implica mejorar y reestructurar el codigo existente sin cambiar su comportamiento externo
2.2.4. Semana de 40 horas
2.2.4.1. Se centran en la entrega eficiente de software de alta calidad a traves de la colaboracion y la flexibilidad
3. TDD
3.1. Ciclo
3.1.1. Red
3.1.1.1. Escribe una prueba y observa como falla
3.1.2. Green
3.1.2.1. Escribe el código suficiente para pasar la prueba
3.1.3. Refractor
3.1.3.1. Mejorar el código sin cambiar su comportamiento
3.2. ¿Qué es?
3.2.1. TDD es muy efectivo debido a la automatización de las pruebas de programador (programmer unit test)
3.3. ¿Por qué?
3.3.1. Mantenibilidad, flexibilidad, extensibilidad
3.3.2. Alto porcentaje de cobertura del código de prueba
3.3.3. Base de código optimizada
3.3.4. Interfaces más limpias
3.3.5. Refactorización de código más sencilla
3.3.6. Las pruebas proporcionan cierta documentación del código
4. BDD
4.1. Principios
4.1.1. Feature
4.1.1.1. Describe la funcionalidad que hay que desarrollar.
4.1.2. Scenario
4.1.2.1. Son las características que se dan para lograr la funcionalidad.
4.1.3. Given
4.1.3.1. Hace referencia a las predicciones para que se puedan ejecutar las distintas acciones.
4.1.4. When
4.1.4.1. Son las condiciones de las acciones a ejecutar.
4.1.5. Then
4.1.5.1. Es el resultado de las acciones ejecutadas.
4.2. Patrón Role-Feaure-Reason
4.2.1. Como
4.2.1.1. Especifica el tipo de usuario de la acción.
4.2.2. Quiero
4.2.2.1. Hace referencia a las necesidades de ese usuario.
4.2.3. Para que
4.2.3.1. Es el objetivo final que desea cumplir.
4.3. ¿Que es?
4.3.1. BDD es Behavior Driven Development, o lo que es lo mismo en español, desarrollo guiado por comportamiento. Es un proceso de software ágil que busca la colaboración y entendimiento entre desarrolladores, gestores de proyecto y equipo de negocio.
5. ATDD
5.1. Es una dimensión del TDD aplicada al nivel de gestión de requerimientos de software, en el cual las pruebas escritas son a nivel de cliente, es decir, lo equivalente a una prueba de aceptación o test funcional
5.1.1. Esta fuertemente asociado con metodologías ágiles
5.1.2. Promueve la colaboración de los desarrolladores, testers, y stakeholders de negocios
5.1.2.1. El resultado de su trabajo son los requerimientos de la aplicación hechas en un formato entendible para todos
5.1.2.2. El resultado es convertido en una prueba de aceptación automatizada
5.1.3. No es una técnica de testing, sino una técnica de programación
5.1.4. Verifica el funcionamiento de la aplicación con respecto a criterios de aceptación
5.2. Tiene como propósito asegurar que el sistema satisfaga los requerimientos del cliente
5.2.1. La automatización de procesos es la actividad más importante