MEMOIRE PRESENTE EN VUE DE L’OBTENTION DU DIPLOME DE

 

 

 

 

 

 

 

LA CONTINUITE DES METHODES AGILES PAR DEVOPS

 

 

 

 

Présenté par :

 

 

GLOSSAIRE

ASD		Agile Software Development
DSDM		Dynamic System Development Method
DSI		Direction des Systèmes Informatiques
FDD		Feature Driven Development
JAD		Joint Application Design
JRP		Joint Requirements Planning
RAD		Rapid Application Development
RUP		Rational Unified Process

 

INTRODUCTION

Bien que les missions incombées au chef de projet présentent des enjeux économiques majeurs, leurs exécutions revêtent  des difficultés particulières en raison de l’obligation de s’adapter aux mutations et au développement du climat des affaires. En effet, il est attendu de la part de celui-ci, une pluridisciplinarité lui permettant de prouver ses connaissances techniques pour gérer efficacement le projet, de mobiliser ses équipes, d’impliquer toutes les parties prenantes et surtout de mettre en valeur les particularités du projet qu’il conduit.

 

Un chef de projet doit disposer comme finalité principale d’achever à échéance fixée au préalable les réalisations escomptées conformément aux dépenses prévues pendant la phase de conception. Afin de pouvoir y parvenir, il ne peut en aucun cas négliger la formule « 3C », c’est-à-dire les trois facteurs de contrainte composant un projet.

 

Comme de coutume, la méthode classique avait toujours été utilisée dans le management du projet, laquelle est constituée, dans le domaine de l’informatique, par les identifications des besoins, la détermination des produits, la vérification du bon fonctionnement des produits à livrer ainsi obtenus et se termine par la livraison. Il s’agit du « cycle en cascade » avec lequel est mise en exergue l’approche dite « prédictive ».

 

A cet effet, le résultat d’une investigation démontre que :

« 31 % des projets informatiques sont arrêtés en cours de route, 52 % n’aboutissent qu’au prix d’un important dépassement des délais et du budget tout en offrant moins de fonctionnalités qu’il n’en était demandé ; seuls 16 % des projets peuvent être considérés comme des succès. »[1].

 

Toutefois, on a pu constater une lente progression de ce pourcentage de succès vers la fin des années 2000. A cet égard, une amélioration de 19% a été marquée par le rapport de la même investigation sans que les obstacles ci-dessus citées n’aient été écartées. Lesdits obstacles tirent principalement leurs fondements de la hausse du pourcentage de :

• L’insuffisance de techniques d’implication des parties prenantes, dont les clients notamment ;
• La modification pendant la phase d’exécution des spécifications.

 

Tandis que la première cause atteint 12,8%, la seconde affiche 11,8%.

 

Face à ce ralentissement, une révolution est apparue pour une gestion plus efficace des projets informatiques, laquelle porte le nom : « méthode agile ».

Cette dernière est conçue pour diminuer ou même pour anéantir l’effet tunnel ci-dessus décrit parce qu’elle permet de mieux afficher la « visibilité », par le biais de l’implication des clients depuis l’établissement du projet jusqu’à son terme, ainsi que par l’application de nouvelles caractéristiques du processus de développement : « itératif et incrémental ». Cela signifie que la méthode agile prend en compte la mutation des attentes et essaie de s’en superposer tout en respectant les normes.

 

La méthode consiste à augmenter la célérité du développement d’un logiciel par la diminution de son cycle de vie. Plus généralement, les tâches y afférentes consistent à développer une version minimale et à intégrer les fonctionnalités par la suite. C’est dans cette seconde activité que le processus itératif est inéluctable parce qu’il faut tenir compte des désirs des clients et il faut toujours s’assurer des produits au cours du cycle de développement.

 

Cependant, les clients ne sont pas toujours en mesure d’exprimer clairement leurs attentes lors de la conception du projet. En outre, les mutations technologiques s’accentuent considérablement. C’est dans le cadre de la gestion de ces mutations que le concept « agile » est conçu pour faire allusion à la capacité d’adaptation au bouleversement de la situation et aux changements de spécifications au cours du processus de développement.

 

Vers le début du troisième millénaire, cette notion d’ « agile » a changé plusieurs autres. A cet effet, la notion d’interactions est utilisée à la place de processus. Le concept développement logiciel a également remplacé la documentation exhaustive. En ce qui concerne la négociation contractuelle, ces expressions sont devenues caduques car il est désormais question de parler, avec le cocontractant ou le client, de collaboration. Tel est également le cas pour la rigidité de plan car la nouvelle méthode implique l’ouverture au changement.

 

En effet, les finalités des méthodes agiles sont d’aider les client à devenir également capable de piloter son projet et que l’opérationnalisation des logiciels soient accélérée. C’est aussi pour le même cadre d’analyse que la notion « devops » intervient.

 

Au demeurant, la question qui se pose est de savoir : Comment devops s’inscrit dans la continuité des méthodes agiles ?

 

Les réponses à cette question se trouvent dans les deux parties qui suivent :

• Première partie : les méthodes agiles : analyses théoriques et conceptuelles
• Deuxième partie : Les méthodes agiles et Devops : analyse des liens.

 

 

 

PREMIERE PARTIE : LES METHODES AGILES : ANALYSES THEORIQUES ET CONCEPTUELLES

Dans ce cadre d’analyse, il sera exposé que les méthodes agiles sont des concepts sujets d’une longue explication et dont l’étude sur le scrum marque un point important car il constitue l’aînée de ces méthodes.

 

I – La méthode Agiles : analyses conceptuelles

A cet effet, la définition, l’étude historique, l’analyse des valeurs agiles et l’approche comparative sur les méthodes permettent de mieux appréhender les concepts liés aux méthodes agiles comme suit :

 

A – Définition de la méthode

Il s’agit de la méthodologie appliquée en matière de projets informatiques, laquelle est fondée sur des cycles de développement conformes aux changements imprévisibles des attentes des clients, une raison pour laquelle on les qualifie d’ « itératifs et adaptatifs ». De surcroît, il s’agit d’une méthode d’implication des parties prenantes au développement du projet, telles que : les clients et les fournisseurs.

 

Cette méthodologie constitue un meilleur moyen pour satisfaire le client impliqué, par le biais de la valorisation de la compétence des fournisseurs également impliqués et avec une célérité de l’exécution du projet. On peut en déduire que, aussi bien pour le fournisseur que pour le client, la méthode agile améliore la capacité de production et renforce les potentialités.

 

Il existe deux grands fondements de la méthode agile, lesquels servent comme règles identiques d’art  utilisées à titre principal ou subsidiaire en la matière :

• L’identité de la structure : cycle de développement itératif, adaptatif et incrémental.
• L’identité des valeurs.

 

A cet effet, on peut citer les deux grands méthodes agiles les plus connus et les plus répandus à travers le monde, à savoir :

• La méthode Scrum apportée par Jeff Sutherland[2]
• La méthode XP Extreme programming apportée par Kent Beck[3].

 

