Prototipos y Modelado Ágil

Modelo Ágil: Valores, Actividades, Principios Y Practicas

Es una metodología basada en la practica para modelado efectivo de sistemas de software. Es una colección de prácticas, guiadas por principios y valores que pueden se aplicados por profesionales de software en el día a día.. (Scott W. Ambler, 2002).

Son una colección de metodologías innovadoras para el desarrollo de sistemas, las cuales se centran en los usuarios. En esta sección aprenderá sobre valores y principios, actividades, recursos, prácticas, procesos y herramientas asociadas con las metodologías ágiles. A estos métodos se les acreditan muchos proyectos exitosos de desarrollo de sistemas y en muchos casos también se les acredita el haber rescatado empresas de un sistema fallido diseñado mediante el uso de una metodología estructurada.(Julia A.Kendall y de Edward. 2011. p166).

Valores

El Manifiesto hace énfasis en cuatro valores principales que deben soportar el desarrollo de software las cuales describió Scott W. Ambler (2002).

• Comunicación: En todo esfuerzo humano existe la posibilidad de una mala comunicación. Los proyectos de sistemas que requieren de una constante actualización y diseño técnico son especialmente propensos a dichos errores.

• Simpleza:  Un proyecto de desarrollo de software, nuestra primera tendencia es abrumarnos con la complejidad y tamaño de la tarea. Sin embargo, no podemos correr sino hasta aprender a caminar, ni podemos caminar hasta no aprender a erguirnos. La simpleza para el desarrollo de software significa que debemos empezar con la cosa más simple que podamos hacer.

• Retroalimentacion:  Ocurre cuando los clientes crean pruebas funcionales para todas las historias que hayan implementado posteriormente los programadores (más adelante en el capítulo podrá ver más sobre las historias de los usuarios). La retroalimentación crítica sobre la programación de fechas y tiempos proviene de los clientes que comparan el objetivo del plan con el progreso realizado hasta ese momento.

• Valor: La valentía tiene que ver con un nivel de confianza y confort que debe existir en el equipo de desarrollo. Significa no tener miedo de desperdiciar una tarde o un día de programación y empezar de nuevo si no todo está bien. significa responder a la retroalimentación concreta, actuando con base en las corazonadas de sus compañeros de equipo cuando ellos piensan que tienen una forma más simple y mejor de obtener su objetivo.

Principios

En un mundo perfecto, los clientes y su equipo de desarrollo de software se verían directamente a los ojos y no sería necesaria ninguna otra forma de comunicación. Todos estaríamos de acuerdo en todo momento.

Estos principios se pueden expresar en una serie de dichos tales como:

1. Satisfacer al cliente por medio de la entrega de software funcional.
2. Adoptar el cambio, incluso si se introduce en las últimas etapas del desarrollo.
3. Seguir entregando software funcional en incrementos y con frecuencia.
4. Fomentar a los clientes y analistas a que trabajen juntos a diario.
5. Confiar en los individuos motivados para que realicen su trabajo.
6. Promover la conversación cara a cara.
7. Concentrarse en hacer que el software funcione.
8. Fomentar el desarrollo continuo, regular y sostenible.
9. Adoptar la agilidad con especial atención en un diseño lúcido.
10. Apoyar a los equipos auto organizados.
11. Proveer retroalimentación rápida.
12. Fomentar la calidad.
13. Revisar y ajustar el comportamiento de vez en cuando.
14. Adoptar la simpleza.

Actividades

Hay cuatro actividades básicas de desarrollo que utilizan los métodos ágiles: codificar, probar, escuchar y diseñar. El analista necesita identificar el grado de esfuerzo requerido por cada actividad para compararlo con los recursos necesarios para completar el proyecto.

• Codificar: Es la actividad indispensable. Un autor establece que lo más valioso que recibimos del código es el “aprendizaje”. El proceso es fundamentalmente el siguiente: elija una idea, codifíquela, pruébela y compruebe si la idea era lógica.
• Probar: las pruebas automatizadas son imprescindibles. La metodología ágil aboga por la escritura de pruebas para verificar codificación, funcionalidad, rendimiento y cumplimiento.
• Escuchar: El proceso de escuchar se lleva al extremo. Los desarrolladores utilizan la escucha activa para oír a su socio de programación. En el modelado ágil hay menos dependencia de la comunicación formal por escrito, por lo que escuchar se convierte en una habilidad de suma importancia.
• Diseñar: Se prefiere sobre una representación más compleja. Además, el diseño guía la implementación de una historia conforme se escribe: nada más y nada menos. Se desalienta el diseño de funcionalidad adicional porque el desarrollador supone que se requerirá después.

Recursos

Significa que el analista sacrifique algunas ventajas por otras. Algunas veces el costo puede estar predeterminado, mientras que otras veces el tiempo puede llegar a ser el factor más importante.

