Développement S / W adaptatif - Guide rapide

Développement adaptatif de S / W - Introduction

Qu'est-ce que l'Agile?

En termes littéraires, le mot «agile» signifie quelqu'un qui peut se déplacer rapidement et facilement ou quelqu'un qui peut penser et agir rapidement et clairement. En affaires, «agile» est utilisé pour décrire les façons de planifier et de faire un travail dans lequel il est entendu que faire des changements au besoin est une partie importante du travail. L '«agilité» des entreprises signifie qu'une entreprise est toujours en mesure de tenir compte des changements du marché.

Dans le développement de logiciels, le terme «agile» est adapté pour signifier «la capacité de répondre aux changements - changements par rapport aux exigences, à la technologie et aux personnes».

Manifeste Agile

Le Manifeste Agile a été publié par une équipe de développeurs de logiciels en 2001, soulignant l'importance de l'équipe de développement, répondant aux exigences changeantes et à l'implication des clients.

Le Manifeste Agile est -

Nous découvrons de meilleures façons de développer des logiciels en le faisant et en aidant les autres à le faire. Grâce à ce travail, nous avons pris de la valeur -

  • Individus et interactions sur les processus et les outils.
  • Logiciel de travail sur une documentation complète.
  • Collaboration client sur négociation de contrat.
  • Répondre au changement au sujet d'un plan.

Autrement dit, bien qu'il y ait de la valeur dans les éléments de droite, nous valorisons davantage les éléments de gauche.

Caractéristiques de l'agilité

Voici les caractéristiques de l'agilité -

  • L'agilité dans le développement logiciel agile se concentre sur la culture de toute l'équipe avec des équipes multidisciplinaires et interfonctionnelles qui sont responsabilisées et autogérées.

  • Il favorise une responsabilité et une reddition de comptes partagées.

  • Facilite une communication efficace et une collaboration continue.

  • L'approche de toute l'équipe évite les retards et les temps d'attente.

  • Des livraisons fréquentes et continues garantissent une rétroaction rapide qui, à son tour, permet à l'équipe de s'aligner sur les exigences.

  • La collaboration facilite la combinaison de différentes perspectives en temps opportun dans la mise en œuvre, la correction des défauts et la prise en compte des changements.

  • Les progrès sont constants, durables et prévisibles, mettant l'accent sur la transparence.

Méthodologies Agiles

Les premières implémentations des méthodes Agile incluent Rational Unified Process, Scrum, Crystal Clear, Extreme Programming, Adaptive Software Development, Feature Driven Development et Dynamic Systems Development Method (DSDM). Celles-ci sont désormais appelées collectivement les méthodologies Agile, après la publication du manifeste Agile en 2001.

Dans ce didacticiel, nous apprendrons la méthodologie Agile - Développement de logiciels adaptatifs .

Qu'est-ce que le développement de logiciels adaptatifs?

Le développement de logiciels adaptatifs est une évolution vers des pratiques adaptatives, laissant les pratiques déterministes dans le contexte de systèmes complexes et d'environnements complexes. Le développement de logiciels adaptatifs se concentre sur la collaboration et l'apprentissage en tant que technique pour construire des systèmes complexes. Il est issu des meilleures pratiques de développement rapide d'applications (RAD) et de cycles de vie évolutifs. Le développement de logiciels adaptatifs a ensuite été étendu pour inclure des approches adaptatives pour la gestion, la spéculation remplaçant la planification.

Cycle de vie ASD

Jim Highsmith a publié un livre sur le développement de logiciels adaptatifs en 2000. Selon les mots de Highsmith -

«Le développement logiciel adaptatif est cyclique comme le modèle évolutif, avec les noms de phase spéculer, collaborer, apprendre reflétant le domaine imprévisible de systèmes de plus en plus complexes. Le développement adaptatif va plus loin que son héritage évolutif de deux manières clés. Premièrement, il remplace explicitement le déterminisme par l'émergence. Deuxièmement, cela va au-delà d'un changement de cycle de vie pour un changement plus profond dans le style de gestion. »

Modèles SDLC - Evolution

Un modèle de cycle de vie de développement logiciel (SDLC) est un cadre qui décrit les activités effectuées à chaque étape d'un projet de développement logiciel.

Dans un cycle de vie de développement logiciel, les activités sont exécutées en cinq phases -

  • Collecte des exigences - Les exigences pour un logiciel à développer sont rassemblées. Ces exigences seront rédigées dans une langue comprise par le client / utilisateur. Une terminologie spécifique au domaine est recommandée.

  • Analyse - Les exigences rassemblées sont analysées du point de vue de la mise en œuvre et les spécifications du logiciel sont écrites pour couvrir à la fois les exigences fonctionnelles et les exigences non fonctionnelles.

  • Conception - Cette phase consiste à arriver à l'architecture logicielle et aux spécificités d'implémentation en fonction de la technologie choisie pour le développement.

  • Construction - Dans cette phase, le code est développé, testé en unité, intégré, testé en intégration et la construction est produite.

  • Test - Le test fonctionnel du logiciel intégré est effectué au cours de cette phase. Cela comprend également le test des exigences non fonctionnelles.

Il existe deux approches pour effectuer ces activités -

  • Prescriptive - Les modèles SDLC qui vous fourniront des moyens d'effectuer les activités d'une manière prescrite telle que définie par le cadre.

  • Adaptatif - Les modèles SDLC qui vous donneront de la flexibilité dans l'exécution des activités, avec certaines règles qui doivent être suivies. Les méthodes agiles suivent principalement cette approche, chacune ayant ses règles. Cependant, suivre une approche adaptative ou agile ne signifie pas que le logiciel est développé sans suivre aucune discipline. Cela conduirait au chaos.

