DevOps et développement

continue

LAMALEM Yasser
 Planification

●
La phase de planification de DevOps est souvent considérée comme
la première étape de DevOps, qui n’est pas assez précise. En
pratique, les équipes logicielles modernes travaillent dans des cycles
serrés où chaque phase informe continuellement les autres à travers
les leçons apprises.
 Planification

●
Parfois, ces leçons sont positives. Parfois, ils sont négatifs. Et
parfois, ils sont des informations neutres dont l’équipe a besoin
afin qu’elle puisse prendre des décisions stratégiques pour
l’avenir. L’industrie s’est fusionnée autour d’un seul adjectif pour
décrire la capacité à s’adapter rapidement aux circonstances
changeantes que ces leçons créent : Agile. Le terme est
devenu si omniprésent qu’il s’agit maintenant d’un synonyme de
la plupart des formes de planification DevOps.
 Qu’est-ce qu’Agile ?
●
Agile est un terme qui décrit les approches du développement de
logiciels qui mettent l’accent sur la livraison incrémentielle, la
collaboration d’équipe, la planification continue et l’apprentissage
continu. Le terme Agile a été inventé en 2001 dans le Manifeste
Agile. Le manifeste établit des principes pour guider une meilleure
approche du développement de logiciels. À son cœur, le manifeste
déclare quatre déclarations de valeur qui représentent la base du
mouvement Agile. Comme écrit, le manifeste déclare :.
 Qu’est-ce qu’Agile ?

Nous sommes venus à la valeur :

●
Individus et interactions sur les processus et les outils.
●
Les logiciels opérationnels plutôt qu’une documentation exhaustive.
●
La collaboration avec les clients plutôt que la négociation de contrat.
●
Réponse au changement par rapport à la suite d’un plan.
●
Le manifeste n’implique pas que les éléments du côté droit de ces
déclarations ne sont pas importants ou nécessaires. Au lieu de cela,
les éléments de gauche sont simplement plus appréciés.
 Méthodes et pratiques agiles

●
Il est important de comprendre que Agile n’est pas une chose.
Vous ne faites pas Agile. Au lieu de cela, Agile est un état
d’esprit qui pilote une approche du développement logiciel.
Étant donné qu’il n’existe aucune approche unique qui
fonctionne pour toutes les situations, le terme Agile est venu
représenter différentes méthodes et pratiques qui s’alignent sur
les déclarations de valeur dans le manifeste.
 Méthodes et pratiques agiles

●
Les méthodes agiles, souvent appelées frameworks, sont des
approches complètes des phases du cycle de vie DevOps :
planification, développement, livraison et opérations. Ils
prescrivent une méthode pour accomplir le travail, avec des
conseils et des principes clairs.

●
Scrum est le framework Agile le plus courant, et celui que la
plupart des gens commencent par. En revanche, les pratiques
agiles sont des techniques qui sont appliquées pendant les
phases du cycle de vie du développement logiciel.
 Qu’est-ce que le développement Agile ?

●
Le développement Agile est un terme utilisé pour décrire le
développement logiciel itératif. Le développement logiciel itératif
raccourcit le cycle de vie DevOps en effectuant des tâches par
incréments courts, généralement appelés sprints. Les sprints
sont généralement longs de 1 à quatre semaines. Le
développement agile est souvent contrasté avec le
développement traditionnel ou en cascade, qui planifie des
projets plus importants à l’avance et les termine en fonction du
plan.
 Qu’est-ce que le développement Agile ?
Fournir du code de qualité de production chaque sprint nécessite que
l’équipe de développement Agile compte pour un rythme accéléré.
L’ensemble du codage, des tests et de la vérification de la qualité doivent
être effectués à chaque sprint. À moins qu’une équipe ne soit
correctement configurée, les résultats peuvent tomber en deçà des
attentes. Bien que ces déceptions offrent de grandes opportunités
d’apprentissage, il est utile d’apprendre quelques leçons clés avant de
commencer.
Cet article présente quelques facteurs de réussite clés pour les équipes
de développement Agile :
●
Affinement du backlog diligent
●
Intégration précoce et souvent
●
Réduction de la dette technique
 Affinement du backlog diligent