Cependant, diverses autres familles de la méthode agile apparaissaient vers les années 90 mais dont la célébrité a été peu connue par les utilisateurs, telles que :

• Vers le début des années 90 : le RAD avec DSDM ou Développement Rapide d’Applications,
• Vers le milieu des années 90 : le RAD en version anglaise, l’ASD et le FDD.

 

Depuis lors, l’extension de la méthode agile a marqué le monde du projet informatique car le « management agile » s’est apparu. C’est une autre nouvelle méthodologie dont les valeurs identiques agiles et la perfection de la qualité sont associées dans tout le cycle de développement.

 

Les méthodes agiles présentent des spécificités permettant de les distinguer des autres méthodes de gestion de projet informatiques :

 

• Premièrement, elles présentent un caractère « itératif » :

La technique utilisée étant le découpage du projet en « itérations » : le développement est devenu subdivisé en quelques étapes afin d’obtenir des mini projets. Ce découpage est avantageux dans la mesure où il permet la priorisation des fonctionnalités à développer suivant l’urgence et l’importance des besoins du client.

 

Par la suite, il appartient au chef de projet de coordonner les activités afférentes à la mise en œuvre du développement desdites fonctionnalités par le biais du macroplanning. L’avantage dans cette optique est de pouvoir faire face au changement d’avis des clients au fur et à mesure où on travaille sur le développement car il s’avère impossible de prévoir et coordonner entièrement les cas lors de la conception du projet même si les collaborateurs disposent l’entière capacité et la maîtrise parfaite requises.

 

• Deuxièmement, les méthodes agiles sont « incrémentales » :

Ce caractère renvoie au délai d’exécution du projet : la technique consiste à partager les délais de production des fonctionnalités en « incréments ». Cela intervient pour les projets dont le délai d’exécution ou de production est supérieur à 10 jours.

 

• Troisièmement, les méthodes agiles présentent un caractère « adaptatif » :

Contrairement aux deux premiers caractères, le terme « adaptatif » suppose une intervention avant – pendant et après la production. Cela signifie que la méthode agile implique des tests de bon fonctionnement des produits livrés et exige l’adaptation au changement par le biais d’une métrique formelle. Il en déduit un affichage mural avec lequel on peut avoir un aperçu de la planification opérationnelle élémentaire.

 

Toute méthode se prétendant d’agile doit suivre des règles de l’art identiques matérialisées dans 12 principes de base, à savoir :

1. « La plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à forte valeur ajoutée.
2. Le changement est accepté, même tardivement dans le développement, car les processus agiles exploitent le changement comme avantage concurrentiel pour le client.
3. La livraison s’applique à une application fonctionnelle, toutes les deux semaines à deux mois, avec une préférence pour la période la plus courte.
4. Le métier et les développeurs doivent collaborer régulièrement et de préférence quotidiennement au projet.
5. Le projet doit impliquer des personnes motivées. Donnez-leur l’environnement et le soutien dont elles ont besoin et faites leur confiance quant au respect des objectifs.
6. La méthode la plus efficace pour transmettre l’information est une conversation en face à face.
7. L’unité de mesure de la progression du projet est un logiciel fonctionnel (ce qui exclut de comptabiliser les fonctions non formellement achevées).
8. Les processus agiles promeuvent un rythme de développement soutenable (afin d’éviter la non qualité découlant de la fatigue).
9. Les processus agiles recommandent une attention continue à l’excellence technique et à la qualité de la conception.
10. La simplicité et l’art de minimiser les tâches parasites, sont appliqués comme principes essentiels.
11. Les équipes s’auto-organisent afin de faire émerger les meilleures architectures, spécifications et conceptions.
12. À intervalle régulier, l’équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son processus de travail en conséquence.»[4]

 

En effet, la faisabilité d’une convention agile est garantie par la détermination du contour prédéfini sur lequel on effectue la production et par l’accord sur l’utilisation de la technique agile. La valeur recherchée reste toujours l’identité ou l’unité tandis que les fonctionnalités se différencient d’un client à un autre et peuvent être changées tout le long du cycle de développement.

 

B – Origine et historique des méthodes Agiles

 

1 – Analyses contextuelles

Quelques études effectuées au préalable ont permis de dégager la méthode agile, comme celles de :

• Tom Gilb sur le « cycle de vie évolutif »,
• Scott Shultz sur la « production en itérations rapides »,
• Brian Gallagher et Alex Balchin

 

Bien que l’EVO5 soit la première méthode agile trouvée par Tom Gilb en 1976, la méthode qualifiée d’agile de nos jours emprunt plusieurs techniques inspirées des œuvres de J. Wood et D. Silver publiées vers la fin des années 80, lesquelles ont été issues des investigations faite par Dan Gielan et reprises par Chuck Morris d’IBM dans le milieu des années 80. On peut citer à cet effet :

• Les JRP : Joint Requirements Planning,
• Les JAD : Joint application design.

 

Depuis lors, plusieurs autres modèles ont été publiés, comme :

 

• L’ingénierie concourante :

Il en est par exemple de l’extrait des œuvres de Hirotaka Takeuchi et Ikujiro Nonaka dans « The new new product developpement game6 » qui parle du développement associant plusieurs disciplines.

 

• Le développement incrémental :

Il s’agit d’un modèle de développement en spirale publié dans le milieu des années 80 par Barry Boehm.

 

Puis, une idée de célérité de développement d’application s’est survenu vers le début des années 90. Cela a été dû à la course du développement de la technologie informatique. Ainsi, James Martin a créé le RAD qui présentait à l’époque, les spécificités qui suivent :

• Structure utilisée : itérative, incrémentale, adaptative.
• Principe utilisé : implication continue des clients.

 

Les esquisses de perfectionnement du RAD ont continué sur le continent européen qu’au milieu des années 90, d’autres chercheurs ont pu apporter des nouveaux points de vu pour ajouter des techniques novatrices :

• Jean-Pierre Vickoff : publication de ses résultats de recherche au niveau du territoire français,
• Gartner Group : le Processus RAD2,
• Jennifer Stapleton : publication de ses résultats de recherche sur le DSDM au niveau du territoire de la Grande-Bretagne.

 

A partir du troisième millénaire, XP Extreme programming et Scrum ont été vulgarisés comme étant de nouvelles autres méthodes agiles les plus connues mais de nombreuses autres méthodes ont été également répandues.

 

Concernant le XP Extreme programming, les mesures prises consistent à détecter les problèmes pour pouvoir chercher à appliquer les pratiques de qualité dans la construction applicative, à rendre plus efficace les techniques adaptatives d’estimation consensuelle, à rationnaliser la planification pilotée par l’utilisateur ainsi que la célérité du repoting visuel dans affichage mural à base de post-it.

 

S’agissant du scrum, les mesures prises consistent à s’auto-organiser et à apprendre dans le but de mettre en place l’adaptabilité dans la compression des pratiques de développement.

 

Par la suite, la prolifération des méthodes s’est étendue en Amérique où les débats sur les méthodes ci-après se sont succéder afin de trouver des points de convergences de techniques :

