Ministère de l’enseignement supérieur et de la recherche

scientifique
Ecole nationale supérieure de management

Année d’étude : 1ère année master.

Spécialité : management stratégique et système d’information.

Module :gouvernance si

Professeure : Mme TOUMI.

Etudiante : Gharbi Mohamed chakib

Les projets d’ingénierie ou de recherche deviennent aujourd’hui de plus en
plus complexes, non seulement sur les aspects techniques ou scientifiques,
mais également sur d’autres aspects comme la complexité des produits, le
nombre d’acteurs (éventuellement de nationalité et de culture fort
différentes), des législations différentes. Cette complexité croissante
demande une organisation minimale pour structurer les projets. De plus ,
avec l'évolution de la technologie , la multitude de taches proposée aux
consommateurs ainsi que les différents domaines desservis par l'informatique
la gestion et la planification des logiciels devient de plus en plus
ardu d'où la nécessité de la mise en œuvre d'un programme afin de faciliter
cette gestion et surtout d'économiser du temps et de l'énergie . 

Au début, le développement de logiciels ne faisait pas vraiment partie d'un

cadre de gestion particulier. Puis vint la cascade, qui évoquait l'idée que le
développement de logiciels pouvait être défini par la durée de création ou de
construction d'une application.
À l'époque, la création, le test et le déploiement de logiciels prenaient
souvent de longues périodes, car il n'y avait pas de freins et contrepoids
pendant le processus de développement. Les résultats ont été une mauvaise
qualité logicielle avec des défauts et des bogues et des délais non
satisfaits. L'accent a été mis sur des plans longs et longs pour des projets
logiciels.
Les projets en cascade ont été associés au modèle à triple contrainte,
également appelé triangle de gestion de projet. Chaque côté du triangle
représente une composante des triples contraintes de la gestion de
projet : portée, temps et coût. Comme l'écrit Angelo Baretta, le modèle à
triple contrainte dit que le coût est fonction du temps et de la portée, que ces
trois facteurs sont liés de manière définie et prévisible ... Si nous voulons
raccourcir le calendrier (temps), nous devons augmenter les coûts. Il dit que si
nous voulons augmenter la portée, nous devons augmenter les coûts ou le
calendrier. "
La cascade est venue de la fabrication et de l'ingénierie, où un processus
linéaire a du sens ; vous construisez le mur avant de construire le toit. De
même, les problèmes de développement logiciel étaient considérés comme
quelque chose qui pouvait être résolu avec la planification. Du début à la fin,
le processus de développement était clairement défini par une feuille de
route qui conduirait à la livraison finale d'un produit.
Finalement, la cascade a été reconnue comme nuisible et contre-intuitive au
développement de logiciels parce que, souvent, la valeur ne pouvait être
déterminée qu'à la toute fin du cycle du projet, et dans de nombreux cas, les
projets avaient échoué. De plus, le client n'a pu voir aucun logiciel fonctionnel
avant la fin du projet.

La méthodologie agile découle du Manifeste pour le développement logiciel

