¿Qué es una metodología ágil?

17 marzo 2017

[ Estás en Unidades Didácticas / Unidad 3. Metodologías / ¿Qué es una metodología ágil? ]
 
 
Una metodología ágil es un conjunto de técnicas ágiles aplicadas según una estrategia, más o menos rígida, dirigida a mejorar la productividad de un equipo.

Son muchas las técnicas que puede adoptar un equipo para volverse ágil. Lo más importante no es aplicar muchas de ellas, lo que vamos a aprender durante este curso es qué son y cómo pueden ayudar a un equipo a funcionar mejor como tal. En esta unidad revisaremos algunas de las metodologías ágiles más utilizadas, formadas por estrategias y técnicas de diversa índole (no todo tiene la etiqueta «ágil» pero muchos «detalles» pueden ser aprovechados para agilizar equipos). Cada equipo está formado por personas con diferentes cualidades, sean cuales sean las de los miembros de tu equipo seguro que siempre encontrarás una técnica o un conjunto de ellas que logren un mejor funcionamiento del equipo en un proyecto determinado. Y si además encuentras una metodología que se adapte a vuestro hábitat podréis beneficiaros de la experiencia divulgada por muchos otros equipos o investigadores.

A continuación veremos una breve descripción de algunas de las metodologías ágiles más utilizadas por las empresas de desarrollo de software.

 
 

kanban

 

Kanban es una técnica que hace hincapié en la documentación pública de las tareas que han de llevarse a cabo en un proyecto y de su estado en cada momento, básicamente: «Por hacer», «En proceso» y «Terminada».

Kanban es básicamente una pizarra con diferentes columnas adaptadas a las características del proyecto en la que se van colocando tarjetas (post-its) con las tareas que se han de realizar, se van cambiando de columna según el proceso real del proyecto (se colocan en la columna «En proceso» cuando se está trabajando en esa tarea, se mueven a «Con impedimentos» cuando se encuentra un impedimento para llevarla a cabo, se mueven a «Terminada» cuando se da por finalizada…).

Uno de los principios ágiles anima a las reuniones de equipo «cara a cara«. Es evidente que funciona en equipos que coinciden en el espacio y el tiempo, el contacto físico entre los miembros de un equipo aporta más información que el contacto virtual que proporcionan los múltiples dispositivos que tenemos interconectados.

Sin embargo en equipos con mucha movilidad o dispersos geográficamente hay que recurrir a reuniones online, bien con el uso de teléfono, videoconferencia… En estos casos es preferible tener una pizarra Kanban distribuida, en la que todos los miembros del equipo puedan intervenir y el resto de miembros de la empresa (o del mundo como es el caso de Kanban del desarrollo de Trello) puedan ver el progreso real del proyecto.

 
 

eXtreme Programming

 

Trabajo realizado por el grupo A

1.Introducción

La programación extrema o eXtreme Programming es una metodología de desarrollo de la ingeniería de software formulada por Kent Beck.
Es el más destacado de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las metodologías
tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad.
Los defensores de la XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos.
Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir
todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.

2.Objetivos a aplicar XP

Cualquier equipo que aplique XP para mejorar su productividad, buscare los siguientes objetivos:

  • Establecer las mejores prácticas de Ingeniería de Software en los desarrollo de proyectos.
  • Mejorar la productividad de los proyectos.
  • Garantizar la Calidad del Software desarrollando, haciendo que este supere las expectativas del cliente.

3. Los 5 Principios Básicos de la XP

Los principios básicos de la programación extrema son: simplicidad, comunicación, retroalimentación, coraje y respeto.



Vamos a detallar estos 5 principios:

  • Simplicidad: es la base de la programación extrema. Se simplifica el diseño para agilizar el desarrollo y facilitar el mantenimiento. Un diseño complejo del código junto a sucesivas modificaciones por parte de diferentes desarrolladores hacen que la complejidad aumenta exponencialmente.
  • Comunicación: se realiza de diferentes formas. Para los programadores el código comunica mejor cuanto más simple sea. Si el código es complejo hay que esforzarse para hacerlo inteligible. El código autodocumentado es más fiable que los comentarios ya que éstos últimos pronto quedan desfasados con el código a medida que es modificado. Debe conectarse sólo aquello que no va a variar, por ejemplo el objetivo de una clase o la funcionalidad de un método.
  • Realimentación: al estar el cliente integrado en el proyecto, su opinión sobre el estado del proyecto se conoce en tiempo real.
  • Valentía: una de ellas es siempre diseñar y programar para hoy y no para mañana. Esto es un esfuerzo para evitar empantanarse en el diseño y requerir demasiado tiempo y trabajo para implementar el resto del proyecto. La valentía le permite a los desarrolladores que se sientan cómodos con reconstruir su código cuando sea necesario.
  • Respeto: se manifiesta de varias formas. Los miembros del equipo se respetan los unos a otros, porque los programadores no pueden realizar cambios que hacen que las pruebas existentes fallen o que demore el trabajo de sus compañeros. Los miembros respetan su trabajo porque siempre están luchando por la alta calidad en el producto y buscando el diseño óptimo o más eficiente para la solución a través de la refactorización del código. Los miembros del equipo respetan el trabajo del resto no haciendo menos a otros, una mejor autoestima en el equipo eleva su ritmo de producción.