• Débat sur la DSDM ou Dynamic System Development Method menée par Arie van Bennekum,
• Débat sur la méthode Crystal clear apportée par Alistair Cockburn,
• Débat sur l’ASD de Jim Highsmith,
• Débat sur le Scrum inventé par Ken Schwaber et Jeff Sutherland,
• Débat sur l’extreme programming de Kent Beck,
• Débat sur le Wiki trouvé par Ward Cunningham.

 

A cet effet, dix autres experts en développement logiciel ont rejoins ces personnalités en vue d’apporter leurs expériences et connaissances dans l’optique de perfectionner la méthode agile. A l’issue de cette concertation, la « manifeste agile » a vu le jour comme étant des expressions qui désignent d’une manière normative les valeurs identiques agiles et les règles qui les régissent.

 

2 – Avantages de la méthode agile

Un grand bouleversement s’est apparu avec la méthode agile dans le monde de gestion des projets informatiques. Les nuances flagrantes entre les méthodes classiques de gestion et celles qualifiées d’agile sont expliquées dans la matrice qui suit :

A la lecture de cette matrice, il convient de déduire que les méthodes agiles  sont particulièrement destinées aux projets de grande dimension pour leur conférer davantage des atouts en raison de l’augmentation de la visibilité et de l’adaptabilité. Cela permet de mieux maîtriser les risques. Mais elles sont également spécifiées pour permettre au client de suivre la progression des projets qui ne nécessitent pas de documentations détaillées. Cela contribue à lui mieux satisfaire parce qu’on peut tout modifier suivant ses attentes au fur et à mesure que le projet avance.

 

En effet, les enjeux pouvant être attendus des méthodes agiles sont à l’ordre de six, à savoir :

 

• La qualité de la visibilité :

Elle confère notamment la possibilité du client de suivre la progression du projet.

• La communication permanente :

C’est un atout pour les échanges d’idées afin d’identifier les besoins du client pendant l’exécution du projet.

• La maîtrise des risques :

Les méthodes agiles permettent d’anticiper les éventuels obstacles.

• Le contrôle permanent :

Il sert à assurer le bon fonctionnement des produits livrés.

• L’implication des collaborateurs :

Il s’agit d’un élément fondamental dans la réalisation des activités pour mieux répondre aux besoins des clients.

• La maîtrise du budget :

Les découpages permettent de connaître en avance le budget nécessaire pour chaque itération et permettent au client d’en déterminer les marges de manœuvre en matière financière.

 

D – Les méthodes agiles : valeurs de base

Les valeurs de base prévues par le « Manifeste pour le développement agile des logiciels » à l’issue de la concertation des 17 experts sont de quatre ordres :

 

• « Les individus et leurs interactions, plus que les processus et les outils » :

Les méthodes agiles accordent plus de considérations à l’esprit d’équipe. A cet effet, la valeur prône pour la primauté des individus devant les outils et règles de procédure, pour la cohésion d’une équipe et surtout pour la communication permanente inter équipe. Cette valeur s’impose même s’il y a hiérarchie dans le cadre du travail de développement. Les échanges et dialogues entre l’équipe conditionnent beaucoup plus le succès du projet que les outils et les processus.

 

• « Des logiciels opérationnels, plus qu’une documentation exhaustive » :

C’est l’importance du fonctionnement de l’application qui tient compte dans la méthode agile. L’application constitue une des principales valeurs de cette dernière parce que la documentation technique ne joue qu’un rôle complémentaire pour la mise en œuvre du projet en tant que moyen de communication. En effet, la documentation est à renouveler périodiquement afin de s’assurer sur sa fiabilité. A cet égard, les commentaires des codes sont les éléments d’informations les plus pertinentes et plus utiles à clarifier pour faire comprendre facilement aux collaborateurs.

 

• « La collaboration avec les clients, plus que la négociation contractuelle » :

Il s’agit d’un détachement de la routine avec laquelle le client est exclu dès lors que le contrat soit signé parce que les négociations sont terminées. Au contraire, le moyen utilisé est de l’impliquer dans le processus afin de connaître ses besoins aussi bien avant, pendant qu’après la réalisation du projet. Par conséquent dans le cadre de cette collaboration, implication du client veut dire étroite collaboration avec le fournisseur lors de l’établissement du projet et communication permanente à celui-ci sur ses désirs par rapport aux produits livrés.

 

• « L’adaptation au changement, plus que le suivi d’un plan » :

Comme toute prévision rencontre d’imprévus, la planification établie au départ connaît toujours des modifications au cours des développements. Ainsi, la valeur agile est de devoir  permettre des changements. La flexibilité de la structure du logiciel est impérative pour pouvoir suivre ces changements.

 

La méthode agile s’écarte, donc, de la rigidité du système de gestion afin de s’adapter à la variation des besoins du client ou à ses changements par le biais d’une bonne communication.

 

E – Exposé des diverses méthodes agiles et analyses comparatives

Il existe diverses méthodes agiles, telles que :

 

• Le Scrum :

Littéralement, le terme scrum se traduit par les expressions : « mêlée au rugby ». Il s’agit de la méthode agile la plus vulgarisée à travers le monde. Ses spécificités résident dans la réduction des sprints ou itérations à un mois seulement et dans la réduction du formalisme. Ce dernier ne se compose que de trois points essentiels, à savoir :

 

– Les timeboxes comprenant la planification de sprint et de releases, la tenue de scrum quotidien, l’exercice de la revue de sprint et l’application de l’introspection,

 

– Les artéfacts contenant le backlog de produit, le plan de produit, le plan de sprint, le burdown/burnup de release et le burdown/burnup de sprint,

 

– Les rôles composés de ceux du Product Owner, du ScrumMaster et de l’équipe.

 

• L’XP Extreme Programming :

Fréquemment utilisé avec le scrum, l’XP Extreme Programming est beaucoup plus axé sur la réduction des coûts. Etant donné qu’une estimation est préalablement fixée pour chaque itération, c’est le prix à allouer par le client en cas de modification qui intéresse particulièrement cette méthode. Techniquement, elle concerne l’exercice par un binôme d’une revue permanente de code, la vérification par des examens préalablement au commencement des travaux de développement, la refactoring ou conception continue et la mise en métaphore des besoins.

 

• Le RUP ou Rational Unified Process :

Cette méthode est caractérisée par la combinaison des méthodes classiques avec la méthodologie nouvelle. Le RUP est parfois accusé d’être moins agile mais son principe est de découper le projet en itérations et dans chacune d’elles, de traverser un cycle de vie composé d’une inspection, d’une élaboration, d’une construction et enfin d’une transition.

 

Par voie de conséquence, les démarches du RUP sont plus complexes et plus budgétivores mais elles sont avantageuses pour les projets de grandes dimensions.

 

• Le FDD ou Feature Driven Development :

Le développement ainsi que le design sont les centres de préoccupation du créateur de cette méthode. A ce propos, le FDD consiste à utiliser les diagrammes UML pour formaliser un modèle objet. En outre, sa technique est de subdiviser les fonctions pour que chacun des membres d’une équipe ait sa part d’activités à réaliser. Par ailleurs, le contrôle de la qualité et la qualité des produits à livrer sont exigées avec cette méthode.

 

