2. Qui sommes-nous ?
Une équipe d'experts en transformation digitale
Depuis 2018
Nos expertises: Développement Web Front / Back / Full-Stack, DevOps, AMOE, AMOA
L'équipe
La stack technique
3. Nos Rocket Points
Clients
Equipe
Des partenariats
long-termes
Une fabrique à
projets interne
Top Profils
Top Missions
Vision 360° - Think out of the box
Onboarding 1 mois chez un client BluTech
Bonnes pratiques & Valeurs
Garantie de moyens et de ressources
Profil opérationnel au 1er jour
Fabrique à projets interne
Diversité & Intrapreneuriat
Recrutement sur profil
Onboarding BluTech chez un client référence
Montée en compétence rapide
Nos Postes Ouverts: développeur Fullstack, Product Owner, Chef de projet
Technique
6. Sommaire
Histoire
70s et 80s
90s
Ford VS Toyota
Le LEAN
Naissance de l’agile manifesto
4 valeurs
12 principes
Pour conclure
7. Histoire : 70s et 80s
Progrès continue et rapide de l’informatique
Ordinateur personnel fin 70s avec Minitel en France
Plus complexe de faire des systèmes d’information
Première représentation graphique du modèle en
cascade par Winston W. Royce
8. Evolution du Waterfall : le cycle en V
Apparition des premiers diagrammes
Histoire : 70s et 80s
10. Histoire : Ford vs. Toyota
Japon vient de perdre la WWII
Pas de production de masse
Domine le marché mondial
Grande quantité de produit
Performance : une personne fait une tâche en boucle
Plus ils fabriquent, plus ils font de l’argent
Satisfaction client est fondamentale
2 concepts principaux : zéro perte et zéro
inflexibilité
Fabrication d’une boite à outil :
le LEAN manufacturing
11. Histoire : le LEAN
2 concepts
principaux
Zéro perte
Zéro inflexibilité
Satisfaction client
fondamentale
Eliminate waste
Amplified learning
Decide as late as possible
Deliver as soon as possible
Empower the team
Build integrity
See the all
12. Création en 2001
Naissance de l’agile
manifesto
17 experts
« Mieux développer des logiciels par la pratique et
aider les autres à le faire »
4 valeurs et 12 principes
Waterfall et cycle en V ne correspondent plus aux
exigences des entreprises
Attention aux dérives
13. L’interaction entre les individus
PLUS QUE
les processus et les outils
Une collaboration avec les clients
PLUS QUE
une négociation contractuelle
Un logiciel opérationnel
PLUS QUE
une documentation exhaustive
Une adaptation au changement
PLUS QUE
le suivi d’un plan
“Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.”
Les 4 Valeurs
14. “La 2eme partie de la formulation n’est pas un objectif en soi,
mais un moyen au service de la 1ere qui elle est bien l’objectif
visé.”
Finalité
pourquoi
Stratégie
quoi
Tactique
comment
Les 4 Valeurs
“Nous reconnaissons la valeur des seconds éléments, mais
privilégions les premiers.”
L’interaction entre les individus PLUS QUE les
processus et les outils
Définir la meilleure solution possible
Challenger la valeur de chaque élément du produit
à réaliser.
15. L’interaction entre les individus
PLUS QUE
les processus et les outils
Définir la meilleure solution possible
Challenger la valeur de chaque élément du produit à réaliser
Une collaboration avec les clients
PLUS QUE
une négociation contractuelle
La réussite qui s’obtient en négociant puis en préservant les intérêts
divergents de chacun
Rechercher un accord WIN-WIN entre toutes les parties prenantes
Un logiciel opérationnel
PLUS QUE
une documentation exhaustive
Prioriser chaque élément du backlog en fonction de sa valeur et des
risques projet
Réaliser un MVP enrichit par incréments si la valeur des ajouts est
démontrée
Une adaptation au changement
PLUS QUE
le suivi d’un plan
Maîtriser les aléas sur la cible produit et sa trajectoire en anticipant
les risques
Décider le plus tard possible puis délivrer le plus vite possible
Les 4 Valeurs
16. Les 12 Principes
Le dialogue en face à face
L’équipe réfléchit aux moyens de devenir plus efficace,
puis modifie son comportement
Réaliser les projets avec des personnes motivées, leur
fournir l’environnement et le soutien dont ils ont besoin
La simplicité est essentielle
Accueillir positivement les changements de besoins
Les meilleures architectures, spécifications et
conceptions émergent d’équipes autoorganisées
Les utilisateurs et les développeurs doivent travailler
ensemble quotidiennement
Un rythme de développement soutenable et constant
Livrer fréquemment un logiciel opérationnel
L’attention continue à l’excellence technique et à une
bonne conception renforce l’agilité
Satisfaire le client en délivrant rapidement
Un logiciel opérationnel comme principale mesure
d’avancement
17. Satisfaire le client en délivrant rapidement
Croire que le délai prime sur le contenu livré
Utiliser un diagramme de Kano pour mesurer la satisfaction client
L’attention continue à l’excellence technique et à une
bonne conception renforce l’agilité
Conduire le projet en mode agile en oubliant de concevoir un SI
agile apte à supporter aisément des changements
Concevoir la solution en respectant de bonnes pratiques
d’architecture
Livrer fréquemment un logiciel opérationnel
Noyer les utilisateurs par des recettes et des modification
incessantes
Cible un MVP en V1 puis des incréments selon un rythme
soutenable
Un rythme de développement soutenable et constant
Epuiser les équipes pour tenir chaque échéance
Respecter comme pour tout autre métier le code du travail et les
dispositions légales de l’organisation
4 Principes détaillés
19. Pour conclure
Existe depuis plus de 20 ans
Formalisé pour mieux développer des logiciels
Valeurs et principes présentent des risques de mauvaise compréhension
Sur 17 experts, 5 en font la critique :
Non respect des valeurs et principes
Devenu commercial
Services prétendument « agiles »
Imposition des méthodes aux équipes
Naissance aussi du C
Ordinateurs de + en + fiable
Waterfall -> modèle avec 6 phases
WWR -> critique l’article de Herbert D. Benington sur le dev du système militaire SAGE en 56 (le trouve insuffisant : chaque phase doit renvoyer à la précédente en cas de défaut).
Article WWR -> fondateur pour waterfall et qui le popularise
80 -> ère des GUI (Interfaces Utilisateur Graphique)
Cycle en V -> comporte 2 flux : - descendant : détailler le produit jusqu’à la réalisation (expression des besoins, analyse, conception, et mise en œuvre)
- Ascendant : valider le produit jusqu’à la recette (comprend une série de tests jusqu’à pouvoir valider que le produit répond au besoin)
HIPO -> IBM (70) : représentation des modules du système comme une hiérarchie
UML -> (créé 80 mais publié 97)
Avec arrivé d’internet -> forte demande pour le numérique (numérisation de photos, musiques ou avoir des données partagées)
6 sigma -> Motorola (découvre le LEAN en 90) / 2 concepts principaux : Zéro défaut et Zéro Variation
UP puis RUP d’Ivar Jackobson / 4 phases de conception de produit ([Cadrage / Elaboration] (disade as late as possible) / [Construction / Transition] (Deliver as soon as possible))
SCRUM de Ken Schwaber et Jeff Sutherland / méthode de gestion des pratiques comportementale -> répond à la plupart des préconisations du manifeste agile. Sprints passant par différentes phases
Zéro perte : éviter le gaspillage
Zéro inflexibilité : s’adapter à la demande client
Beaucoup d’outils :
TPM : (Total Productive Maintenance) pratique qui vise à construire une culture d’entreprise qui améliore l’efficience du système de production
Kanban : Carte de gestion des stocks qui permet l’amélioration de la relation client – fournisseur (backlog scrum)
JIT : (Juste à Temps) Rotation des stocks -> permet de les dimensionner au plus juste (gestion -> Kanban) -> le moins de stock possible (pas beaucoup de place au Japon)
5s : (5 termes japonais) méthode d’organisation de l’espace de travail
SMED : Changement de série rapide -> méthode qui vise a optimiser les opération nécessaire pour passer d’un lot à un suivant
Principes :
Éliminer le gaspillage
Approfondir l’apprentissage
Décider le plus tard possible
Délivrer le plus tôt possible
Responsabilisé l’équipe
Construire l’intégrité (créer une proximité et une relation de confiance)
Voir l’ensemble
Decide as late ET Deliver as soon -> repris dans UP
Empower the team -> repris dans SCRUM (ex : daily meeting)
Kent Beck -> père fondateur de l’extreme programming et co-fondateur de Junit
Ken schwaber
Jeff Sutherland
Alistair Cockburn -> Crystal Clear
« développer des logiciels » -> on peut l’appliquer dans d’autre domaine
Principes repris directement du LEAN
Accueillir -> si changement, il faut dire oui même si ça remet en question le SI, Avec la 3eme valeurs « une collaboration avec les clients plus que une négociation contractuelle », combo gagnant pour que le projet prenne du retard et qu’il soit de plus en plus coûteux
Logiciel opérationnel -> si sur plusieurs semaines, l’équipe se concentre sur des aspects techniques et non sur des aspects fonctionnel, alors le projet n’avance pas
L’équipe -> induit l’idée que si il y a un problème, c’est de la faute de l’équipe
Kano -> 2 courbes avec les attentes de bases et les attentes attractives s‘oppose). Le but est de tendre vers les 2 pour avoir une bonne satisfaction client.
But : donner une introduction à l’agilité
Donner des exemples de rôles :
PO : responsable de la conception d’un produit
Scrum master : responsable de la méthode et des équipes. Fait en sorte que la méthode soit bien respecté
Exemples de rituels:
Sprint Planning : première réunion de chaque sprint scrum -> prendre des éléments du backlog à intégrer sur le sprint
Daily meeting : réunion de l’équipe tous les jours pour voir l’avancement sur le backlog (3questions : ce que j’ai fais hier, ce que je vais faire ajd, et est-ce que j’ai besoin d’aide)
Backlog grooming : réunion pour passer en revu le backlog et s’assurer que tout est à jour
Méthodes:
Google Design Sprint -> processus de conception pour répondre a une problématique en un cours laps de temps
A3 -> méthodes pour identifier les pb et proposer des solutions résumées en un coup d’œil
