Développement de logiciels adaptatifs - Pratiques

Les pratiques de développement logiciel adaptatif sont motivées par la croyance en l'adaptation continue, le cycle de vie étant équipé pour accepter le changement continu comme norme.

Le cycle de vie du développement de logiciels adaptatifs est dédié à -

  • Apprentissage continu
  • Changer d'orientation
  • Réévaluation
  • Regard vers un avenir incertain
  • Collaboration intense entre les développeurs, la direction et les clients

SDLC adaptatif

Le développement de logiciels adaptatifs combine RAD avec les meilleures pratiques d'ingénierie logicielle, telles que -

  • Lancement du projet.
  • Planification du cycle adaptatif.
  • Ingénierie de composants simultanés.
  • Examen de la qualité.
  • QA final et sortie.

Les pratiques de développement de logiciels adaptatifs peuvent être illustrées comme suit -

Boucle d'apprentissage des pratiques

Comme illustré ci-dessus, les pratiques de développement logiciel adaptatif sont réparties sur les trois phases comme suit -

  • Spéculer - Initiation et planification

    • Lancement du projet

    • Établir un calendrier pour l'ensemble du projet

    • Décidez du nombre d'itérations et attribuez une case de temps à chacune

    • Développer un thème ou un objectif pour chacune des itérations

    • Attribuer des fonctionnalités à chaque itération

  • Collaborer - Développement de fonctionnalités simultanées

    • Collaboration pour des équipes réparties

    • Collaboration pour des projets plus petits

    • Collaboration pour des projets plus importants

  • Learn - Quality Review

    • Qualité des résultats du point de vue du client

    • Qualité des résultats d'un point de vue technique

    • Le fonctionnement de l'équipe de livraison et les membres de l'équipe des pratiques utilisent

    • Le statut du projet

Spéculer - Initiation et planification

Dans le développement de logiciels adaptatifs, la phase de spéculation a deux activités -

  • Initiation
  • Planification

Spéculer a cinq pratiques qui peuvent être exécutées de manière répétitive pendant la phase d'initiation et de planification. Ce sont -

  • Lancement du projet
  • Établir un calendrier pour l'ensemble du projet
  • Décidez du nombre d'itérations et attribuez une case de temps à chacune
  • Développer un thème ou un objectif pour chacune des itérations
  • Attribuer des fonctionnalités à chaque itération

Lancement du projet

L'initiation du projet implique -

  • Fixer la mission et les objectifs du projet
  • Comprendre les contraintes
  • Mise en place de l'organisation du projet
  • Identification et définition des exigences
  • Faire des estimations initiales de la taille et de la portée
  • Identifier les principaux risques du projet

Les données de lancement du projet doivent être rassemblées lors d'une session JAD préliminaire, considérant la vitesse comme l'aspect principal. L'initiation peut être complétée en un effort concentré de deux à cinq jours pour des projets de petite à moyenne taille, ou de deux à trois semaines d'effort pour des projets plus importants.

Pendant les sessions JAD, les exigences sont rassemblées avec suffisamment de détails pour identifier les fonctionnalités et établir une vue d'ensemble de l'objet, des données ou d'un autre modèle architectural.

Établir un calendrier pour l'ensemble du projet

Le délai pour l'ensemble du projet doit être établi, en fonction de la portée, des exigences de l'ensemble de fonctionnalités, des estimations et de la disponibilité des ressources résultant du travail de lancement du projet.

Comme vous le savez, spéculer n'abandonne pas l'estimation, mais cela signifie simplement accepter que les estimations peuvent mal tourner.

Itérations et Time-box

Décidez du nombre d'itérations et des longueurs d'itérations individuelles en fonction de la portée globale du projet et du degré d'incertitude.

Pour une application de petite à moyenne taille -

  • Les itérations varient généralement de quatre à huit semaines.
  • Certains projets fonctionnent mieux avec des itérations de deux semaines.
  • Certains projets peuvent nécessiter plus de huit semaines.

Choisissez l'heure, en fonction de ce qui vous convient. Une fois que vous avez décidé du nombre d'itérations et de la longueur de chacune des itérations, affectez un calendrier à chacune des itérations.

Développer un thème ou un objectif

Les membres de l'équipe doivent développer un thème ou un objectif pour chaque itération. C'est quelque chose de similaire à l'objectif de sprint dans Scrum. Chaque itération doit fournir un ensemble de fonctionnalités qui peuvent démontrer la fonctionnalité du produit, rendant le produit visible pour le client afin de permettre la révision et les commentaires.

Au sein des itérations, les versions doivent fournir des fonctionnalités fonctionnelles de préférence quotidiennement, permettant un processus d'intégration et rendant le produit visible pour l'équipe de développement. Les tests doivent faire partie intégrante et continue du développement des fonctionnalités. Il ne doit pas être retardé jusqu'à la fin du projet.

Attribuer des fonctionnalités

Les développeurs et les clients doivent ensemble attribuer des fonctionnalités à chaque itération. Le critère le plus important pour cette attribution de fonctionnalités est que chaque itération doit fournir au client un ensemble de fonctionnalités visibles avec des fonctionnalités considérables.

