AGILE METHODOLOGY

_Comencé a trabajar como Analista Funcional en una empresa que utilizan SCRUM. Nunca lo había usado así que hacer este curso me ayudo muchísimo.
Empece esta semana así que me mandaron a investigar sobre estos temas que mencione. Me pareció interesante compartir el documento que hice para que otras personas que se encuentren en una situación parecida puedan leer y aportar. _

En el presente documento se detallan los temas principales que debe saber el equipo de trabajo sobre Agile para llevar a cabo un proyecto con metodología SCRUM.

1. Diferencia entre Agile vs Waterfall.

Agile: Es una metodología basada en el desarrollo iterativo e incremental, donde los requisitos y soluciones evolucionan mediante la colaboración de grupos auto organizados y multidisciplinarios. Se valora la interacción y los productos entregados frente a la documentación.
Se ha convertido también en base del modelo de desarrollo de negocios.

Waterfall: Es el ciclo de desarrollo tradicional. Se trata de un modelo de desarrollo secuencial con resultados claramente definidos para cada fase. Para su ejecución se requieren profesionales especializados en cada fase.
_
Resumen: Son dos metodologías diferentes, Agile es interactivo e incremental y Waterfall es secuencial._

2. User Story

Una User Story (Historia de usuario) es la descripción de una funcionalidad que debe incorporar un sistema de software, y cuya implementación aporta valor al cliente.
Cada historia de usuario debe ser limitada. Su estructura está formada por: Nombre breve y descriptivo.
Las metodologías agiles como Scrum utilizan las User Story como instrumento principal para identificar los requerimientos de usuario. Se escriben desde la perspectiva de una persona que necesita una nueva capacidad de un sistema, por lo general el usuario, área de negocio o cliente.

Resumen: Son historias de usuario, que tienen una descripción limitada de una funcionalidad.

3. Story Points

Una Story Points (Puntos de historia) son los puntos que se le dan a una historia. Por ejemplo, escogemos una historia sencilla, una que todo el mundo entiende, para emplearla como referencia. Esta sería la definición de 1 punto de la historia de nuestro proyecto.
Establecida la referencia, cada vez que queremos estimar algo tan solo tenemos que compararlo con la historia de referencia. Si creemos que nos llevará el doble de trabajo que la historia de referencia, entonces el valor será de 2 puntos de historia; si creemos que tarda la mitad del esfuerzo, sería 0.5 puntos; etcétera.
Para esto se utiliza la secuencia de Fibonacci, se trata de una sucesión infinita de números naturales que comienzan con los números 1 y 1, y a partir de ellos, cada término se obtiene sumando los dos anteriores:
1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987, 1.597…

Resumen: Son puntos de historia. Se definen según el tiempo y la complejidad de la historia. Utilizan la secuencia Fibonacci.

4. Moscow Method

El método MoSCoW es una técnica de priorización utilizada en la gestión, el análisis empresarial , la gestión de proyectos y el desarrollo de software para llegar a un entendimiento común con las partes interesadas sobre la importancia que asignan a la entrega de cada requisito ; también se conoce como priorización de MoSCoW o análisis de MoSCoW .
El término MoSCoW en sí mismo es un acrónimo derivado de la primera letra de cada una de las cuatro categorías de priorización ( debe tener , debería tener , podría tener y no tendrá ).

Resumen: Es un método de priorización en la gestión y desarrollo del software. Se le pregunta al cliente que debe tener, debería tener, podría y no tendrá para definir prioridades.

**5. INVEST
**
Es un modelo para describir las características de una buena historia. Las mismas son:

• Independiente: las historias pueden completarse en cualquier orden.
• Negociable: los detalles de la historia son co-creados por los programadores y los clientes durante el desarrollo.
• Valiosa: la funcionalidad es valiosa para los clientes o los usuarios del software.
• Estimable: los programadores pueden encontrar una estimación razonable para construir la historia.
• Pequeña: las historias deberían construirse en poco tiempo, generalmente alrededor de “días/persona”. Se tienen que poder construir muchas historias en una iteración.
• Testeable: se debe poder escribir pruebas que verifiquen que el software de la historia funcione adecuadamente.

Resumen: Es un modelo para describir las características de una historia de usuario. Deben ser Independientes, Negociables, Valiosas, Estimables, Pequeñas y Testeables.