Une équipe de développement Agile travaille sur un backlog de
conditions requises, souvent appelées récits utilisateur. Le backlog est
hiérarchisé, avec les récits utilisateur les plus importants en haut. Le
propriétaire du produit, qui est le backlog, ajoute, modifie et hiérarchise
de nouveau les récits utilisateur en fonction des besoins du client.
 Affinement du backlog diligent

●
Un backlog mal défini constitue l’un des principaux freins à la
productivité d’une équipe Agile. Une équipe ne peut pas être censée
fournir de manière cohérente des logiciels de haute qualité chaque
sprint, sauf s’ils ont des exigences clairement définies.
●
e travail du propriétaire du produit est de s’assurer que chaque sprint,
les ingénieurs ont clairement défini des récits utilisateur à utiliser. Les
récits utilisateur en haut du backlog doivent toujours être prêts pour
que l’équipe commence. Cette notion est appelée affinement du
backlog. Le maintien d’un backlog prêt pour une équipe de
développement Agile nécessite un effort et une discipline.
Heureusement, il vaut bien la peine d’investir.
 Scrum

●
Qu’est-ce que Scrum ?
➔
Scrum est un framework utilisé par les équipes pour gérer le
travail et résoudre les problèmes en collaboration en cycles
courts. Scrum implémente les principes d’Agile en tant
qu’ensemble concret d’artefacts, de pratiques et de rôles.
●
Cycle de vie de Scrum
➔
Le diagramme ci-dessous détaille le cycle de vie itératif
de Scrum. Le cycle de vie entier est terminé dans des
périodes fixes appelées sprints. Un sprint est
généralement long d’un à quatre semaines.
Scrum
 Scrum

●
Rôles Scrum
➔
Il existe trois rôles clés dans Scrum : le propriétaire du
produit, le maître Scrum et l’équipe Scrum.
●
Propriétaire du produit
➔
Le propriétaire du produit est responsable de ce que
l’équipe génère et de la raison pour laquelle elle l’a
générée. Le propriétaire du produit est chargé de
maintenir le backlog de travail à jour et dans l’ordre de
priorité.
 Scrum

●
Master Scrum
➔
Le maître Scrum garantit que le processus Scrum est suivi par
l’équipe. Les maîtres Scrum sont continuellement à l’affût de la
façon dont l’équipe peut s’améliorer, tout en résolvant
également les obstacles et d’autres problèmes bloquants qui
surviennent pendant le sprint. Les maîtres de Scrum sont des
entraîneurs, des membres de l’équipe et des cheerleaders.
●
Propriétaire du produit
➔
Les membres de l’équipe Scrum créent réellement le produit.
L’équipe possède l’ingénierie du produit et la qualité qui
l’accompagne.
 Scrum : Backlog de produit

●
Le backlog de produits est une liste hiérarchisée du travail que
l’équipe peut fournir. Le propriétaire du produit est responsable
de l’ajout, de la modification et de la réorientation du backlog en
fonction des besoins. Les éléments situés en haut du backlog
doivent toujours être prêts pour que l’équipe s’exécute.
 Scrum : Planifier le sprint

●
Dans la planification du sprint, l’équipe choisit les éléments du
backlog à utiliser dans le sprint à venir. L’équipe choisit les
éléments de backlog en fonction de la priorité et de ce qu’ils
peuvent, selon elle, effectuer dans le sprint. Le backlog de
sprint est la liste des éléments que l’équipe prévoit de livrer
dans le sprint. Souvent, chaque élément du backlog de sprint
est divisé en tâches. Une fois que tous les membres acceptent
que le backlog de sprint soit réalisable, le sprint commence.
 Scrum : Exécuter le sprint

●
Une fois le sprint démarré, l’équipe s’exécute sur le backlog de
sprint. Scrum ne spécifie pas comment l’équipe doit s’exécuter.
L’équipe décide comment gérer son propre travail.

