Tema 3 - Procesos Ligeros

Ingeniería del Software II 2011
Tema 3. Procesos ligeros de desarrollo de
software.
Tipos de procesos ligeros.
Tipos de procesos ligeros:





Desarrollo Rápido de Software.
Desarrollo Ágil.
Programación Extrema.
Scrum.
Escalamiento de Métodos Ágiles.
Desarrollo Rápido de Software.
Las empresas maniobran en un entorno que cambia constantemente, al cual deben adaptarse
para obtener beneficios.
El software es parte de casi todas las operaciones industriales, de modo que debe
desarrollarse rápidamente para aprovechar las nuevas oportunidades.
Además resulta difícil definir un conjunto estable de requisitos, tal y como se requiere en los
modelos de procesos tradicionales.
Cada vez más se elige rapidez en la entrega en contraposición a la fiabilidad o a la calidad del
producto.
Principales características:

Especificación, diseño e implementación están entrelazados.

El sistema se desarrolla como una serie de versiones con los clientes involucrados en
la evaluación de las mismas si es necesario.

Los interfaces de usuario son a menudo desarrollados usando un IDE y herramientas
gráficas.
Métodos Ágiles.
Nace como contraposición a la percepción generalizada durante los años ochenta y noventa de
que una planificación cuidadosa del proyecto conduce a un mejor software. Esta planificación
incluye costes significativos en su diseño y documentación y aunque está justificada en el
1
desarrollo de sistemas críticos, donde trabajen múltiples equipos o donde vayan a trabajar
muchas personas diferentes a lo largo de su mantenimiento.
Los Métodos Ágiles se caracterizan por:

Estar centrados en el código más que en el diseño.

Basados en aproximaciones iterativas al desarrollo de software.

Destinados a entregar software operativo rápidamente y evolucionarlo para
satisfacer los requerimientos cambiantes.
Los objetivos de los Métodos Ágiles son:

Reducir sobrecargas en los procesos software, por ejemplo limitando la
documentación.

Ser capaces de responder rápidamente a los requerimientos cambiantes sin excesivo
trabajo adicional, sin rehacer demasiado trabajo.
Manifiesto Ágil.
Nace como resultado de las metodologías ágiles para el desarrollo de software, de forma
sencilla este manifiesto propone que se valore:

Individuos e interacciones sobre procesos y herramientas.

Software operativo sobre documentación exhaustiva.

Colaboración con el cliente sobre negociación del contrato.

Respuesta al cambio sobre seguimiento de un plan.
Los 5 principios de los Métodos Ágiles.
1. Participación estrecha del cliente. Los clientes deben intervenir estrechamente
durante el proceso de desarrollo. Su función consiste en ofrecer y priorizar nuevos
requerimientos del sistema y evaluar las iteraciones del mismo.
2. Entrega incremental. El software se desarrolla en incrementos con el cliente
especificando los requerimientos que van a ser incluidos en cada uno.
2
3. Personas, no procesos. Deben reconocerse y aprovecharse las habilidades del equipo
de desarrollo. Debe permitirse a los miembros del equipo desarrollar sus propias
maneras de trabajar sin procesos establecidos.
4. Adoptar el cambio. Esperar que los requerimientos cambien y, de este modo, diseñar
el sistema para adoptar dichos cambios.
5. Mantener la simplicidad. Centrarse en la simplicidad tanto en el software como en el
proceso de desarrollo. Siempre que sea posible, trabajar de manera activa para
eliminar la complejidad del sistema. Esfuerzo en mejorar del código.
Aplicabilidad de los Métodos Ágiles.
Las metodologías ágiles son aplicables por ejemplo en:
Desarrollo del producto donde una compañía de software elabora un producto pequeño o
mediano para su venta.
Diseño de sistemas a medida dentro de una organización, donde hay un claro compromiso del
cliente por intervenir en el proceso y donde no existen muchas reglas ni regulaciones
externas que afecten al desarrollo.
Dado su enfoque en equipos reducidos firmemente integrados hay problemas en escalarlos
hacia sistemas grandes pero pueden ser aplicados en sistemas pequeños.
Problemas con los Métodos Ágiles.
Los principales problemas de estas metodologías son:

Puede ser difícil mantener el interés de los clientes que intervienen en el proceso.

Los miembros del equipo pueden ser inadecuados para la participación intensa
característica de los métodos ágiles.

Priorizar los cambios puede ser difícil cuando hay múltiples participantes.

Mantener la simplicidad requiere trabajo adicional.

Los contratos pueden ser un problema, como en otros procesos de desarrollo
iterativo.
Métodos Ágiles y mantenimiento.
La mayoría de las compañías gastan más tiempo manteniendo software que creándolo nuevo.
Por lo tanto si los Métodos Ágiles quieren tener éxito también tienen que dar un buen soporte
al mantenimiento.
3
Las preguntas resultantes de esta afirmación son:

¿Son los sistemas desarrollados usando una aproximación ágil mantenibles, a pesar del
énfasis en minimizar la documentación formal?

¿Los métodos ágiles pueden usarse con efectividad para evolucionar un sistema como
respuesta a requerimientos de cambio por parte del cliente?

Si el equipo cambia, ¿pueden aparecer otros problemas?
Desarrollo Dirigido por un Plan y Ágil.
Desarrollo dirigido por un plan:

Está basado en etapas separadas con salidas producidas en cada una de ellas
planeadas por adelantado.

No es necesario seguir un modelo de cascada, es posible el desarrollo incremental.

La iteración ocurre dentro de las actividades.
Desarrollo Ágil:

Especificación, diseño, implementación y prueba están solapados y las salidas se
deciden a través de un proceso de negociación durante el desarrollo.

La iteración ocurre a través de las actividades.
4
Programación Extrema (XP).
Quizás el método ágil mejor conocido y más ampliamente utilizado. Lleva a niveles “extremos”
el desarrollo iterativo. Método ágil llevado al extremo.
Características:

Pueden construirse versiones nuevas varias veces al día.

Se entregan incrementos a los clientes cada poco tiempo (sobre 2 semanas variando
en base al proyecto).

Deben ejecutarse todas las pruebas para cada nueva versión y sólo es aceptada si las
supera.
Tres principios importantes de la Programación Extrema.
1. Los requerimientos se expresan como escenarios (llamados historias de usuario o
casos de uso) que se implementan directamente como una serie de tarea.
2. Los programadores trabajan en pares o parejas.
3. Antes de escribir el código se desarrollan pruebas para cada tarea.
Programación Extrema y Principios Ágiles.

Desarrollo incremental apoyado por pequeñas y frecuentes liberaciones del sistema.

La participación del cliente implica un compromiso a tiempo completo con el equipo
de desarrollo.

Personas y no procesos a través de programación por parejas, la propiedad colectiva
del código y un proceso que evita las jornadas de trabajo largas.

El cambio es soportado mediante liberaciones regulares del sistema.

Se mantiene la simplicidad mediante la refactorización (depuración) constante del
código.
Ciclo de Liberación de la Programación Extrema.
5
Prácticas de la Programación Extrema.

Planeación incremental. Los requerimientos se registran en tarjetas de historia y las
historias que se van a incluir en una liberación se determinan por el tiempo disponible
y la prioridad relativa. Los desarrolladores las desglosan en tareas.

Pequeñas entregas. Se desarrolla primero el conjunto mínimo de funcionalidad útil
que ofrece valor para el negocio. Las entregas son frecuentes y añaden funcionalidad
incrementalmente.

Diseño simple. Se realiza un diseño estrictamente suficiente para cumplir con los
requerimientos actuales.

Desarrollar primero las pruebas. Se utiliza un marco de trabajo automático de pruebas
para testear cualquier nueva funcionalidad, dicho marco de trabajo es creado antes de
que la nueva funcionalidad sea implementada.