agile publié par un groupe de développeurs en 2001. Elle définit une
approche collaborative plus adaptative, centrée sur le code et du
développement logiciel que celle mise en évidence dans Waterfall. Agile
adopte une approche différente qui s'éloigne de la planification de l'ensemble
du projet, s'engage à des dates estimées et est responsable d'un plan. Au
contraire, l'agile suppose et embrasse l'incertitude. Il est construit autour de
l'idée de répondre au changement au lieu de le dépasser ou d'en ignorer la
nécessité. Au lieu de cela, le changement est considéré comme un moyen de
répondre aux besoins du client.
Agile, est régi par le Manifeste Agile, qui définit 12 principes :
Satisfaire le client est la priorité absolue.
Accueillez l'évolution des exigences, même en retard de développement.
Fournir fréquemment des logiciels fonctionnels
Le développement et entreprise doivent travailler ensemble.
Construisez des projets autour de personnes motivées.
La communication en face-à-face est la méthode la plus efficace et la plus
efficace pour transmettre des informations.
La principale mesure du succès est le logiciel de travail.
Les processus agiles favorisent le développement durable.
Maintenir une attention continue à l'excellence technique et à une bonne
conception
La simplicité est essentielle.
Les meilleures architectures, exigences et conceptions émergent d'équipes
auto-organisées
Réfléchissez régulièrement au travail, puis ajustez et ajustez le
comportement.
Les quatre valeurs fondamentales d'Agile sont :
Individus et interactions sur les processus et les outils
Logiciel de travail sur une documentation complète
Collaboration cliente sur la négociation de contrat
Répondre au changement suite à un plan
Cela contraste avec le style de planification rigide de la cascade. En agile, le
client, est membre de l'équipe de développement plutôt que de s'engager
uniquement au début, lors de la définition des exigences commerciales, et à
la fin, lors de la révision du produit final (comme en cascade). Le client aide
l'équipe à rédiger les critères d'acceptation et reste engagé tout au long du
processus. De plus, l'agilité nécessite des changements et une amélioration
continue dans toute l'organisation. L'équipe de développement travaille avec
d'autres équipes, y compris le bureau de gestion de projet et les testeurs. Ce
qui est fait et quand est dirigé par un rôle désigné et accepté par l'équipe
dans son ensemble.
Le développement de logiciels agiles nécessite une planification adaptative,
un développement évolutif et une livraison. De nombreuses méthodologies,
cadres et pratiques de développement de logiciels relèvent de la souplesse,
notamment :
Scrum
Kanban (flux de travail visuel)
XP (programmation eXtreme)
Maigre
DevOps
Développement axé sur les fonctionnalités (FDD)
Développement piloté par les tests (TDD)
Cristal
Méthode de développement de systèmes dynamiques (DSDM)
Développement de logiciels adaptatifs (ASD)
Tous ces éléments ont été utilisés seuls ou en combinaison pour développer
et déployer des logiciels. Les plus courants sont la mêlée, le kanban (ou la
combinaison appelée scrumban) et le DevOps.
Agile est une méthodologie de développement relativement formelle prend
en charge un certain nombre de cadres populaires, notamment Scrum, un
concept d'équipe axé sur des actions itératives réalisées en « sprints»,
et Kanban, une méthodologie allégée pour gérer le travail autour de systèmes
basés sur l'homme.
Scrum est un cadre dans lequel une équipe, généralement composée d'un
maître Scrum, d'un propriétaire de produit et de développeurs, opère de
manière interdisciplinaire et de manière autonome pour augmenter la vitesse
de livraison des logiciels . Si on veut une plus grande valeur commerciale au
client. L'accent est mis sur des itérations plus rapides avec des incréments
plus petits.
Kanban est un framework agile, parfois appelé système de gestion
de workflow, qui aide les équipes à visualiser leur travail et à maximiser leur
efficacité (donc agile). Kanban est généralement représenté par un tableau
numérique ou physique. Par exemple, le travail d'une équipe se déplace dans
tous les domaines, de non commencé à en cours, en testant et terminé, au fur
et à mesure de sa progression. Kanban permet à chaque membre de l'équipe
de voir l'état de tous les travaux à tout moment.
À un niveau élevé, DevOps est un processus de collaboration entre les
équipes de développement et d'exploitation informatique utilisé tout au long
du cycle de vie du développement logiciel. L'objectif est d'améliorer la vitesse
de développement et de déploiement des produits. Il s'agit d'une approche
Agile qui brise les cloisonnements traditionnels entre les équipes, ce qui rend
le processus suffisamment flexible pour pouvoir répondre au besoin de
changements et de correctifs à tout moment.
DevOps est une culture, un état d'esprit, une façon dont le développement ou
l'infrastructure de logiciels est, et une façon dont les logiciels et les
applications sont construits et déployés. Il n'y a pas de mur entre le
développement et les opérations ; ils fonctionnent simultanément et sans
silos.
DevOps est basé sur deux autres domaines de pratique : lean et
agile. DevOps n'est pas un titre ou un rôle au sein d'une entreprise ; c'est
vraiment un engagement qu'une organisation ou une équipe prend pour une
livraison, un déploiement et une intégration continus. Selon Gene Kim,
auteur de The Phoenix Project et The Unicorn Project.

