Gestion de projet

Livraison continue
 Le développeur fait du code fonctionnel
 Il le met dans le versionning
 Tout le reste est automatisé :
o Compilation du code avec les changements de tous
o Tests (interfaces, unitaire, etc.)
o Déploiement sur des serveurs de test
o Entre chaque étape on reçoit un résultat et si chaque étape fonctionne 
Déploiement sur serveur test ou prod

Permet le déploiement à chaque moment et après chaque changement. À tout moment, ils ont une
version prête à être déployé.

Build pipeline
C’est les différentes étapes automatisées de la livraison ou le déploiement continu. On peut y ajouter
toutes les étapes qu’on souhaite automatiser.

Déploiement continu
Chaque changement (surtout les petits changements), si tous les tests passent, est déployé. C’est
utilisé dans les grosses boîtes. On pousse la livraison continue, plus loin.

En déployant, chaque petit changement, ça facilite le déploiement. Le stress du déploiement, n’est

plus là On sait directement, si l’utilisateur utilise une nouvelle fonction et si elle fonctionne.

Déploiement automatisé
C’est utile d’avoir un environnement seulement pour les développeurs, avec le dernier code et un
autre environnement, pour le client, avec la dernière version stable. Cette dernière doit être le plus
proche possible de l’environnement de production, pour faciliter le déploiement. Mais ce n’est pas
pratique de maintenir plusieurs serveurs.

C’est des scripts pour automatiser le déploiement. Cela permet de ne pas oublier des choses au
moment du déploiement. Et ça permet de faire le déploiement plus rapidement et plus facilement.

Métriques
Faits par des développeurs, pour les développeurs. Permet de repérer des problèmes ou attire
l’attention sur quelque chose.

Mais c’est à double-tranchant : si les managers se réfèrent seulement à ça, ça va induire des
mauvaises pratiques (par ex. : on voudra corriger seulement des petits bugs, pour avoir le plus de
bugs corrigés,)

Statistiques sur le code :

 Analyse statique de code

o Nombre de lignes
o Complexité du code
 Analyse dynamique du code
o Tests

1
  Code coverage : pourcentage de code couvert par les tests

Code coverage
Les tests appellent les méthodes et les classes, donc on va voir toutes lignes qui ont été exécutées et
calculer le pourcentage, en fonction du nombre de lignes totales. Cela permet de savoir, si on a
oublié de faire des tests, pour du code. C’est pratique pour le développeur.

Si vous voulez faire changer le pourcentage, vous pouvez facilement « tricher ». Donc il ne faut pas
seulement se référer au code coverage.

Tests
Tester par petites parties, quitte à faire des copier-coller. Pendant les tests, l’accès est bloqué aux
autres classe  Dès un changement est fait et que ce n’est plus fonctionnel, le test ne passe plus. On
sait précisément d’où ça vient !

Tester un maximum de cas limites  100% ce n’est pas assez

Cela ne sert à rien de tester du code généré automatiquement où qui font appel à des méthodes de
libraires, qui fonctionnent.

Tests unitaires
Appelle un morceau de code

Tests d’interface
C’est un test plus concret, sur le fonctionnement de l’application à partir de l’interface  Pratique
pour les applications web, mais beaucoup plus lourds à mettre en place

Integration test
Appelle la base de données aussi et l’interaction avec la logique du code

Component test
Teste les couches internes de l’application

Blue/Green Deployement
À tout moment, seul l’un des environnements est en direct, avec l’environnement en direct
desservant tout le trafic de production. Pour cet exemple, Blue est actuellement en direct et Green
est inactif.

Au fur et à mesure que vous préparez une nouvelle version de votre logiciel, le déploiement et
l’étape finale des tests se déroulent dans l’environnement qui n’est pas en direct : dans cet exemple,
Green. Une fois que vous avez déployé et testé entièrement le logiciel en vert, vous basculez le
routeur de sorte que toutes les demandes entrantes passent maintenant à vert au lieu de bleu. Le
vert est maintenant live, et le bleu est inactif.

Cette technique permet d’éliminer le temps d’arrêt dû au déploiement d’applications. En outre, le

déploiement bleu-vert réduit les risques : si quelque chose d’inattendu se produit avec votre
nouvelle version sur Green, vous pouvez immédiatement revenir à la dernière version en revenant à
Blue.

Il y a une complexité ajoutée, avec la DB. On peut facilement ajouter des nouveaux champs, mais s’il
faut retire des champs, ça devient compliqué.