Refactorización. Se espera que todos los desarrolladores refactoricen el código
continuamente tan pronto como sea posible en busca de mejoras. Esta práctica
produce código simple y mantenible.

Programación por parejas. Los desarrolladores trabajan en parejas, cada uno revisa el
trabajo del otro, dando soporte para que siempre se realice un buen trabajo.

Propiedad colectiva. Las parejas de desarrolladores trabajan en todas las áreas del
sistema de manera que no se desarrollen islas de experiencia y todos los
desarrolladores se responsabilicen de todo el código. Cualquiera puede producir
cambios.

Integración continua. Tan pronto como está completa una tarea se integra en el
sistema completo. Después de la integración deben superarse todas las pruebas de
unidad para que dicha tarea se considere añadida al sistema.

Ritmo sostenible. No se consideran aceptables grandes cantidades de tiempo extra ya
que su efecto neto suele ser la reducción de la calidad del código y una rebaja de la
productividad media.

Cliente in situ. Debe disponerse de un representante del usuario final del sistema
(normalmente el cliente) a tiempo completo por parte del equipo. Se le considera un
miembro más del equipo y es responsable de traer al equipo los requisitos para su
implementación.
6
Escenarios de Requerimientos en la Programación
Extrema.

El cliente que forma parte del equipo es responsable de tomar decisiones sobre los
requerimientos.

Los requerimientos de usuario se expresan como escenarios o historias de usuario.

Se escriben en tarjetas y el equipo de desarrollo las descompone en tareas de
implementación.

Estas tareas son la base para la planificación y la estimación de costes.

El cliente elige las historias que hay que incluir en cada entrega en base a sus
prioridades.
Programación Extrema y el Cambio.
Una creencia popular en la Ingeniería del Software tradicional es diseñar para cambiar, es
decir, se considera valioso gastar tiempo y esfuerzo en anticipar cambios ya que se presupone
que esto reducirá costes futuros durante la vida del producto.
En contraposición con esta idea la Programación Extrema mantienen que no merece la pena y
que los cambios no pueden ser anticipados de modo fiable de manera que es mejor
mantener una mejora constante del código o refactorización para facilitar los posibles
cambios que en el futuro tengan que se implementados.
Refactorización en Programación Extrema.
El equipo de programación busca posible mejoras en el software y hace estas mejoras incluso
cuando no hay una necesidad inmediata de ellas, esto mejora la compresión del software y
reduce la necesidad de documentación.
Los cambios son más fáciles de hacer porque el código está bien estructurado, sin embargo
algunos cambios requieren refactorización de la arquitectura algo mucho más costoso.
Reorganizar una jerarquía de clases para remover código duplicado, ordenar y cambiar de
nombre atributos y métodos para que sean más fáciles de comprender o sustituir código por
llamadas a métodos incluidos en librerías son ejemplos prácticos de factorización.
Pruebas dentro de la Programación Extrema.
Probas es primordial para la Programación Extrema y para ello se ha desarrollado un enfoque
donde el programa es probado después de cada cambio realizado.

Este enfoque determinado se caracteriza por:
7

Desarrollar primero las pruebas.

Desarrollo incremental de pruebas a partir de los escenarios.

Implicación del usuario en el desarrollo y validación de las pruebas.