DevOps va au-delà de la simple automatisation du pipeline de

déploiement. Pour citer John Allspaw, DevOps fait référence à des « équipes
opérationnelles qui pensent comme des développeurs, et vice-versa ». En
partant de cette idée, Gene Kim explique ses Trois Voies comme des
principes DevOps :

met l'accent sur les performances

de tout le système, par rapport
aux performances d'un silo ou
d'un département spécifique (qui
peut aller d'un simple
La contributeur individuel à une
Première Voie Pensée systémique division dans son ensemble).
crée les boucles de feedback de
droite à gauche. La plupart des
initiatives d'amélioration des
processus ont pour objectif de
raccourcir et d'amplifier les
boucles de feedback, afin que les
La Amplifier les boucles corrections nécessaires puissent
Deuxième Voie de feedback être appliquées en continu.
crée une culture qui favorise
deux aspects : d'un côté,
l'expérimentation continue, la
prise de risques et l'apprentissage
Culture de des erreurs ; de l'autre,
l'expérimentation comprendre que répétition et
La continue et de pratique sont nécessaires pour
Troisième Voie l'apprentissage maîtriser une tâche.

 
La livraison continue (CD) se concentre sur la Première Voie : automatiser le
flux entre les équipes de développement et les équipes
opérationnelles. L'automatisation joue un rôle évident dans l'accélération
d'un système de déploiement. Mais la pensée systémique ne se limite pas à
l'automatisation.
La Deuxième Voie est caractérisée par la pratique suivante : « Les
développeurs portent eux aussi des pagers ». Bien que l'utilisation
de pagers ne soit pas forcément nécessaire, les développeurs devront
participer à la résolution des tickets opérationnels. Ils pourront ainsi
comprendre les conséquences de leurs choix de développement. Par
exemple, les développeurs pourront placer les messages de journal à de
meilleurs endroits et les rendre plus pertinents. Il n'est pas simplement
question de sensibilisation. La compréhension interne du système dont
disposent les développeurs peut être exploitée durant le dépannage, afin de
trouver une solution et de l'implémenter plus rapidement.
La Troisième Voie consiste à faire des expériences incrémentielles dans le
système global, et non à apporter des changements à l'application qui
progresse dans le pipeline. En d'autres termes, c'est relativement facile de
déterminer le temps nécessaire pour l'automatisation et d'exploiter
l'infrastructure de plus en plus puissante pour procéder à des améliorations
continues. Il est plus difficile de comprendre comment le système de transfert
entre les rôles ou les départements induit des retards. Cela signifie que les
équipes procèdent à des « inspections et des adaptations » dans tout
le workflow de livraison, et recherchent des opportunités d'amélioration de
la collaboration humaine. Dans ce contexte, la CD nécessite d'être rompu à
l'adaptation et à l'amélioration. Si l'équipe ne réfléchit pas à la façon de
gagner en efficacité, mais qu'elle adapte ses comportements pour tout le
reste, la CD ne va pas se développer et se populariser. L'équipe doit sentir
qu'on lui donne les moyens de résoudre ses propres problèmes.
Dans Scrum, chaque rétrospective est une occasion d'améliorer les pratiques
et les outils. Mais si l'équipe ne saisit pas ces occasions pour résoudre les
problèmes techniques à court et long terme, elle se contentera d'attendre
que le Product Owner place les tâches de CD dans le backlog, ce qui n'arrivera
jamais.
DevOps ne se produit pas dans le vide ; il s'agit d'une pratique flexible qui,
dans sa forme la plus vraie, est une culture et un état d'esprit partagés autour
du développement de logiciels et de la mise en œuvre informatique ou
d'infrastructure.
Quand vous pensez à l'automatisation, au cloud, aux microservices, vous
pensez à DevOps. Dans une interview, les
auteurs d'Accelerate: Building and Scaling High Performing Technology Organi
zations Nicole Forsgren, Jez Humble et Gene Kim ont expliqué :
Les performances de livraison de logiciels sont importantes et ont un impact
significatif sur les résultats organisationnels tels que la rentabilité, la part de
marché, la qualité, la satisfaction des clients et la réalisation des objectifs
organisationnels et de mission.