4. Características fundamentales

Las características fundamentales del método son:

  • Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.
  • Pruebas unitarias continuas: ademas de frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación.
  • Programación en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. La mayor calidad del código escrito de esta manera -el código es revisado y discutido mientras se escribe- es más importante que la posible pérdida de productividad inmediata.
  • Frecuente integración del equipo de programación con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.
  • Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes.
  • Refactorización del código, es decir, reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo.
  • Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.
  • Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.

5. Roles en XP

Vemos los roles típicos de XP:

  • Programador: es el creador del código del sistema o aplicación, ademas escribe las pruebas unitarias.
  • Cliente: es el creador de los Storyboards del sistema, asignando las prioridades a cada historia de usuario, decide cuales se implementarán en cada interacción, buscando en aportar el mayor valor de negocio,una vez realizado esto ademas prueba las funciones para validar y comprobar su implementación.
  • Tester: mano derecha del cliente, ya que ayuda a este a detallar las pruebas funcionales, el Tester realiza pruebas regularmente, comparte los resultados con el equipo y el responsable de las herramientas de soporte para pruebas.
  • Tracker: realiza el seguimiento, y proporciona realimentación al equipo, el Tracker verifica el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, comunicando los resultados para mejorar futuras estimaciones.
  • Entrenador (coach): es el responsable del proceso global. el Entrenador es el guía de los miembros del equipo para seguir el proceso adecuadamente.
  • Consultor: es un miembro externo con el que cuenta el equipo, el Consultor cuenta con un conocimiento específico en algún tema necesario para el proyecto, de esta manera ayuda a solventar y resolver problemas específicos.
  • Gestor (Big boss): es el dueño de la tienda y el vínculo entre clientes y programadores, el Gestor su papel principal es la coordinación.

6. Bibliografía

 
 

Scrum

 

 

Principios Scrum

 

Inspección y adaptación

Auto-organización y colaboración

Priorización

Mantener un latido

 

Roles en Scrum

 

Product Owner

Scrum Master

Equipo

 

Artefactos en Scrum

 

Product Backlog

Sprint Backlog

Burndown Chart

 

Reuniones en Scrum

 

Sprint Planning

Daily Meeting

Sprint Review

Sprint Retrospective

 
 

Dynamic Systems Development Method (DSDM)

 

 
 

Crystal Technologies

 

 
 

Adaptive Software Development (ASD)

 

Trabajo realizado por el grupo A

¿Qué es el Desarrollo de Software adaptable (ASD)?

Desarrollo de software adaptable (ASD) es un proceso de desarrollo de software que surgió del trabajo en el desarrollo de aplicaciones de Jim Highsmith y Sam Bayer. Incorpora el principio de que la adaptación continua del proceso al trabajo que nos ocupa es el estado normal de las cosas. El desarrollo de software adaptativo reemplaza el tradicional ciclo en cascada por una serie repetitiva de: especular, colaborar y aprender ciclos. Este ciclo dinámico favorece el aprendizaje continuo y la adaptación al estado emergente del proyecto.

Características

Las características de un ciclo de vida de ASD son que es iterativo, orientado a los componentes software más que a las tareas, tolerante al cambio, guiado por el riesgo y que la revisión de los componentes sirve para aprender de los errores y volver a iniciar el ciclo de desarrollo, trabajo orientado y guiado por la misión del proyecto, desarrollo acotado temporalmente.

La palabra “especular” se refiere a la paradoja de la planificación – es más probable asumir que todos los actores son comparativamente malos para ciertos aspectos de la misión del proyecto, al tratar de definirlo. La “colaboración” se refiere a los esfuerzos para equilibrar el trabajo en partes previsibles del entorno (planificación y guía) y la “adaptación” a la incertidumbre de los cambios causados por diversos factores, como la tecnología, los requisitos, los interesados, los proveedores de software…

Los ciclos de aprendizaje se basan en iteraciones cortas de diseño, construcción y pruebas. Durante estas iteraciones el conocimiento se recoge al producirse pequeños errores basados en suposiciones falsas y corregir estos errores, lo que conduce a una mayor experiencia y, finalmente, a la maestría en el dominio del problema.

En definitiva, ASD es una metodología que incorpora el principio de la adaptación continua, o sea, adaptarse al cambio y no luchar contra él. En ella no hay un ciclo de vida estático (planear-diseñar-construir), sino que ofrece un ciclo de vida iterativo, donde cada ciclo puede ser modificado al tiempo que otro es ejecutado.

Ciclo Especular-Colaborar-Aprender

A diferencia de la mayoría de las metodologías de desarrollo de software, las cuales utilizan un ciclo de vida estático: Planear-Diseñar-Construir, DAS ofrece un ciclo de vida iterativo no lineal. El desarrollo adaptable de software utiliza un ciclo de desarrollo dinámico conocido como Especular-Colaborar-Aprender, este ciclo está dedicado a un constante aprendizaje y a una intensa colaboración entre desarrolladores y clientes, esto debido al constante cambio en el ambiente de los negocios.