2
Dark Launch
Le Dark Launch est un processus où le logiciel est progressivement ou "invisiblement" libéré aux
consommateurs afin d’obtenir des commentaires des utilisateurs et de tester les performances. Le
code est enveloppé dans un "feature flag" de caractéristique ou une "feature toggle" qui est utilisée
pour contrôler qui peut voir la nouvelle fonction et quand. C’est aussi utilisé pour des releases
spéciales : par ex. des fonctionnalités pour la période des fêtes, …

Dèsavantage : complexifie le code/tests avec toutes les conditions.

Canary Release
On déploie une nouvelle version seulement à certains utilisateurs. On peut arriver à faire ceci avec le
Dark Launch ou avec le Blue/Green Deployement.

A/B testing
Cela permet de faire des tests de fonctionnalités, auprès des utilisateurs, sur deux versions
différentes. Par exemple deux versions avec des UI différents, pour savoir laquelle est plus efficace au
niveau des utilisateurs. On peut faire ceci avec du Blue/Green Deployement ou les features toggles.

DevOps
DevOps >< ITIL

ITIL
Méthodologie avec deux équipes distinctes : change et run. Chaque équipe à sa hiérarchie
(managers,etc) qui n’ont pas forcément les mêmes objectifs.

Le change veut faire beaucoup de changements, souvent. Tandis que le run préférerait l’inverse.

DevOps
Le devOps est un mouvement visant à l’alignement de l’ensemble des équipes du système
d’information sur un objectif commun, à commencer par les équipes de dev ou dev engineers
chargés de faire évoluer le système d’information et les ops ou ops engineers responsables des
infrastructures (exploitants, administrateurs système, réseau, bases de données, ...).

 Donner les mêmes responsabilités aux Dev et Ops le dev est plus enclin à faire en sorte
que l’application est plus facilement utilisable par l’Ops. S’il y a un souci avec l’application, ce
n’est plus l’ops qui est appelé, mais le dev
 On les fait travailler au même étage, voir l’un à côté de l’autre, on évite les « barrières »
entre les équipes  Besoin de moins de doc, car ils collaborent plus
 Le dev voit aussi l’utilisation de son application Permet l’optimisation dans le code, car il
apprend l’utilisation réelle (comment ça fonctionne au jour le jour)
 Automatiser certains tests (tests d’interfaces)  Pas besoin de faire des réunions et de
tests inutiles. Les rapports sont faits automatiquement aussi

Outils devops (CHEF, Docker, …)

Toute la config des serveurs se trouvent dans un fichier texte, dans un format structuré. En lisant le
fichier de config, on peut créer des serveurs avec des configurations 100% similaires.

 Backup On peut aussi garder la config sur git

 Audit détaillé des changements sur le serveur
 Le dev, peut facilement faire des changements, car on peut faire un rollback, s’il y a un souci

3
Livraison continue pour l’infrastructure !

Chaos Engineering
Combien de temps me faut-il pour remettre mes serveurs en route, après un disaster?

Dans le monde ITIL : Disaster Recovery Plan (DRP). Un très gros plan, détaillé avec les différentes
étapes pour remettre en routes les serveurs. Il faut s’entraîner pour les DRP.

Avec des outils DevOps, on peut remettre un serveur en route, très rapidement, grâce au fichier de
config du serveur.

Chaos monkey
Application que Netflix lance dans leur application, pour tout casser (de manière imprévisible) ! Pour
observer ce qu’il se passe dans différents cas. L’idée est de simuler les problèmes, pour être sûr que
leur système se rétablit bien lors de problèmes.

Si vous cassez des choses toutes les semaines On aura l’habitude et de le réparer et on ne
découvrira pas seulement au moment où le serveur crash !

Agile à grande échelle

Scrum of Scrum
Chaque équipe fait son daily scrum et envoie un représentant (ambassadeur) à une réunion. Essaye
d’encourager la communication entre des équipes  Facile à mettre en place

Chaque équipe a toujours son Product Owner.

Safe
Méthodologie psuedo-agile, avec un manifest, bouquin, … C’est une approche waterfall d’agile. Une
approche restrictif d’agile.

Agile Release Train

Toutes les équipes travaillent sur leur module. Il y a un release prévu (par ex. toute les 2 semaines),
chaque équipe à la possibilité de déployer, à ce moment-là.

LeSS
Cadre gloable qui est proposé, mais beaucoup moins de détails que Safe. Reste un peu restrictif.

Nexus
Basé sur Scrum of Scrum. On désigne une équipe qui suit au jour le jour, l’avancement des autres
équipes et faire en sorte que l’intégration des différentes parties des équipes se fait bien.

Spotify
Pas vraiment de structure. Ils encouragent aux équipes de tester des nouvelles choses. Et les
personnes avec des rôles similaires de chaque équipe, échangent souvent leur découverte.