• Le RAD ou Rapid Application Development:

S’érigeant en la première méthode qualifiée véritablement d’agile avec les nouvelles techniques extrêmement différentes de la méthode classique, le RAD a apporté à la gestion de projet les caractères « itératif et incrémental ». Les objectifs du RAD étant de réaliser le projet dans un délai raccourcis, de mieux maîtriser les risques, d’assurer une visibilité et de diminuer les dépenses. Dans cette perspective, le temps imparti pour un cycle de développement ne dépasse pas quatre mois ; néanmoins, le délai minimum est de trois mois. Ce cycle passe par le design et la construction, du cadrage vers la finalisation.

 

• Le DSDM ou Dynamic Systems Development Method:

Utilisée par les Britanniques en 1995, cette méthode avait déjà emprunté les valeurs et principes agiles comme : le cycle de développement itératif et incrémental, la meilleure visibilité, l’implication des parties prenantes, la motivation des équipes, l’adaptatif et le contrôle qualité.

Dans le cadre des méthodes agiles, il existe des modes de fonctionnement identiques, comme :

 

• La meilleure coordination de travail d’équipe :

Ce qui implique une capacité de l’équipe à intégrer le client dans le processus, à prendre des dispositions adéquates devant toute situation, à se doter d’une autosuffisance dans l’organisation du travail, à savoir identifier les besoins de chaque individu et à trouver un accord avec le client.

 

• Les modes de fonctionnement en matière de pilotage de projet :

Il est nécessaire de pratiquer dans le cadre de pilotage de projet, une différenciation suivant le degré des enjeux, de la typologie de méthodes à utiliser. En effet, le projet est piloté dans l’entière connaissance des enjeux ainsi que dans la maîtrise des risques.

 

Il convient également d’appliquer une célérité des itérations comme étant un fondement des stratégies et de la planification. A cet effet, les itérations sont les repères dans l’exécution du développement auquel la règle d’or est de rationnaliser les pratiques et renforcer les expériences.

 

• L’identité des processus de démarche qualité dans la production :

Dans le cadre de la conception, la méthode agile requiert un perfectionnement des techniques à exploiter, l’utilisation d’une modélisation représentée par une graphique claire, l’exploitation d’une documentation complète, l’emploi d’un code métrique normatif et de qualité, l’usage d’une architecture conforme et la facilitation des modifications.

 

Pourtant, il reste toujours quelques particularités de ces diverses méthodes notamment sur le plan technique. Les différences sont minimes mais tiennent compte de la dimension du projet et à ses catégories. On peut citer comme points de dissection de ces méthodes :

 

• Pour le RAD :

D’une part, cette méthode emprunte les techniques d’XP pour la construction de l’application, telles que :

• La documentation avec les revues de codes personnelles,
• La documentation avec les revues de codes collectives,
• L’intégration préalablement au show.

 

D’autre part, la méthode réserve aux parties du projet considérées comme d’importance capitale, la programmation en binôme.

 

Par ailleurs, le RAD exige automatiquement l’engagement d’une personne chargée de l’animation et de la facilitation malgré que tout pilotage de projet doive être assorti d’un mode opératoire afin de signaler les impératifs d’arrêts. Cette personne joue un rôle capital dans l’intermédiation entre les participants et la hiérarchie suprême formant les ressources humaines du projet. Elle est obligée de faire preuve d’impartialité. Les tâches incombées à cet animateur-facilitateur sont axées aux informations à l’organe suprême de tous les changements des facteurs conditionnant le projet sans qu’il n’effectue une appréciation sur la nécessité d’informer ou non dès que les nouvelles touchent le projet. Il en est du domaine de la technique, de l’économie ou de la stratégie. A partir de ces reportages,  il appartient à l’autorité suprême de fixer les dispositions adéquates.

 

• Pour le RAD 2 :

D’un côté, cette méthode se diffère des autres par la prise en compte d’une nécessaire proportionnalité entre les membres composant une équipe ainsi que les engagements à leur confier et les différentes phases qui forment un projet. La finalité de cette technique est de rationnaliser la gestion des ressources humaines par la motivation d’abord et par l’adaptation du travail ensuite. Sa particularité s’affiche ainsi sur l’instauration du GAR ou Groupe d’Animation et de Rapport.

 

D’un autre côté, le RAD 2 utilise l’organisation des réunions pour déterminer les modes opératoires de communication et les techniques pour l’obtention de la validation des utilisateurs finaux.

 

Enfin, la livraison par thème est adoptée par le RAD 2 pour garantir un pilotage stratégique.

 

• Pour le DSDM :

L’unique spécificité de cette méthode s’avère l’insertion du concept de « rôles » car le DSDM vise quelques catégories de personnes dans la réalisation d’un projet, telles que : les rapporteurs, les agents diplomatiques, les clients, les conseillers, l’animateur-facilitateur.

 

• Pour le scrum :

D’abord, le scrum se distingue des autres méthodes par l’organisation de rétrospectives et de courtes réunions durant le cycle de développement.

 

Ensuite, les briefings ainsi fixés sont utilisés pour les échanges d’acquis ou d’obstacles, pour la résolution des problèmes, pour l’implication des collaborateurs, pour la répartition des travaux.

 

• Pour le FDD :

L’importance particulièrement accordée au caractère « itératif » du cycle de développement est la plus remarquable dans cette méthode. L’atteinte d’objectif vérifiable en un intervalle de temps la plus courte est l’essentiel pour les partisans du FDD.

 

• Pour le XP Extreme Programming :

Le planning game fait la grande différence de cette méthode car il consiste à engager les clients en même temps que les développeurs. Le premier souci dans cette méthode est, donc, l’établissement de l’application. Mais elle ne néglige pas la qualité de la production du code par la vérification régulière.

 

 

II – Focus sur la méthode Scrum, la méthode agile la plus populaire

De nos jours, le scrum est de plus en plus vulgarisé grâce à sa simplicité, à sa facilité et à son exhaustivité. Pourtant, il convient de souligner que les pratiques propres au scrum n’ont pas suffi pas à elles seules pour garantir la réussite du projet, celles-ci ont toujours été pratiquées de pair avec les principes et les valeurs agiles.

 

Bon nombre de projets ont pu bénéficier de la méthode scrum. Toutefois, le scrum est spécifiquement conçu pour des projets dont le périmètre n’est pas rigoureusement inchangeable et auxquels les clients attendent une possibilité de contrôle de l’évolution et plus de visibilité. Autrement dit, le scrum est destiné au projet auquel le client veut jouer un rôle actif dans le cycle de développement.

 

En effet, obligation s’impose au client d’avoir une large disponibilité afin d’effectuer le suivi car il s’agit d’un paramètre substantiel pour la sélection du scrum. Du côté des développeurs et du chef de projet, le scrum impose l’obligation de rapidité dans la compréhension des attentes des clients qui surveillent étroitement. Ce qui implique une certaine réduction de l’écart entre les attentes à satisfaire et le concept équipe que l’on appelle qualité du product.

 