• Tiempo: hay que asignar tiempo suficiente para completar el sistema y entender lo que necesita para varias actividades distintas.

• Costo: es la segunda variable que podríamos ajustar, tal vez tengamos que contribuir más recursos que requieran dinero para balancear el proyecto.

• Calidad: La tercera variable de control de recursos.Si los sistemas ideales son perfectos, ¿por qué hay que poner tanto esfuerzo en dar mantenimiento a los sistemas? ¿Acaso estamos practicando ya el desarrollo agil al sacrificar la calidad en el desarrollo de software?

• Alcance: Para determinar el alcance hay que escuchar a los clientes, las historias deben se breves y fáciles de comprender.

  
  

Practicas

Hay cuatro prácticas básicas que marcan una diferencia considerable entre la metodología ágil y las demás metodologías: entregas pequeñas, semana de trabajo de 40 horas, alojar al cliente en el sitio, y programar en pareja. Las practicas básicas están interrelacionadas con los recursos, actividades y valores del modelo ágil.

• Entregas pequeñas: El equipo de desarrollo comprime el tiempo entre entregas de su producto.
• Semana de trabajo de 40 horas: los equipos de desarrollo ágil patrocinan una práctica básica cultural en la que el equipo trabaja intensamente durante una semana laboral de 40 horas. Como corolario de esta práctica, la cultura refuerza la idea de que trabajar tiempo extra por más de una semana consecutiva es dañino para la salud del proyecto y de los desarrolladores.
• Alojar al cliente en el sitio: Es decir, tener “en casa”, durante el proceso de desarrollo, a un usuario experto en el aspecto de negocios relacionado con el trabajo de desarrollo de sistemas.
• La programación en pareja: Es una importante práctica básica. Aquí usted trabaja con otro programador que usted mismo haya elegido. Ambos realizan la codificación y las pruebas.

Proceso De Desarrollo Ágil y Metodología Scrum

Proceso De Desarrollo Ágil

El enfoque de este tipo de desarrollo es eficaz para la toma de decisiones para el desarrollo de proyectos de software basados en el desarrollo iterativo e incremental, es un proceso compartido a corto plazo.

Este tipo de métodos se enfocan en comunicación cara a cara en vez de documentación técnica.

Entre las metodologías más notables se encuentra Scrum, Programación Extrema XP, Cristal trasparente y método de desarrollo de sistemas dinámicos.

Plataformas de Lanzamiento 

Estas son las oficinas utilizadas para la comunicación cara a cara incluyendo a los diseñadores de iteración y directores de proyectos. Estas oficinas deben incluir revisores escritores de documentación y ayuda.

Metodología Scrum

Es un proceso en el cual se aplican de manera regular un conjunto de buenas prácticas para trabajar en equipos altamente productivos. Scrum se utiliza especialmente para proyectos en entornos complejos donde se necesita obtener resultados pronto, donde los requisitos son cambiantes y la competitividad son fundamentales.

Proceso Scrum

·         Un proyecto se ejecuta en ciclos temporales cortos y de duración fija;

o   Iteraciones de dos semanas hasta cuatro, cada iteración tiene que proporcionar un resultado completo.

o   El proceso parte de la lista de objetivos priorizada del producto.

Planificación de la Iteración

1.   Selección de requisitos (Dos Horas).
2.   Planificación de la iteración (Dos Horas)

Ejecución de la Iteración

         El equipo inspecciona el trabajo del resto, cada miembro del equipo responde a tres preguntas:

1. Que me echo de la última reunión de sincronización para ayudar a cumplir el objetivo.
2. Que voy a hacer a partir de este momento para ayudar al equipo para cumplir su objetivo.
3. Que impedimentos tengo o voy a tener que nos impidan obtener nuestro objetivo.

Scrum Master (Facilitador)

·         Elimina los obstáculos que el equipo no puede resolver por sí mismo.

·         Protege al equipo de interrupciones externas.

Inspección y Adaptación

       El ultimo día de la interacción se realiza la reunión de revisión de la iteración:

1.  Revisión 1.5 horas, se presentan al cliente los requisitos completados en la iteración
2. Retrospectiva 1.5 horas, el equipo analiza cómo ha sido su manera de trabajar y cuáles son los problemas que les impiden progresar.

Alternativa al SDLC, desarrollo y lineamientos de prototipos

Prototipos como alternativa al SDLC

     Uno de los problemas que se pueden dar a la hora de realizar el SDLC es que conlleva demasiados pasos para su realización a comparación de un prototipo.

     Al ser de cierta manera más sencillo, el prototipo permite que el desarrollo del proyecto se realice de forma más rápida, lo que requiere menos inversión de costos en relación al tiempo. El prototipo también es flexible, por lo que al introducirse por primera vez a los usuarios ellos podrán tener una buena imagen de lo que será el proyecto, permitiéndoles también hacer opiniones o correcciones para que el analista pueda mejorarlas. 

