ASD (Adaptive Software Development)

Le développement logiciel adaptatif (Adaptive Software Development) est défini par Highsmith comme consistant en trois composants, le modèle conceptuel adaptatif (Adaptive Conceptual Model), le modèle de développement adaptatif (Adaptive Development Model) et le modèle de gestion adaptative (Adaptive Management Model) (Highsmith, 2000). Le modèle conceptuel adaptatif (systèmes adaptatifs complexes), définit la mentalité nécessaire pour pouvoir utiliser les modèles de développement et de gestion (Highsmith, 2000). Le modèle de développement adaptatif (spéculer, collaborer, apprendre), établit la grande vitesse par l’utilisation de l’itération, de la concurrence, du feedback et de la collaboration (Highsmith, 2000). Le focus du modèle de gestion adaptative (leadership et collaboration) vise à créer la culture adaptative et à identifier les pratiques adaptatives, à impliquer des groupes de travail distribués et à gérer les changements élevés, la collaboration et la gestion des résultats. L’idée est d’adapter le modèle de gestion à des environnements où l’équilibre n’est pas la condition normale et le changement est la norme, comme les environnements à grande vitesse et à changement élevé. Highsmith dit également que le focus sur le modèle de gestion adaptative se concentre sur les aspects culturels et structurels de la collaboration nécessaires pour créer un ordre émergent à plus globalement et étendre le développement adaptatif jusqu’à des projets complexes plus gros (Highsmith, 2000). La collaboration fonctionne bien avec les équipes interfonctionnelles et Highsmith recommande des réunions facilitées ou des sessions JAD (Joint Application Development) pour rassembler des groupes interfonctionnels afin de construire des relations de collaboration capables de produire des livrables de haute qualité dans un court laps de temps (Highsmith, 2000). Selon Highsmith, les meilleures équipes sont petites; une équipe centrale devrait comprendre moins de dix membres.

Highsmith définit également une opposition entre les modèles adaptatifs et les modèles traditionnels en disant que si ce dernier est une approche qui dépend d’un « ordre imposé », le premier a une approche qui passe par un « ordre émergent ». Les modèles traditionnels reposent sur la croyance et les actions qui dépendent de la capacité de prédire l’avenir et de le réaliser (ordre imposé). Le modèle adaptatif a la propriété de « l’émergence » qui est la capacité de produire des résultats par l’interaction spontanée d’agents auto-organisateurs. Cette idée est bien illustrée dans la Figure 10 (Highsmith, 2000). Highsmith dit que l’ASD est venu en réponse au fait que RAD (Rapid Application Development – §2.3.4. RAD (Rapid Application Development)) a des problèmes avec des taux de changement élevés. Il compare les approches ASD, RAD, cascade et evolutive dans les axes de changement faible/élevé et de vitesse faible/élevée. Alors que l’approche en cascade fonctionne bien avec une faible vitesse et de faibles taux de changement, l’approche évolutive traite des taux de changement élevés au détriment de la vitesse (basse vitesse), l’approche RAD à grande vitesse traite généralement de petits volumes de changements et l’ASD est orienté à la fois à haute vitesse et un volume élevé de changements (Highsmith, 2000). ASD dispose de techniques de planification adaptative qui peuvent être définies en sept « étapes de planification de cycle », à savoir: mener la phase de démarrage du projet, déterminer le timebox du projet, déterminer le nombre optimal de cycles et le timebox pour chacun, écrire un objectif pour chaque cycle, attribuer les composants primaires aux cycles, attribuer la technologie et les composants de support aux cycles et développer une liste de tâches de projet (Highsmith, 2000).