A – Définition de la méthode Scrum

Assimilée à la technique pratiquée dans la mêlée de rugby, la notion de cohésion d’une équipe ainsi que la stratégie de fixer la vision dans le même sens et également dans une unique direction sont adoptées par la méthode scrum.

 

Tel que le schéma ci-dessous le démontre, il convient d’appréhender l’importance de l’esprit d’équipe dans le scrum par approche comparative avec la mêlée de rugby :

 

 

Inventée au début du troisième millénaire, la méthode scrum fait partie intégrante des méthodes agiles. La dénomination a été tirée du terme mêlée dans le rugby. Ainsi, le scrum consiste à travailler sur des « sprints » que l’on appelle également « itérations » avec lesquelles la durée de développement est inférieure à 30 jours.

 

Afin de mieux comprendre le processus, le schéma suivant éclaircit les techniques du scrum[5] :

 

Bien qu’il existe des pratiques communes dans les méthodes agiles, notamment entre les pratiques du scrum et de l’XP Extrem Programming, le premier n’a pas opté pour la pratique d’ingénierie.

 

Dans l’optique d’accélérer l’évolution du projet en même temps que de permettre un dialogue ou échange d’informations/d’expériences au sein de l’équipe, les tâches et les engagements de chacun des membres de l’équipe sont délimités par le biais d’un workflow et les entretiens continus ainsi que la communication sont exercés à travers des artefacts.

 

Le « planning poker » est exploité dans la méthode scrum préalablement au commencement des travaux relatifs à un sprint. Les objectifs à atteindre étant de pouvoir décortiquer les éventuels obstacles et risques et de définir la durée nécessaire pour réaliser chaque tâche. Ainsi, le planning poker permet de mesurer concrètement les obstacles et leur progression par le biais des cartes tout comme dans le rugby. En même temps, les prévisions en déduites servent pour la planification et l’estimation budgétaire à proposer à l’utilisateur final.

 

Le « sprint backlog » n’est rien d’autre que le produit de l’ « user stories » c’est-à-dire les fonctionnalités ayant subi les découpages en itérations ou sprints. En matière de scrum, l’ensemble de sprint backlog forme le « product baklog » ou le résultat intégral de tous les sprints.

 

Dans le cadre du contrôle de l’évolution du développement, la méthode scrum applique le « morning » ou le « stand-up » tout comme dans une mêlée quotidienne où tous les intervenants exposent lors de cette occasion les activités qu’ils ont chacun réalisé et leurs prochaines tâches. Tous les travailleurs à tout niveau sont obligés d’y assister, comme : l’organe de décision, les responsables techniques ainsi que les développeurs. C’est également une stratégie de mobilisation des intervenants, un moyen pour sauver les membres d’une équipe freinés par des obstacles.

 

Malgré que le scrum soit la méthode agile la plus vulgarisée, elle est pourtant la moins utilisée. Elle est la plus vulgarisée parce qu’elle est répandue dans plusieurs supports aussi bien matériels qu’électroniques, tels que : les manuels et les vidéos et les blogs. Le scrum fait également l’objet de bon nombre de conférences. Certain cursus académique ou professionnel insère le scrum dans ses disciplines. Mais les chefs de projet choisissent la méthode scrum en dernier moyen en raison de la complexité à surmonter pour pouvoir la maîtriser.

 

A cet effet, il faut un ensemble composé de trois éléments importants pour constituer le « framework » pilier du scrum :

 

• Les rôles également composés de trois éléments de base :

 

• Le rôle lié du Product Owner : basé sur la fixation de la vision sur le produit attendu par les utilisateurs finaux,
• Le rôle lié à la mise en œuvre des techniques scrum incombé notamment au Scrum Master,
• Le rôle lié à l’exécution des tâches sur le développement proprement dit.

 

• Les réunions,

Le cycle de développement avec la méthode scrum est cadencé par des timeboxing ou des briefings dont les objets sont délimités d’une manière très concise, tels que :

 

• La priorisation des fonctionnalités à développer à la suite des découpages en sprints que l’on appelle « Planification du Sprint » suivant l’ordre de priorité des prints blaklogs à atteindre convenu avec le Product Owner,

 

• L’exposé par les développeurs des fonctionnalités achevées dans chaque sprint que l’on appelle « Revue de Sprint » avec laquelle on attend le retour, les remarques ou critiques des clients. Lors de cette réunion, il est aussi fixé la nouvelle dimension du sprint suivant dont la détermination tient compte de l’effectif de sprints en instance,

 

• La recherche du perfectionnement de la méthode tiré de l’expérience à la suite de la revue de sprint que l’on appelle « Rétrospective de Sprint » dont plusieurs domaines sont examinés comme : les procédures, les qualités, les coûts…,

 

• La « mêlée quotidienne » proprement dite dont la réunion dure un quart d’heure pour les développeurs afin de s’auto évaluer tous les jours par rapport à l’unité mêlée : les activités réalisées, à réaliser et enfin les obstacles.

 

• Les artefacts.

C’est dans ce cadre qu’intervient les communications échangées par rapport aux rôles et dans le cadre des réunions.

En gros, la figure ci-après récapitule les procédures dans le scrum[6] :

 

 

 

 

Par ailleurs, la maîtrise de la méthode scrum exige le respect scrupuleux de trois valeurs :

 

• L’amélioration continue de la visibilité :

Le scrum impose qu’il y ait prévision surtout par rapport au produit.

• L’exercice de l’inspection :

Dans la méthode scrum, il ne devrait y avoir de distance non raisonnable entre les travaux réalisés et les prévisions préalablement déterminées.

• L’adaptation :

Lorsque distance existe, les développeurs sont obligés de la rattraper par les ajustements.

 

B – Historique de la méthode SCRUM

Le domaine de l’industrie a été le premier à emprunter le terme « scrum » du rugby dans les milieux des années 80 pour désigner la méthode émergente pour l’accélération et la souplesse dans la production de biens. La première diffusion a été lancée officiellement dans « The New Product Development Game »[7]. Dans cette œuvre, les auteurs ont fait référence au rugby à 15 joueurs. Ainsi, ils ont expliqué que le processus d’exécution se superpose, que les membres d’une équipe disposant chacun des potentialités s’unissent lors de la division en phase et avancent dans une même direction.

 

Par opposition au scrum de nos jours, le terme suppose à cette époque la répartition en phases, le caractère concourant de l’ingénierie, l’existence d’une disparité de compétences dans un même projet et les superpositions de phases.

 

Puis, la méthode scrum a fait l’objet d’une recherche par Ken Schwaber dans le milieu des années 90. D’après la prévision de cette personnalité à l’époque, l’organisation de communication permanente aurait dû baser le scrum.

 

En effet, il s’est associé avec Mike Beedle au début du troisième millénaire afin de sortir un œuvre intitulé « Agile Software Development With Scrum ».

 

Cependant, cet ouvrage n’a pas été édité que vers le milieu des années 2000. Ce n’était qu’au tout début du XXIème Siècle que le scrum guide, contenant les pratiques de la méthode scrum, ait été  publié par Jeff Sutherland et Ken Schwaber.

 

