Synthèse​ ​:​ ​Gestion​ ​de​ ​Projet 
Gestion​ ​de​ ​projet​ ​avancée​ ​:​ ​introduction 3 
Rappel 3 
Agile 3 

Extreme​ ​Programming 4 

Livraison​ ​continue 5 

DevOps 6 

Lean​ ​Software​ ​Development 7 

Eliminer​ ​le​ ​superflu 8 
Encenser​ ​l’apprentissage 8 
La​ ​décision​ ​doit​ ​être​ ​prise​ ​au​ ​plus​ ​tard 8 
Livré​ ​aussi​ ​vite​ ​que​ ​possible 8 
Améliorer​ ​l’équipe 8 
Inclure​ ​l’intégrité 9 
Voir​ ​l’ensemble 9 

La​ ​méthode​ ​Kanban 9 

Commencez​ ​par​ ​ce​ ​que​ ​vous​ ​faites​ ​actuellement 9 
Acceptez​ ​d’appliquer​ ​les​ ​changements​ ​évolutifs 9 
Respectez​ ​le​ ​processus​ ​actuel,les​ ​rôles,les​ ​responsabilités​ ​et​ ​les​ ​titres 10 
Encouragez​ ​le​ ​leadership​ ​à​ ​tous​ ​les​ ​niveaux 10 
Visualiser 10 
Limiter​ ​le​ ​nombre​ ​de​ ​tâches​ ​en​ ​cours 10 
Gestion​ ​du​ ​flux 10 
Rendre​ ​les​ ​règles​ ​explicites 10 
Implémenter​ ​des​ ​boucles​ ​de​ ​feedback 10 

Test​ ​automatisés 11 

Behavior​ ​Driven​ ​Development 11 

Agile​ ​à​ ​grande​ ​échelle 12 

SAFe 12 
LeSS 12 

Projets​ ​au​ ​Forfait 12 

Lean​ ​Startup 13 

Les​ ​entrepreneurs​ ​sont​ ​partout 13 
L'entreprenariat​ ​revient​ ​à​ ​faire​ ​du​ ​management 13 
Apprentissage​ ​validé 14 
Faire-Mesurer-Apprendre 14 
Evaluer​ ​pour​ ​l’innovation 14 
Conclusion 14 
Gestion​ ​de​ ​projet​ ​avancée​ ​:​ ​introduction 
 

Rappel 
Pour​ ​certaines​ ​entreprises,lorsqu’elles​ ​débutent,celles-ci​ ​n’accordent​ ​pas​ ​une​ ​très​ ​grande 
importance​ ​à​ ​l’organisation. 
 
Il​ ​arrive​ ​alors​ ​un​ ​moment​ ​où​ ​les​ ​chose​ ​commencent​ ​à​ ​se​ ​complexifier: 
 
● Peur​ ​du​ ​changement 
● Les​ ​bugs​ ​sont​ ​difficiles​ ​à​ ​gérer​ ​et​ ​le​ ​projet​ ​n’avance​ ​plus 
 
L’arrivée​ ​de​ ​procédures​ ​administratives​ ​dans​ ​le​ ​développement​ ​aide​ ​un​ ​peu​ ​à​ ​réorganiser 
tout​ ​ça​ ​mais​ ​ralenti​ ​à​ ​se​ ​façon,il​ ​y​ ​a​ ​trop​ ​de​ ​documentation​ ​à​ ​remplir. 
 
L’accumulation​ ​de​ ​retard​ ​entraine​ ​une​ ​perte​ ​d’intérêt​ ​du​ ​client.En​ ​effet,la​ ​perte​ ​de​ ​temps 
entraîne​ ​le​ ​report​ ​des​ ​changements​ ​et​ ​livraisons,une​ ​perte​ ​de​ ​compétitivité​ ​et​ ​une 
démotivation​ ​des​ ​troupes. 
 

Agile 
C’est​ ​là​ ​que​ ​Agile​ ​s’est​ ​avéré​ ​être​ ​d’un​ ​grand​ ​secours​ ​pour​ ​les​ ​entreprises. 
 
En​ ​effet,Agile​ ​quant​ ​à​ ​lui​ ​pousse​ ​à​ ​l’auto-organisation​ ​ce​ ​qui​ ​améliore​ ​la​ ​collaboration​ ​entre 
les​ ​différents​ ​employés. 
 
Agile​ ​introduit​ ​beaucoup​ ​de​ ​nouveaux​ ​concepts​ ​d’organisation​ ​tel​ ​que​ ​: 
 
● Orient​ ​le​ ​client​ ​et​ ​les​ ​producteurs​ ​vers​ ​un​ ​but​ ​commun. 
a. Le​ ​producteur​ ​s’engage​ ​à​ ​orienter​ ​l’équipe​ ​vers​ ​le​ ​résultat​ ​voulu 
b. L’équipe​ ​s’engage​ ​à​ ​collaborer​ ​et​ ​partager​ ​des​ ​rôles​ ​dans​ ​le​ ​but​ ​de​ ​fournir​ ​au 
client​ ​le​ ​produit​ ​voulu 
● Le​ ​développement​ ​suit​ ​une​ ​marche​ ​cyclique 
a. Planifier​ ​ce​ ​qu’il​ ​y​ ​a​ ​à​ ​faire 
b. Réaliser​ ​ce​ ​qui​ ​a​ ​été​ ​planifié 
c. Mesurer​ ​la​ ​qualité​ ​de​ ​ce​ ​qui​ ​à​ ​été​ ​réalisé​ ​par​ ​rapport​ ​à​ ​lui​ ​même​ ​mais​ ​aussi​ ​le 
reste​ ​du​ ​projet 
d. Adapter​ ​le​ ​produit 
● La​ ​répétition​ ​et​ ​l’automatisation​ ​de​ ​certains​ ​processus​ ​tel​ ​que​ ​les​ ​test​ ​unitaires​ ​sont 
un​ ​excellent​ ​moyen​ ​de​ ​prévenir​ ​de​ ​l’apparition​ ​du​ ​moindre​ ​bug. 
On​ ​peut​ ​citer​ ​plusieurs​ ​méthodologies​ ​qui​ ​sont​ ​considérés​ ​comme​ ​étant​ ​“Agile”​ ​: 
● Scrum 
● Extreme​ ​Programming 
 ● … 
 

Extreme​ ​Programming 
Maître​ ​mot​ ​:​ C ​ ommunication 
 
C’est​ ​pour​ ​cette​ ​importance​ ​accordée​ ​à​ ​la​ ​communication​ ​que​ ​XP​ ​utilise​ ​des​ ​systèmes​ ​de 
graphique​ ​de​ ​tailler​ ​assez​ ​conséquente,afin​ ​d’assurer​ ​une​ ​visibilité​ ​et​ ​une​ ​vision​ ​d’ensemble 
du​ ​projet​ ​à​ ​qui​ ​le​ ​regarderait. 
 