Serum Scrum ou Scrummage est un terme qui vient du football de rugby qui signifie un type de reprise de jeu où les joueurs sont réunis étroitement pour tenter de prendre possession du ballon. Scrum dans le contexte du développement logiciel est un framework Agile définissant comment un produit logiciel doit être développé. Le mot Scrum a été utilisé pour la première fois dans un article de Harvard Business Review de 1986, « The New New Product Development Game » (Takeuchi et aL, 1986), par Hirotaka Takeuchi et Ikujiro Nonaka. Dans cet article, Takeuchi et Nonaka comparent la course de relais, où un seul membre de l’équipe travaille seul à la fois, au rugby, où les membres de l’équipe travaillent généralement en même temps, en particulier dans la mêlée avec laquelle ils jouent très près les uns des autres avec le même objectif. La méthode classique en cascade est un exemple de la façon dont le processus est similaire à une course de relais. Le processus est séquentiel, les phases sont bien divisées, sont différentes les unes des autres et la phase suivante ne démarre que lorsque toutes les exigences de la phase précédente sont remplies. Selon le Serum Guide (Schwaber et al., 2016), Serum est « un cadre dans lequel les gens peuvent résoudre des problèmes adaptatifs complexes, tout en fournissant de manière productive et créative des produits de la plus haute valeur possible. »

Les équipes Serum sont auto-organisées et interfonctionnelles.

L’équipe est libre de décider de la meilleure façon de travailler et ses membres ont toutes les connaissances et les capacités pour accomplir les tâches. Le Serum Master est responsable de s’assurer que l’équipe Serum adhère à la théorie, aux pratiques et aux règles Serum. Le Serum Master agit comme un facilitateur en supprimant les obstacles à la progression de l’équipe de développement et en facilitant les événements Serum comme demandé ou nécessaire. Le Serum Master assure également la collaboration entre les membres de l’équipe Serum. Le processus Serum divise le Backlog de produit en Backlog de sprint à développer pendant le sprint (généralement 30 jours), fournissant un incrément de travail du logiciel (Figure 11). Le processus Serum est optimisé pour fournir un feedback pendant les itérations. L’utilisation de prototypes est importante car chaque itération fournit des incréments logiciels de produit non final – le prototype peut avoir à la fois produits déjà développés et des maquettes – la partie « à développer » peut ensuite être visualisée par les parties intéressées et l’équipe Serum peut avoir des commentaires pour ce qui a été fait et ce qui doit être fait en même temps. Le Sprint commence avec le « Sprint Planning » lorsque l’équipe reçoit les « Epies » et joue un « Planning Poker », où chaque « User Story » est dimensionnée en points concernant la taille de l’effort du développement, les tests et la documentation. Chaque Epie est une collection de « User Stories ». L’User Story est généralement définie en utilisant le format suivant: « En tant que <rôle utilisateur>, je veux <faire quelque chose> pour que <résultat attendu> ».

Durabilité

La durabilité est le moyen de créer et de maintenir les conditions dans lesquelles l’homme et la nature peuvent exister en harmonie productive pour soutenir les générations présentes et futures (EPA, 2011). Nous comprenons que les humains ne sont pas censés détruire la capacité de la nature à se préserver en éteignant les ressources nécessaires pour cela. La manière la plus simple de voir cela est l’utilisation par l’humanité de l’énergie provenant des ressources naturelles ne pourrait pas épuiser ces ressources, de sorte qu’elles devraient soit utiliser moins de ressources, soit trouver de nouvelles sources d’énergie renouvelables. On peut définir le développement durable comme un moyen de développer un produit en utilisant moins d’énergie ou en utilisant le moins d’énergie possible. Le produit durable ne fait pas l’objet de ce travail. Le développement doit être durable pour accélérer le processus de développement et utiliser moins de ressources. En utilisant moins de ressources, le coût du développement est le minimum possible. Nous pouvons également apprendre des processus durables comment mieux utiliser l’énergie pour augmenter les performances des projets aéronautiques. Il est attendu d’un projet que ses gestionnaires travaillent pour maintenir le budget du projet. Concrètement, c’est une bonne idée d’essayer de minimiser les coûts de développement pour garder le budget. Le guide PMBOK définit le processus de maîtriser les coûts comme le processus de suivi de l’état du projet pour mettre à jour les coûts du projet et gérer les modifications de la base de référence des coûts. Le principal avantage de ce processus est que la base de référence des coûts est maintenue tout au long du projet (Project Management Institute, 2017a). Nous pouvons supposer que l’utilisation des pratiques de durabilité des Méthodes Agiles peut aider à minimiser les coûts du projet et à maintenir le budget.