Les personnes très performantes atteignent des niveaux de débit, de stabilité

et de qualité ; ils ne font pas de compromis pour atteindre ces attributs.
Vous pouvez améliorer vos performances en mettant en œuvre des pratiques
à partir des playbooks lean, agile et DevOps.
La mise en œuvre de ces pratiques et capacités a également un impact sur
votre culture organisationnelle, qui à son tour a un impact sur vos
performances de livraison de logiciels et sur les performances
organisationnelles.
Il y a encore beaucoup de travail à faire pour comprendre comment améliorer
les performances.
Malgré leurs similitudes, DevOps et agile ne sont pas les mêmes, et certains
soutiennent que DevOps est meilleur qu'agile.
Les deux sont des méthodologies de développement logiciel; il n'y a pas à
contester cela.
Agile existe depuis plus de 20 ans et DevOps est apparu assez récemment.
Tous deux croient en un développement logiciel rapide, et leurs principes
sont basés sur la vitesse à laquelle un logiciel peut être développé sans nuire
au client ou aux opérations.
La différence entre les deux est ce qui se passe après le développement.
Le développement, les tests et le déploiement de logiciels se produisent à la
fois dans DevOps et agile. Cependant, l'agilité pure a tendance à s'arrêter
après ces trois étapes. En revanche, DevOps inclut des opérations, qui se
produisent continuellement. Par conséquent, la surveillance et le
développement de logiciels sont également continus.
En mode agile, des personnes distinctes sont responsables du
développement, des tests et du déploiement du logiciel. Dans DevOps, le rôle
d'ingénierie DevOps est responsable de tout ; le développement, c'est
l'exploitation, et l'exploitation, c'est le développement.
DevOps est davantage associé à la réduction des coûts, et agile est plus
synonyme de lean et de réduction des déchets, et des concepts tels que la
comptabilité de projet agile et le produit minimum viable (MVP) sont
pertinents.
Agile se concentre sur et incarne l'empirisme (adaptation , transparence et
inspection) au lieu de mesures prédictives.

Agile DevOps

Commentaires du client Rétroaction de soi

Cycles de libération plus Cycles de version plus petits, rétroaction

petits immédiate

Focus sur la vitesse Focus sur la vitesse et l'automatisation

Pas le meilleur pour les

Idéal pour les entreprises
affaires
Agile et DevOps se concentrent tous deux sur la vitesse, l'efficacité et les
résultats de qualité tout au long du cycle de vie du développement logiciel. Ils
se concentrent également sur des cycles de libération plus courts. Les deux
méthodologies ne mettent pas beaucoup l'accent sur les niveaux de
documentation et passent plutôt plus de temps sur l'automatisation et la
collaboration. À mesure que les projets progressent, le niveau de risque a
tendance à diminuer lors de l'utilisation d'une approche Agile ou DevOps,
tandis que le risque a tendance à augmenter avec le temps avec d'autres
approches comme Waterfall .
Si de nouveaux besoins commerciaux apparaissent, les méthodologies Agile
et DevOps préparent les organisations à être extrêmement réactives en
répondant immédiatement aux besoins des entreprises. Les entreprises qui
utilisent l'une ou l'autre approche ont également généralement une propriété
plus étroite de leurs projets respectifs.

Agile et DevOps sont distincts, bien que leurs similitudes conduisent les gens
à penser qu'ils sont une seule et même chose. Cela rend à la fois agile
et DevOps un mauvais service.
Agile et DevOps ne sont, en aucun cas, pas contradictoires (ou du moins,
l'intention n'est pas là). Ils sont plus alliés qu'ennemis dans la révolution
agile. Agile et DevOps peuvent fonctionner de manière exclusive et inclusive,
ce qui permet aux deux d'exister dans le même espace.
La bonne nouvelle est qu'il n'est pas nécessaire de s'engager dans une
approche plutôt qu'une autre. Un mélange des deux méthodologies peut être
utilisé pour assurer une efficacité accrue. Les deux ont un rôle majeur à jouer
en matière de développement et de déploiement de logiciels, et l'un peut
être utilisé pour activer l'autre.