Desarrollo

     Como ya se ha mencionado, los prototipos son de suma importancia en la creación de un proyecto, por lo que se necesita analizar los distintos costos que conlleva la realización del prototipo y de esta manera garantizar su ejecución. Es así como se obtiene el primer paso en el desarrollo de un prototipo, estimando “costos involucrados en la construcción de un módulo del sistema… costos del tiempo de los programadores y del analista, así como los costos del equipo” (Kendall & Kendall, 2011, p. 158).

     De acuerdo a los análisis llevados en cuanto a costos y determinando que la realización del prototipo es factible se puede proceder al siguiente paso, que de acuerdo al libro “Análisis y diseño de sistemas” (Kendall & Kendall, 2011, p.158) son los siguientes:

     Trabajar en módulos administrables. Este lineamiento se refiere a crear pequeños módulos funcionales en el prototipo. En lugar de crear todo un sistema funcional, lo que se hace es crear módulos en donde el usuario pueda interactuar con las operaciones claves, sin preocuparse por los pequeños detalles. 

     Crear el prototipo con rapidez. Este punto va de la mano con el anterior, ya que al utilizar el menor número de recursos a la hora de crear los módulos administrables se gana tiempo y se cumple con los requerimientos de una manera más rápida, incluso si el proyecto llega a fallar no se habrán desperdiciado tantos recursos. 

     Modificar el prototipo. Otra de las cuestiones a tomar en cuenta cuando se realiza el prototipo es la interdependencia. Cuando se trabaja con módulos que no son tan altamente interdependientes se facilita el realizar mejoras al prototipo, ya que es posible realizarlas sin obtener algún tipo de efecto secundario o que surja la necesidad de cambiar otras partes. 

     Hacer énfasis en la interfaz de usuario. Como se ha dicho antes, el propósito de realizar un prototipo para un sistema es que el usuario pueda asimilar el futuro sistema de mejor manera, por lo que es vital desarrollar una interfaz que sea entendible y amigable para él. Si este lineamiento se cumple, los usuarios tendrán la oportunidad de experimentar mediante el prototipo la manera en la que harán uso del sistema.

PROGRAMACION EXTREMA (XP)

La programación extrema usa un enfoque orientado a objetos como paradigma preferido de desarrollo, y engloba un conjunto de reglas y prácticas que ocurren en el contexto de cuatro actividades estructurales: planeación, diseño, codificación y pruebas. La figura 1 ilustra el proceso XP y resalta algunas de las ideas y tareas clave que se asocian con cada actividad estructural. En los párrafos que siguen se resumen las actividades de XP clave.

 

 

Figura 1. El proceso de la programación extrema.

Planeación: La actividad de planeación (también llamada juego de planeación) comienza escuchando actividad para recabar requerimientos que permite que los miembros técnicos del equipo XP entiendan el contexto del negocio para el software y adquieran la sensibilidad de la salida y características principales y funcionalidad que se requieren.

Diseño. El diseño XP sigue rigurosamente el principio MS (mantenlo sencillo). Un diseño sencillo siempre se prefiere sobre una representación más compleja. Además, el diseño guía la implementación de una historia conforme se escribe: nada más y nada menos.

Codificación. Después de que las historias han sido desarrolladas y de que se ha hecho el trabajo de diseño preliminar, el equipo no inicia la codificación, sino que desarrolla una serie de pruebas unitarias a cada una de las historias que se van a incluir en la entrega en curso (incremento de software). Una vez creada la prueba unitaria, el desarrollador está mejor capacitado para centrarse en lo que debe implementarse para pasar la prueba. No se agrega nada extraño (MS). Una vez que el código está terminado, se le aplica de inmediato una prueba unitaria, con lo que se obtiene retroalimentación instantánea para los desarrolladores.

Un concepto clave durante la actividad de codificación (y uno de los aspectos del que más se habla en la XP) es la programación por parejas. XP recomienda que dos personas trabajen juntas en una estación de trabajo con el objeto de crear código para una historia. Esto da un mecanismo para la solución de problemas en tiempo real (es frecuente que dos cabezas piensen más que una) y para el aseguramiento de la calidad también en tiempo real (el código se revisa conforme se crea).

Pruebas. Ya se dijo que la creación de pruebas unitarias antes de que comience la codificación es un elemento clave del enfoque de XP. Las pruebas unitarias que se crean deben implementarse con el uso de una estructura que permita automatizarlas (de modo que puedan ejecutarse en repetidas veces y con facilidad). Esto estimula una estrategia de pruebas de regresión siempre que se modifique el código (lo que ocurre con frecuencia, dada la filosofía del rediseño en XP).

Las pruebas de aceptación XP, también llamadas pruebas del cliente, son especificadas por el cliente y se centran en las características y funcionalidad generales del sistema que son visibles y revisables por parte del cliente. Las pruebas de aceptación se derivan de las historias de los usuarios que se han implementado como parte de la liberación del software.