Il​ ​devient​ ​donc​ ​ainsi​ ​facile​ ​de​ ​déterminer​ ​à​ ​vue​ ​d’oeil​ ​les​ ​retards,la​ ​progression​ ​du​ ​projet​ ​en 
fonction​ ​de​ ​la​ ​disposition​ ​des​ ​post-it. 
 
Coding​ ​standards​​ ​:​ ​Il​ ​reprend​ ​l’ensemble​ ​des​ ​accords​ ​pris​ ​avant​ ​la​ ​phase​ ​de​ ​développement 
pour​ ​ce​ ​qui​ ​concerne​ ​la​ ​structure​ ​du​ ​code​ ​et​ ​ces​ ​modalités​ ​(tabulations,espaces,...) 
 
Collective​ ​ownership​​ ​:​ ​Un​ ​produit​ ​n’est​ ​pas​ ​le​ ​fruit​ ​d’un​ ​leader​ ​et​ ​son​ ​équipe​ ​mais​ ​juste 
d’une​ ​grande​ ​équipe​ ​où​ ​tout​ ​le​ ​monde​ ​est​ ​leader. 
 
Pair​ ​programming​​ ​:​ ​C’est​ ​le​ ​simple​ ​fait​ ​de​ ​développer​ ​à​ ​2​ ​sur​ ​le​ ​même​ ​ordinateur.​ ​Alors​ ​que 
l’un​ ​se​ ​charge​ ​de​ ​coder,​ ​l’autre​ ​pour​ ​regarder​ ​le​ ​code​ ​en​ ​tant​ ​réel​ ​et​ ​dénicher​ ​les​ ​erreurs​ ​de 
distractions​ ​éventuels​ ​mais​ ​également​ ​partager​ ​son​ ​expérience​ ​personnelle.​ ​Elle​ ​est​ ​un 
excellent​ ​moyen​ ​de​ ​prévention​ ​face​ ​aux​ ​distractions​ ​externes​ ​(réseaux​ ​sociaux,mails,sms,...) 
et​ ​au​ ​“​ ​bâclage​ ​“​ ​en​ ​passant​ ​la​ ​phase​ ​de​ ​refactoring​ ​mais​ ​une​ ​sécurité​ ​au​ ​cas​ ​l’un​ ​des 
développeurs​ ​est​ ​absent​ ​puisque​ ​l’autre​ ​aura​ ​suivi​ ​le​ ​développement. 
 
 
Le​ ​but​ ​escompté​ ​n’est​ ​pas​ ​de​ ​faire​ ​du​ ​coaching​ ​mais​ ​bien​ ​d’assister​ ​une​ ​autre 
personne. 
 
Dette​ ​technique​​ ​:​ ​La​ ​précipitation​ ​accélère​ ​le​ ​travail​ ​mais​ ​génère​ ​des​ ​problèmes,c’est​ ​la 
dette.​ ​A​ ​un​ ​moment,il​ ​faudra​ ​“rembourser”​ ​cette​ ​dette​ ​par​ ​un​ ​refactoring.Le​ ​but​ ​de​ ​cette 
métaphore​ ​est​ ​d’expliquer​ ​aux​ ​personnes​ ​non​ ​développeurs​ ​les​ ​risques​ ​qui​ ​peuvent 
apparaître. 
 
Toutes​ ​les​ ​méthodes​ ​XP​ ​se​ ​fondent​ ​sur​ ​les​ ​principes​ ​primordiaux​ ​du​ ​confort​​ ​et​ ​de​ ​la 
communication​. 
 
Le​ ​client​ ​se​ ​doit​ ​de​ ​suivre​ ​le​ ​projet​ ​jusqu’à​ ​sa​ ​finalisation​ ​afin​ ​de​ ​faire​ ​gagner​ ​du​ ​temps​ ​dans 
les​ ​incertitudes​ ​du​ ​développement. 
 
De​ ​plus,​ ​XP​ ​est​ ​une​ ​méthodologie​ ​évolutive​ ​ainsi​ ​les​ ​équipes​ ​qui​ ​l’adopte​ ​peuvent 
l’accomoder​ ​suivant​ ​les​ ​projets​ ​et​ ​les​ ​facilités​ ​de​ ​chacun. 
 
Livraison​ ​continue 
 
Avant​ ​tout​ ​déploiement,il​ ​est​ ​nécessaire​ ​de​ ​passer​ ​par​ ​différentes​ ​phases​ ​de​ ​test. 
 
Sans​ ​test,il​ ​y​ ​a​ ​énormément​ ​de​ ​risques​ ​d’erreurs​ ​au​ ​déploiement. 
 
Avec​ ​des​ ​tests​ ​à​ ​la​ ​Waterfall​ ​(Beaucoup​ ​de​ ​documentation),les​ ​risques​ ​sont​ ​réduits​ ​mais​ ​le 
processus​ ​est​ ​lent. 
 
Le​ ​déploiement​ ​pipeline​ ​permet​ ​de​ ​tester​ ​les​ ​fonctionnalités​ ​progressivement​ ​au​ ​fur​ ​et​ ​à 
mesure​ ​du​ ​développement​ ​jusqu’à​ ​la​ ​mise​ ​en​ ​production. 
 
Livraison​ ​continue​​ ​:​ ​Chaque​ ​nouvelle​ ​fonctionnalité​ ​peut-être​ ​déployé​ ​directement​ ​où​ ​à​ ​la 
demande​ ​du​ ​client.​ ​(événements,...) 
 
Déploiement​ ​continu​​ ​:​ ​Chaque​ ​changement​ ​est​ ​déployé​ ​en​ ​production.Ce​ ​procédé​ ​est 
utilisé​ ​énormément​ ​auprès​ ​de​ ​firme​ ​qui​ ​fournisse​ ​des​ ​produits​ ​à​ ​la​ ​demande 
(Amazon,Netflix,Facebook,...) 
 
La​ ​production​ ​de​ ​petits​ ​changements​ ​réduit​ ​grandement​ ​les​ ​risques​ ​même​ ​si​ ​l’impression​ ​de 
non​ ​progrès​ ​peut​ ​donner​ ​une​ ​sensation​ ​de​ ​contre-intuitivité.Néanmoins,le​ ​client​ ​saura 
donner​ ​des​ ​feedback​ ​plus​ ​rapide​ ​étant​ ​donné​ ​la​ ​taille​ ​des​ ​changements. 
 