Vous devez comprendre que nous ne pouvons pas dire qu'un modèle SDLC spécifique est bon ou mauvais. Chacun d'eux a ses propres forces et faiblesses et convient donc dans certains contextes.

Lorsque vous choisissez un modèle SDLC pour votre projet, vous devez comprendre -

  • Contexte de votre organisation
  • Votre contexte technologique
  • La composition de votre équipe
  • Votre contexte client

Par exemple, si le développement du logiciel est prévisible, vous pouvez utiliser une approche normative. D'un autre côté, si le développement du logiciel est imprévisible, c'est-à-dire que les exigences ne sont pas entièrement connues, ou que l'équipe de développement n'a pas été préalablement exposée au domaine ou à la technologie actuelle, etc., alors l'approche adaptative est le meilleur choix.

Dans les sections suivantes, vous comprendrez les modèles SDLC les plus répandus qui ont évolué lors de l'exécution de projets de développement logiciel dans l'industrie. Vous apprendrez également à connaître les forces et les faiblesses de chacun d'entre eux et dans quels contextes ils conviennent.

SDLC - Modèle en cascade

Le modèle Waterfall est un modèle SDLC classique largement connu, compris et couramment utilisé. Il a été introduit par Royce en 1970 et est toujours utilisé comme une approche commune pour le développement de logiciels dans diverses organisations de l'industrie.

Dans le modèle Waterfall, chaque phase du cycle de vie ne peut démarrer qu'après la fin de la phase de cycle de vie précédente. Il s'agit donc d'un modèle linéaire sans boucles de rétroaction.

Cycle de vie de la cascade

Modèle de cascade - Forces

Les points forts du modèle Waterfall sont -

  • Facile à comprendre, facile à utiliser.
  • Fournit une structure à une équipe de développement inexpérimentée.
  • Les jalons sont bien compris.
  • Définit la stabilité des exigences.
  • Idéal pour le contrôle de gestion (planification, suivi, reporting).
  • Fonctionne bien lorsque la qualité est plus importante que le coût ou le calendrier.

Modèle de cascade - Faiblesses

Les faiblesses ou les inconvénients du modèle Waterfall sont -

  • Idéalisé - Il ne correspond pas bien à la réalité.

  • Irréaliste - ne peut pas s'attendre à des exigences précises au début du projet.

  • Ne reflète pas la nature itérative du développement exploratoire qui est plus courante.

  • Difficile et coûteux de faire des changements.

  • Le logiciel n'est livré qu'à la fin du projet. Pour cette raison -

    • Retarde la découverte de défauts graves.

    • Possibilité de livraison d'exigences obsolètes.

  • Frais généraux de gestion importants, qui peuvent être coûteux pour les petites équipes et les petits projets.

  • Nécessite des ressources expérimentées à chaque phase - analystes, concepteurs, développeurs, testeurs.

  • Les tests ne commencent qu'une fois le développement terminé et les testeurs ne sont impliqués dans aucune des phases précédentes.

  • L'expertise des équipes transverses n'est pas partagée car chaque phase est exécutée en silos.

Quand utiliser le modèle Waterfall?

Vous pouvez utiliser le modèle Waterfall si -

  • Les exigences sont très bien connues.

  • La définition du produit est stable.

  • La technologie est bien comprise.

  • Nouvelle version d'un produit existant.

  • Portage d'un produit existant vers une nouvelle plateforme.

  • Grande organisation avec des équipes structurées et interfonctionnelles.

  • Les canaux de communication sont bien établis au sein de l'organisation et avec le client également.

Modèle de prototypage évolutif

Dans le développement de logiciels utilisant le modèle de prototypage évolutif, les développeurs construisent un prototype pendant la phase des exigences. Les utilisateurs finaux évaluent ensuite le prototype et donnent leur avis. Les commentaires peuvent être des corrections du prototype ou des fonctionnalités supplémentaires. Sur la base des commentaires, les développeurs affinent davantage le prototype.

Ainsi, le produit évolue à travers Prototype → Feedback → Refined Prototype Cycles et donc le nom Evolutionary Prototyping. Lorsque l'utilisateur est satisfait de la fonctionnalité et du fonctionnement du produit, le code prototype est mis aux normes requises pour la livraison finale du produit.

Livraison du produit final

Modèle de prototypage évolutif - Forces

Les forces ou les avantages d'un modèle de prototypage évolutif sont -

  • Les clients / utilisateurs finaux peuvent visualiser les exigences du système lorsqu'ils sont rassemblés en regardant le prototype.

  • Les développeurs apprennent des clients et donc aucune ambiguïté concernant le domaine ou l'environnement de production.

  • Permet une conception et un développement flexibles.

  • L'interaction avec le prototype stimule la prise de conscience des fonctionnalités supplémentaires nécessaires.

  • Les exigences inattendues et les modifications des exigences sont facilement prises en compte.

  • Des signes de progrès réguliers et visibles se produisent.

  • Livraison d'un produit final précis et maintenable.

Modèle de prototypage évolutif - Faiblesses