Lors de l'affectation des fonctionnalités aux itérations -

  • L'équipe de développement doit proposer les estimations, les risques et les dépendances des fonctionnalités et les fournir au client.

  • Les clients doivent décider de la priorité des fonctionnalités, en utilisant les informations fournies par l'équipe de développement.

Ainsi, la planification des itérations est basée sur les fonctionnalités et se fait en équipe avec les développeurs et les clients. L'expérience a montré que ce type de planification permet une meilleure compréhension du projet qu'une planification basée sur les tâches par le chef de projet. De plus, la planification basée sur les fonctionnalités reflète le caractère unique de chaque projet.

Collaborer ─ Développement de fonctionnalités simultanées

Pendant la phase de collaboration, l'accent est mis sur le développement. La phase de collaboration comporte deux activités -

  • L'équipe de développement collabore et fournit des logiciels fonctionnels.

  • Les chefs de projet facilitent la collaboration et les activités de développement simultanées.

La collaboration est un acte de création partagée qui englobe l'équipe de développement, les clients et les managers. La création partagée est favorisée par la confiance et le respect.

Les équipes devraient collaborer sur -

  • Problèmes techniques
  • Besoins de l'entreprise
  • Prise de décision rapide

Voici les pratiques pertinentes pour la phase de collaboration dans le développement de logiciels adaptatifs -

  • Collaboration pour des équipes réparties
  • Collaboration pour des projets plus petits
  • Collaboration pour des projets plus importants

Collaboration pour les équipes distribuées

Dans les projets impliquant des équipes réparties, les éléments suivants doivent être pris en compte:

  • Différents partenaires d'alliance
  • Connaissance large
  • La façon dont les gens interagissent
  • La façon dont ils gèrent les interdépendances

Collaboration pour les petits projets

Dans les petits projets, lorsque les membres de l'équipe travaillent à proximité physique, la collaboration avec les discussions informelles dans les couloirs et le gribouillage du tableau blanc devrait être encouragée, car cela s'avère efficace.

Collaboration pour des projets plus importants

Les projets plus importants nécessitent des pratiques supplémentaires, des outils de collaboration et une interaction avec le chef de projet et doivent être organisés en fonction du contexte.

Learn - Quality Review

Le développement de logiciels adaptatifs encourage le concept «d'expérimenter et d'apprendre».

Pour tirer parti des erreurs et de l'expérimentation, les membres de l'équipe doivent partager tôt le code et les artefacts partiellement terminés afin de -

  • Trouver des erreurs
  • Apprenez d'eux
  • Réduisez les reprises en trouvant de petits problèmes avant qu'ils ne deviennent de gros problèmes

À la fin de chaque itération de développement, il y a quatre catégories générales de choses à apprendre -

  • Qualité des résultats du point de vue du client
  • Qualité des résultats d'un point de vue technique
  • Le fonctionnement de l'équipe de livraison et de l'équipe des pratiques
  • Le statut du projet

Qualité des résultats du point de vue du client

Dans les projets de développement de logiciels adaptatifs, obtenir la rétroaction des clients est la première priorité. La pratique recommandée pour cela est un groupe de discussion avec les clients. Ces sessions sont conçues pour explorer un modèle de travail de l'application et enregistrer les demandes de changement des clients.

Les sessions de groupes de discussion avec les clients sont des sessions facilitées, similaires aux sessions jad, mais plutôt que de générer des exigences ou de définir des plans de projet, elles sont conçues pour examiner l'application elle-même. Les clients fournissent des commentaires sur le logiciel de travail résultant d'une itération.

Qualité des résultats d'un point de vue technique

Dans les projets de développement de logiciels adaptatifs, un examen périodique des artefacts techniques doit être accordé de l'importance. Les révisions de code devraient être effectuées de façon continue. Des examens d'autres artefacts techniques, tels que l'architecture technique, peuvent être effectués chaque semaine ou à la fin d'une itération.

Dans les projets de développement de logiciels adaptatifs, l'équipe doit surveiller périodiquement ses propres performances. Les rétrospectives encouragent les équipes à se connaître et à découvrir leur travail, en équipe.

Les rétrospectives de fin d'itération facilitent l'auto-évaluation périodique des performances de l'équipe telles que -

  • Déterminez ce qui ne fonctionne pas.
  • Ce que l'équipe doit faire de plus.
  • Ce que l'équipe doit faire moins.

L'état du projet

L'examen de l'état du projet aide à planifier les travaux futurs. Dans les projets de développement de logiciels adaptatifs, la détermination de l'état du projet est une approche basée sur les fonctionnalités, la fin de chaque itération étant marquée par des fonctionnalités terminées résultant en un logiciel fonctionnel.

L'examen de l'état du projet devrait comprendre:

  • Où est le projet?
  • Où est le projet par rapport aux plans?
  • Où devrait être le projet?

Comme les plans des projets de développement de logiciels adaptatifs sont spéculatifs, plus que la question 2 ci-dessus, la question 3 est importante. C'est-à-dire que l'équipe de projet et les clients doivent continuellement se demander: "Qu'avons-nous appris jusqu'à présent et cela change-t-il notre perspective sur où nous devons aller?"