Il​ ​faut​ ​aussi​ ​garder​ ​en​ ​tête​ ​une​ ​“Definition​ ​Of​ ​Done”​ ​ou​ ​à​ ​partir​ ​de​ ​quel​ ​moment 
considérons-nous​ ​que​ ​le​ ​produit​ ​est​ ​terminé.​ ​Cela​ ​permet​ ​l’agilité. 
 
Build​ ​pipeline​​ ​:​ ​Il​ ​s’agit​ ​d’une​ ​suite​ ​de​ ​phases​ ​auquel​ ​doit​ ​passer​ ​une​ ​fonctionnalité​ ​jusqu’à 
arriver​ ​en​ ​production.Ce​ ​processus​ ​peut​ ​dès​ ​alors​ ​être​ ​automatisé​ ​afin​ ​de​ ​gagner​ ​du​ ​temps. 
 
Il​ ​est​ ​important​ ​néanmoins​ ​de​ ​garder​ ​trace​ ​des​ ​changements​ ​apportés​ ​via​ ​divers​ ​outils. 
 
L’utilisation​ ​de​ ​métrique​ ​permet​ ​aux​ ​développeurs,et​ ​uniquement​ ​aux​ ​développeurs,d’avoir 
une​ ​vision​ ​de​ ​la​ ​qualité​ ​du​ ​projet​ ​en​ ​général.​ ​On​ ​peut​ ​mesurer​ ​: 
 
● Le​ ​pourcentage​ ​de​ ​succès​ ​des​ ​test 
● La​ ​couverture​ ​des​ ​tests​ ​:​ ​Elle​ ​permet​ ​de​ ​savoir​ ​jusqu’à​ ​quel​ ​portion​ ​du​ ​code​ ​le​ ​test​ ​va 
vérifier​ ​la​ ​véracité.​ ​Cependant​ ​il​ ​ne​ ​faut​ ​pas​ ​abuser​ ​de​ ​ce​ ​procédé​ ​puisque​ ​celui-ci 
pousse​ ​au​ ​refactoring​ ​constant​ ​jusqu’à​ ​ce​ ​que​ ​la​ ​barre​ ​des​ ​100%​ ​soit​ ​atteinte​ ​ce​ ​qui 
peut​ ​finir​ ​par​ ​affecter​ ​la​ ​lisibilité​ ​du​ ​code​ ​en​ ​général. 
● Les​ ​règles​ ​de​ ​l’équipe:​ ​A​ ​quel​ ​point​ ​nos​ ​conventions​ ​(tabulations,espaces,..)​ ​ont​ ​été 
respectées. 
Blue/Green​ ​Deployment​​ ​:​ ​On​ ​utilise​ ​2​ ​groupes​ ​de​ ​serveurs.Le​ ​principe​ ​est​ ​qu’un​ ​groupe 
contiendra​ ​la​ ​version​ ​actuelle​ ​du​ ​projet​ ​et​ ​l’autre​ ​la​ ​nouvelle​ ​et​ ​ainsi​ ​de​ ​suite.​ ​Ainsi​ ​,si​ ​erreur, 
il​ ​est​ ​possible​ ​de​ ​faire​ ​un​ ​retour​ ​arrière​ ​en​ ​basculant​ ​sur​ ​le​ ​groupe​ ​de​ ​serveurs​ ​ayant 
l’ancienne​ ​version​ ​du​ ​projet.​ ​Cependant,​ ​lorsque​ ​les​ ​2​ ​groupes​ ​sont​ ​à​ ​la​ ​même​ ​version,​ ​il​ ​est 
intéressant​ ​d’utiliser​ ​tous​ ​les​ ​serveurs​ ​afin​ ​de​ ​maximiser​ ​les​ ​capacités​ ​et​ ​performances. 
 
Des​ ​difficultés​ ​peuvent​ ​néanmoins​ ​apparaitre​ ​lorsqu’il​ ​faut​ ​également​ ​changer​ ​de​ ​base​ ​de 
données. 
 
Feature​ ​toggle​​ ​:​ ​Toutes​ ​les​ ​fonctionnalités​ ​non-terminées​ ​sont​ ​cachés​ ​de​ ​l’utilisateur​ ​mais 
comme​ ​étant​ ​déjà​ ​déployé,à​ ​la​ ​modification​ ​d’un​ ​paramètre,on​ ​peut​ ​rendre​ ​cette 
fonctionnalité​ ​disponible​ ​à​ ​volonté. 
 
Canary​ ​release​​ ​:​ ​Utiliser​ ​avec​ ​le​ ​feature​ ​toggle​ ​ou​ ​Blue/Green​ ​deployment.Il​ ​s’agit​ ​d’utliser 
des​ ​cobayes​ ​sur​ ​nos​ ​serveurs​ ​afin​ ​de​ ​tester​ ​la​ ​bonne​ ​fonctionnalité​ ​du​ ​produit​ ​avant​ ​tout 
mise​ ​en​ ​production.​ ​Si​ ​cela​ ​fonctionne​ ​bien,tous​ ​les​ ​utilisateurs​ ​de​ ​l’ancienne​ ​version​ ​sont 
migrés​ ​vers​ ​la​ ​nouvelle. 
 
A/B​ ​testing​​ ​:​ ​On​ ​crée​ ​2​ ​versions​ ​d’un​ ​même​ ​produit.Chacune​ ​des​ ​version​ ​va​ ​être​ ​paramétré 
différemment​ ​afin​ ​de​ ​tester​ ​les​ ​performances​ ​et​ ​de​ ​déterminer​ ​la​ ​meilleure​ ​marche​ ​à​ ​suivre. 
 
 

DevOps 
 
Dans​ ​Waterfall​ ​et​ ​Agile​ ​se​ ​présentait​ ​un​ ​fait​ ​commun,​ ​il​ ​y​ ​a​ ​distinction​ ​entre​ ​l’équipe​ ​de 
développement​ ​et​ ​celle​ ​de​ ​déploiement​ ​et​ ​maintenance. 
 
DevOps​ ​retire​ ​cette​ ​barrière​ ​et​ ​pousse​ ​ainsi​ ​à​ ​la​ ​collaboration​ ​entre​ ​ces​ ​2​ ​côtés. 
 
DevOps​ ​se​ ​compose​ ​de​ ​2​ ​parties​ ​:​ ​la​ c​ ulture​ ​(difficile​ ​à​ ​acquérir)​​ ​et​ ​les​ o
​ utils(facile​ ​à 
acquérir) 
Chacun​ ​des​ ​2​ ​partis​ ​a​ ​quelque​ ​chose​ ​à​ ​apporter​ ​: 
1. Les​ ​développeurs​ ​apportent​ ​: 
○ L’automatisation​ ​des​ ​processus 
○ Les​ ​pratiques​ ​agiles 
2. Les​ ​techniciens​ ​apportent​ ​: 
○ La​ ​vision​ ​réelle​ ​du​ ​déploiement 
○ La​ ​notion​ ​de​ ​maintenance​ ​efficace 
○ La​ ​notion​ ​d'hébergement 
○ La​ ​vision​ ​de​ ​l’utilisation​ ​réelle 
 