Uso de marcos de pruebas automatizados para correr todas las pruebas cada vez que
se construye una nueva versión.
Desarrollar primero las Pruebas.
Escribir las pruebas antes de codificar es un método de clarificación de los requerimientos.
Son escritas como programas más que como datos de modo que puedan ejecutarse
automáticamente y sirvan como verificación de las funcionalidades.
Todas las pruebas previas y nuevas se ejecutan automáticamente cuando se añada una nueva
funcionalidad, aumentando el control de errores y la depuración del código.
Implicación del Cliente en las Pruebas.
Ayuda a desarrollar pruebas de aceptación a partir de las historias que van a implementarse
en la siguiente versión.
Es parte del equipo que escribe las pruebas a medida que el desarrollo avanza y todo el código
nuevo es validado para así asegurar que es lo que realmente necesita el cliente.
Sin embargo, el cliente tiene disponibilidad muy limitada y es probable que no puedan
participar a tiempo completo. Podría creer que aportar los requerimientos es suficiente
contribución y ser reacio a intervenir en las pruebas.
Dificultades con las Pruebas en Programación Extrema.
Los programadores prefieren programar a probar y algunos toman “atajos” cuando escriben
las pruebas como no comprobar todas las excepciones.
Algunas pruebas pueden ser muy difíciles de escribir de modo incremental.
Es difícil juzgar las completitud de un conjunto de pruebas.
Programación en Parejas.
Los programadores trabajan por pares, sentándose juntos para desarrollar el código en la
misma máquina.
Las parejas son creadas dinámicamente de modo que todos los miembros del equipo trabajen
unos con otros durante el proceso, esto ayuda a desarrollar la idea de propiedad común y
responsabilidad del código y extiende el conocimiento en el equipo.
8
Compartir el conocimiento es muy importante porque reduce el riesgo global del proyecto
cuando se marchan miembros del equipo, al mismo tiempo programar por parejas sirve como
revisión informal ya que el código está “testeado” por dos programadores favoreciendo la
factorización.
La productividad se mantiene o incluso aumenta ya que los programadores menos
experimentados son apoyados por otros con mayor experiencia evitando salidas en falso,
rediseño, errores y, aunque para los programadores experimentados pueda suponer una
pérdida de productividad realmente el intercambio de información dinamiza el trabajo y
reduce los riesgos del proyecto.
Administración de un Proyecto Ágil.
La responsabilidad principal de los administradores es dirigir el proyecto de modo que el
software se entregue a tiempo y con el presupuesto planeado.
El enfoque básico o estándar está basado en un plan:



Qué se debe entregar.
Cuándo se debe entregar.
Quién trabajará en su desarrollo.
El enfoque para la administración ágil es distinto y debe adaptarse al desarrollo incremental y
a las fortalezas y debilidades particulares de los métodos ágiles.
SCRUM.
Es un método ágil general pero enfocado a la administración del desarrollo iterativo más que
a prácticas ágiles específicas.
Consta de tres fases:

Planificación del boceto donde se establecen los objetivos generales del proyecto y el
diseño de la arquitectura del software.

Una serie de ciclos sprint donde cada ciclo desarrolla un incremento del sistema.

Cierre del proyecto donde se completa la documentación requerida, manuales de
usuario etc. En esta fase también se realiza la valoración de las lecciones aprendidas
durante el proyecto.
El Ciclo Sprint en SCRUM.
1. Los sprints tienen longitud fija, normalmente de 2 a 4 semanas. Corresponden al
desarrollo de una liberación del sistema en Programación Extrema.
9
2. El punto de partida es el backlog de producto. Consiste en una lista de trabajo que se
tiene que hacer en el proyecto, se revisan dichas tareas y se asignan prioridades y
riesgos.
3. El equipo de desarrollo que trabaja con el cliente selecciona las características y la
funcionalidad a desarrollar en el sprint.
4. Se organiza el equipo para desarrollar el software, se aísla del cliente y la organización
canalizando todas las comunicaciones a través del Maestro de Scrum (Scrum
Manager).
5. El papel del Maestro de Scrum es proteger al equipo de desarrollo de “distracciones”
externas.
6. Al final se revisa el trabajo hecho y se presenta a los participantes antes de comenzar
el siguiente sprint.
El Equipo de Trabajo en SCRUM.
Maestro de Scrum. Es un facilitador que organiza las reuniones diarias, planifica el trabajo por
hacer, registra las decisiones, mide el progreso del proyecto y detecta los retrasos. Sirve como
punto de comunicación entre el cliente, la dirección del proyecto y el equipo de desarrollo.
Todo el equipo acude a reuniones diarias cortas donde se comparte información, describen su
progreso, los problemas y sus planes desde la última reunión.
Todos conocen todos los problemas y los progresos del resto del equipo y ayudan a replantear
el trabajo a corto plazo y a solucionar dichos problemas de forma colectiva.
Beneficios de SCRUM.

