El ciclo de desarrollo que aplican las Metodologías Ágiles es iterativo e incremental. Este modelo permite entregar el software en partes pequeñas y utilizables, conocidas como incrementos. Cada iteración se puede considerar como un mini-proyecto en el que las actividades de análisis de requerimiento, diseño, implementación y testing son llevadas a cabo con el fin de producir un subconjunto del sistema final. El proceso se repite varias veces produciendo un nuevo incremento en cada ciclo hasta que se elabora el producto completo. Si bien todas las metodologías ágiles adoptan este ciclo, cada una presenta sus propias características.
¿Hasta aquí, se identifican participando en alguna etapa? ¿Le será muy distante a un tester acostumbrado a proyectos del tipo cascada?
Este párrafo no menciona si el testing es manual o automatizado, ¿Qué opinas, cuánto porcentaje de manual y cuánto de automatizado habrá?
Una de las metodologías más usadas es la de Scrum:
Scrum – Indicada para proyectos con alto ratio de cambio de requerimientos, su principal característica es la definición de sprints – cada una de las iteraciones del proceso con una duración máxima de 30 días. El resultado de cada sprint es un incremento ejecutable que se muestra al cliente. Otra característica importante son las reuniones diarias que se llevan a cabo a lo largo del proyecto. Dichas reuniones no requieren más de 15 minutos del equipo de desarrollo y su objetivo son la coordinación e integración del producto a entregar.
Otras metodologías pueden ser:
Cristal Methodologies
Dynamic Systems Development Method (DSDM)
Adaptive Software Development (ASD)
Feature-Driven Development (FDD)
Programación Extrema (XP)
Scrum
La metodología respeta el ciclo de vida evolutivo y la entrega incremental. Al comienzo del proyecto, se identifican los requerimientos funcionales y no funcionales y se conforma una lista de los mismos llamada product backlog. El product backlog constituye el artefacto base para medir el avance del proyecto. Las iteraciones, denominadas sprints entregan partes del producto llamadas builds, que si bien no incluyen toda la funcionalidad del sistema, constituyen ejecutables operativos. Cada iteración comienza con una planificación adaptativa guiada por el cliente y culmina con una demostración del build al cliente. Cada sprint puede durar como máximo 30 días. En cada sprint, el equipo de desarrollo selecciona del product backlog un conjunto de ítems de mayor prioridad que se convierte en el objetivo a desarrollar. La metodología propone las siguientes tres fases:
1) Fase de Planeamiento – es subdividida en: a) Planeación – se define el equipo del proyecto, herramientas, el sistema de desarrollo y se crea el product backlog con la lista de requerimientos conocidos hasta ese momento, se definen prioridades para los requerimientos y se estima el esfuerzo necesario para llevar a cabo la implementación de los mismos; y b) Diseño Arquitectónico – se define la arquitectura del producto que permita implementar los requerimientos definidos.
2) Fase de Desarrollo – es la parte ágil, donde el sistema se desarrolla en sprints. Cada sprint incluye las fases tradicionales del desarrollo de software –
relevamiento de requerimientos, análisis, diseño, implementación y entrega.
3) Fase de Finalización – incluye integración, testing y documentación. Indica la implementación de todos los requerimientos, quedando el product backlog vacío y el sistema listo para entrar en producción.
Hasta donde se puede leer aquí, participamos únicamente en la etapa de Fase de Finalización, no antes. Seguramente no será así porque en este tipo de proyectos, la actividad es dinámica y la participación es extrema. Lo cierto es que la palabra Testing solo aparece mencionada en la fase 3.
La metodología propone la creación de equipos de trabajo auto-dirigidos y autoorganizados, aconsejando equipos pequeños que maximizan la comunicación entre
sus integrantes. Dentro del equipo de trabajo, se identifican roles com o el Scrum Master – responsable de asegurar que el proyecto se ejecute en base a las prácticas, valores y reglas de Scrum-; el Dueño del Producto – responsable del proyecto, administra, controla y mantiene y publica el product backlog-; los Miembros del Equipo – tienen la autoridad para decidir acerca de las acciones a realizar y organizarlas de tal manera de alcanzar los objetivos de cada sprint; y el Cliente -participa de las tareas relacionadas con la lista de requerimientos del producto a desarrollar, aporta ideas, sugerencias y nuevas necesidades-.
Scrum prevee las siguientes prácticas:
- Reunión de Planeamiento del Sprint – organizada por el Scrum Master, se divide en dos etapas. En la primera etapa se reúnen los clientes, el dueño del producto y los miembros del equipo para decidir sobre los objetivos y funcionalidad del nuevo sprint. La segunda etapa de la reunión se realiza entre el Scrum Master y el equipo de trabajo y se concentra en cómo el incremento del producto será implementado durante el proceso.
- Sprint – es una lista de requerimientos seleccionados para ser implementados en la próxima iteración. Los requerimientos son seleccionados por el equipo de trabajo, en conjunto con el Scrum Master y el propietario del producto en la reunión de planeamiento del sprint. Cuando todos los ítems del sprint se completan, se entrega una nueva iteración del sistema.
- Reuniones Diarias – son dirigidas por el Scrum Master. Se organizan básicamente para mantener una revisión constante del avance del proyecto. Los integrantes responden a tres preguntas: 1) ¿Qué se ha logrado completar desde la última reunión?, 2) ¿Qué obstáculos o problemas se han detectado ?, y 3) ¿Qué funciones del backlog planea completar para la próxima reunión?
- Revisión del Sprint – el equipo de trabajo y el Scrum Master presentan los resultados del sprint al cliente.
- Retrospectiva del Sprint – se realiza al finalizar un product backlog y la revisión del sprint. El equipo de trabajo revisa el cumplimiento de los objetivos marcados al inicio del sprint. Se analizarán y se aplicarán los ajustes y cambios necesarios cuando corresponda, se destacarán los aspectos positivos y se tratará de cambiar aquellos aspectos negativos, para no repetirlos en el siguiente sprint.
Me pregunta, ¿Alguien podría (tendría ganas) de hacer el paralelo con proyectos en cascada, y donde encuentran similitudes? ¿Y respecto de los entregables, que hay?
¿Conoces de proyectos en cascada donde se apliquen algunas de estas técnicas?
Fuente:
http://sedici.unlp.edu.ar/bitstream/handle/10915/21086/Documento_completo.pdf?sequence=1