Cette​ ​division​ ​qu’il​ ​y​ ​a​ ​avait​ ​était​ ​source​ ​de​ ​conflit​ ​puisque​ ​c’était​ ​toujours​ ​la​ ​faute​ ​des 
autres.Mais​ ​avec​ ​DevOps,étant​ ​donné​ ​que​ ​les​ ​compétences​ ​sont​ ​désormais​ ​partagées,c’est 
la​ ​faute​ ​du​ ​groupe​ ​dans​ ​sa​ ​totalité​ ​et​ ​donc​ ​la​ ​responsabilité​ ​de​ ​tous​ ​pour​ ​que​ ​tout 
fonctionne.Tout​ ​le​ ​monde​ ​doit​ ​se​ ​montrer​ ​disponible​ ​si​ ​problème​ ​et​ ​pas​ ​que​ ​les 
administrateurs. 
 
Le​ ​fait​ ​de​ ​vivre​ ​l'utilisation​ ​le​ ​déploiement​ ​et​ ​l’utilisation​ ​réelle​ ​de​ ​l’application​ ​apporte 
énormément​ ​de​ ​nouvelles​ ​choses. 
 
Alors​ ​qu’avant​ ​,entre​ ​chaque​ ​déploiement,il​ ​y​ ​avait​ ​une​ ​vérification​ ​et​ ​un​ ​traçage​ ​des​ ​étapes 
ce​ ​qui​ ​générait​ ​beaucoup​ ​de​ ​paperasse. 
 
La​ ​collaboration​ ​des​ ​2​ ​équipes​ ​crée​ ​une​ ​autonomie​ ​puisque​ ​la​ ​supervision​ ​simultanée​ ​d’un 
projet​ ​demande​ ​alors​ ​moins​ ​de​ ​vérifications.Tous​ ​les​ ​test​ ​sont​ ​automatisés​ ​ainsi​ ​que​ ​les 
déploiements​ ​et​ ​le​ ​déploiement​ ​est​ ​assisté​ ​en​ ​direct. 
 
Snowflake​ ​Server​​ ​:​ ​Tel​ ​les​ ​flocons​ ​de​ ​neige,2​ ​serveurs​ ​ne​ ​sont​ ​jamais​ ​les​ ​même​ ​et​ ​cela 
peut-être​ ​embêtant​ ​puisque​ ​2​ ​serveurs​ ​pourraient​ ​réagir​ ​différemment​ ​au​ ​déploiement. 
 
Pour​ ​le​ ​problème​ ​de​ ​Snowflake​ ​Server,il​ ​faut​ ​s’assurer​ ​que​ ​tous​ ​les​ ​serveurs​ ​partagent​ ​la 
mêm​ ​configuration.Pour​ ​cela,on​ ​pourrait​ ​par​ ​exemple​ ​utiliser​ ​un​ ​fichier​ ​texte 
(docker-compose,...)​ ​qui​ ​contiendrait​ ​toutes​ ​les​ ​configurations​ ​nécessaire​ ​afin​ ​de​ ​s’assurer 
de​ ​l'homogénéité​ ​des​ ​serveurs. 
 
De​ ​plus​ ​,l’utilisation​ ​de​ ​ces​ ​fichiers​ ​de​ ​config​ ​permet​ ​qu’au​ ​moindre​ ​problème,il​ ​est​ ​très 
simple​ ​de​ ​rétablir​ ​le​ ​serveur​ ​dans​ ​sa​ ​configuration​ ​par​ ​défaut. 
 
Chaos​ ​Engineering​​ ​:​ ​Il​ ​faut​ ​expérimenter​ ​les​ ​serveurs​ ​pour​ ​détecter​ ​les​ ​faiblesses​ ​et​ ​les 
combler. 
 

Lean​ ​Software​ ​Development 

 
Inspiré​ ​de​ ​la​ ​la​ ​méthodologie​ ​des​ ​usines​ ​japonaises​ ​Toyota. 
 
2​ ​principes​ ​: 
● Just-in-time 
○ Il​ ​faut​ ​éviter​ ​la​ ​surproduction,de​ ​produire​ ​plus​ ​que​ ​nécessaire​ ​et​ ​de​ ​réduire​ ​la 
taille​ ​des​ ​stocks. 
● Stop-the-line 
○ Au​ ​lieu​ ​de​ ​viser​ ​la​ ​quantité,il​ ​faut​ ​viser​ ​la​ ​qualité.Si​ ​un​ ​problème​ ​est​ ​détecté 
alors​ ​il​ ​est​ ​du​ ​devoir​ ​des​ ​employés​ ​de​ ​tout​ ​arrêter​ ​pour​ ​corriger​ ​le​ ​problème 
mais​ ​également​ ​enrichir​ ​les​ ​compétences​ ​des​ ​travailleurs. 
 
Tom​ ​Poppendieck​ ​s’est​ ​inspiré​ ​de​ ​cette​ ​méthodologie​ ​afin​ ​de​ ​mettre​ ​au​ ​point​ ​Lean. 
 
Lean​ ​reprend​ ​7​ ​principes​ ​: 
 
1. Supprimer​ ​le​ ​non​ ​nécessaire 
2. Encenser​ ​l’apprentissage 
3. Prendre​ ​des​ ​décision​ ​le​ ​plus​ ​tard​ ​possible 
 4. Livré​ ​aussi​ ​vite​ ​que​ ​possible 
5. Améliorer​ ​l’équipe 
6. Inclure​ ​l’intégrité 
7. Voir​ ​l’ensemble 
 

Eliminer​ ​le​ ​superflu 

 
Il​ ​faut​ ​savoir​ ​repérer​ ​les​ ​procédures,fonctionnalités​ ​inutiles.​ ​Utiliser​ ​une​ ​hiérarchie​ ​pour 
monter​ ​le​ ​développement​ ​du​ ​projet​ ​n’intéresse​ ​pas​ ​le​ ​client. 
 
Il​ ​faut​ ​être​ ​prêt​ ​à​ ​changer​ ​de​ ​tâche​ ​à​ ​tout​ ​moment.A​ ​faire​ ​ses​ ​propres​ ​recherches. 
 
Value​ ​Stream​ ​Mapping​​ ​:​ ​Cette​ ​modélisation​ ​permet​ ​une​ ​analyse​ ​du​ ​superflu​ ​et​ ​permet​ ​ainsi 
d'optimiser​ ​le​ ​travail. 
 