Les faiblesses ou les inconvénients du modèle de prototypage évolutif sont les suivants -

  • Tendance à abandonner le développement structuré dans le développement code-and-fix, bien que ce ne soit pas ce qui est prescrit par le modèle.

  • Ce modèle a reçu une mauvaise réputation pour les méthodes rapides et sales.

  • La maintenabilité globale peut éventuellement être négligée.

  • Le client peut éventuellement demander la livraison du prototype en tant que final, sans donner aux développeurs la possibilité d'exécuter la dernière étape, à savoir la standardisation du produit final.

  • Le projet peut se poursuivre indéfiniment (avec un fluage de portée continu) et la direction peut ne pas l'apprécier.

Quand utiliser le modèle de prototypage évolutif?

Vous pouvez utiliser le modèle de prototypage évolutif -

  • Lorsque les exigences sont instables ou doivent être clarifiées
  • Comme étape de clarification des exigences d'un modèle en cascade
  • Développer des interfaces utilisateurs
  • Pour des manifestations de courte durée
  • Pour un développement nouveau ou original
  • Pour la mise en œuvre d'une nouvelle technologie

SDLC - Modèle incrémental itératif

Dans un modèle incrémentiel itératif, au départ, une implémentation partielle d'un système total est construite de sorte qu'il sera dans un état livrable. Une fonctionnalité accrue est ajoutée. Les défauts, le cas échéant, de la livraison précédente sont corrigés et le produit de travail est livré. Le processus est répété jusqu'à ce que le développement complet du produit soit terminé. Les répétitions de ces processus sont appelées itérations. À la fin de chaque itération, un incrément de produit est livré.

Itérations

Modèle incrémental itératif - Forces

Les avantages ou les points forts du modèle incrémentiel itératif sont:

  • Vous pouvez d'abord développer des exigences prioritaires.

  • La livraison initiale du produit est plus rapide.

  • Les clients obtiennent rapidement des fonctionnalités importantes.

  • Réduit le coût de livraison initial.

  • Chaque version est un incrément de produit, de sorte que le client aura toujours un produit fonctionnel à portée de main.

  • Le client peut fournir des commentaires sur chaque incrément de produit, évitant ainsi les surprises à la fin du développement.

  • Les modifications des exigences peuvent être facilement prises en compte.

Modèle incrémental itératif - Faiblesses

Les inconvénients du modèle incrémentiel itératif sont -

  • Nécessite une planification efficace des itérations.

  • Nécessite une conception efficace pour garantir l'inclusion des fonctionnalités requises et prévoir des modifications ultérieurement.

  • Nécessite une définition précoce d'un système complet et entièrement fonctionnel pour permettre la définition des incréments.

  • Des interfaces de module bien définies sont nécessaires, car certaines sont développées bien avant que d'autres soient développées.

  • Le coût total du système complet n'est pas inférieur.

Quand utiliser le modèle incrémentiel itératif?

Le modèle incrémentiel itératif peut être utilisé lorsque -

  • La plupart des exigences sont connues dès le départ mais devraient évoluer avec le temps.

  • Les exigences sont priorisées.

  • Il est nécessaire d'obtenir rapidement les fonctionnalités de base.

  • Un projet a de longs calendriers de développement.

  • Un projet a une nouvelle technologie.

  • Le domaine est nouveau pour l'équipe.

SDLC - Modèle de développement rapide d'applications

Le modèle de développement rapide d'applications (RAD) comprend les phases suivantes -

  • Phase de planification des exigences - Dans la phase de planification des exigences, un atelier doit être organisé pour discuter des problèmes commerciaux de manière structurée.

  • Phase de description de l'utilisateur - Dans la phase de description de l'utilisateur, des outils automatisés sont utilisés pour capturer les informations des utilisateurs.

  • Phase de construction - Dans la phase de construction, des outils de productivité, tels que des générateurs de code, des générateurs d'écran, etc. sont utilisés à l'intérieur d'une boîte de temps, avec une approche «Do until Done».

  • Phase de coupure - Dans la phase de coupure, l'installation du système, les tests d'acceptation des utilisateurs et la formation des utilisateurs sont effectués.

Phases RAD

Modèle de développement rapide d'applications - Forces

Les avantages ou les points forts du modèle de développement rapide d'applications sont les suivants:

  • La réduction du temps de cycle et l'amélioration de la productivité avec moins de membres de l'équipe signifieraient des coûts inférieurs.

  • L'implication du client tout au long du cycle complet minimise le risque de ne pas atteindre la satisfaction du client et la valeur commerciale.

  • Le focus se déplace vers le code dans un mode ce que vous voyez est ce que vous obtenez (WYSIWYG). Cela apporte de la clarté sur ce qui est construit est la bonne chose.

  • Utilise des concepts de modélisation pour capturer des informations sur l'entreprise, les données et les processus.

Modèle de développement rapide d'applications - Faiblesses

Les inconvénients ou les points forts du modèle de développement rapide d'applications sont les suivants -

  • Un processus de développement accéléré doit donner des réponses rapides à l'utilisateur.

  • Risque de ne jamais atteindre la fermeture.

  • Difficile à utiliser avec les anciens systèmes.

  • Les développeurs et les clients doivent être engagés dans des activités à tir rapide dans un délai abrégé.

Quand utiliser le modèle de développement rapide d'applications?

Le modèle de développement rapide d'applications peut être utilisé lorsque -

  • L'utilisateur peut être impliqué tout au long du cycle de vie.
  • Le projet peut être limité dans le temps.
  • La fonctionnalité peut être fournie par incréments.

