Desarrollo de software adaptativo: prácticas

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

El ciclo de vida del desarrollo de software adaptativo está dedicado a:

  • Aprendizaje continuo
  • Cambiar de orientación
  • Re-evaluation
  • Mirando hacia un futuro incierto
  • Intensa colaboración entre desarrolladores, administración y clientes

SDLC adaptativo

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

  • Inicio del proyecto.
  • Planificación del ciclo adaptativo.
  • Ingeniería de componentes concurrente.
  • 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:

Como se ilustra anteriormente, las prácticas de desarrollo de software adaptativo se distribuyen en las tres fases de la siguiente manera:

  • Especular - Iniciación y planificación

    • Iniciación del proyecto

    • Establecimiento de una caja de tiempo para todo el proyecto

    • Decidir el número de iteraciones y asignar un cuadro de tiempo a cada una

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

    • Asignar características a cada iteración

  • Collaborate - Desarrollo de funciones concurrentes

    • Colaboración para equipos distribuidos

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

    • Colaboración para proyectos más grandes

  • Learn - Revisión de calidad

    • Calidad de resultado desde la perspectiva del cliente

    • Calidad de resultado 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 de especular tiene dos actividades:

  • Initiation
  • Planning

Speculate tiene cinco prácticas que se pueden ejecutar de forma repetitiva durante la fase de inicio y planificación. Ellos son -

  • Inicio del proyecto
  • Establecimiento de una caja de tiempo para todo el proyecto
  • Decidir el número de iteraciones y asignar un cuadro de tiempo a cada una
  • Desarrollar un tema u objetivo para cada una de las iteraciones.
  • Asignar características a cada iteración

Iniciación del proyecto

La iniciación del proyecto implica:

  • Establecer la misión y los objetivos del proyecto
  • Entender las limitaciones
  • Establecer la organización del proyecto
  • Identificación y descripción de 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 JAD preliminar, 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 a medianos, o 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 descripción general del objeto, los datos u otro modelo arquitectónico.

Establecimiento de una casilla de tiempo para todo el proyecto

Se debe establecer la casilla de tiempo 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 sabe, la especulación no abandona la estimación, sino que solo significa aceptar que las estimaciones pueden salir mal.

Iteraciones y caja de tiempo

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

Para una aplicación de tamaño pequeño a mediano:

  • Las iteraciones suelen variar 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 las iteraciones, asigne un programa 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 Sprint Goal 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 la revisión y la retroalimentación.

Dentro de las iteraciones, las compilaciones deben ofrecer funciones de trabajo preferiblemente a diario, permitiendo el proceso de integración y haciendo que el producto sea visible para el equipo de desarrollo. Las pruebas deben ser una parte integral y continua del desarrollo de funciones. No debe retrasarse hasta el final del proyecto.

Asignar funciones

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

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

  • El equipo de desarrollo debe generar estimaciones de características, riesgos y dependencias y proporcionárselas al cliente.

  • Los clientes deben decidir la priorización de las funciones, utilizando la información proporcionada por el equipo de desarrollo.

Por lo tanto, la planificación de la iteración se basa en funciones 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 director 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, la atención se centra en el desarrollo. La fase de colaboración tiene dos actividades:

  • El equipo de Desarrollo colabora y entrega software funcional.

  • Los directores de proyecto facilitan la colaboración y las actividades de desarrollo simultáneas.

La colaboración es un acto de creación compartida que engloba al equipo de desarrollo, los clientes y los responsables. La creación compartida se fomenta mediante la confianza y el respeto.

Los equipos deben colaborar en:

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

A continuación se muestran 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 gestionan 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 fomentar la colaboración con charlas informales en los pasillos y 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 sobre una base 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, con el fin de:

  • 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 resultado desde la perspectiva del cliente
  • Calidad de resultado desde una perspectiva técnica
  • El funcionamiento del equipo de entrega y del equipo de prácticas.
  • El estado del proyecto

Calidad del resultado desde la perspectiva del cliente

En los proyectos de desarrollo de software adaptativo, la primera prioridad es obtener comentarios de los clientes. La práctica recomendada para esto es un grupo de enfoque del 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 de enfoque de clientes son sesiones facilitadas, similares a las sesiones jad, pero en lugar de generar requisitos o definir planes de proyecto, están diseñadas para revisar la aplicación en sí. Los clientes brindan comentarios sobre el software de trabajo resultante 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 realizarse 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 desempeño periódicamente. Las retrospectivas animan a los equipos a aprender sobre sí mismos y su trabajo, juntos como equipo.

Las retrospectivas del final de la iteración facilitan la autoevaluación periódica del desempeño del equipo, como:

  • Determine qué no está funcionando.
  • 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 el trabajo futuro. En los proyectos de desarrollo de software adaptativo, la determinación del estado del proyecto es un enfoque basado en características, el final de cada iteración marcado por características completadas que resultan en software funcional.

La revisión del estado del proyecto debe incluir:

  • ¿Dónde está el proyecto?
  • ¿Dónde está el proyecto frente a los planes?
  • ¿Dónde debería estar el proyecto?

Como los planes de 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? ¿Cambia nuestra perspectiva sobre a dónde debemos ir?".