El producto se desglosa en un conjunto de piezas manejables y comprensibles.

Los requerimientos inestables no causan retraso.

Todo el equipo tiene visibilidad total del proyecto mediante una comunicación directa
y continua.

Los clientes ven la entrega a tiempo de los incrementos y obtienen retroalimentación
del funcionamiento del producto.

Se crea confianza entre los clientes y los desarrolladores, es decir, nace una cultura
positiva donde todos esperan el éxito del proyecto.
Escalamiento de los Métodos Ágiles.
10
Se ha probado que son exitosos para proyectos de tamaño pequeño y medio que pueden ser
desarrollados por un equipo local.
Un factor de dicho éxito proviene de la comunicación entre todos los miembros del equipo.
Escalar estos métodos conlleva cambiarlos para tratar con proyecto más grandes y largos o
donde hay múltiples equipos de desarrollo incluso geográficamente distantes.
Desarrollo de Grandes Sistemas.
Usualmente son colecciones de sistemas separados que se comunican, desarrollados por
distintos equipos, frecuentemente trabajando en diferentes sitios y zonas horarias diversas.
Incluyen e interaccionan con sistemas ya existentes, muchos de sus requerimientos tienen
que ver con esto y no permiten la flexibilidad y el desarrollo incremental.
Cuando varios sistemas se integran para crear un sistema, una fracción significativa del
desarrollo tiene que ver con la configuración del sistema más que con el desarrollo del código.
A menudo sus procesos de desarrollo están restringidos por reglas externas y regulaciones
que limitan la forma en que se llevan a cabo.
Tienen un largo tiempo de elaboración y desarrollo. Es difícil mantener equipos coherentes
que conozcan el sistema durante todo el desarrollo. Es inevitable que la gente cambie de
trabajo o de proyecto.
Normalmente tiene un conjunto diverso de participantes, es prácticamente imposible implicar
a todos ellos en el desarrollo.
Scaling Up y Scaling Out.

Scaling Up. (Expansión) Los métodos ágiles se usan para desarrollar grandes sistemas
software que no se logran desarrollar por un equipo pequeño.

Scaling Out. (Ampliación) Los métodos ágiles se pueden introducir en una gran
organización con muchos años de experiencia en el desarrollo de software.
Cuando se escalan métodos ágiles es esencial mantener sus fundamentos ágiles: planificación
flexible, frecuentes entregas del sistema, integración continua, desarrollo dirigido por pruebas
y buenas comunicaciones de equipo.
Adaptaciones para Grandes Sistemas.

No es posible centrarse sólo en el código, se necesita más diseño y documentación.

Tienen que diseñarse y usarse mecanismos de comunicación entre equipos como
teléfono, videoconferencias, reuniones electrónicas, email…
11

La integración continua. El sistema completo se construye cada vez que un
desarrollador comprueba un cambio, es imposible aunque es esencial mantener
construcciones y liberaciones del sistema frecuentes.
Adaptaciones para Grandes Compañías.
Gerentes sin experiencia pueden ser reticentes al riesgo de un nuevo enfoque.
Incompatibilidad con los procesos de calidad y estándares para todos los proyectos.
Los métodos ágiles parecen funcionar mejor cuando se tiene un nivel de habilidad
relativamente alto, pero puede haber una amplia gama de habilidades.
Quizás haya una resistencia cultural en donde se tenga un largo historial de uso de procesos
convencionales de ingeniería de sistemas.
12