Encenser​ ​l’apprentissage 
Un​ ​développement​ ​ne​ ​doit​ ​pas​ ​suivre​ ​une​ ​liste​ ​de​ ​procédure​ ​comme​ ​une​ ​recette​ ​de​ ​cuisine 
(manque​ ​de​ ​feedback)​ ​ ​mais​ ​plutôt​ ​être​ ​prêt​ ​à​ ​tester​ ​après​ ​chaque​ ​itération​ ​si​ ​le​ ​produit​ ​est 
perfectible. 
 

La​ ​décision​ ​doit​ ​être​ ​prise​ ​au​ ​plus​ ​tard 

 
Avec​ ​le​ ​temps,nos​ ​connaissances​ ​vont​ ​s’accumuler​ ​et​ ​nous​ ​serons​ ​plus​ ​à​ ​même​ ​de​ ​prendre 
des​ ​décisions​ ​et​ ​d’éviter​ ​les​ ​frais​ ​inutiles. 
 

Livré​ ​aussi​ ​vite​ ​que​ ​possible 

 
Au​ ​lieu​ ​de​ ​préparer​ ​en​ ​avance​ ​quitte​ ​à​ ​faire​ ​du​ ​superflu,il​ ​faut​ ​au​ ​contraire​ ​préparer​ ​un​ ​fois​ ​la 
demande​ ​passé​ ​et​ ​de​ ​le​ ​livrer​ ​le​ ​plus​ ​tôt​ ​possible​ ​en​ ​suivant​ ​une​ ​suite​ ​de​ ​procédures​ ​de 
production​ ​rapide. 
 

Améliorer​ ​l’équipe 
Si​ ​on​ ​veut​ ​que​ ​les​ ​principes​ ​Lean​ ​marchent​ ​il​ ​faut​ ​mettre​ ​l’humain​ ​à​ ​l’avant​ ​plan,il​ ​fallait 
responsabiliser,respecter,accorder​ ​une​ ​certaine​ ​autonomie​ ​le​ ​tout​ ​dans​ ​un​ ​bon 
environnement. 
 
Inclure​ ​l’intégrité 
 
Il​ ​faut​ ​faire​ ​un​ ​travail​ ​le​ ​plus​ ​propre​ ​possible​ ​afin​ ​de​ ​minimiser​ ​les​ ​corrections​ ​finales. 
La​ ​qualité​ ​s’obtient​ ​en​ ​suivant​ ​les​ ​pratiques​ ​Agile. 
 

Voir​ ​l’ensemble 
Il​ ​ne​ ​faut​ ​pas​ ​se​ ​limiter​ ​à​ ​l’individu​ ​mais​ ​voir​ ​la​ ​globalité​ ​des​ ​interactions​ ​possible. 
Un​ ​individu​ ​faite​ ​partie​ ​d’une​ ​équipe​ ​qui​ ​fait​ ​partie​ ​d’une​ ​entreprise. 
 
Kanban​​ ​:​ ​Un​ ​projet​ ​est​ ​décomposé​ ​en​ ​composants​ ​qui​ ​sont​ ​distribuées​ ​sur​ ​des​ ​cartes,on 
peut​ ​ainsi​ ​mieux​ ​visualiser​ ​les​ ​outils​ ​nécessaire.Si​ ​on​ ​a​ ​pas​ ​de​ ​travail​ ​alors​ ​on​ ​va​ ​aider​ ​un 
autre. 
 

La​ ​méthode​ ​Kanban 

“Commencez​ ​avec​ ​ce​ ​que​ ​vous​ ​faites​ ​maintenant​ ​“ 
 
On​ ​oppose​ ​Kanban​ ​à​ ​Scrum​ ​car​ ​Scrum​ ​est​ ​considéré​ ​néanmoins​ ​comme​ ​un​ ​mini-Waterfall 
alors​ ​que​ ​Kanban​ ​ne​ ​se​ ​concentre​ ​que​ ​sur​ ​l’actuel​ ​et​ ​ne​ ​cherche​ ​pas​ ​la​ ​planification. 
 
On​ ​peut​ ​citer​ ​4​ ​principes​ ​de​ ​Kanban​ ​:  
● Commencez​ ​par​ ​ce​ ​que​ ​vous​ ​faites​ ​actuellement 
● Acceptez​ ​d’appliquer​ ​les​ ​changements​ ​évolutifs 
● Respectez​ ​le​ ​processus​ ​actuel,les​ ​rôles,les​ ​responsabilités​ ​et​ ​les​ ​titres 
● Encouragez​ ​le​ ​leadership​ ​à​ ​tous​ ​les​ ​niveaux 
 

Commencez​ ​par​ ​ce​ ​que​ ​vous​ ​faites​ ​actuellement 

Visualisez​ ​le​ ​travail​ ​futur​ ​est​ ​proscrit.C’est​ ​une​ ​perte​ ​de​ ​temps​ ​et​ ​nous​ ​ne​ ​sommes​ ​pas​ ​apte 
à​ ​décider​ ​ce​ ​qu’il​ ​sera​ ​fait​ ​plus​ ​tard.Il​ ​faut​ ​se​ ​concentrer​ ​sur​ ​ce​ ​qu’il​ ​y​ ​a​ ​à​ ​faire​ ​dans 
l’immédiat. 
 

Acceptez​ ​d’appliquer​ ​les​ ​changements​ ​évolutifs 

Il​ ​ne​ ​faut​ ​pas​ ​fixer​ ​les​ ​différentes​ ​phases​ ​du​ ​développement​ ​mais​ ​les​ ​adapter​ ​en​ ​fonction​ ​de 
la​ ​situation.Il​ ​peut​ ​arriver​ ​que​ ​certaines​ ​étapes​ ​aient​ ​moins​ ​de​ ​phases​ ​à​ ​traversé​ ​que 
d’autres.C’est​ ​Agile. 
 
Respectez​ ​le​ ​processus​ ​actuel,les​ ​rôles,les​ ​responsabilités​ ​et​ ​les​ ​titres 
Faciliter​ ​les​ ​futurs​ ​changements​ ​et​ ​le​ ​respect​ ​des​ ​rôles​ ​,des​ ​responsabilités​ ​et​ ​des​ ​titres 
professionnels​ ​permettent​ ​d’éliminer​ ​les​ ​peurs​ ​initiales 

Encouragez​ ​le​ ​leadership​ ​à​ ​tous​ ​les​ ​niveaux 

 
Tout​ ​le​ ​monde​ ​est​ ​encouragé​ ​à​ ​partager​ ​ses​ ​idées​ ​et​ ​à​ ​faire​ ​preuve​ ​d’un​ ​certain​ ​leadership​ ​à 
tous​ ​les​ ​niveaux​ ​de​ ​l’organisation. 
 