C – Caractéristiques de la méthode SCRUM

Contrairement au cycle en cascade ou en V, le scrum se caractérise par la considération du fait que les travaux relatifs au développement logiciel ne sont pas toujours faciles à réaliser et que la planification et la prévision y afférentes ne peuvent pas toujours être programmées entièrement au début du processus.

 

Par conséquent, l’empirisme est le fondement du modèle de contrôle qui fait la particularité du scrum pour remédier et maîtriser les imprévus. C’est cette base qui fait que le projet géré avec la méthode scrum soit susceptible de subir les changements suivant les véritables besoins du travail et les évolutions du contexte. Il s’agit donc d’un moyen pour valoriser le caractère adaptatif du cycle de développement. En ce qui concerne la réalisation en temps voulu des travaux, c’est à travers cette adaptation de la planification aux modifications en cours, assortie de la subdivision en itérations que la célérité ait lieu dans le scrum.

 

La méthode Scrum est élaborée aussi bien pour le développement de logiciel que pour la maintenance. Pour les projets de très grandes dimensions, on utilise ce que l’on appelle le « Scrum de Scrums » parce que le nombre des intervenants est forcément considérable (notamment l’effectif des développeurs). En tout état de cause, la méthode scrum s’utilise quelque soit la situation qui entoure le projet, quelque soit la catégorie des membres composant un groupement (religieuse, administrative, scolaire, médecine…) afin d’arriver à un objectif commun.

 

La règle de rigueur dans toute méthode agile étant la forte implication des utilisateurs finaux. Il s’agit d’un moyen pour faire un choix rationnel sur les fonctionnalités à développer  dans chaque incrément. Ces derniers disposent la faculté de dresser une nouvelle liste de fonctionnalités en cour d’exécution des travaux dans l’optique d’en ajouter ou d’en changer après chaque sprint achevé. Indépendamment des finalités des sprints fixées préalablement au développement, ils ont la possibilité de revoir les conventions en cours d’exécution avec les développeurs lorsqu’ils aperçoivent un besoin de modification. Ils peuvent aussi estomper une itération en cours si les finalités sont devenues inadéquates à la suite de cette demande de révision.

 

En effet, la simplicité du pilotage du projet dans la méthode scrum est ainsi due à l’utilisation de l’incrément correspondant à chaque sprint. En outre, le caractère adaptatif est assuré par le découpage en itération dont seul le but de chaque sprint est la limite.

 

A cet égard, ci-après les règles de pratique qui régissent le scrum :

 

• L’obligation de transparence :

Il doit y avoir une unique vision au sein des intervenants par le biais d’un langage commun, lequel doit aboutir à un même niveau d’entendement sur la conception du projet.

• L’exercice d’inspections :

Périodiquement, des vérifications des produits sont exercées pour identifier tout mauvais développement que l’utilisateur final souhaite surtout modifier. Dans la mesure où la découverte d’un tel cas exige l’arrêt du développement pour trouver d’autres résolutions, il est inéluctable que l’inspection soit faite par un expert.

• L’adaptation aux changements :

C’est dans cette règle que les diverses réunions obligatoires dans le scrum s’avèrent importantes. Ceci, car obligation s’impose aux intervenants de faire adapter le processus aux impératifs de changements découverts lors de l’inspection. A titre de rappel, les réunions sont composées de la planification du sprint, la revue de sprint, la rétrospective de sprint et la mêlée quotidienne.

 

D – Organisation générale de la méthode Scrum

Cette organisation est composée de trois éléments, à savoir :

 

• Les préparations :

La première préparation la plus importante et fondamentale en matière de méthode scrum est la détermination du « Product Backlog ».

 

A titre d’illustration, le tableau suivant démontre une typologie de cette préparation dans la création d’un site de commerce en ligne[8] :

 

Elément du backlog	Estimation
Un internaute peut rechercher un article selon différents critères	5
Un gestionnaire du catalogue de produits peut ajouter des articles	2
L’internaute peut acheter en ligne un ou plusieurs articles	3
…	…

 

La deuxième préparation consiste pour le product owner de communiquer la liste des fonctionnalités à développer suivant ses propres analyses de leur opportunité, de sa situation budgétaire et de sa conception des risques à encourir. Ensuite, il appartient aux développeurs d’organiser leurs tâches suivant la priorité du product owner.

 

Troisièmement, il est déterminé, le temps imparti pour la réalisation du Product Backlog suivant le découpage en sprints. En d’autres termes, c’est le délai pour chaque sprint qui est déterminé car la célérité de la production d’une grande valeur ou le time to market.

 

• La planification des sprints :

Dès lors qu’il y eu convention avec le product owner et que le Product Backlog déterminé, on établit la planification des sprints. Il s’agit d’un moment crucial pour le premier car c’est une communication ou même échange avec les développeurs qui maîtrisent parfaitement les détails techniques, lequel contribue à la détermination concise des tâches de ceux-ci.

 

Force est de relever qu’il importe peu de faire une conception décortiquée  en séance puisqu’il existe une forte probabilité de modification demandée par le client. Cette modification est liée à la possibilité accordée au client de passer en revue les exigences non insérées dans les sprints. Il peut y avoir également de modification de l’initiative des développeurs pour des raisons techniques relatives au périmètre d’un sprint.

 

Lorsqu’un sprint est achevé, on organise une revue de sprint et une rétrospection et on délimite les activités prochaines pour les sprints restants.

 

• Le suivi de l’avancement :

A l’aide d’un graphique de suivi de l’avancement, formé à partir du découpage en sprints et de la répartition des tâches liées aux exigences, on peut voir clairement la progression du projet dans la durée impartie.

 

E- Objectifs et avantages de la méthode Scrum

Parmi les objectifs de toute méthode agile, la gestion de projet de grande dimension à laquelle l’ensemble du périmètre ne peut être délimitée en avance constitue surtout ses raisons d’être.

 

Auparavant, les développeurs se contentaient  des méthodes de gestion en cascade car ce sont les méthodes classiques mondialement connues. Puis, ils ont utilisé le cycle de développement en V pour permettre la correction des erreurs sans revenir dans les phases précédentes. Ils se sont rendu compte de la rigidité de la méthode cascade et inventent ainsi la méthode cycle V qui s’explique comme suit :

 

• Les phases de conception sont reflétées par la barre oblique descendante,
• Les examens des livrables correspondent à la barre oblique montante,
• L’exécution entière des tâches constitue le sommet du V.

 

Le schéma suivant illustre ces explications[9] :

 

 

 

Afin de résoudre ce problème de rigidité et de suivre l’évolution le long du cycle de développement, la méthode scrum est inventée. Grâce à scrum, on peut facilement changer les spécifications. Désormais, les réajustements sont faisables dans la limite de l’objectif d’une itération. La bonne gestion des imprévues dans le contexte forme l’essence du scrum.

 

Nombreuses sont les avantages de la méthode Scrum, à citer :

 

• Ressources humaines impliquées :