Bien que les atouts du modèle de développement rapide d'applications soient appréciés, il est utilisé avec parcimonie dans l'industrie.

SDLC - Modèle en spirale

Le modèle en spirale ajoute l'analyse des risques et le prototypage RAD au modèle Waterfall. Chaque cycle implique la même séquence d'étapes que le modèle Waterfall.

Modèle en spirale

Le modèle en spirale a quatre quadrants. Laissez-nous en discuter en détail.

Quadrant 1 - Déterminer les objectifs, les alternatives et les contraintes

  • Objectifs - Fonctionnalité, performances, interface matérielle / logicielle, facteurs de succès critiques, etc.

  • Alternatives - Construire, réutiliser, acheter, sous-traiter, etc.

  • Contraintes - Coût, calendrier, interface, etc.

Quadrant 2 - Évaluer les alternatives, identifier et résoudre les risques

  • Etudier des alternatives par rapport aux objectifs et contraintes déterminés.

  • Identifier les risques tels que le manque d'expérience, les nouvelles technologies, les horaires serrés, etc.

  • Résoudre les risques identifiés en évaluant leur impact sur le projet, en identifiant les plans d'atténuation et d'urgence nécessaires et en les mettant en œuvre. Les risques doivent toujours être surveillés.

Quadrant 3 - Développer un produit de niveau supérieur

Les activités typiques incluent -

  • Créer un design
  • Revoir la conception
  • Développer du code
  • Inspectez le code
  • Produit test

Quadrant 4 - Planifier la phase suivante

Les activités typiques incluent -

  • Élaborer un plan de projet
  • Développer un plan de gestion de la configuration
  • Développer un plan de test
  • Développer un plan d'installation

Modèle en spirale - Forces

Les avantages ou les points forts de la méthode Spiral sont -

  • Fournit une indication précoce des risques, sans impliquer beaucoup de coûts.
  • Les utilisateurs peuvent visualiser le système tôt grâce aux outils de prototypage rapide.
  • Les fonctions critiques à haut risque sont développées en premier.
  • Le design n'a pas besoin d'être parfait.
  • Les utilisateurs peuvent être étroitement associés à toutes les étapes du cycle de vie.
  • Rétroaction précoce et fréquente des utilisateurs.
  • Les coûts cumulatifs sont évalués fréquemment.

Modèle en spirale - Faiblesses

Les inconvénients ou les faiblesses de la méthode Spiral sont -

  • Il peut être difficile de définir des objectifs, des jalons vérifiables qui indiquent la volonté de passer à l'étape suivante.

  • Le temps consacré à la planification, à la réinitialisation des objectifs, à l'analyse des risques et au prototypage peut être un surcoût.

  • Le temps consacré à l'évaluation des risques peut être trop long pour les petits projets ou les projets à faible risque.

  • Le modèle en spirale est complexe à comprendre pour les nouveaux membres de l'équipe.

  • Une expertise en évaluation des risques est requise.

  • La spirale peut continuer indéfiniment.

  • Les développeurs doivent être réaffectés pendant les activités hors phase de développement.

Quand utiliser le modèle en spirale?

Le modèle Spiral peut être utilisé lorsque -

  • La création d'un prototype est appropriée.
  • L'évaluation des risques est importante.
  • Un projet présente un risque moyen à élevé.
  • Les utilisateurs ne sont pas sûrs de leurs besoins.
  • Les exigences sont complexes.
  • La gamme de produits est nouvelle.
  • Des changements importants sont attendus pendant l'exploration.
  • Engagement de projet à long terme imprudent en raison de changements commerciaux potentiels.

SDLC - Méthodes Agiles

Les méthodes agiles sont basées sur le manifeste Agile et sont de nature adaptative. Les méthodes agiles garantissent -

  • La collaboration d'équipe.
  • Collaboration client.
  • Communication constante et continue.
  • Réponse aux changements.
  • Disponibilité d'un produit fonctionnel.

Plusieurs méthodes Agiles ont vu le jour, favorisant le développement itératif et incrémentiel avec des itérations temporelles. Bien que les méthodes Agiles soient adaptatives, les règles de la méthode spécifique ne peuvent pas être contournées et nécessitent donc une mise en œuvre disciplinée.

Méthodes Agiles - Forces

Les avantages ou les points forts de la méthode Agile sont -

  • Libérations précoces et fréquentes.
  • Prise en compte des besoins changeants.
  • Communication quotidienne entre le client et les développeurs.
  • Des projets construits autour d'individus motivés.
  • Équipes auto-organisées.
  • Simplicité, en se concentrant sur ce qui est immédiatement requis.
  • Pas de construction pour l'avenir ou de surcharge du code.
  • Réflexion régulière pour ajuster le comportement afin d'améliorer l'efficacité.

Méthodes Agiles - Faiblesses

Les inconvénients ou les faiblesses de la méthode Spiral sont -

  • La disponibilité du client peut ne pas être possible.

  • Les équipes doivent être expérimentées pour suivre les règles de la méthode.

  • Une planification appropriée est nécessaire pour décider rapidement des fonctionnalités qui doivent être fournies dans une itération.

  • L'équipe devrait avoir des compétences d'estimation et de négociation.

  • L'équipe doit avoir des compétences de communication efficaces.

  • Les nouvelles équipes peuvent ne pas être en mesure de s'organiser.

  • Nécessite de la discipline pour développer et livrer dans des itérations temporelles.

  • La conception doit rester simple et maintenable, nécessitant ainsi des compétences de conception efficaces.

