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.

• Dueño del producto: su misión es pedir lo que necesita (no el cómo sino el qué), y aceptar o pedir correcciones sobre lo que se entrega.
  • Cliente: Es el dueño del producto y el usuario final.
• Analista de negocio: También es el dueño del producto porque trabaja codo a codo con el cliente y traduce los requisitos en tests de aceptación para que los desarrolladores los entiendan, es decir, les explica qué hay que hacer y resuelve sus dudas.
• Desarrolladores: Toman la información del analista de negocio y deciden cómo lo van a resolver además de implementar la solución. Aparte de escribir código, los desarrolladores deben tener conocimientos avanzados sobre usabilidad y diseño de interfaces de usuario.
  • Arquitectos: En el mundo anglosajón el arquitecto es la persona capaz de tomar decisiones de diseño pero además tiene la capacidad de poder hablar directamente con el cliente y entender los requisitos de negocio. En lugar de un rol, es una persona que adopta varios roles. En el desarrollo ágil los desarrolladores hacen la función de arquitectos, ya que son los que toman las decisiones sobre la arquitectura a medida que se va implementando o refactorizando la solución.
• Administradores de sistemas: Se encargan de velar por los servidores y servicios que necesitan los desarrolladores.

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.

1. Análisis: En esta etapa de realiza un Análisis de los requisitos Sistema, donde se establecen los requisitos de todos los elementos del sistema, tanto hardware como software: Qué voy a necesitar, qué voy a usar, cómo lo voy a distribuir, etc. Uno de estos elementos son los requisitos de software, que nos lleva al Análisis de los requisitos de software. Es el proceso de recopilación de los requisitos que se centra e intensifica especialmente en el software.
2. Diseño: En esta etapa se traducen los requisitos en una representación de software. El diseño orientado a objetos se centra en el diseño del subsistema: el diseño de las clases y objetos y su jerarquía, la colaboración entre los objetos y las responsabilidades que hay entre clases. Para realizar este diseño se crean modelos (diagramas) empleando un lenguaje de modelado UML (Unified Modeling Language), el cual está basado en diagramas.
3. Codificación o implementación: el diseño (modelos) debe traducirse en una forma legible para la maquina (código). Si el diseño se realiza de una manera detallada, la codificación puede realizarse mecánicamente.
4. Pruebas: una vez que se ha generado el código comienza la prueba del programa. La prueba se centra en la lógica interna del software y en las funciones externas, realizando pruebas de software que aseguren que la entrada definida produce los resultados que realmente se requieren.
5. Mantenimiento: el software sufrirá cambios después de que se entrega al cliente. Los cambios ocurrirán debidos a que se hayan encontrado errores, a que el software deba adaptarse a cambios del entorno externo (sistema operativo, dispositivos periféricos) o a que el cliente requiera ampliaciones funcionales.

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:

• Los proyectos reales raramente siguen el flujo secuencial que propone este modelo. Siempre hay iteraciones, y surjen problemas en la aplicación de este paradigma.
• Es difífil para el cliente establecer todos los requisitos antes de comenzar.
• El cliente no puede ver una versión operativa del proyecto hasta las etapas finales. Un error no detectado hasta que el programa esté funcionando conllevará muchos problemas para su solución.

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:

• No se necesitan conocer todos los requisitos al comienzo
• Permite la entrega temprana de partes operativas de software.
• Las entregas facilitan la realimentación de las siguientes.

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:

• Individuos e interacciones sobre procesos y herramientas
• Software funcionando sobre documentación extensiva
• Colaboración con el cliente sobre negociación contractual
• Respuesta ante el cambio sobre seguir un plan

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.

• La esencia del agilismo es la habilidad para adaptarse a los cambios. La superación de obstáculos imprevistos tiene prioridad sobre las reglas generales de trabajo preestablecidas. Es decir, se para la forma habitual de trabajo o la forma en la que se lanzan nuevas versiones, para resolver un problema.
• También existen las fases de análisis, desarrollo y pruebas pero, en lugar de ser consecutivas, están solapadas y se suelen repetir en cada iteración. Las iteraciones suelen durar de dos a seis semanas.
• En cada iteración se habla con el cliente para analizar requerimientos, se escriben pruebas automatizadas, se escriben líneas de código nuevas y se mejora código existente (Refactorización).
• Al cliente se le enseñan los resultados después de cada iteración para comprobar su aceptación e incidir sobre los detalles que se estimen oportunos.
• Todo el equipo trabaja unido, y el cliente es parte de él. No es un oponente. La estrategia de juego ya no es el control sino la colaboración y la confianza.
• La jerarquía clásica (director técnico, analista de negocio, arquitecto, programador senior, junior …) pierde sentido y los roles se disponen sobre un eje horizontal, donde cada cual cumple su cometido pero sin estar por encima ni por debajo de los demás.
• En lugar de trabajar por horas, se trabaja por objetivos y se usa el tiempo como un recurso más. ( Pero existen fechas de entrega para cada iteración).
• En cualquier método ágil, los equipos deben ser pequeños, típicamente menores de siete personas.
• Todo el equipo se reúne periódicamente, incluidos usuarios. Las reuniones tienen hora de comienzo y de final y son breves.
• La aplicación se ensambla y se despliega a diario, de forma automatizada. Las baterías de tests se ejecutan varias veces al día.
• Los desarrolladores envían sus cambios al repositorio de código fuente al menos una vez al día (commit).

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.

La metodología Scrum se organiza de la siguiente forma:

• Reunión inicial

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.

• Planificación de la iteración (Sprint Planning)

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).

• Ejecución de la iteración (Sprint)

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.

• Reunión diaria del equipo (Daily Scrum Meeting)

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.

• Revisión de la entrega (Sprint Review)

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.

• Retrospectiva (Sprint Retrospective)

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.

• Cliente (Product Owner)

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.

• Facilitador (Scrum Master)

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.

• Equipo (Team)

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

• Lista de requisitos priorizada (Product Backlog)

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 pendientes del Sprint (Sprint Backlog)

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.

• Gráficos de trabajo pendiente (Burndown Chart)

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:

• Revisión del código → Revisión diaria, Programación por parejas, Refactorización constante del código
• Probar cada funcionalidad → Diseño de pruebas unitarias automatizadas para cada pequeña implementación de código.
• Entregas al cliente muy rápidas, cada pocos días.
• Integración equipo-cliente para recibir feedback casi diario, aceptación de cambios y modificaciones.

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:

• Calidad del Diseño: programas más cortos, diseños mejores, pocos defectos, etc. El código debe ser comprensible para dos programadores, y se plantean más alternativas.
• Coste reducido de desarrollo: Cuando los defectos son la parte más cara del desarrollo de software, especialmente si se encuentran en etapas avanzadas, se minimizan programando por parejas.
• Aprendizaje y formación: el conocimiento pasa fácilmente entre programadores.
• Superación de problemas difíciles
• Incremento de la disciplina y mejor gestión del tiempo: menos distracciones para cada uno, menos tiempo perdido en tareas ajenas, etc.
• Menos interrupciones externas: cuesta más interrumpir a una pareja que a una persona que trabaja sola.

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.

1. Planificación modelo de desarrollo en cascada.
2. Gestión de proyectos Scrum con Trello

© 2024 Fernando Valdeón