On parle dans ce cas de la participation active et en toute motivation des agents dans la détermination des tâches et de la durée.

• Qualité de la visibilité :

Le scrum offre la possibilité de voir en globalité le projet tout entier : les produits déjà livrés peuvent être consultés de nouveau par tous les intervenants.

• Diminution des bugs :

Cela implique une meilleure qualité des développements.

• Révision dans la priorisation :

C’est possible grâce à la flexibilité.

• Valorisation de la qualité :

Il ne suffit pas de se contenter d’atteindre les échéances de livraisons, le scrum impose une qualité des livrables.

• Réduction de l’effet tunnel :

Ce bénéfice est tiré du cycle itératif et incrémental.

• L’adaptabilité :

Il s’agit même de la caractéristique de toute méthode se prétendant d’agile.

• Le renforcement de la communication :

Cela s’effectue non seulement par le biais des réunions mais aussi par les divers outils de communication.

• Le renforcement de la coopération :

On parle notamment de la coopération avec les utilisateurs finaux.

• L’amélioration de la productivité :

 

On obtient cette qualité de productivité par la rationalisation des processus et par l’utilisation des meilleures techniques.

 

F – Risques à maitriser dans la mise en œuvre de la méthode Scrum

Malgré les novations apportées par la méthode scrum, on ne peut pas avancer qu’elle résolve systématiquement toutes les difficultés. Les facteurs de risques doivent être analysés et il faut prévoir des méthodes pour les gérer :

 

• La précaution sur la dimension d’une équipe :

Au maximum, une équipe est composée d’une dizaine de membres. Cette mesure vise à éviter toute difficulté liée à la gestion des ressources humaines et à l’organisation de leurs travaux. L’excédent d’effectif va à l’encontre du principe selon lequel les réunions et communications sont primordiales au sein d’une équipe pour qu’il y ait avancement dans une seule direction. Cela étant puisque  l’équipe rencontrera des problèmes pour les réunions, pratiques obligatoires dans la méthode.  C’est la raison pour laquelle, le scrum du scrum a été proposé.

 

• La précaution liée à l’existence de demandes multiples :

Le problème se situe notamment dans le cadre de l’attente de validation lorsqu’il y a demandes contradictoires. Il convient, donc, d’exploiter un seul outil de gestion des demandes.

 

• La précaution nécessaire pour la qualité des développements :

La qualité peut varier en fonction des nombres d’équipes pour les projets partagés dans des sites différentes. Lors de l’intégration, il risque d’y avoir erreurs sur le code ou autres omissions. Par voie de conséquence, il faut disposer d’une politique qualité et multiplier les audits de codes.

 

DEUXIEME PARTIE : Les méthodes agiles et Dévops : analyse des liens

Les analyses théoriques et conceptuelles sur devops doivent être effectuées afin de pouvoir déterminer ses liens avec les méthodes agiles ci-dessus expliquées.

 

I – Devops : analyses théoriques et conceptuelles

A cet effet, ces analyses sont composées de cinq substances, à conjuguer :

 

A – Définition

Vers la fin des années 2000, les termes anglais « development » associé avec « operations » [10] ont formé le concept « devops » pour la première fois en Belgique. La technique a été inventée à l’époque pour reformer la qualité des projets informatiques. Elle a été menée par des développeurs, des agents spécialisés dans l’exploitation et dans les vérifications ou inspections, par des chercheurs dans le domaine de l’évolution contextuelle des informatiques, par des experts en organisation, par des professionnels en méthode agile.

 

En effet, devops constitue une méthodologie établissant un cadre de travail dédié aux concepteurs de projet et aux professionnels du domaine donné pour la mise en place d’une méthode commune dans un but d’atteindre une meilleure qualité de prestation.

 

C’est à partir de l’efficacité des entreprises œuvrant  dans le cadre du web qu’agissent les agents qui se prétendent de devops. Leurs finalités sont claires : offrir une novation aux entreprises, leur permettre d’exploiter des outils performants et d’en percevoir des résultats concrets et mesurables. Les web les plus ciblés à cet effet sont : Google, Yahoo et Amazon.

 

La soumission limitée aux principes rigoureux et l’apport de changement dans le domaine de de l’informatique constitue les préoccupations dans la création du mouvement devops. Cela s’effectue dans une optique de mobiliser les ressources afin de renforcer ses potentialités.

 

B – Historique et origine

La chronologie de l’histoire du devops se présente comme suit :

 

Vers la fin des années 2000, des problèmes sérieux se sont apparus en Belgique en matière d’interactivité entre l’administration des réseaux et systèmes et les simples développeurs. Le fondateur du mouvement Patrick Debois s’est obligé lui-même de trouver des issues car il a été l’expert à qui la mission d’administration de système a été attribuée.

L’année suivante, l’« Agile Systems Administration Group » a été organisée par lui et Andrew Shafer.

 

Un an plus tard, d’autres développeurs (John Allspaw et Paul Hammond) ont organisé d’autres conférences pour démontrer les résultats positifs de l’assemblage des « dev » avec les « ops ».

 

Finalement, le 30 octobre 2009, la conférence dénommée « DevOpsDays » organisée par  Patrick Debois s’est tenu lieu en Belgique pour publier officiellement le mouvement devops.

 

Cette personnalité avait confirmé que la dénomination « devops » convient le mieux au mouvement car c’est plutôt court que « Agile Administration System » même si les significations sont exactement les mêmes. Dans son discours, il a bien mentionné que : “There never was a grand plan for DevOps as a word.”

 

Actuellement, l’évolution du mouvement devops est incontournable. La dimension émergente des tâches relatives au devops prend sa place dans bon nombre d’entreprises et les conférences sur les DevOpsDays se sont multiplier au niveau mondial.

 

C – Positionnement actuel du Devops

Cette année encore, le quart des groupes de grandes envergures exploite le mouvement devops. Ce qui fait les 500 organisations mondiales.

 

Ces chiffres tendent vers un accroissement considérable car l’objectif de devops pour la fin de cette année est d’occuper un marché de 2,3 milliards de dollars. La relève est atteignable puisque la technique consiste à mettre en place une forte cohésion des développeurs avec les membres des équipes de la production et de recette. Selon un haut responsable du mouvement, une seule année pourrait faire du devops un mouvement le plus recommandé par les entreprises puissantes.

 

Une estimation d’une multiplication de deux fois des chiffres d’affaires réalisés dans le marché des technologies de devops est envisagée. Pour les Etats – Unis, il s’agit d’un marché dit « virtuel ». Mais devops cherche à rationnaliser la gestion des programmmations au sein des entreprises.

 

A cet effet, la quasi-totalité des entreprises implantées en France procède pour le mouvement devops car les apports en sont saisissables. A titre d’illustration, les investigations effectuées par Vanson Bourne démontrent que les entreprises ayant fait plus de demandes en mouvement devops depuis des années sont beaucoup plus puissantes que celle qui n’a pu commencer à l’exploiter que tout récemment. Les Français envisagent ainsi d’utiliser devops pour rythmer la livraison d’applications.

 