Quand utiliser des méthodes agiles?

Les méthodes Agiles peuvent être utilisées lorsque -

  • L'application est urgente.

  • La portée est limitée et moins formelle (la mise à l'échelle des méthodes agiles vers des projets plus importants est en cours, avec certaines extensions de certaines des méthodes agiles).

  • L'organisation utilise des méthodes disciplinées.

Développement de logiciels adaptatifs - Evolution

Les modèles SDLC antérieurs sont davantage orientés vers les pratiques de stabilité, de prévisibilité et de rendements décroissants. L'industrie, comme les plates-formes Internet, évolue pour augmenter les environnements de retour, les approches imprévisibles, non linéaires et rapides.

Le développement de logiciels adaptatifs (ASD) a évolué pour résoudre ces problèmes. Il se concentre sur l'émergence comme facteur le plus important du point de vue de la direction, pour améliorer la capacité de gérer le développement de produits.

Selon Jim Highsmith, «le cadre de développement logiciel adaptatif est basé sur des années d'expérience avec les méthodologies traditionnelles de développement logiciel, consultant, pratiquant et écrivant sur les techniques de développement rapide d'applications (RAD) et travaillant avec des éditeurs de logiciels de haute technologie pour gérer le développement de leurs produits les pratiques".

Le modèle en cascade se caractérise par sa linéarité et sa prévisibilité, avec une rétroaction maigre. Il peut être vu comme une séquence Plan → Build → Implement .

Modèle de cascade

Les modèles de cycle de vie évolutionnaire tels que le modèle en spirale ont déplacé l'approche déterministe vers l'approche adaptative, avec Plan → Construire → Réviser les cycles .

Cycle de vie évolutif

Cependant, l'état d'esprit des praticiens est resté déterministe, la prévisibilité à long terme se transformant en prévisibilité à court terme. Les pratiques des modèles de cycle de vie évolutionnaire tels que RAD se révèlent moins déterministes.

Le cycle de vie adaptatif

Le modèle adaptatif est construit à partir d'un point de vue différent. Bien que cycliques comme le modèle évolutionnaire, les noms de la phase reflètent la nature imprévisible de systèmes de plus en plus complexes.

Le développement adaptatif va plus loin que son héritage évolutif de deux manières clés -

  • Il remplace explicitement le déterminisme par l'émergence.

  • Cela va au-delà d'un changement de cycle de vie pour un changement plus profond dans le style de gestion.

Cycle de vie de développement S / W adaptatif

Les trois phases du cycle de vie du développement logiciel adaptatif sont les suivantes:

  • Spéculer - spéculer remplace la planification déterministe des mots, la planification des spécifications du produit ou la planification des tâches de gestion de projet.

  • Collaborer - Collaborer représente un équilibre entre

    • Gérer dans le sens traditionnel de la gestion de projet, et

    • Créer et maintenir l'environnement collaboratif nécessaire à l'émergence.

  • Les activités de collaboration créent des produits, en suivant le rythme des changements dans l'environnement.

  • Learn - Learn vise à la fois, les développeurs et les clients, à utiliser les résultats de chaque cycle de développement pour apprendre la direction du suivant.

Développement de logiciels adaptatifs - Concepts

Dans ce chapitre, nous comprendrons les différents concepts du développement de logiciels adaptatifs.

Théorie des systèmes adaptatifs complexes (CAS)

Brian Arthur et ses collègues de l'institut de Santa Fe ont utilisé la théorie des systèmes adaptatifs complexes (CAS) pour révolutionner la compréhension de la physique, de la biologie, de l'évolution et de l'économie.

Brian Arthur a culminé ses plus de deux décennies d'essayer de convaincre les économistes traditionnels que leur point de vue, dominé par des hypothèses fondamentales de rendements décroissants, d'équilibre et de dynamique déterministe, n'était plus suffisant pour comprendre la réalité. Le nouveau monde est caractérisé par des rendements, une instabilité et une incapacité croissants à déterminer les causes et les effets.

Les deux mondes diffèrent par leur comportement, leur style et leur culture. Ils appellent à -

  • Différentes techniques de gestion
  • Différentes stratégies
  • Compréhension différente

Développement de logiciels complexes

Avec la portée des applications logicielles explosée, même les organisations de développement de logiciels accumulent des contradictions similaires à celles mentionnées ci-dessus.

  • One World est représenté par le développement déterministe, dérivé de pratiques de gestion qui sont enracinées dans les bases de la stabilité et de la prévisibilité (ce qui, selon Arthur, signifie des rendements décroissants)

  • Second World est représenté par les industries qui passent de décroissants à des environnements de retour croissants qui sont imprévisibles, non linéaires et rapides.

Pour répondre aux problèmes de ce deuxième monde, Jig Highsmith a proposé un cadre, le développement logiciel adaptatif, différent du développement logiciel déterministe.

Le développement de logiciels adaptatifs se concentre sur les systèmes complexes -

  • Développement de logiciels adaptatifs pour le cycle de vie du développement.

  • Techniques de gestion adaptative appelant à un état d'esprit différent de celui des pratiques traditionnelles de gestion de projet.

Dans ce didacticiel, vous pouvez comprendre ces deux implémentations.

Le développement logiciel adaptatif (ASD) est basé sur deux perspectives -

  • Perspective conceptuelle basée sur la théorie des systèmes adaptatifs complexes (CAS), telle que présentée dans la première section de ce chapitre.

  • Perspective pratique basée sur

    • Années d'expérience avec les méthodologies de développement logiciel déterministes.

    • Consultation, pratique et rédaction sur les techniques de développement rapide d'applications (RAD); et travailler avec des éditeurs de logiciels de haute technologie pour gérer le développement de leurs produits.

Dans ce chapitre, vous comprendrez la perspective conceptuelle du développement de logiciels adaptatifs.

Concepts des systèmes adaptatifs complexes (CAS)

La théorie des systèmes adaptatifs complexes (CAS) comporte de nombreux concepts. Le développement de logiciels adaptatifs est basé sur deux de ces concepts -

  • Émergence
  • Complexité

Émergence

Dans les projets complexes de développement de produits logiciels, les résultats sont intrinsèquement imprévisibles. Cependant, des produits performants émergent constamment de tels environnements.

Cela peut arriver par Emergence, comme illustré dans la théorie des systèmes adaptatifs complexes (CAS). Il peut être compris par un exemple simple, le comportement de vol des oiseaux.

Lorsque vous observez une volée d'oiseaux, vous remarquez que -

  • Chaque oiseau essaie de

    • Maintenez une distance minimale par rapport aux autres objets de l'environnement, y compris les autres oiseaux.

    • Faites correspondre les vitesses avec les oiseaux de son voisinage.

    • Déplacez-vous vers le centre de masse des oiseaux perçu dans son voisinage.

  • Il n'y a pas de règles de comportement pour le groupe. Les seules règles concernent le comportement de chaque oiseau.

  • Cependant, il existe un comportement émergent, le vol d'oiseaux. Lorsque des oiseaux errants se précipitent pour rattraper leur retard, le troupeau se divise autour des obstacles et se réforme de l'autre côté.

Cela montre l'exigence des changements de modèle mental les plus difficiles dans le développement adaptatif - Des façons de gérer et d'organiser cette liberté individuelle à la notion qu'un nouvel ordre créatif émerge de façon imprévisible de l'autoformation spontanée.

Outre le développement, l'émergence est également le concept le plus important du point de vue de la gestion.

Complexité

Dans le contexte du développement logiciel, la complexité concerne -

  • Les individus d'une équipe tels que les développeurs, les clients, les fournisseurs, les concurrents et les actionnaires, leur nombre et leur vitesse.

  • Taille et complexité technologique.

Pratiques de développement de logiciels adaptatifs

Le développement de logiciels adaptatifs offre une perspective différente sur les pratiques de gestion de logiciels. Dans les sections ci-dessous, vous pouvez comprendre les deux pratiques importantes - Qualité et RAD, qui ont toutes deux des ramifications pour la collecte des exigences.

Vous pouvez trouver les détails de toutes les pratiques dans le chapitre, Pratiques de développement de logiciels adaptatifs dans ce tutoriel.

Qualité

Dans un environnement complexe, la pratique séculaire de «Faites-le bien la première fois» ne fonctionne pas car vous ne pouvez pas prédire ce qui est bien au début. Vous devez avoir pour objectif de produire la bonne valeur. Cependant, dans un environnement complexe, les combinaisons et permutations de composants de valeur tels que la portée (fonctionnalités, performances, niveaux de défauts), le calendrier et les ressources sont si vastes qu'il ne peut jamais y avoir de valeur optimale. Par conséquent, l'objectif est de changer pour offrir la meilleure valeur sur le marché concurrentiel.

Pratiques RAD

Les pratiques RAD impliquent généralement une combinaison des éléments suivants -

  • Cycle de vie évolutif
  • Groupes de discussion clients, sessions JAD, examens techniques
  • Gestion de projet dans le temps
  • Génie logiciel continu
  • Équipes dédiées avec salles de guerre

Les projets RAD ont une saveur adaptative et émergente inhérente. De nombreuses organisations informatiques sont contre RAD. Cependant, Microsoft et d'autres ont produit des logiciels incroyablement volumineux et complexes utilisant des techniques comparables à RAD car cela soulève des questions sur leur vision fondamentale du monde.

Les pratiques RAD et le processus Microsoft sont deux exemples de développement adaptatif en action. Leur donner une étiquette (c.-à-d. Développement adaptatif) et se rendre compte qu'il existe un corpus croissant de connaissances scientifiques (c.-à-d. La théorie CAS) explique pourquoi ils fonctionnent. Cela devrait fournir une base pour une utilisation plus étendue de ces pratiques.

Développement de logiciels adaptatifs - Cycle de vie

Le développement de logiciels adaptatifs a évolué à partir des pratiques RAD. Les aspects d'équipe ont également été ajoutés à ces pratiques. Des entreprises de la Nouvelle-Zélande au Canada, pour un large éventail de types de projets et de produits, ont utilisé le développement logiciel adaptatif.

Jim Highsmith a publié Adaptive Software Development en 2000.

Les pratiques de développement logiciel adaptatif permettent de s'adapter au changement et sont adaptables dans des environnements turbulents avec des produits évoluant avec peu de planification et d'apprentissage.

Phases du cycle de vie des TSA

Le développement logiciel adaptatif est cyclique comme le modèle évolutionnaire, les noms de phase reflétant l'imprévisibilité des systèmes complexes. Les phases du cycle de vie du développement adaptatif sont -

  • Spéculer
  • Collaborer
  • Apprendre

Ces trois phases reflètent la nature dynamique du développement de logiciels adaptatifs. Le développement adaptatif remplace explicitement le déterminisme par l'émergence. Cela va au-delà d'un simple changement de cycle de vie pour un changement plus profond dans le style de gestion. Le développement de logiciels adaptatifs a un cycle de vie dynamique spéculer-collaborer-apprendre.

Le cycle de vie du développement logiciel adaptatif se concentre sur les résultats, pas sur les tâches, et les résultats sont identifiés comme des fonctionnalités d'application.

Cycle de vie du développement de logiciels adaptatifs

Spéculer

Le terme plan est trop déterministe et indique un degré raisonnablement élevé de certitude quant au résultat souhaité. L'objectif implicite et explicite de conformité au plan limite la capacité du gestionnaire à orienter le projet dans des directions innovantes.

Dans Adaptive Software Development, le terme plan est remplacé par le terme spéculer. Tout en spéculant, l'équipe n'abandonne pas la planification, mais elle reconnaît la réalité de l'incertitude dans les problèmes complexes. Spéculer encourage l'exploration et l'expérimentation. Les itérations avec des cycles courts sont encouragées.

Collaborer

Les applications complexes ne se construisent pas, elles évoluent. Les applications complexes nécessitent qu'un grand volume d'informations soit collecté, analysé et appliqué au problème. Les environnements turbulents ont des taux élevés de flux d'informations. Par conséquent, les applications complexes nécessitent qu'un grand volume d'informations soit collecté, analysé et appliqué au problème. Il en résulte des exigences de connaissances diverses qui ne peuvent être gérées que par une collaboration d'équipe.

Collaborer nécessiterait la capacité de travailler conjointement pour produire des résultats, partager des connaissances ou prendre des décisions.

Dans le contexte de la gestion de projet, la collaboration décrit un équilibre entre la gestion avec des techniques de gestion traditionnelles et la création et le maintien de l'environnement collaboratif nécessaire à l'émergence.

Apprendre

La partie Apprendre du cycle de vie est vitale pour la réussite du projet. L'équipe doit constamment améliorer ses connaissances, en utilisant des pratiques telles que -

  • Revues techniques
  • Rétrospectives du projet
  • Groupes de discussion clients

Les examens doivent être effectués après chaque itération. Les développeurs et les clients examinent leurs hypothèses et utilisent les résultats de chaque cycle de développement pour apprendre la direction du suivant. L'équipe apprend -

  • À propos des changements de produits

  • Changements plus fondamentaux dans les hypothèses sous-jacentes sur la façon dont les produits sont développés

Les itérations doivent être courtes, afin que l'équipe puisse apprendre de petites erreurs plutôt que de grandes erreurs.

Spéculer - Collaborer - Apprendre le cycle dans son ensemble

Comme vous pouvez le constater dans le cycle Spéculer-Collaborer-Apprendre, donné ci-dessus, il est évident que les trois phases sont non linéaires et se chevauchent.

Nous observons ce qui suit à partir d'un cadre adaptatif.

  • Il est difficile de collaborer sans apprendre ou d'apprendre sans collaborer.

  • Il est difficile de spéculer sans apprendre ou d'apprendre sans spéculer.

  • Il est difficile de spéculer sans collaborer ou de collaborer sans spéculer.

Caractéristiques du cycle de vie

Le cycle de vie du développement logiciel adaptatif a six caractéristiques de base -

  • Axé sur la mission
  • Basé sur les fonctionnalités
  • Itératif
  • Time-boxed
  • Axé sur le risque
  • Tolérant au changement

Dans ce chapitre, vous comprendrez ces six caractéristiques du développement de logiciels adaptatifs.

Axé sur la mission

Pour de nombreux projets, la mission globale qui guide l'équipe est bien articulée, bien que les exigences puissent être incertaines au début du projet. Les énoncés de mission agissent comme des guides qui encouragent l'exploration au début mais ont un objectif étroit au cours d'un projet. Une mission fournit des frontières plutôt qu'une destination fixe. Les énoncés de mission et les discussions qui ont abouti à ces énoncés fournissent une orientation et des critères pour prendre des décisions critiques de compromis de projet.

Sans une mission claire et une pratique de raffinement de mission constante, les cycles de vie itératifs deviennent des cycles de vie oscillants, oscillant d'avant en arrière sans progrès dans le développement.

Basé sur les fonctionnalités

Le cycle de vie du développement logiciel adaptatif est basé sur les fonctionnalités de l'application et non sur les tâches. Les fonctionnalités sont les fonctionnalités développées au cours d'une itération en fonction des priorités du client.

Les fonctionnalités peuvent évoluer sur plusieurs itérations lorsque les clients fournissent des commentaires.

Les fonctionnalités de l'application qui fournissent des résultats directs au client après la mise en œuvre sont principales. Un document orienté client tel qu'un manuel d'utilisation est également considéré comme une fonctionnalité. Les autres documents tels que le modèle de données, même s'ils sont définis comme livrables, sont toujours secondaires.

Itératif

Le cycle de vie du développement logiciel adaptatif est itératif et se concentre sur les versions fréquentes afin d'obtenir des commentaires, d'assimiler l'apprentissage qui en résulte et de définir la bonne direction pour le développement ultérieur.

Time-boxed

Dans Adaptive Software Development Lifecycle, les itérations sont temporelles. Cependant, il ne faut pas oublier que le time-boxing dans Adaptive Software Development ne concerne pas les délais. Il ne doit pas être utilisé pour faire travailler l'équipe pendant de longues heures dans un environnement collaboratif ou pour compromettre la qualité des livrables.

Dans le développement de logiciels adaptatifs, le time-boxing est considéré comme une direction pour concentrer et forcer les décisions de compromis difficiles au fur et à mesure des besoins. Dans un environnement incertain, dans lequel les taux de changement sont élevés, il doit y avoir une fonction de forçage périodique telle qu'une boîte de temps pour terminer le travail.

Axé sur le risque

Dans le développement de logiciels adaptatifs, les itérations sont déterminées par l'identification et l'évaluation des risques critiques.

Tolérant au changement

Le développement de logiciels adaptatifs est tolérant au changement, considérant le changement comme la capacité d'incorporer un avantage concurrentiel, mais pas comme un problème de développement.

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?"

Développement S / W adaptatif - Gestion

Un organigramme de la gestion traditionnelle des logiciels est présenté ci-dessous.

Réévaluation

La gestion de logiciels traditionnelle a été caractérisée par le terme commande-contrôle.

De nombreuses organisations sont ancrées dans une tradition d'optimisation, d'efficacité, de prévisibilité, de contrôle, de rigueur et d'amélioration des processus. Cependant, l'économie émergente de l'ère de l'information requiert adaptabilité, rapidité, collaboration, improvisation, flexibilité, innovation et souplesse.

Les livres d'analyse et de gestion des affaires de Harvard ont trouvé des termes tels que l'autonomisation, la gestion participative, l'organisation apprenante, la gestion centrée sur l'humain, etc., mais aucun de ceux-ci n'est utilisé dans la gestion d'organisations modernes.

Dans le contexte du développement de logiciels adaptatifs, l'écart semble beaucoup plus large et il est nécessaire de considérer les techniques de gestion adaptative qui ont fait leurs preuves dans d'autres domaines.

Gestion adaptative

La gestion adaptative a fait ses preuves dans les environnements où les gestionnaires de ressources ont collaboré avec les parties prenantes et les scientifiques en équipe, avec les objectifs suivants:

  • Apprendre comment les systèmes gérés répondent aux interventions humaines.

  • Améliorer les politiques et les pratiques en matière de ressources à l'avenir.

Le principe de la gestion adaptative est que de nombreuses activités de gestion des ressources sont des expériences car leurs résultats ne peuvent pas être prédits de manière fiable à l'avance. Ces expériences sont ensuite utilisées comme des opportunités d'apprentissage pour les améliorations à venir.

La gestion adaptative vise à accroître la capacité de réagir en temps opportun face à de nouvelles informations et dans un cadre d'objectifs et de préférences variés des parties prenantes. Il encourage les parties prenantes à limiter les différends et à en discuter de manière ordonnée pendant que les incertitudes environnementales sont étudiées et mieux comprises.

La gestion adaptative aide les parties prenantes, les gestionnaires et les autres décideurs à reconnaître les limites des connaissances et la nécessité d'agir sur des informations imparfaites.

La gestion adaptative aide à changer les décisions prises en précisant que -

  • Les décisions sont provisoires.
  • La décision d'une direction ne doit pas toujours être juste.
  • Des modifications sont attendues.

Il existe deux types d'approches de gestion adaptative -

  • Gestion adaptative passive.
  • Gestion adaptative active.

Gestion adaptative passive

La gestion adaptative vise à améliorer les connaissances scientifiques et à réduire ainsi les incertitudes.

Passif Adaptatif

Au sein de la gestion adaptative passive, une seule ligne de conduite privilégiée, basée sur les informations et la compréhension existantes, est sélectionnée. Les résultats des actions de gestion sont contrôlés et les décisions ultérieures sont ajustées en fonction des résultats.

Cette approche contribue à l'apprentissage et à une gestion efficace. Cependant, il est limité dans sa capacité à améliorer les capacités scientifiques et de gestion dans des conditions qui vont au-delà du plan d'action choisi.

Gestion adaptative active

Une approche de gestion adaptative active examine les informations avant de prendre des mesures de gestion.

Active Adaptive

Une gamme de modèles de systèmes alternatifs concurrents de l'écosystème et des réponses connexes (par exemple, les changements démographiques, les utilisations récréatives), plutôt qu'un modèle unique, est ensuite développée. Les options de gestion sont choisies en fonction des évaluations de ces modèles alternatifs.

Gestion du leadership et de la collaboration

La gestion adaptative est celle qui convient le mieux au développement de logiciels adaptatifs. L'approche nécessite des gestionnaires de ressources, c'est-à-dire des gestionnaires capables de travailler avec les gens, de permettre des interventions humaines et de créer un environnement amical.

Dans le développement de logiciels, les dirigeants assument souvent ces responsabilités. Nous avons besoin de dirigeants plus que de commandants. Les dirigeants sont des collaborateurs et travaillent aux côtés de l'équipe. Le leadership collaboratif est la pratique la plus recherchée en développement adaptatif.

Les dirigeants ont les qualités suivantes -

  • Saisissez et définissez la direction.

  • Influencer les personnes impliquées et fournir des conseils.

  • Collaborer, faciliter et macro-gérer l'équipe.

  • Fournir une orientation.

  • Créez des environnements où les personnes talentueuses peuvent être innovantes, créatives et prendre des décisions efficaces.

  • Comprenez qu'occasionnellement, ils doivent commander, mais ce n'est pas leur style prédominant.