Pour​ ​la​ ​mise​ ​en​ ​pratique​ ​il​ ​y​ ​a​ ​6​ ​pratiques​ ​principales​ ​à​ ​Kanban​ ​: 
1. Visualiser 
2. Limiter​ ​le​ ​nombre​ ​de​ ​tâches​ ​en​ ​cours 
3. Gestion​ ​du​ ​flux 
4. Rendre​ ​les​ ​règles​ ​explicites 
5. Implémenter​ ​ds​ ​boucles​ ​de​ ​feedback 
6. Améliorez-vous​ ​de​ ​façon​ ​collaborative​ ​et​ ​par​ ​expérimentation 
 

Visualiser 
 
La​ ​visualisation​ ​du​ ​travail​ ​permet​ ​de​ ​mieux​ ​comprendre​ ​les​ ​processus.Une​ ​façon​ ​commune 
de​ ​faire​ ​le​ ​faire​ ​est​ ​via​ ​un​ ​panneau​ ​de​ ​post-it​ ​afin​ ​d’assurer​ ​une​ ​vue​ ​d’ensemble​ ​du​ ​projet. 
 

Limiter​ ​le​ ​nombre​ ​de​ ​tâches​ ​en​ ​cours 

Il​ ​faut​ ​savoir​ ​s’arrêter​ ​dans​ ​les​ ​différents​ ​processus​ ​et​ ​terminer​ ​ce​ ​qui​ ​est​ ​en​ ​cours​ ​afin​ ​de 
pouvoir​ ​livrer​ ​quelque​ ​chose​ ​de​ ​concret. 

Gestion​ ​du​ ​flux 

Le​ ​déroulement​ ​du​ ​travail​ ​doit​ ​être​ ​suivi​ ​à​ ​chaque​ ​étape​ ​afin​ ​de​ ​pouvoir​ ​évoluer​ ​si​ ​besoin​ ​est 
et​ ​de​ ​pouvoir​ ​évaluer​ ​les​ ​modifications​ ​apportés​ ​au​ ​déroulement​ ​du​ ​travail. 

Rendre​ ​les​ ​règles​ ​explicites 

Il​ ​faut​ ​rendre​ ​clair​ ​la​ ​structure​ ​de​ ​notre​ ​tableau,quel​ ​est​ ​la​ ​fonction​ ​de​ ​chaque​ ​colonne​ ​afin 
de​ ​mieux​ ​comprendre​ ​les​ ​migrations​ ​des​ ​étapes​ ​du​ ​travail​ ​au​ ​sein​ ​d’un​ ​tableau. 
 

Implémenter​ ​des​ ​boucles​ ​de​ ​feedback 

Les​ ​équipes​ ​sont​ ​encouragés​ ​à​ ​discuter​ ​et​ ​à​ ​proposer​ ​des​ ​améliorations​ ​sur​ ​le​ ​déroulement 
du​ ​travail​ ​ou​ ​le​ ​projet​ ​en​ ​soi 
 
Test​ ​automatisés 
Le​ ​test​ ​d’une​ ​application​ ​doit​ ​être​ ​considéré​ ​comme​ ​partie​ ​intégrante​ ​du​ ​processus​ ​de 
développement. 
 
Néanmoins,les​ ​méthodes​ ​de​ ​test​ ​restent​ ​multiples​ ​et​ ​libres​ ​de​ ​choix​ ​à​ ​condition​ ​que​ ​des 
conventions​ ​de​ ​nommages​ ​soient​ ​dressées​ ​et​ ​respectées. 
 
Il​ ​est​ ​également​ ​d’important​ ​d'automatiser​ ​ses​ ​tests​ ​puisque​ ​des​ ​tests​ ​manuels​ ​auront 
tendance​ ​à​ ​nous​ ​se​ ​faire​ ​en​ ​toute​ ​fin​ ​du​ ​projet. 
 
La​ ​portabilité​ ​des​ ​test​ ​est​ ​primordiale​ ​afin​ ​de​ ​pouvoir​ ​tester​ ​le​ ​projet​ ​en​ ​cours​ ​peu​ ​importe 
notre​ ​situation​ ​actuelle. 
 
L’utilisation​ ​d’un​ ​“Stub”​ ​permettra​ ​de​ ​nous​ ​dispenser​ ​d’une​ ​base​ ​de​ ​données​ ​lorsque​ ​celle-ci 
n’est​ ​pas​ ​accessible. 
 
Stub​​ ​:​ ​Classe​ ​dont​ ​le​ ​but​ ​principale​ ​est​ ​de​ ​fournir​ ​des​ ​données​ ​et​ ​d’empêcher​ ​toute 
connexion​ ​à​ ​un​ ​système​ ​externe. 
 
Mock​​ ​:​ ​Classe​ ​dont​ ​le​ ​but​ ​est​ ​de​ ​vérifier​ ​la​ ​validité​ ​de​ ​la​ ​réponse​ ​elle​ ​même​ ​et​ ​non​ ​la​ ​valeur 
de​ ​la​ ​réponse. 
 
Il​ ​est​ ​également​ ​important​ ​de​ ​s’assurer​ ​de​ ​la​ ​zone​ ​de​ ​couverture​ ​du​ ​test​ ​que​ ​ce​ ​soit​ ​en​ ​terme 
d’espace​ ​ou​ ​de​ ​profondeur​ ​(Testez​ ​un​ ​appel​ ​de​ ​classe,...). 
 
Cependant,​ ​la​ ​quête​ ​d’optimisation​ ​à​ ​la​ ​couverture​ ​de​ ​test​ ​pousse​ ​à​ ​une​ ​réduction​ ​du 
nombre​ ​de​ ​lignes​ ​de​ ​codes​ ​jusqu’au​ ​détriment​ ​de​ ​la​ ​lisibilité​ ​du​ ​code​ ​(A​ ​ne​ ​pas​ ​abuser) 
 
On​ ​peut​ ​notamment​ ​citer​ ​plusieurs​ ​types​ ​de​ ​tests: 
1. De​ ​bout​ ​en​ ​bout​​ ​:​ ​Comme​ ​son​ ​l’indique,l’application​ ​est​ ​testée​ ​dans​ ​son​ ​entiereté 
jusqu’à​ ​la​ ​connexion​ ​à​ ​la​ ​base​ ​de​ ​donnée. 
2. Test​ ​d’intégration​​ ​:​ ​Chaque​ ​classe​ ​est​ ​testée​ ​individuellement​ ​jusqu’à​ ​sa​ ​connexion 
à​ ​la​ ​base​ ​de​ ​donnée. 
3. Test​ ​unitaire​​ ​:​ ​Chaque​ ​classe​ ​est​ ​testée​ ​individuellement. 
4. Test​ ​de​ ​composants​​ ​:​ ​L’application​ ​est​ ​testée​ ​au​ ​niveau​ ​offline. 
 
 