Plus techniquement, le schéma ci-dessous représente les atouts dans l’exploitation du mouvement devops :[11]

 

 

D – Obstacles dans la mise en œuvre du devOps

L’organisation et la culture forment les obstacles fondamentaux du devops. Sur le plan culturel, les attitudes de travailler isolément dans une diversité d’objectifs sont difficilement résolvables. Sur le plan organisationnel quant à lui, avec devops, il faut procéder à la mise en place d’un ITIL pour découper le processus de la DSI au lieu de l’IT qui exige une structuration en silos.

 

E – Les bonnes pratiques de mise en œuvre du DevOps

Quatre bonnes pratiques régissent le devops :

• La redéfinition des objectifs des équipes :

Il est obligatoire d’en redéfinir en même temps les indicateurs d’objectifs.

• Tirer profit de la réussite des autres :

L’analyse de Denis Herriau[12] démontre que cette réussite commence par l’application du devops sur un périmètre très restreint et sur l’extension progressive.

• L’accompagnement des équipes dans le changement.
• L’équipement en une structure adéquate au mouvement devops.

 

II – Devops et méthodes agiles : les liens

Trois points importants marquent les liens entre devops et les méthodes agiles, à savoir :

 

• L’implication des équipes dans le processus :

Devops ne se contente pas de l’obligation de la dotation en outils mais met l’accent sur les réorganisations d’une équipe dans l’optique de faciliter la communication et renforcer la cohésion. C’est là l’importance de leur accompagnement dans le cadre du changement de méthode car il faut considérer le concept « mutation » à laquelle il existe toujours des résistants.

 

• Le poids de la communication :

Une communication permanente subsiste entre les deux catégories d’équipes (développement et opérations). Le code étant le point de convergence des informations obtenues par eux pour adapter le travail au contexte.

 

Cette communication permanente est inéluctable en mouvement devops car ce sont les développeurs qui disposent les informations relatives aux outils et processus avec lesquels les équipes opérationnelles vont devoir travailler. En outre, il est vital que  la fluidité des informations existe pour la meilleure gestion des ressources et pour les modifications nécessaires en vue de satisfaire les clients.

 

A titre d’illustration, devops a pu résoudre le problème de gestion de logs et d’exceptions existant en matière de production par la communication et la mise au point entre les équipes sur les difficultés rencontrées.[13]

 

• La convergence des objectifs et l’unité de la vision.

 

 

CONCLUSION

En guise de conclusion, la distance entre le travail et les techniques pour l’accomplir est réduite depuis l’apparition des méthodes agiles vers le XIXème Siècle. La conformité et la correspondance sont devenues dominantes et ont conduit à la réussite des projets informatiques à travers le monde. Des nouveaux rôles se sont émergés pour rendre identiques les méthodes de travail : on constate une forte progression des chiffres d’affaires des entreprises ayant su profiter des pratiques, principes et valeurs nouveaux. Cela a renforcé la cohésion et la motivation des équipes de travail dans le développement.

 

Parmi les nombreuses méthodes agiles, telles que : l’XP Extrem Programming, l’ASD, le SFD, le Kanban…, la méthode scrum est la plus connue et la plus diffusée dans le monde et elle est la première méthode agile la plus performante. De par sa définition, on peut sortir ses caractéristiques propres comme : l’empirisme comme fondement de son modèle de contrôle, une méthode conçue aussi bien pour le développement de logiciel que pour la maintenance, une possibilité de pratiquer le « Scrum de Scrums », le respect de la règle de rigueur d’impliquer activement les utilisateurs finaux, la simplicité du pilotage du projet dans la méthode scrum due à l’utilisation de l’incrément correspondant à chaque sprint.

 

Le scrum conduit toujours au succès du projet pour trois raisons : l’adaptation aux changements, l’exercice d’inspections et l’obligation de transparence. Ceci étant car la flexibilité est la règle d’or dans le scrum afin de satisfaire réellement les utilisateurs finaux qui n’aperçoivent  exactement les fonctionnalités qu’ils veulent développer qu’à travers la parfaite connaissance du fonctionnement d’un produit déjà livré ou à partir des informations qu’ils ont recueilli lors des diverses réunions, principe de base des méthodes agiles. Ainsi, son organisation se déroule toujours en trois étapes, à savoir : le suivi de l’avancement, la planification des sprints et les préparations.

Plusieurs avantages découlent de cette méthode scrum, sans ne citer que les plus importantes comme : la possession des ressources humaines impliquées, la qualité de la visibilité, la diminution des bugs, la révision dans la priorisation, la valorisation de la qualité, la réduction de l’effet tunnel, l’adaptabilité, le renforcement de la communication, le renforcement de la coopération et l’amélioration de la productivité.

 

En raison de ces caractéristiques, principes, valeurs et avantages des méthodes agiles, dont le scrum notamment, il existe des liens indiscutables entre elles et le mouvement devops. Ce que veut réaliser les dirigeants de projet avec devops est de doter le projet d’équipements  en structure plus adéquate au mouvement devops, d’en redéfinir les objectifs des équipes ainsi que les indicateurs, de tirer profit de la réussite et de l’expérience des autres par l’application du devops sur un périmètre très restreint et sur l’extension progressive par la suite et enfin et surtout d’accompagner les équipes dans l’accomplissement du changement.

 

Dans le cadre de ces liens, les principaux points d’intersections des diverses pratiques propres aux méthodes agiles et celles de devops sont matérialisés dans l’implication des équipes dans le processus, la réorganisation d’une équipe, le poids de la communication entre les équipes aussi bien de développement que d’opérations dont le code étant le point de convergence des informations. Le territoire dans lequel est très pratiqué le devops est celui de la France car rien qu’au bout d’une année d’exploitation de devops, les chiffres d’affaires réalisés par les entreprises œuvrant dans l’informatique se sont multipliés deux fois et la même rentabilité est espérée cette année par bons nombres d’entreprises. Mais les stratégies pour la maîtrise des risques sont à renforcer avec le monde de l’informatique et face à l’intensification de la concurrence sur le marché mondiale.

 

BIBLIOGRAPHIE

 

[1] Effectuée par Standish Group en 1994

[2] Il s’agit de la troisième vague de publication après celle de Mike Beedle en 2001 et de Ken Schwaber en 1995.

[3] Année de publication : 1999

[4] Source : Manifeste pour le développement Agile de logiciels

[5] Source : http://www.mcnext.com

[6] Source: http://ineumann.developpez.com/tutoriels/alm/agile_scrum/

 

[7] Ecrit par Hirotaka Takeuchi et Ikujiro Nonaka

[8] Source : http://www.agiliste.fr/fiches/introduction-methodes-agiles/

[9] Source : http://blog.dcube.fr/blog/2014/04/28/scrum-vs-cycle-en-v/)

 

[10] Ou développement et exploitation.

[11] Source schéma : http://www.journaldunet.com/developpeur/algo-methodes/devops.shtml

 

[12] Sales Director chez CA Technologies

[13] Source : http://www.journaldunet.com/developpeur/expert/57372/agilite—du-developpement-logiciel-a-la-culture-produit.shtml