Desarrollo de software adaptativo: prácticas

Las prácticas de desarrollo de software adaptativo se basan en la creencia en la adaptación continua, con el ciclo de vida equipado para aceptar el cambio continuo como la norma.

Adaptive Software Development Lifecycle se dedica a:

  • Aprendizaje continuo
  • Cambiar orientación
  • Reevaluación
  • Mirando hacia un futuro incierto
  • Intensa colaboración entre desarrolladores, gerentes y clientes.

SDLC adaptativo

El desarrollo de software adaptativo combina RAD con las mejores prácticas de ingeniería de software, tales como:

  • Iniciación del proyecto.
  • Planificación del ciclo adaptativo.
  • Ingeniería concurrente de componentes.
  • Revisión de calidad.
  • Control de calidad final y lanzamiento.

Las prácticas de desarrollo de software adaptativo se pueden ilustrar de la siguiente manera:

Practica Learning Loop

Como se ilustra arriba, las prácticas de desarrollo de software adaptativo se extienden a través de las tres fases de la siguiente manera:

  • Especular - Iniciación y planificación

    • Iniciacion de proyecto

    • Establecer un calendario para todo el proyecto.

    • Decida el número de iteraciones y asigne un cuadro de tiempo a cada una.

    • Desarrolle un tema u objetivo para cada una de las iteraciones.

    • Asigna funciones a cada iteración

  • Colaborar : desarrollo de funciones concurrentes

    • Colaboración para equipos distribuidos.

    • Colaboración para proyectos más pequeños.

    • Colaboración para proyectos más grandes.

  • Aprender - Revisión de calidad

    • Calidad de resultados desde la perspectiva del cliente.

    • Calidad de resultados desde una perspectiva técnica.

    • El funcionamiento del equipo de entrega y los miembros del equipo de prácticas están utilizando

    • El estado del proyecto.

Especular - Iniciación y planificación

En el desarrollo de software adaptativo, la fase especulativa tiene dos actividades:

  • Iniciación
  • Planificación

Speculate tiene cinco prácticas que pueden ejecutarse repetidamente durante la fase de inicio y planificación. Ellos son

  • Iniciacion del proyecto
  • Establecer un calendario para todo el proyecto.
  • Decida el número de iteraciones y asigne un cuadro de tiempo a cada una.
  • Desarrolle un tema u objetivo para cada una de las iteraciones.
  • Asigna funciones a cada iteración

Iniciacion de proyecto

La iniciación del proyecto implica:

  • Establecer la misión y los objetivos del proyecto.
  • Comprender las restricciones
  • Establecimiento de la organización del proyecto.
  • Identificación y descripción de los requisitos.
  • Hacer estimaciones iniciales de tamaño y alcance
  • Identificar los riesgos clave del proyecto.

Los datos de inicio del proyecto deben recopilarse en una sesión preliminar de JAD, considerando la velocidad como el aspecto principal. La iniciación se puede completar en un esfuerzo concentrado de dos a cinco días para proyectos pequeños o medianos, o en un esfuerzo de dos a tres semanas para proyectos más grandes.

Durante las sesiones de JAD, los requisitos se recopilan con suficiente detalle para identificar características y establecer una visión general del objeto, los datos u otro modelo arquitectónico.

Establecer un cuadro de tiempo para todo el proyecto

Se debe establecer el cronograma para todo el proyecto, en función del alcance, los requisitos del conjunto de características, las estimaciones y la disponibilidad de recursos que resultan del trabajo de inicio del proyecto.

Como saben, especular no abandona la estimación, pero solo significa aceptar que las estimaciones pueden salir mal.

Iterations y Time-box

Decida el número de iteraciones y las longitudes de iteración individuales en función del alcance general del proyecto y el grado de incertidumbre.

Para una aplicación pequeña a mediana -

  • Las iteraciones generalmente varían de cuatro a ocho semanas.
  • Algunos proyectos funcionan mejor con iteraciones de dos semanas.
  • Algunos proyectos pueden requerir más de ocho semanas.

Elija el tiempo, según lo que funcione para usted. Una vez que decida el número de iteraciones y la duración de cada una de ellas, asigne un cronograma a cada una de las iteraciones.

Desarrollar un tema u objetivo

Los miembros del equipo deben desarrollar un tema u objetivo para cada iteración. Esto es algo similar al Objetivo Sprint en Scrum. Cada iteración debe ofrecer un conjunto de características que puedan demostrar la funcionalidad del producto haciendo que el producto sea visible para el cliente para permitir su revisión y comentarios.

Dentro de las iteraciones, las compilaciones deben ofrecer características de trabajo de forma preferentemente diaria que permitan el proceso de integración y hagan que el producto sea visible para el equipo de desarrollo. Las pruebas deberían ser una parte continua e integral del desarrollo de características. No debe retrasarse hasta el final del proyecto.

Asignar características

Los desarrolladores y los clientes deben asignar juntos características a cada iteración. El criterio más importante para esta asignación de características es que cada iteración debe entregar un conjunto visible de características con una funcionalidad considerable para el cliente.