Behavior​ ​Driven​ ​Development 

 
Le​ ​Behavior​ ​Driven​ ​Development​ ​ou​ ​BDD​ ​est​ ​considéré​ ​comme​ ​un​ ​Test​ ​Driven 
Development​ ​amélioré. 
 
Elle​ ​se​ ​caractérise​ ​par​ ​une​ ​amélioration​ ​de​ ​la​ ​lisibilité​ ​des​ ​tests​ ​notamment​ ​via​ ​le​ ​nommage 
des​ ​tests​ ​qui​ ​sont​ ​des​ ​phrases​ ​explicatives​ ​des​ ​résultats​ ​attendus. 
 
Elles​ ​permettent​ ​notamment​ ​à​ ​des​ ​personnes​ ​non​ ​développeurs​ ​de​ ​pouvoir​ ​lire​ ​et 
comprendre​ ​les​ ​tests.​ ​Elle​ ​est​ ​même​ ​conçue​ ​expressément​ ​dans​ ​ce​ ​but,de​ ​pouvoir​ ​êtres​ ​uivi 
par​ ​des​ ​tiers​ ​personnes.​ ​(Une​ ​démonstration​ ​vaut​ ​mieux​ ​que​ ​1000​ ​mots) 
 
Néanmoins,des​ ​inconvénients​ ​restes​ ​à​ ​prévoir,citons​ ​la​ ​lourdeur​ ​de​ ​l’implémentation,le 
temps​ ​perdu​ ​dû​ ​aux​ ​multiples​ ​compilations​ ​et​ ​l’automatisation​ ​difficile.Cela​ ​exige​ ​de​ ​plus 
une​ ​participation​ ​obligatoire​ ​du​ ​client​ ​afin​ ​d’assurer​ ​une​ ​vérification​ ​constante​ ​des​ ​test. 

Agile​ ​à​ ​grande​ ​échelle 

Les​ ​méthodes​ ​Agile​ ​restent​ ​assez​ ​simple​ ​à​ ​appliquer​ ​lorsqu’il​ ​n’y​ ​a​ ​que​ ​un​ ​seul​ ​groupe​ ​à 
gérer.Cependant,en​ ​grandissant,une​ ​entreprise​ ​peut​ ​avoir​ ​de​ ​plus​ ​en​ ​plus​ ​de​ ​mal 
d’appliquer​ ​ces​ ​méthodologies​ ​au​ ​sein​ ​de​ ​plusieurs​ ​équipes​ ​simultanées.En​ ​effet,la 
communication​ ​étant​ ​primordiale​ ​il​ ​devient​ ​difficile​ ​de​ ​la​ ​maintenir​ ​entre​ ​plusieurs​ ​équipes. 
 
Scrum​ ​of​ ​Scrums​​ ​:​ ​C’est​ ​une​ ​réunion​ ​journalière​ ​de​ ​+-​ ​15min​ ​où​ ​chaque​ ​équipe​ ​se​ ​doit 
d’envoyer​ ​un​ ​“ambassadeur”​ ​dans​ ​le​ ​but​ ​de​ ​quérir​ ​les​ ​dernières​ ​informations. 
 

SAFe 
SAFe​ ​ou​ ​Sealed​ ​Agile​ ​Framework​ ​est​ ​un​ ​plan​ ​d’application​ ​des​ ​méthodes​ ​Agile​ ​c’est​ ​à​ ​dire 
un​ ​ensemble​ ​de​ ​processus​ ​préfaits​ ​et​ ​à​ ​être​ ​appliquée​ ​au​ ​sein​ ​d’une​ ​entreprise. 
 
Cependant​ ​la​ ​formation​ ​à​ ​ce​ ​système​ ​est​ ​assez​ ​onéreux​ ​dû​ ​à​ ​son​ ​système​ ​de​ ​certification​ ​et 
convient​ ​aux​ ​entreprises​ ​assez​ ​volumineuses,de​ ​plus​ ​il​ ​inclut​ ​un​ ​ ​nombre​ ​de​ ​règles​ ​assez 
conséquent​ ​et​ ​rend​ ​parfois​ ​les​ ​choses​ ​moins​ ​pragmatiques. 
 

LeSS 
De​ ​Large​ ​Scale​ ​Scrum​ ​,​ ​Less​ ​est​ ​moins​ ​prescriptif​ ​que​ ​SAFe​ ​et​ ​moins​ ​axé​ ​sur​ ​les 
certifications. 
 
Bien​ ​d’autres​ ​framework​ ​existe​ ​mais​ ​elles​ ​restent​ ​assez​ ​paradoxal​ ​au​ ​principe​ ​même​ ​d’Agile 
qu’est​ ​l’évolutivité​ ​au​ ​jour​ ​le​ ​jour​ ​et​ ​non​ ​suivre​ ​un​ ​plan​ ​de​ ​règles​ ​pré-établies. 
 

Projets​ ​au​ ​Forfait 

On​ ​peut​ ​comparer​ ​les​ ​projets​ ​forfaits​ ​aux​ ​projets​ ​en​ ​régies 
 
Projet​ ​forfait​​ ​:​ ​Une​ ​société​ ​demande​ ​à​ ​ce​ ​qu'un​ ​projet​ ​soit​ ​développé​ ​au​ ​sein​ ​d’une 
entreprise​ ​informatique.Une​ ​analyse​ ​du​ ​projet​ ​demandé​ ​sera​ ​fait​ ​c’est​ ​à​ ​dire​ ​des​ ​frais 
encourus​ ​ainsi​ ​que​ ​la​ ​planification​ ​du​ ​temps​ ​de​ ​développement​ ​estimé​ ​(Contraire​ ​à​ ​Agile​ ​!). 
Il​ ​s’en​ ​suit​ ​alors​ ​une​ ​offre​ ​fixe​ ​du​ ​prix​ ​de​ ​développement.Le​ ​projet​ ​devient​ ​ensuite​ ​à​ ​charge 
de​ ​l’entreprise​ ​informatique. 
 
Projet​ ​régie​​ ​:​ ​Des​ ​consultants​ ​sont​ ​envoyés​ ​au​ ​sein​ ​d’une​ ​entreprise​ ​qui​ ​souhaiterait 
développer​ ​un​ ​projet.Le​ ​projet​ ​reste​ ​à​ ​charge​ ​de​ ​l'entreprise​ ​et​ ​les​ ​consultants​ ​sont​ ​payés​ ​à 
un​ ​tarif​ ​horaire. 
 