●
Scrum définit une pratique appelée scrum quotidienne, souvent
appelée standup quotidienne. Le quotidien Scrum est une
réunion quotidienne limitée à quinze minutes. Les membres de
l’équipe se tiennent souvent pendant la réunion pour s’assurer
qu’ils restent brefs. Chaque membre de l’équipe signale
brièvement ses progrès depuis hier, les plans d’aujourd’hui et
tout ce qui entrave leur progression.
 Scrum : Révision de sprint et rétrospective sprint

À la fin du sprint, l’équipe effectue deux pratiques :

●
Sprint de révision.
➔
L’équipe montre ce qu’elle a accompli aux parties prenantes.
Ils font la démonstration du logiciel et affichent sa valeur.
●
Rétrospective sprint.
➔
L’équipe prend du temps pour réfléchir à ce qui s’est bien
passé et quels domaines ont besoin d’amélioration. Le résultat
de la rétrospective est des actions pour le sprint suivant.
 Scrum : Incrément

●
Le produit d’un sprint est appelé incrémentation ou incrément
potentiellement shippable. Quel que soit le terme, la sortie d’un
sprint doit être de qualité shippable, même si elle fait partie de
quelque chose de plus grand et ne peut pas expédier par lui-
même. Il doit répondre à tous les critères de qualité définis par
l’équipe et le propriétaire du produit.
 Scrum : Répéter, apprendre, améliorer
●
Le cycle entier est répété pour le sprint suivant. La planification sprint
sélectionne les éléments suivants dans le backlog de produits et le
cycle se répète. Pendant que l’équipe exécute le sprint, le
propriétaire du produit garantit que les éléments situés en haut du
backlog sont prêts à s’exécuter dans le sprint suivant.

●
Ce cycle itératif plus court offre à l’équipe de nombreuses occasions
d’apprendre et d’améliorer. Un projet traditionnel a souvent un cycle
de vie long, par exemple 6 à 12 mois. Bien qu’une équipe puisse
apprendre à partir d’un projet traditionnel, les opportunités sont
beaucoup moins qu’une équipe qui s’exécute dans des sprints de
deux semaines, par exemple.
 Scrum : Répéter, apprendre, améliorer

●
Scrum est très populaire parce qu’il fournit juste assez de
framework pour guider les équipes tout en leur donnant de la
flexibilité dans la façon dont ils s’exécutent. Ses concepts sont
simples et faciles à apprendre. Teams peut commencer
rapidement et apprendre à mesure qu’ils vont. Tout cela rend
Scrum un excellent choix pour les équipes qui commencent
simplement à implémenter des principes Agile .
 Kanban
●
Kanban est un terme japonais qui signifie signboard ou
billboard. Un ingénieur industriel nommé Taiichi Ohno a
développé Kanban à Toyota Motor Corporation pour améliorer
l’efficacité de la fabrication.
 Kanban

●
Bien que Kanban ait été créé pour la fabrication, le
développement de logiciels partage plusieurs des mêmes
objectifs, tels que l’augmentation du flux et du débit. Les
équipes de développement logiciel peuvent améliorer leur
efficacité et fournir de la valeur aux utilisateurs plus rapidement
à l’aide des principes et méthodes guidant Kanban.
 Principes kanban : Visualiser le travail
●
Comprendre l’état de l’équipe de développement et la
progression du travail peuvent être difficiles. La progression du
travail et l’état actuel sont plus faciles à comprendre lorsqu’elles
sont présentées visuellement plutôt qu’en tant que liste
d’éléments de travail ou d’un document.
 Principes kanban : Visualiser le travail

●
La visualisation du travail est un principe clé que Kanban traite
principalement par le biais de tableaux Kanban. Ces tableaux
utilisent des cartes organisées par progression pour
communiquer l’état global. La visualisation du travail en tant
que cartes dans différents états d’un tableau permet de voir
facilement l’image globale de l’emplacement d’un projet, ainsi
que d’identifier les goulots d’étranglement potentiels
susceptibles d’affecter la productivité.
Principes kanban : Utiliser un modèle d’extraction