Especulación: ofrece más espacio para explotar, par darse cuenta que no todo es seguro, permitiendo desviarse del plan sin ningún temor. Muchas veces desviarse del plan original puede considerarse un error, más que una oportunidad de aprendizaje, es ahí donde la especulación incita a explorar y a experimentar. Si se admite que no se conoce todo, se está más dispuesto a aprender.

Colaboración: las aplicaciones complejas requieren, la recolección y el análisis de un gran volumen de información, lo cual no puede ser controlado por una sola persona. A su vez aplicaciones con ambientes cambiantes producen un gran flujo de datos, los cuales pueden ser manejados por una persona, o por un grupo pequeño, ya que estos no pueden saberlo todo.

Aprendizaje: se debe evaluar el conocimiento constantemente realizando retroalimentaciones y reuniones de grupo, al final de cada ciclo iterativo, en lugar de al final del proyecto, ya que esto ayuda a soportar y solucionar de una mejor manera el constante cambio que puede tener el proyecto y su adaptación.

Comparativa de ciclos

Ciclo de vida en cascada

Ciclo de vida evolutivo

Ciclo adaptativo

El enfoque de ASD

Do it Wrong the Firt Time – Hazlo mal la primera vez
Teniendo en cuenta nuestro objetivo, vamos a ver que el estado actual de las prácticas de software de gestión de calidad puede resumirse en la frase -hazlo bien la primera vez-. En un entorno complejo, “hacerlo bien la primera vez” es una receta para el fracaso.
En primer lugar, ¿Cómo podemos predecir lo que es hacerlo bien?
En las primeras etapas, si el horizonte de tiempo de entrega no está demasiado lejos, podemos ser capaces de especular sobre si la dirección general es correcta, pero la definición de “correcto” es difícil y confusa. Incluso si pudiéramos definir lo correcto, haciéndolo la primera vez no tiene sentido en algunos productos triviales. La primera vez supone entender la causa y el efecto, el algoritmo específico de llegar hasta el producto final desde nuestra posición inicial de partida, y las necesidades de todas las partes interesadas.

Los escritores James Bach y Ed Yourdon han abordado esta cuestión desde la perspectiva del software lo suficientemente bueno. “Suficientemente bueno” parece indicar una posición de compromiso. Se ofende a muchos desarrolladores cuyo sistema de valores tiende hacia la meta de la perfección.

Ventajas y desventajas

Ventajas

  • Se utiliza para poder aprender de los errores e iniciar nuevamente el ciclo de desarrollo.
  • Utiliza información disponible acerca de todos los cambios para poder mejorar el comportamiento del Software.
  • Difunde la colaboración de distintas personas.

Desventajas

  • Los errores y cambios que nos son detectados con anterioridad afectan a la calidad del producto y costo total.
  • Ya que ésta es una metodología ágil, no permite realizar procesos que son requeridos en las metodologías tradicionales.
  • Apunta hacia el Rapid Application Development (RAD), el cual enfatiza velocidad de desarrollo para crear un producto de alta calidad, bajo mantenimiento involucrando al usuario lo más posible.

Tecnologías clave para el software adaptativo

Ahora sabemos lo que hace el software adaptativo: utiliza la información del entorno para mejorar su comportamiento a través del tiempo, ya que el programa adquiere más experiencia. Y sabemos por qué es difícil hacer esto: porque las especificaciones están incompletas y cambiando, porque el ambiente está cambiando constantemente, porque los diseños cuidadosamente elaborados pueden basarse en supuestos que se convierten en obsoletos, y porque nunca hay tanto tiempo como el programador realmente necesita. En esta sección examinamos algunas de las herramientas que nos ayudan a superar estas dificultades. Aquí están cinco de las más importantes:

  • Lenguajes de programación dinámicos proporcionan un marco sólido para desarrollar aplicaciones que persisten durante largos tiempos de vida, y se pueden actualizar mientras se están ejecutando.
  • Tecnología Agent es un punto de vista que abarca la idea de actuar de acuerdo a las preferencias del usuario.
  • Teoría de la Decisión ofrece la terminología básica para hablar de un mundo incierto, y sobre lo que los resultados son preferidos.
  • Refuerzo de aprendizaje nos da una manera de aprendernos la secuencia de acciones a realizar, teniendo en cuenta los resultados locales de las acciones individuales.
  • Redes probabilísticas proporcionan potentes algoritmos para el cálculo de las acciones óptimas en base a lo que se conoce sobre el estado actual del mundo.

    • Bibliografía

     
     

    Feature-Driven Development (FDD)

     

    Trabajo entregado por el grupo B

     
     

    Lean Development (LD)

     

    Trabajo entregado por el grupo B

     
     

    Bibliografía

     

    «Métodos Ágiles y Scrum», Alonso Álvarez García, Rafael de las Heras del Dedo y Carmen Lasa Gómez, ANAYA Multimedia (2011)

     
     

    <– Anterior               Siguiente –>