Les​ ​projets​ ​au​ ​forfait​ ​implique​ ​donc​ ​une​ ​dimension​ ​de​ ​qualité​ ​supplémentaire​ ​puisque​ ​un 
projet​ ​de​ ​bonne​ ​qualité​ ​fidélisera​ ​une​ ​clientèle. 
 
Cependant​ ​les​ ​frais​ ​d’un​ ​projet​ ​forfait​ ​ne​ ​s’étendent​ ​pas​ ​jusqu’à​ ​la​ ​fin​ ​du​ ​projet​ ​mais​ ​bien 
jusqu’à​ ​un​ ​certain​ ​point.Ainsi​ ​si​ ​les​ ​marges​ ​supplémentaires​ ​sont​ ​minimes,il​ ​y​ ​aura​ ​une 
confiance​ ​croissante​ ​du​ ​client​ ​ainsi​ ​qu’un​ ​gain​ ​d’expérience. 
 
Le​ ​plus​ ​important​ ​reste​ ​pour​ ​autant​ ​la​ ​présentation​ ​d’un​ ​“MVP”​ ​ou​ ​Minimum​ ​Viable​ ​Product 
c’est​ ​à​ ​dire​ ​un​ ​produit​ ​assez​ ​riche​ ​pour​ ​être​ ​présentable​ ​mais​ ​trop​ ​pour​ ​pouvoir​ ​être 
présenté​ ​à​ ​temps. 

Lean​ ​Startup 
 
Il​ ​s’agit​ ​de​ ​l’application​ ​des​ ​principes​ ​Lean​ ​au​ ​lancement​ ​d’une​ ​startup. 
 
L’idée​ ​part​ ​du​ ​problème​ ​qu’une​ ​Startup​ ​cherche​ ​à​ ​développer​ ​un​ ​concept​ ​sans​ ​chercher 
l’avis​ ​du​ ​(futur)client. 
 
5​ ​principes​ ​:  
 
1. Les​ ​entrepreneurs​ ​sont​ ​partout 
2. L'entreprenariat​ ​revient​ ​à​ ​faire​ ​du​ ​management 
3. L’apprentissage​ ​validé 
4. Faire-Mesurer-Apprendre 
5. Evaluer​ ​pour​ ​l’innovation 

Les​ ​entrepreneurs​ ​sont​ ​partout 

La​ ​création​ ​d’une​ ​entreprise​ ​ne​ ​se​ ​limite​ ​pas​ ​à​ ​un​ ​bureau​ ​mais​ ​peut​ ​venir​ ​d'autre 
part(garage,...) 

L'entreprenariat​ ​revient​ ​à​ ​faire​ ​du​ ​management 

Il​ ​faut​ ​être​ ​prêt​ ​à​ ​apprendre​ ​et​ ​même​ ​l’encourager,à​ ​gérer​ ​les​ ​chiffres,à​ ​suivre​ ​la​ ​progression 
au​ ​jour​ ​le​ ​jour. 
Apprentissage​ ​validé 
Le​ ​départ​ ​sur​ ​des​ ​hypothèses​ ​amène​ ​souvent​ ​à​ ​des​ ​déceptions​ ​puisque​ ​le​ ​client​ ​ou​ ​le 
publique​ ​cible​ ​n’est​ ​jamais​ ​consulté. 
 
Une​ ​mauvaise​ ​habitude​ ​est​ ​de​ ​faire​ ​un​ ​changement​ ​radical​ ​de​ ​direction​ ​quand​ ​les​ ​choses​ ​se 
profilent​ ​mal.Le​ ​secret​ ​des​ ​startups​ ​qui​ ​fonctionnent​ ​ne​ ​sont​ ​pas​ ​la​ ​qualité​ ​de​ ​leurs​ ​idées 
mais​ ​leur​ ​faculté​ ​d’adaptations​ ​via​ ​des​ ​“pivots”​ ​suivant​ ​des​ ​retours​ ​du​ ​terrain​ ​c’est​ ​à​ ​dire 
éviter​ ​de​ ​jeter​ ​l'entièreté​ ​du​ ​travail​ ​amis​ ​l’adapter,la​ ​réorienté​ ​vers​ ​un​ ​nouvel​ ​objectif. 
 
Un​ ​projet​ ​ne​ ​se​ ​calcule​ ​dès​ ​lors​ ​plus​ ​qu’en​ ​“pivots”​ ​suivant​ ​le​ ​budget​ ​restant.Bien 
entendu,l’objectif​ ​est​ ​de​ ​réduire​ ​au​ ​maximum​ ​le​ ​nombre​ ​pivots. 

Faire-Mesurer-Apprendre 
Le​ ​but​ ​est​ ​de​ ​suivre​ ​un​ ​schéma​ ​cyclique​ ​précis​ ​: 
1. Idée 
2. Construire 
3. Produire 
4. Mesurer 
5. Récolter​ ​les​ ​données 
6. Apprendre 
 
Chaque​ ​itération​ ​de​ ​ce​ ​schéma​ ​correspond​ ​à​ ​un​ ​pivot​ ​qu’il​ ​faut​ ​de​ ​plus​ ​en​ ​plus​ ​accélérer​ ​au 
fur​ ​et​ ​à​ ​mesure​ ​qu’on​ ​se​ ​fait​ ​une​ ​idée​ ​du​ ​produit​ ​finale. 

Evaluer​ ​pour​ ​l’innovation 

 
Il​ ​s’agit​ ​d’établir​ ​le​ ​stade​ ​actuel​ ​du​ ​projet/entreprise,de​ ​jauger​ ​le​ ​progrès​ ​fait​ ​depuis​ ​le 
commencement​ ​et​ ​de​ ​prévoir​ ​le​ ​prochain​ ​pivot​ ​si​ ​le​ ​besoin​ ​se​ ​fait​ ​ressentir​ ​ou​ ​alors 
continuer​ ​à​ ​se​ ​concentrer​ ​sur​ ​l’état​ ​du​ ​projet​ ​en​ ​cours. 
 

Conclusion 
Une​ ​startup​ ​qui​ ​fonctionne​ ​est​ ​une​ ​startup​ ​qui​ ​ne​ ​craint​ ​pas​ ​l’échec​ ​et​ ​qui​ ​n’hésite​ ​pas​ ​à 
enchainer​ ​une​ ​suite​ ​d’expérimentations​ ​adaptés​ ​au​ ​retour​ ​client.​ ​Le​ ​tout​ ​suivi​ ​par​ ​un 
management​ ​qui​ ​pousse​ ​à​ ​l’innovation​ ​et​ ​à​ ​l’apprentissage.