Durante la asignación de características a las iteraciones:

  • El equipo de desarrollo debe proponer estimaciones de características, riesgos y dependencias y proporcionarlas al cliente.

  • Los clientes deben decidir sobre la priorización de características, utilizando la información proporcionada por el equipo de desarrollo.

Por lo tanto, la planificación de iteraciones se basa en características y se realiza en equipo con desarrolladores y clientes. La experiencia ha demostrado que este tipo de planificación proporciona una mejor comprensión del proyecto que una planificación basada en tareas por parte del gerente del proyecto. Además, la planificación basada en características refleja la singularidad de cada proyecto.

Colaborar ─ Desarrollo de funciones concurrentes

Durante la fase de colaboración, el foco está en el desarrollo. La fase de colaboración tiene dos actividades:

  • El equipo de desarrollo colabora y entrega software de trabajo.

  • Los gerentes de proyecto facilitan la colaboración y las actividades de desarrollo concurrentes.

La colaboración es un acto de creación compartida que abarca el equipo de desarrollo, los clientes y los gerentes. La creación compartida es fomentada por la confianza y el respeto.

Los equipos deberían colaborar en -

  • Problemas técnicos
  • Requisitos comerciales
  • Toma de decisiones rápida

Las siguientes son las prácticas relevantes para la fase de colaboración en el desarrollo de software adaptativo:

  • Colaboración para equipos distribuidos.
  • Colaboración para proyectos más pequeños.
  • Colaboración para proyectos más grandes.

Colaboración para equipos distribuidos

En los proyectos que involucran equipos distribuidos, se debe considerar lo siguiente:

  • Diversos socios de la alianza
  • Conocimiento de base amplia
  • La forma en que las personas interactúan
  • La forma en que manejan las interdependencias

Colaboración para proyectos más pequeños

En los proyectos más pequeños, cuando los miembros del equipo trabajan en proximidad física, se debe alentar la colaboración con los chats informales en los pasillos y los garabatos en la pizarra, ya que se considera que esto es efectivo.

Colaboración para proyectos más grandes

Los proyectos más grandes requieren prácticas adicionales, herramientas de colaboración e interacción del gerente de proyecto y deben organizarse de forma contextual.

Aprender - Revisión de calidad

El desarrollo de software adaptativo fomenta el concepto de 'Experimentar y aprender'.

Aprender de los errores y la experimentación requiere que los miembros del equipo compartan el código y los artefactos parcialmente completados con anticipación, para:

  • Encuentra errores
  • Aprende de ellos
  • Reduzca el retrabajo encontrando pequeños problemas antes de que se conviertan en grandes.

Al final de cada iteración de desarrollo, hay cuatro categorías generales de cosas que aprender:

  • Calidad de resultados desde la perspectiva del cliente.
  • Calidad de resultados desde una perspectiva técnica.
  • El funcionamiento del equipo de entrega y el equipo de prácticas.
  • El estado del proyecto.

Calidad del resultado desde la perspectiva del cliente

En los proyectos de desarrollo de software adaptativo, obtener comentarios de los clientes es la primera prioridad. La práctica recomendada para esto es un grupo de enfoque al cliente. Estas sesiones están diseñadas para explorar un modelo de trabajo de la aplicación y registrar las solicitudes de cambio de los clientes.

Las sesiones de grupos focales de clientes son sesiones facilitadas, similares a las sesiones jad, pero en lugar de generar requisitos o definir planes de proyecto, están diseñados para revisar la aplicación en sí. Los clientes brindan comentarios sobre el software que funciona como resultado de una iteración.

Calidad del resultado desde una perspectiva técnica

En los proyectos de desarrollo de software adaptativo, se debe dar importancia a la revisión periódica de los artefactos técnicos. Las revisiones de código deben hacerse de forma continua. Las revisiones de otros artefactos técnicos, como la arquitectura técnica, se pueden realizar semanalmente o al final de una iteración.

En los proyectos de desarrollo de software adaptativo, el equipo debe monitorear su propio rendimiento periódicamente. Las retrospectivas alientan a los equipos a aprender sobre sí mismos y su trabajo, juntos como un equipo.

Las retrospectivas de finalización de iteración facilitan la autoevaluación periódica del rendimiento del equipo, como por ejemplo:

  • Determina lo que no funciona.
  • Lo que el equipo necesita hacer más.
  • Lo que el equipo necesita hacer menos.

El estado del proyecto

La revisión del estado del proyecto ayuda a planificar más trabajo. En los proyectos de desarrollo de software adaptativo, determinar el estado del proyecto es un enfoque basado en características, el final de cada iteración marcado por características completadas que dan como resultado un software que funciona.

La revisión del estado del proyecto debe incluir:

  • Donde esta el proyecto
  • ¿Dónde está el proyecto versus los planes?
  • ¿Dónde debe estar el proyecto?

Como los planes en los proyectos de desarrollo de software adaptativo son especulativos, más que la pregunta 2 anterior, la pregunta 3 es importante. Es decir, el equipo del proyecto y los clientes deben preguntarse continuamente: "¿Qué hemos aprendido hasta ahora y cambia nuestra perspectiva de hacia dónde debemos ir?"