El Desarrollo de Software es una área cuyo comienzo se dio exactamente en el año 1948, año en el que la primera máquina que almacenaba programas pudo ejecutar éxitosamente su primer programa, por lo que es una disciplina que es apenas una recién nacida frente a otras con una base de conocimiento sólida y estable.
Durante años el tiempo de vida de un producto acabado (software) era muy largo; durante este tiempo, generaba beneficios a las empresas, para las que era más rentable este producto que las posibles novedades.
A partir de los 80, esta situación empieza a cambiar. La vida de los productos es cada vez más corta y una vez en el mercado, son novedad apenas unos meses, quedando fuera de él enseguida. Esto obliga a cambiar la filosofía de las empresas, que se deben adaptar a este cambio constante y basar su sistema de producción en la capacidad de ofrecer novedades de forma permanente.
Saber distinguir las obligaciones y limitaciones de cada uno de los roles del equipo ayuda a que el trabajo lo realicen las personas mejor capacitadas para ello, lo que se traduce en mayor calidad.
Roles distintos no necesariamente significa personas distintas, sobre todo en equipos muy reducidos. Una persona puede adoptar más de un rol, puede ir adoptando distintos roles con el paso del tiempo, o rotar de rol a lo largo del día. Hagamos un repaso a los papeles más comunes en un proyecto software.
Es el más básico de todos los modelos y ha servido como bloque de construcción para los demás paradigmas de ciclo de vida. Está basado en el ciclo convencional de una ingeniería (Se comienza por el principio) y su visión es muy simple: el desarrollo de software se debe realizar siguiendo una secuencia de fases.
Cada etapa tiene un conjunto de metas bien definidas y las actividades dentro de cada una contribuyen a la satisfacción de metas de esa fase. Es un modelo de ciclo de vida usado en el software de hace varias décadas, aunque sigue siendo un modelo a seguir ante cierto tipo de desarrollos.
El modelo en cascada abarca las siguientes etapas: Se parte de las especificaciones o requisitos de un proyecto: qué se debe realizar. Estas pueden estar en documentos, o se pueden obtener de reuniones con el cliente, pero deben tenerse claros antes de comenzar el desarrollo.
A veces también se pueden tener en cuenta otras fases como por ejemplo la fase de documentación (creamos la documentación del proyecto), o la fase de implantación (instalar la aplicación en el sistema de nuestro cliente).
En el modelo vemos una ventaja evidente y radica en su sencillez, ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el software. Pero el modelo se aplica en un contexto, así que debemos atender también a él y saber que:
Utilizar GanttProject para crear un diagrama de Gantt
Se basan en realizar una iteración de varios ciclos de vida en cascada realimentados. En cada iteración nos centramos en el desarrollo de una pequeña parte del software, llamada “incremento”. En cada iteración se vuelven a realiar todas las fases para desarrollar una parte mayor, basándonos o continuando sobre el que ya ha sido entregado.
En la imagen se observa la iteracion (repetición) de distintas fases de desarrollo en cascada para la obtención de un nuevo incremento (versión del programa).
Como ejemplo de aplicación de este modelo se puede considerar el desarrollo de un procesador de textos. En el primer incremento se desarrollan funciones básicas de gestión de archivos y de producción de documentos; en el segundo incremento se desarrollan funciones gramaticales y de corrección ortográfica, en el tercer incremento se desarrollan funciones de paginación, etc.
Ventajas:
Se recomienda cuando los requisitos o el diseño no están completamente definidos y es posible que haya grandes cambios.
Los procesos ágiles se basan en este modelo, con iteraciones cortas.
El agilismo es una respuesta a los fracasos y las frustraciones del modelo en cascada. Contempla un enfoque para la toma de decisiones y la forma de organización en los proyectos de software, basándose en los modelos de desarrollo iterativo e incremental, con iteraciones cortas (semanas) y sin que dentro de cada iteración tenga que haber fases lineales.
En el 2001, 17 representantes de las nuevas tecnologías y el desarrollo de software se juntaron para discutir sobre el desarrollo de software. De esa reunión surgio el Manifiesto Ágil:
“Estamos descubriendo mejores maneras de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de esta experiencia hemos aprendido a valorar:
Esto es, aunque los elementos a la derecha tienen valor, nosotros valoramos por encima de ellos los que están a la izquierda.”
Estas ideas se explican en los 12 principios para el desarrollo ágil de software.
El abanico de metodologías ágiles es amplio, existiendo métodos para organizar equipos o proyectos, y técnicas para escribir y mantener el software. Tanto las técnicas de desarrollo de software como las de organización de proyectos se pueden combinar siendo de las más famosas la programación extrema junto con la gestión Scrum.
Es una técnica de gestión de proyectos englobada dentro del paradigma de desarrollo ágil. No se aplica únicamente al desarrollo de software, sino a la gestión de cualquier tipo de proyectos. El nombre de Scrum, se traduce por Melé, palabra del argot del Rugby usada para designar la unión de los jugadores en bloque.
Como las demás, se basa en el desarrollo iterativo e incremental en el que el proyecto se planifica en diversos bloques temporales (un mes, normalmente) llamados Sprints. Cumple con las características del desarrollo ágil.
El cliente nos indica qué es lo que quiere. De esta reunión entre el cliente y el Scrum Master surge la lista de requisito del producto (Product Backlog). Se realiza una sola vez al inicio del proyecto, a diferencia de las demás fases que se realizan en cada Sprint.
Es una reunión realizada antes de cada Sprint en la que el cliente indica los requisitos prioritarios de la iteración (Sprint), se plantean las dudas y se traducen dichos requisitos a tareas (Sprint Backlog), que deben ser realizadas por cada uno de los miembros del equipo de desarrollo durante el Sprint. Estas tareas se incorporan a un panel que controlará su estado de realización (por hacer, en progreso, terminado, pendiente, etc).
Es el bloque de tiempo, iteración, en el cuál se realizan la tareas (2-4 semanas), siendo recomendable que siempre tengan la misma duración y la duración esté definida por el grupo en base a su experiencia.
Una vez comenzado el Sprint, cada día se celebra una reunión rápida (no más de 10 minutos, siempre puntual y suele ser de pié) en la que se habla del estado de las tareas del Sprint (Sprint Backlog). Se revisan las tareas en proceso del día anterior, y se marcan como terminadas. Se asignan nuevas tareas a miembros del equipos y se ponen en proceso. Solo se habla del estado de las tareas y solo los miembros del equipo pueden hablar.
Es una reunion que se produce al final del Sprint en la que se presenta al cliente el incremento (parte del producto pactada) realizado durante el Sprint. En ella el cliente puede ver cómo han sido desarrollados los requisitos que indicó para el Sprint (Sprint Backlog), si se cumplen las expectativas, y entender mejor qué es lo que necesita.
Cuando se ha terminado un Sprint, se comprobarán, medirán y discutirán los resultados obtenidos en el periodo anterior a través de las impresiones de todos los miembros del equipo. El propósito de la retrospectiva es realizar una mejora contínua del proceso.
Es quién plantea los objetivos y requisitos y ayuda al usuario a escribir las historias de usuario que se incorporarán al Sprint Backlog, definiendo las prioridades. Representa a todas las personas interesadas en el proyecto (usuarios finales, promotores, etc). Es quién indica qué quiere en total y qué quiere en cada Sprint.
Se asegura de que se sigan los valores y principios ágiles, de la existencia de las listas de requisitos para cada iteracion, facilita las reuniones, quitar los impedimentos que se van encontrando en el camino y proteger y aislar al equipo de interrupciones.
Tienen un objetivo común, se autoorganizan, comparten la responsabilidad del trabajo que realizan, y cuyos miembros confian entre ellos. 5-9 personas es lo ideal, aunque si hay más se deben hacer más equipos
Es un documento abierto que representa la lista de objetivos o requisitos, y expectativas del cliente respecto a los objetivos y entregas del producto. Se concreta en la reunión inicial, antes de entrar en la planificación de los Sprints. Solo puede ser modificado por el product owner(cliente) aunque con ayuda del equipo y el “scrum master”, quienes proporcionan el coste estimado tanto del valor de negocio como del esfuerzo de desarrollo. Representa el qué va a ser contruido en su totalidad.
Lista de tareas que el equipo elabora en la reunión al inicio del Sprint,Sprint Planning, como plan para completar los requisitos para la iteración. Los requisitos tienen que estar claramente detallados en tareas (historias de usuario), a diferencia del Product Backlog. No se deben agregar requisitos al Sprint Backlog a menos que su falta amenace al éxito del proyecto. Representa el cómo el equipo va a implementar los requisitos.
La forma de definir las tareas o los requisitos de cada Sprint se suele hacer en terminos de historias de usuario (user stories). Suelen ser frases cortas definiendo en qué consiste la tarea. Algunos requisitos puede que no sean traducibles a historias de usuario.
Es un gráfico de trabajo pendiente a lo largo del tiempo, en el que se muestra la velocidad a la que se están completando los requisitos. También ayuda a intuir si el equipo terminará en el tiempo estimado. Lo normal es que la linea que une todos los sprints completados sea descendente, pero si se añaden nuevos requisitos durante el proceso, puede ser ascendente.
En resumen, Scrum permite conocer en un vistazo rápido cual es el estado general de las cosas, detectando rápidamente qué tareas se han quedado atascadas o qué equipos no están rindiendo al nivel que se esperaba.Es un método de desarrollo ágil ideal para entornos con mucha incertidumbre en cuanto al trabajo a realizar, en los que las tareas cambian muy rápidamente y son susceptibles de olvidarse.
Aplicando metodología SCRUM con herramienta Trello
Conocida comúnmente como XP (eXtreme Programming), es una técnica de implementación de software formulada por Kent Beck, uno de los impulsores del manifiesto ágil. Es una métodología que hace énfasis en la adaptación continua a cambios en el plan, antes que en seguir un plan firme; los cambios en los requisitos deben ser bienvenidos ya que ayudan a crear un programa más sólido. Toma su nombre de aplicar las buenas prácticas del desarrollo tradicional, pero llevadas al “extremo”.
Se trata de realizar entregas continuas de software funcional, en cortos ciclos de desarrollo, de modo que el cliente con cada entrega puede indicarnos nuevos requisitos. Es una metodología enfocada en grupos de desarrollo pequeños en los que hay gran colaboración con el cliente.
Esta forma de trabajar está fundamentada en un modelo de desarrollo incremental con entregas extremadamente rápidas y esperando feedback (opinión, información, cómo lo quiere) del cliente casi a diario por parte del cliente. En cada una de las iteraciones del desarrollo se programa reflexionando, diseñando, probando y documentando el código, a medida que se escribe.
Prácticas llevadas al extremo:
Es una técnica de desarrollo ágil de software en la que dos programadores trabajan juntos en el mismo ordenador. Uno, el controlador (o driver), escribe el código mientras que el otro, el observador, revisa cada linea de código mientras que es escrita. Los dos programadores cambian su rol frecuentemente.
Mientras que el código es revisado por el observador, este va pensando en la dirección estratégica a tomar, incluyendo nuevas ideas para mejoras futuras y anticipándose a futuros problemas. De esta forma el controlador puede prestar su completa atención a terminar la tarea actual, usando al controlador como guía.
Características:
Es otra metodología de desarrollo ágil de software en la que primero se escriben las pruebas a partir de unos requisitos funcionales (cómo debe funcionar) y posteriormente se implementa únicamente el código que debe pasar dichas pruebas. De esta forma el programa se enfoca simplemente en la superación de esas pruebas o tests, que corresponden con los requisitos del programa.
Para escribir las pruebas se usa algún framework de pruebas unitarias (unit tests), que permita crear tests tan pequeños como para probar si el código sobre el que se aplica pasa o no la prueba. El framework JUnit permite crear pruebas unitarias y es una herramienta habitual en la disciplina de software testing.
© 2021 Fernando Valdeón