Conclusion
Il faut plutôt être agile que faire agile. Il ne faut pas essayer de suivre les autres sociétés, à la lettre. Il
faut aussi limiter la croissance de l’entreprise  Plus il y a du monde, plus on passe du temps à
essayer de trouver la bonne méthodologie.

Projets à forfait
Forfait Régie

4
 - Prix fixe en fonction des fonctionnalités
demandés par le client, au début
- Risque chez le fournisseur, car s’il vous
faut plus de temps que prévu, vous ne
serez pas payé en plus
- Consultance ou Time & Means
- On facture par jour
- Risque chez le client, car si ça prend
plus longtemps que prévu, c’est lui qui
paie

Il faut une analyse détaillée de ce qu’on veut faire !  L’agilité n’est pas possible pour ça

Ces trois points suivants sont fixés :

- Scope : fonctionnalités du projet

- Prix
- Temps
- (Qualité) : Variable qu’on oublie souvent

Les grands projets à forfaits amènent de grands risques. L’idéal est de commencer avec des petits
projets.

Il faut prévoir une marge, dans le temps, car il faut 60% pour faire ce que le client a demandé et 40%
pour faire des changements.

Lean
Historique
Toyota >< Ford : Modèles qui ont été appliqués à l’informatique, par après.

Ford Toyota
- Idées du scientific management de - Des gens qui sont capables d’un peu
Taylor tout faire
- Rationnaliser - Des machines qui font la plupart des
- Des personnes qui ont Instruction choses avec un nombre limité de gens
claires, précises et répétitives (on sait qui s’occupent des machines On ne
prédire cmb de temps ça doit prendre) sait pas les remplacer aussi facilement
- D’autre gens qui réfléchissent à quels que chez Ford
sont les opérations à faire et comment
les optimiser
Just in time
On va développer des choses, chez Toyota, au moment où on en a besoin. On améliore la production,
pour que quand on a besoin des pièces, on sait les obtenir rapidement.

C’est l’inverse, chez Ford, où ils stockent des pièces, donc ils font tourner les machines à plein
régime, pour essayer de rentabiliser Gaspillage

Leans Software Developement

1. Eliminate waste : tout ce qui n’est pas indispensable On le vire

5
 a. Code qui traîne sur une machine
b. Documents inutiles
c. Changer constamment de tâche
d. Procédures inutiles
e. Attentes entre étapes : réduire leap time
2. Amplify learning : nous encourage à apprendre des nouvelles choses
3. Decide as late as possible : ça a de la valeur de prendre des décisions plus tard (parfois ça
vaut le coût de dépenser, pour ne pas être bloqué, sur une plateforme par ex)
4. Deliver as fast as possible: just in time
5. Empower the team : c’est l’approche p/r aux employés, il faut demander leur avis
6. See the whole : il ne faut pas optimiser les choses à une trop petite échelle (optimiser au
niveau de l’équipe, plutôt qu’au niveau de la personne)
7. Kanban (trello) : Origine chez toyota. Le vendeur laisse le kanban, chez la personne qui
monte la voiture, s’il lui manque des pièces, il laisse un kanban chez la personne
correspondante

Lean Startup
S’inspire des principes Lean. Permet d’amener une startup à un buisines durable. Il faut adapter ses
principes à une startup, car ça diffère d’une entreprise déjà existant depuis longtemps.

Apprentissage valorisé
Il ne faut pas partir avec la même optique d’une entreprise normale. Il faut aussi valoriser
l’apprentissage. Il faut revoir le modèle de management classique.

- L’objectif de la startup est d’apprendre si l’idée peut mener à un business viable. Donc tout
ce qui ne sert pas cet objectif est inutile  Il ne faut pas punir l’apprentissage
- Pas besoin de mettre la qualité d’un produit fait pour la vente, il faut doser la qualité

Pivot
Si la croissance n’est pas ce qu’on espère, on change une chose du produit et on voit ce que ça
donne. Le but c’est de faire un maximum d’expériences dans le temps qu’on a, pour savoir ce qui
marche. Il faut changer qu’un seul changement à la fois.

Il faut apprendre assez rapidement. Si dans X temps, on n’a pas assez de croissance, il faut
changer quelque chose !

MVP : Minimum Viable Product

C’est le produit minimum fonctionnel qui peut être déjà utilisé, par le client. Le produit minimum qui
a déjà de la valeur pour le client.

Il vaut mieux avoir un MVP assez rapidement.

No Estimate
C’est du gâchis de passer beaucoup de temps à estimer des fonctionnalités sur lesquels on ne pas
travailler maintenant. On estime les fonctionnalités sur lesquels on va travailler en premier. Travailler
d’abord sur la priorité.