●
Historiquement, les parties prenantes ont demandé des
fonctionnalités en transmettant le travail aux équipes de
développement, souvent avec des délais serrés. La qualité a
souffert si les équipes devaient prendre des raccourcis pour
fournir les fonctionnalités dans le délai.
Principes kanban : Utiliser un modèle d’extraction

●
Kanban se concentre sur le maintien d’un niveau de qualité
convenu qui doit être respecté avant de prendre en compte les
travaux effectués. Pour prendre en charge ce modèle, les
parties prenantes ne poussent pas le travail sur les équipes qui
travaillent déjà à la capacité. Au lieu de cela, les parties
prenantes ajoutent des demandes à un backlog qu’une équipe
extrait dans son flux de travail lorsque la capacité devient
disponible.
 Principes kanban : Imposer une limite WIP

●
Les équipes qui essaient de travailler sur trop de choses à la
fois peuvent souffrir d’une productivité réduite en raison d’un
changement de contexte fréquent et coûteux. L’équipe est
occupée, mais le travail n’est pas fait, ce qui entraîne des
temps de prospects inacceptables. La limitation du nombre
d’éléments de backlog qu’une équipe peut travailler à la fois
permet d’augmenter le focus tout en réduisant le changement
de contexte. Les éléments que l’équipe travaille actuellement
sont appelés travaux en cours (WIP).
 Principes kanban : Imposer une limite WIP

●
Teams décide d’une limite WIP ou d’un nombre maximal
d’éléments qu’il peut utiliser à la fois. Une équipe bien
disciplinée s’assure de ne pas dépasser sa limite WIP. Si les
équipes dépassent leurs limites WIP, elles examinent la raison
et fonctionnent pour résoudre la cause racine.
 Principes kanban : Mesurer l’amélioration continue

●
Pour pratiquer une amélioration continue, les équipes de
développement ont besoin d’un moyen de mesurer l’efficacité et
le débit. Les tableaux Kanban fournissent une vue dynamique
des états de travail dans un flux de travail, afin que les équipes
puissent expérimenter des processus et évaluer plus facilement
l’impact sur les flux de travail. Teams qui adoptent Kanban pour
améliorer continuellement les mesures telles que le temps de
prospect et le temps de cycle.
 kanban : Tableaux kanban

●
Le tableau Kanban est l’un des outils que les équipes utilisent
pour implémenter des pratiques Kanban. Un tableau Kanban
peut être un tableau physique ou une application logicielle qui
affiche des cartes organisées en colonnes. Les noms de
colonnes classiques sont To-do, Doing et Done, mais les
équipes peuvent personnaliser les noms pour qu’ils
correspondent à leurs états de flux de travail. Par exemple, une
équipe peut préférer utiliser New, Development, Testing, UAT
et Done.
 kanban : Tableaux kanban
●
Cartes d’affichage des tableaux Kanban basés sur le développement
logiciel qui correspondent aux éléments du backlog de produit. Les
cartes incluent des liens vers d’autres éléments, tels que des tâches
et des cas de test. Teams peut personnaliser les cartes pour inclure
des informations pertinentes pour leur processus.
 Kanban et Scrum dans le développement Agile

Bien qu’il soit largement adapté au développement Agile , Scrum et

Kanban sont très différents.
●
Scrum se concentre sur les sprints de longueur fixe, tandis que
Kanban est un modèle de flux continu.
●
Scrum a défini des rôles, tandis que Kanban ne définit aucun
rôle d’équipe.
●
Scrum utilise la vitesse comme métrique clé, tandis que Kanban
utilise le temps de cycle.
 Kanban et Scrum dans le développement Agile

●
Teams adopte généralement des aspects de Scrum et Kanban
pour les aider à travailler plus efficacement. Quelles que soient
les caractéristiques qu’ils choisissent, les équipes peuvent
toujours passer en revue et s’adapter jusqu’à ce qu’elles
trouvent le meilleur ajustement. Teams doit commencer simple
et ne pas perdre de vue l’importance de fournir une valeur
régulièrement aux utilisateurs.