SlideShare une entreprise Scribd logo
1  sur  46
Télécharger pour lire hors ligne
Connaissez-vous la réponse ?
Selon vous, quelle est la meilleure organisation ?
1. Une méthode unique est indépendante entre chaque équipe
2. Une méthode centrale commune à toutes les équipes
3. Une méthode centrale permettant à chaque équipe d’avoir sa propre méthode
Présentation
Qui Suis-je ?
https://www.meetup.com/fr-FR/Meetup-Leadership-agile-Luxembourg/
Michel Bruchet
• Architecte Entreprise
• Ancien créateur et dirigeant d’une Startup
• Écrivain de nombreux blogues et livres
• Évangéliste Daikibo / Agilité d’Entreprise
• Expert ALM Microsoft
Mes coordonnées :
• Email : michel.bruchet@versusmind.eu
• Linkedin : https://www.linkedin.com/in/michelbruchet/
Les différents cycles de développement
• Rappel historique sur l’évolution de l’informatique
Opportunité
Cadrage
Analyse
Programmation
Tests unitaires
Tests fonctionnels
Site pilote
Cycle en Cascade
Par la structure (Top down)
Exploration
Architecture
Par le besoin (bottom up)
Construction
Test
Cycle semi-itératif
Faisabilité
Elaboration
Construction
Transition
Cycle full-itératif
Évolution des différents cycle de développement
Flaccid Scrum
Martin Fowler, 2009
- Les organisations souhaitent utiliser un processus agile et prennent Scrum
- Ils adaptent les pratiques de SCRUM et voir même ses principes
- Après ils se plaignent que leur projet tardent et leur organisation est lente et peu flexible
Les limites de kanban
• Que se passe-t-il si un développement dure plusieurs jours ?
• Que se passe-t-il si on doit revenir dans la phase Analyse une fois le développement commencé ?
Les limites de LEAN
• Un management désincarné
• Une application partielle
• Des risques pour la santé des travailleurs
• Un prétexte pour licencier
• Une mutualisation des fonctions excessive
• Un accompagnement indispensable
En conséquence
• Il n’existe aucune méthode agile capable d’être appliquée tout le temps partout
• Le manifeste agile a fait tâche d’huile et les organisations cherchent à l’appliquer à leur organisation toute entière et non
seulement le développement
caractéristiques d’un projet pour justifier le recours
à des méthodes agiles
• Orientation majoritairement interne
• Budget inférieur à EUR 1 million
• Equipe de projet de 5 à 9 personnes
• Activités qui se répètent souvent, voire constamment
• Budget grossièrement défini et exigences floues en termes de résultats
• Durée de 3 à 9 mois
DAIKIBO
DU MANIFESTE AGILE A L’AGILITE DE L’ENTREPRISE
ET SI ON RECOPIER L’AGILE A L’ENTREPRISE
• Problème de communication
• Problème de planification
• Problème d’affectation des nouveaux besoins et peines
• Rupture de la chaine
L’agilité et la scalabilité ne consiste pas à cloner les petites équipes mais demandent
de la bonne gouvernance et de l’ intelligence organisationnelle
Pourquoi combiner Agilité et Scalabilité au niveau de l’entreprise ?
Promouvoir au niveau de l’entreprise
Produits de qualité
Marque Employeur et Bien être de travail
Cocréation de valeur
Prise de Risque
Maturité Culturelle
Des moyens, outils, processus et méthodes
Une bonne gouvernance
Une conduite du changement et une meilleur sensibilisation du management
Quand adapter l’Agilité et la Scalabilité à l’entreprise ?
 10 à 120 Personnes
 Plusieurs Projets et équipes de réalisation
 Un nombre restreint d’équipe de conception
 Un nombre restreint d’équipe de validation
DAIKIBO
Introduction à la méthode
大規模
Agilité et Scalabilité appliqué à l’Entreprise 16
Daikibo
• Nom vient du Japonais (大規模) et veut dire « de grande
envergure »
• Méthode scalable, distribuée, agile et orienté LEAN
• Combinaison des frameworks SCRUM, Kanban, XP
• Basée sur les principes et les piliers du manifeste Agile et de
LEAN
Agilité et Scalabilité appliqué à l’Entreprise 17
Valeurs de DAIKIBO
• Transparence
• Inspection
• Adaptation
Valeurs de SCRUM
■ Achèvement
■ Courage
■ Respect
■ Ouverture
Valeurs du Manifeste Agile Valeurs de XP
■ Vérité
■ Simplicité
■ Partage
Agilité et Scalabilité appliqué à l’Entreprise 18
Alignement business et IT
• Partenariat d’égal à égal entre le Business et l’IT
• Business et IT doivent aller de pair
• Chaque équipe doit avoir autant de poid
• Aucun ne doit dominer l’autre
• Si le business l’emporte sur l’IT
• Déconnection entre la réalité et le souhait, les fonctionnalités et la qualité des
livrables seront mis en danger
• Si l’IT l’emporte sur le business
• Déconnection entre la réalité et le souhait, les fonctionnalités et les livrables ne
correspondront plus à ce qui est souhaité
Agilité et Scalabilité appliqué à l’Entreprise 19
DAIKIBO et Scrum
Equipe 2
Product Backlog Sprint Planning
Sprint
SCRUM
Equipe 1
Product Backlog Sprint Planning
Sprint
SCRUM
SCRUM Of SCRUM
Sprint Retro, Sprint
Planning, Backlog
Agilité et Scalabilité appliqué à l’Entreprise 20
Différences entre DAIKIBO et SCRUM
• Même quotidien
• Pas les mêmes équipes
• OTT, Delivery, Validation
• Les fonctionnalités et cas d’utilisation
• Application à la méthode KANBAN ou XP
• Nouveaux indicateurs d’estimation
• Fonction, Du cas d’utilisation & de la tâche
• Estimation doit être avant le planning des sprints
Agilité et Scalabilité appliqué à l’Entreprise 21
Points communs entre DAIKIBO et SCRUM
• Réunion de prévision
• Famille de propriétaire de produit
• Intégrer dans une famille
• Appartenant à l’équipe de production
• Même scénarii
• Importance des cas d’utilisation
• Focus donné aux métriques
Agilité et Scalabilité appliqué à l’Entreprise 22
Planning type d’un développeur
Livraison
• Rétrospective jour 15
ou 20
• Démonstration jour 15
ou 20
Développement
• Test unitaire Jour 4 et 5
• Résolution et correction
Jour 5 à 10 ou 20
• Revue du code jour 6 à
20
Spécification
• Sprint Planning Jour 1
• Spécification Technique
Jour 1 et 2
• Revue des cas
d’utilisation Jour 3
Jour 1 à Jour 3 Jour 4 à Jour
15/20
Jour 15 ou 20
Agilité et Scalabilité appliqué à l’Entreprise 23
Structures d’équipes
Agilité et Scalabilité appliqué à l’Entreprise 24
Approche SCRUM / Agile
Le
Propriétaire
du produit
Le maître des
mêlées
Les développeurs
Transformation
DAIKIBO
L’équipe conception (OTT)
Le
Propriétaire
du produit
L’auteur des
cas
d’utilisation
L’équipe Livraison (Delivery)
Le
Propriétaire
Proxy
Le maître des
mêlées
Les développeurs Les qualiticiens
L’équipe Validation
Le
Propriétaire
Proxy
Les qualiticiens
Développeurs
d’automates de test
Dimensions des équipes
• Taille d’équipe idéale entre 7 et 11 personnes
• Limites maximale 15 personnes
• Limites minimales 5 personnes
• Ajustement et scalabilité entre 5 et 11 personnes
Agilité et Scalabilité appliqué à l’Entreprise 25
5
11
Comparaison entre le cycle en cascade et
DAIKIBO
• Cycle en cascade
Agilité et Scalabilité appliqué à l’Entreprise 26
Spécification des
besoins
Conception /
Modélisation
Implémentation Test et Validation
■ DAIKIBO
Spécification Conception Implémentation Validation
Focus sur La Direction
Informatique
DSI, Direction Informatique, Recherche et Développement
Agilité et Scalabilité appliqué à l’Entreprise 27
Quelques principes ou règles d’or
• Une équipe doit être constituée pour
• Plus d’une release
• Idéalement pour 1 an voir plus
• Travailler sur des projets séquentiels
• Une équipe doit avoir une démarche incrémentale
• En 5 Sprint
• 4 Ajout de fonctionnalités
• 1 Innovation / Amélioration / Préparatoire
• Une Equipe doit avoir des problèmes à résoudre
• Chaque membre d’une équipe doit être solidaire et coresponsable
Agilité et Scalabilité appliqué à l’Entreprise 28
Attention une équipe est sacrée, on ne partage pas les personnes dans plusieurs équipes
Equipe Support / Equipe Fonctionnelle
• Il existe 2 niveau Equipe / Groupe
• Il existe 2 types d’équipe au sein de la production
Agilité et Scalabilité appliqué à l’Entreprise 29
Equipe Support : Ce qui supporte l’équipe fonctionnelle
L’équipe support peut être partagé mais l’équipe fonctionnelle est toujours la même
Equipe fonctionnelle : Ce qui font le travail
Equipe support
• IT, Poste de travail
• Architecture
d’entreprise
• Faisabilité (POC)
• Design applicatif
• Dev ops
• Framework
• UX / UI
• Performance / Testing
Agilité et Scalabilité appliqué à l’Entreprise 30
IT / Poste de travail
• Assurer le bon fonctionnement des postes de travail
• Fournir des solutions de partages de documents
• Fournir des solutions de discussion et d’échange de groupe
(Messagerie, Partage documentaire, Sharepoint)
• Assurer la sécurité du réseau
• Fournir les services réseaux et infrastructures adéquates
Agilité et Scalabilité appliqué à l’Entreprise 31
Architecture Entreprise
• Recommandations et design de très haut niveau
• Travail avec les équipes business sur les plans de route
• Identifie et approuve les outils et composants à utiliser
• Référence technique et guide sur les sujets complexes
Agilité et Scalabilité appliqué à l’Entreprise 32
Etude de Faisabilité (POC)
• Créer des projets d’étude de faisabilités (POC)
• Teste et améliore les solutions techniques apportées
• Valide les nouvelles solutions et composants
Agilité et Scalabilité appliqué à l’Entreprise 33
Design applicatif
• Examine les demandes métiers
• Définit comment y répondre
• Aligne le technique et le business sur la même longueur
• Travaille donc avec le business
Agilité et Scalabilité appliqué à l’Entreprise 34
Dev ops
• Automatise les builds, les tests unitaires
• Environnements
• Développement
• Test
• Qualification
• Production
Critique à la réussite du projet
Agilité et Scalabilité appliqué à l’Entreprise 35
Framework
• Créer des boîtes à outils
• Créer des structures applicatives et des templates
• Faciliter la réutilisabilité
Agilité et Scalabilité appliqué à l’Entreprise 36
UX / UI
• Reprendre le travail de l’équipe architecture
• Le rendre joli et agréable à utiliser
• Créer les lignes graphiques (wireframes) des applications métiers
• S’assurer que l’interface utilisateur soit
• Fonctionnel
• Utilisable
• Confortable et adaptable
Agilité et Scalabilité appliqué à l’Entreprise 37
Test de performance
• Valide le bon fonctionnement des applications
• Valide le temps de réponse
• Valide toutes les couches des services et applications
• Base de données, moteur de recherche, service REST
• Assure le respect des SLA
• Reporte aux développeurs
Agilité et Scalabilité appliqué à l’Entreprise 38
Support applicatif
• S’assure que tout fonctionne correctement en production
• Assiste les utilisateurs finaux
• Intervient à différents niveaux
• L1 directement aux près des utilisateurs
• L2 analyse et support des personnes L1
• L3 Expert techniques, diagnostique et supporte les L2
• Tient des bases de connaissances de problèmes et les partage avec
les différentes équipes
• Escalade les problèmes complexes
Agilité et Scalabilité appliqué à l’Entreprise 39
L’équipe fonctionnelle
• 3 Groupes
• OTT, Delivery Team et Validation
Agilité et Scalabilité appliqué à l’Entreprise 40
Produit 1
Produit 2
OTT
Réalisation 1
Réalisation 2
Validation
Le groupe OTT
• Propriétaires du produit
• Les analystes métiers (Business analyst ou SMES)
• Les analystes fonctionnelles
En livraison
• Définie les épics et fonctions
• Livre les cas d’utilisations ou histoires
• Crée et maintient en vie le backlog
• Prévoit et collabore à l’amélioration de l’expérience utilisateur
Agilité et Scalabilité appliqué à l’Entreprise 41
Les groupes Réalisation
• Réalisent les services et outils demandés
• Utilisent SCRUM
• Divisent les histoires et cas d’utilisation en Tâches et estime le temps nécessaire
• Ecrivent et valident les tests unitaires
• Une collaboration nette doit exister avec le propriétaire du produit (proxy) pour
clarifier les histoires
• Effectuent les démo, explorent et cherchent à comprendre les fonctions non
achevées à la fin de leur sprint
Agilité et Scalabilité appliqué à l’Entreprise 42
Le maître
des mêlées
Les développeursLe Propriétaire
du produit
Proxy
Les
testeurs
Le groupe Validation
• Il est composé par
• Qualiticiens
• Intégrateurs :
• Créé le story d’intégration ou le bon de livraison
• Travaille avec les développeurs pour résoudre les problèmes d’intégration
• Ecrit et exécute les tests d’intégration automatique
• Effectue les tests de non régression
Agilité et Scalabilité appliqué à l’Entreprise 43
Les Interactions entre les groupes et les équipes
Agilité et Scalabilité appliqué à l’Entreprise 44
Architecture UI/UX POC/Implémentation Performance testing Livraison
Entrants Histoire utilisateurs Histoire
utilisateurs
Histoire utilisateurs Cas d’utilisation,
conditions d’acceptances
Code,
Configuration
Sortants Design pattern,
Solution Design et
Framework
Maquette
(Wireframes)
Décision / Applicatifs Scripts de tests
automatique, qa
automatique fonctionnelle
IC, LC, Envs
Contact en
entrée
Business Equipe
Architecture / OTT
Architecture / UI Equipe développement Equipe
Développement /
Performance
Contact en
Sortie
POC / UI POC Livraison Livraison Support
Point sur le meetup
Se réunir est un début, rester
ensemble est un progrès, travailler
ensemble est la réussite.
https://www.meetup.com/fr-FR/Meetup-Leadership-agile-
Luxembourg/

Contenu connexe

Similaire à Meetup daikibo 1

Webinar TDD / BDD : Comment mieux délivrer et s'entendre pour le Product Owne...
Webinar TDD / BDD : Comment mieux délivrer et s'entendre pour le Product Owne...Webinar TDD / BDD : Comment mieux délivrer et s'entendre pour le Product Owne...
Webinar TDD / BDD : Comment mieux délivrer et s'entendre pour le Product Owne...DC CONSULTANTS
 
20181123 - Agile Tour Rennes - Pourquoi je déteste l'agilité à l'échelle
20181123 - Agile Tour Rennes - Pourquoi je déteste l'agilité à l'échelle20181123 - Agile Tour Rennes - Pourquoi je déteste l'agilité à l'échelle
20181123 - Agile Tour Rennes - Pourquoi je déteste l'agilité à l'échelleSéverin Legras
 
Combiner la gestion de projet Agile (AgilePM®) et SCRUM
Combiner la gestion de projet Agile (AgilePM®) et SCRUMCombiner la gestion de projet Agile (AgilePM®) et SCRUM
Combiner la gestion de projet Agile (AgilePM®) et SCRUMSvetlana Sidenko
 
ATMTL23 - L'odysée d'un PMO vers un VMO par Elyes Dekhili et Karl Métivier
ATMTL23 - L'odysée d'un PMO vers un VMO par Elyes Dekhili et Karl MétivierATMTL23 - L'odysée d'un PMO vers un VMO par Elyes Dekhili et Karl Métivier
ATMTL23 - L'odysée d'un PMO vers un VMO par Elyes Dekhili et Karl MétivierAgile Montréal
 
2009 scrum&xp
2009 scrum&xp2009 scrum&xp
2009 scrum&xpdecsdeco
 
Atclt 2012 - Large Scale Scrum - Assurez la polycompétence dans vos équipes -...
Atclt 2012 - Large Scale Scrum - Assurez la polycompétence dans vos équipes -...Atclt 2012 - Large Scale Scrum - Assurez la polycompétence dans vos équipes -...
Atclt 2012 - Large Scale Scrum - Assurez la polycompétence dans vos équipes -...Association pour l'Agilité en Auvergne
 
Après l’#agilité, le #DevOps, la nouvelle arme de la DSI
Après l’#agilité, le #DevOps, la nouvelle arme de la DSIAprès l’#agilité, le #DevOps, la nouvelle arme de la DSI
Après l’#agilité, le #DevOps, la nouvelle arme de la DSISébastien Bourguignon
 
Agilité à l'échelle avec ou sans framework : faire du SAFeLess pour simplifier ?
Agilité à l'échelle avec ou sans framework : faire du SAFeLess pour simplifier ?Agilité à l'échelle avec ou sans framework : faire du SAFeLess pour simplifier ?
Agilité à l'échelle avec ou sans framework : faire du SAFeLess pour simplifier ?DC CONSULTANTS
 
Enrichir Ses Méthodes Avec des Processus Unifiés Agiles
Enrichir Ses Méthodes Avec des Processus Unifiés AgilesEnrichir Ses Méthodes Avec des Processus Unifiés Agiles
Enrichir Ses Méthodes Avec des Processus Unifiés AgilesRomain Couturier
 
Devops : Culture ou Outil ? Pourquoi le mettre en place dans mon Entreprise ?
Devops : Culture ou Outil ? Pourquoi le mettre en place dans mon Entreprise ?Devops : Culture ou Outil ? Pourquoi le mettre en place dans mon Entreprise ?
Devops : Culture ou Outil ? Pourquoi le mettre en place dans mon Entreprise ?DC CONSULTANTS
 
Devops : Culture ou Outil ? Pourquoi le mettre en place dans mon Entreprise ?
Devops : Culture ou Outil ? Pourquoi le mettre en place dans mon Entreprise ?Devops : Culture ou Outil ? Pourquoi le mettre en place dans mon Entreprise ?
Devops : Culture ou Outil ? Pourquoi le mettre en place dans mon Entreprise ?DC CONSULTANTS
 
Agile et Lean : des univers convergents ? par Dimitri Baeli
Agile et Lean : des univers convergents ? par Dimitri BaeliAgile et Lean : des univers convergents ? par Dimitri Baeli
Agile et Lean : des univers convergents ? par Dimitri BaeliInstitut Lean France
 
XebiCon'18 - La guerre des Frameworks n'aura pas lieu
XebiCon'18 - La guerre des Frameworks n'aura pas lieuXebiCon'18 - La guerre des Frameworks n'aura pas lieu
XebiCon'18 - La guerre des Frameworks n'aura pas lieuPublicis Sapient Engineering
 
Aborder la transition vers l'agilité
Aborder la transition vers l'agilitéAborder la transition vers l'agilité
Aborder la transition vers l'agilitéChristophe Addinquy
 

Similaire à Meetup daikibo 1 (20)

Webinar TDD / BDD : Comment mieux délivrer et s'entendre pour le Product Owne...
Webinar TDD / BDD : Comment mieux délivrer et s'entendre pour le Product Owne...Webinar TDD / BDD : Comment mieux délivrer et s'entendre pour le Product Owne...
Webinar TDD / BDD : Comment mieux délivrer et s'entendre pour le Product Owne...
 
La gestion de projet agile
La gestion de projet agileLa gestion de projet agile
La gestion de projet agile
 
20181123 - Agile Tour Rennes - Pourquoi je déteste l'agilité à l'échelle
20181123 - Agile Tour Rennes - Pourquoi je déteste l'agilité à l'échelle20181123 - Agile Tour Rennes - Pourquoi je déteste l'agilité à l'échelle
20181123 - Agile Tour Rennes - Pourquoi je déteste l'agilité à l'échelle
 
Combiner la gestion de projet Agile (AgilePM®) et SCRUM
Combiner la gestion de projet Agile (AgilePM®) et SCRUMCombiner la gestion de projet Agile (AgilePM®) et SCRUM
Combiner la gestion de projet Agile (AgilePM®) et SCRUM
 
Initiation Scrum
Initiation ScrumInitiation Scrum
Initiation Scrum
 
ATMTL23 - L'odysée d'un PMO vers un VMO par Elyes Dekhili et Karl Métivier
ATMTL23 - L'odysée d'un PMO vers un VMO par Elyes Dekhili et Karl MétivierATMTL23 - L'odysée d'un PMO vers un VMO par Elyes Dekhili et Karl Métivier
ATMTL23 - L'odysée d'un PMO vers un VMO par Elyes Dekhili et Karl Métivier
 
2009 scrum&xp
2009 scrum&xp2009 scrum&xp
2009 scrum&xp
 
Atclt 2012 - Large Scale Scrum - Assurez la polycompétence dans vos équipes -...
Atclt 2012 - Large Scale Scrum - Assurez la polycompétence dans vos équipes -...Atclt 2012 - Large Scale Scrum - Assurez la polycompétence dans vos équipes -...
Atclt 2012 - Large Scale Scrum - Assurez la polycompétence dans vos équipes -...
 
EA archi it.pdf
EA archi it.pdfEA archi it.pdf
EA archi it.pdf
 
Après l’#agilité, le #DevOps, la nouvelle arme de la DSI
Après l’#agilité, le #DevOps, la nouvelle arme de la DSIAprès l’#agilité, le #DevOps, la nouvelle arme de la DSI
Après l’#agilité, le #DevOps, la nouvelle arme de la DSI
 
Agilité à l'échelle avec ou sans framework : faire du SAFeLess pour simplifier ?
Agilité à l'échelle avec ou sans framework : faire du SAFeLess pour simplifier ?Agilité à l'échelle avec ou sans framework : faire du SAFeLess pour simplifier ?
Agilité à l'échelle avec ou sans framework : faire du SAFeLess pour simplifier ?
 
Enrichir Ses Méthodes Avec des Processus Unifiés Agiles
Enrichir Ses Méthodes Avec des Processus Unifiés AgilesEnrichir Ses Méthodes Avec des Processus Unifiés Agiles
Enrichir Ses Méthodes Avec des Processus Unifiés Agiles
 
L'Agilité chez GEE Montréal
L'Agilité chez GEE MontréalL'Agilité chez GEE Montréal
L'Agilité chez GEE Montréal
 
Devops : Culture ou Outil ? Pourquoi le mettre en place dans mon Entreprise ?
Devops : Culture ou Outil ? Pourquoi le mettre en place dans mon Entreprise ?Devops : Culture ou Outil ? Pourquoi le mettre en place dans mon Entreprise ?
Devops : Culture ou Outil ? Pourquoi le mettre en place dans mon Entreprise ?
 
Plm lab btb12
Plm lab btb12Plm lab btb12
Plm lab btb12
 
Agile Tour Lille 2008
Agile Tour Lille 2008Agile Tour Lille 2008
Agile Tour Lille 2008
 
Devops : Culture ou Outil ? Pourquoi le mettre en place dans mon Entreprise ?
Devops : Culture ou Outil ? Pourquoi le mettre en place dans mon Entreprise ?Devops : Culture ou Outil ? Pourquoi le mettre en place dans mon Entreprise ?
Devops : Culture ou Outil ? Pourquoi le mettre en place dans mon Entreprise ?
 
Agile et Lean : des univers convergents ? par Dimitri Baeli
Agile et Lean : des univers convergents ? par Dimitri BaeliAgile et Lean : des univers convergents ? par Dimitri Baeli
Agile et Lean : des univers convergents ? par Dimitri Baeli
 
XebiCon'18 - La guerre des Frameworks n'aura pas lieu
XebiCon'18 - La guerre des Frameworks n'aura pas lieuXebiCon'18 - La guerre des Frameworks n'aura pas lieu
XebiCon'18 - La guerre des Frameworks n'aura pas lieu
 
Aborder la transition vers l'agilité
Aborder la transition vers l'agilitéAborder la transition vers l'agilité
Aborder la transition vers l'agilité
 

Plus de Michel Bruchet

Rechercherunproduit pitch-en
Rechercherunproduit pitch-enRechercherunproduit pitch-en
Rechercherunproduit pitch-enMichel Bruchet
 
Rechercherunproduit pitch
Rechercherunproduit pitchRechercherunproduit pitch
Rechercherunproduit pitchMichel Bruchet
 
Microservices architecture v2
Microservices architecture v2Microservices architecture v2
Microservices architecture v2Michel Bruchet
 
Configure an environnement for ASP.NET Core 2
Configure an environnement for ASP.NET Core 2Configure an environnement for ASP.NET Core 2
Configure an environnement for ASP.NET Core 2Michel Bruchet
 
Architecture multi tiers et système de notification
Architecture multi tiers et système de notificationArchitecture multi tiers et système de notification
Architecture multi tiers et système de notificationMichel Bruchet
 
Video3 mise enplacedaikibo
Video3 mise enplacedaikiboVideo3 mise enplacedaikibo
Video3 mise enplacedaikiboMichel Bruchet
 
Aspnetcore introduction
Aspnetcore introductionAspnetcore introduction
Aspnetcore introductionMichel Bruchet
 
Startpoint - Sprint 2 - Objectifs
Startpoint - Sprint 2 - ObjectifsStartpoint - Sprint 2 - Objectifs
Startpoint - Sprint 2 - ObjectifsMichel Bruchet
 
Devops - VSTS - Source
Devops - VSTS - SourceDevops - VSTS - Source
Devops - VSTS - SourceMichel Bruchet
 

Plus de Michel Bruchet (20)

Rechercherunproduit pitch-en
Rechercherunproduit pitch-enRechercherunproduit pitch-en
Rechercherunproduit pitch-en
 
Rechercherunproduit pitch
Rechercherunproduit pitchRechercherunproduit pitch
Rechercherunproduit pitch
 
Proxy pattern
Proxy patternProxy pattern
Proxy pattern
 
Proxy pattern
Proxy patternProxy pattern
Proxy pattern
 
Microservices architecture v2
Microservices architecture v2Microservices architecture v2
Microservices architecture v2
 
Configure an environnement for ASP.NET Core 2
Configure an environnement for ASP.NET Core 2Configure an environnement for ASP.NET Core 2
Configure an environnement for ASP.NET Core 2
 
About netcore2
About netcore2About netcore2
About netcore2
 
ECommerce Logging
ECommerce LoggingECommerce Logging
ECommerce Logging
 
Architecture multi tiers et système de notification
Architecture multi tiers et système de notificationArchitecture multi tiers et système de notification
Architecture multi tiers et système de notification
 
Revue sprint2
Revue sprint2Revue sprint2
Revue sprint2
 
Revue sprint 1
Revue sprint 1Revue sprint 1
Revue sprint 1
 
Video3 mise enplacedaikibo
Video3 mise enplacedaikiboVideo3 mise enplacedaikibo
Video3 mise enplacedaikibo
 
Ingenius Web Services
Ingenius Web ServicesIngenius Web Services
Ingenius Web Services
 
Aspnetcore introduction
Aspnetcore introductionAspnetcore introduction
Aspnetcore introduction
 
Startpoint - Sprint 2 - Objectifs
Startpoint - Sprint 2 - ObjectifsStartpoint - Sprint 2 - Objectifs
Startpoint - Sprint 2 - Objectifs
 
StartPoint - Sprint 1
StartPoint - Sprint 1StartPoint - Sprint 1
StartPoint - Sprint 1
 
Devops - VSTS - Source
Devops - VSTS - SourceDevops - VSTS - Source
Devops - VSTS - Source
 
Devops - Git - VSTS
Devops - Git - VSTSDevops - Git - VSTS
Devops - Git - VSTS
 
VSTS Git
VSTS GitVSTS Git
VSTS Git
 
Devops in english
Devops in englishDevops in english
Devops in english
 

Meetup daikibo 1

  • 1.
  • 2. Connaissez-vous la réponse ? Selon vous, quelle est la meilleure organisation ? 1. Une méthode unique est indépendante entre chaque équipe 2. Une méthode centrale commune à toutes les équipes 3. Une méthode centrale permettant à chaque équipe d’avoir sa propre méthode
  • 4. Qui Suis-je ? https://www.meetup.com/fr-FR/Meetup-Leadership-agile-Luxembourg/ Michel Bruchet • Architecte Entreprise • Ancien créateur et dirigeant d’une Startup • Écrivain de nombreux blogues et livres • Évangéliste Daikibo / Agilité d’Entreprise • Expert ALM Microsoft Mes coordonnées : • Email : michel.bruchet@versusmind.eu • Linkedin : https://www.linkedin.com/in/michelbruchet/
  • 5. Les différents cycles de développement • Rappel historique sur l’évolution de l’informatique
  • 6. Opportunité Cadrage Analyse Programmation Tests unitaires Tests fonctionnels Site pilote Cycle en Cascade Par la structure (Top down) Exploration Architecture Par le besoin (bottom up) Construction Test Cycle semi-itératif Faisabilité Elaboration Construction Transition Cycle full-itératif Évolution des différents cycle de développement
  • 7. Flaccid Scrum Martin Fowler, 2009 - Les organisations souhaitent utiliser un processus agile et prennent Scrum - Ils adaptent les pratiques de SCRUM et voir même ses principes - Après ils se plaignent que leur projet tardent et leur organisation est lente et peu flexible
  • 8. Les limites de kanban • Que se passe-t-il si un développement dure plusieurs jours ? • Que se passe-t-il si on doit revenir dans la phase Analyse une fois le développement commencé ?
  • 9. Les limites de LEAN • Un management désincarné • Une application partielle • Des risques pour la santé des travailleurs • Un prétexte pour licencier • Une mutualisation des fonctions excessive • Un accompagnement indispensable
  • 10. En conséquence • Il n’existe aucune méthode agile capable d’être appliquée tout le temps partout • Le manifeste agile a fait tâche d’huile et les organisations cherchent à l’appliquer à leur organisation toute entière et non seulement le développement
  • 11. caractéristiques d’un projet pour justifier le recours à des méthodes agiles • Orientation majoritairement interne • Budget inférieur à EUR 1 million • Equipe de projet de 5 à 9 personnes • Activités qui se répètent souvent, voire constamment • Budget grossièrement défini et exigences floues en termes de résultats • Durée de 3 à 9 mois
  • 12. DAIKIBO DU MANIFESTE AGILE A L’AGILITE DE L’ENTREPRISE
  • 13. ET SI ON RECOPIER L’AGILE A L’ENTREPRISE • Problème de communication • Problème de planification • Problème d’affectation des nouveaux besoins et peines • Rupture de la chaine L’agilité et la scalabilité ne consiste pas à cloner les petites équipes mais demandent de la bonne gouvernance et de l’ intelligence organisationnelle
  • 14. Pourquoi combiner Agilité et Scalabilité au niveau de l’entreprise ? Promouvoir au niveau de l’entreprise Produits de qualité Marque Employeur et Bien être de travail Cocréation de valeur Prise de Risque Maturité Culturelle Des moyens, outils, processus et méthodes Une bonne gouvernance Une conduite du changement et une meilleur sensibilisation du management
  • 15. Quand adapter l’Agilité et la Scalabilité à l’entreprise ?  10 à 120 Personnes  Plusieurs Projets et équipes de réalisation  Un nombre restreint d’équipe de conception  Un nombre restreint d’équipe de validation
  • 16. DAIKIBO Introduction à la méthode 大規模 Agilité et Scalabilité appliqué à l’Entreprise 16
  • 17. Daikibo • Nom vient du Japonais (大規模) et veut dire « de grande envergure » • Méthode scalable, distribuée, agile et orienté LEAN • Combinaison des frameworks SCRUM, Kanban, XP • Basée sur les principes et les piliers du manifeste Agile et de LEAN Agilité et Scalabilité appliqué à l’Entreprise 17
  • 18. Valeurs de DAIKIBO • Transparence • Inspection • Adaptation Valeurs de SCRUM ■ Achèvement ■ Courage ■ Respect ■ Ouverture Valeurs du Manifeste Agile Valeurs de XP ■ Vérité ■ Simplicité ■ Partage Agilité et Scalabilité appliqué à l’Entreprise 18
  • 19. Alignement business et IT • Partenariat d’égal à égal entre le Business et l’IT • Business et IT doivent aller de pair • Chaque équipe doit avoir autant de poid • Aucun ne doit dominer l’autre • Si le business l’emporte sur l’IT • Déconnection entre la réalité et le souhait, les fonctionnalités et la qualité des livrables seront mis en danger • Si l’IT l’emporte sur le business • Déconnection entre la réalité et le souhait, les fonctionnalités et les livrables ne correspondront plus à ce qui est souhaité Agilité et Scalabilité appliqué à l’Entreprise 19
  • 20. DAIKIBO et Scrum Equipe 2 Product Backlog Sprint Planning Sprint SCRUM Equipe 1 Product Backlog Sprint Planning Sprint SCRUM SCRUM Of SCRUM Sprint Retro, Sprint Planning, Backlog Agilité et Scalabilité appliqué à l’Entreprise 20
  • 21. Différences entre DAIKIBO et SCRUM • Même quotidien • Pas les mêmes équipes • OTT, Delivery, Validation • Les fonctionnalités et cas d’utilisation • Application à la méthode KANBAN ou XP • Nouveaux indicateurs d’estimation • Fonction, Du cas d’utilisation & de la tâche • Estimation doit être avant le planning des sprints Agilité et Scalabilité appliqué à l’Entreprise 21
  • 22. Points communs entre DAIKIBO et SCRUM • Réunion de prévision • Famille de propriétaire de produit • Intégrer dans une famille • Appartenant à l’équipe de production • Même scénarii • Importance des cas d’utilisation • Focus donné aux métriques Agilité et Scalabilité appliqué à l’Entreprise 22
  • 23. Planning type d’un développeur Livraison • Rétrospective jour 15 ou 20 • Démonstration jour 15 ou 20 Développement • Test unitaire Jour 4 et 5 • Résolution et correction Jour 5 à 10 ou 20 • Revue du code jour 6 à 20 Spécification • Sprint Planning Jour 1 • Spécification Technique Jour 1 et 2 • Revue des cas d’utilisation Jour 3 Jour 1 à Jour 3 Jour 4 à Jour 15/20 Jour 15 ou 20 Agilité et Scalabilité appliqué à l’Entreprise 23
  • 24. Structures d’équipes Agilité et Scalabilité appliqué à l’Entreprise 24 Approche SCRUM / Agile Le Propriétaire du produit Le maître des mêlées Les développeurs Transformation DAIKIBO L’équipe conception (OTT) Le Propriétaire du produit L’auteur des cas d’utilisation L’équipe Livraison (Delivery) Le Propriétaire Proxy Le maître des mêlées Les développeurs Les qualiticiens L’équipe Validation Le Propriétaire Proxy Les qualiticiens Développeurs d’automates de test
  • 25. Dimensions des équipes • Taille d’équipe idéale entre 7 et 11 personnes • Limites maximale 15 personnes • Limites minimales 5 personnes • Ajustement et scalabilité entre 5 et 11 personnes Agilité et Scalabilité appliqué à l’Entreprise 25 5 11
  • 26. Comparaison entre le cycle en cascade et DAIKIBO • Cycle en cascade Agilité et Scalabilité appliqué à l’Entreprise 26 Spécification des besoins Conception / Modélisation Implémentation Test et Validation ■ DAIKIBO Spécification Conception Implémentation Validation
  • 27. Focus sur La Direction Informatique DSI, Direction Informatique, Recherche et Développement Agilité et Scalabilité appliqué à l’Entreprise 27
  • 28. Quelques principes ou règles d’or • Une équipe doit être constituée pour • Plus d’une release • Idéalement pour 1 an voir plus • Travailler sur des projets séquentiels • Une équipe doit avoir une démarche incrémentale • En 5 Sprint • 4 Ajout de fonctionnalités • 1 Innovation / Amélioration / Préparatoire • Une Equipe doit avoir des problèmes à résoudre • Chaque membre d’une équipe doit être solidaire et coresponsable Agilité et Scalabilité appliqué à l’Entreprise 28 Attention une équipe est sacrée, on ne partage pas les personnes dans plusieurs équipes
  • 29. Equipe Support / Equipe Fonctionnelle • Il existe 2 niveau Equipe / Groupe • Il existe 2 types d’équipe au sein de la production Agilité et Scalabilité appliqué à l’Entreprise 29 Equipe Support : Ce qui supporte l’équipe fonctionnelle L’équipe support peut être partagé mais l’équipe fonctionnelle est toujours la même Equipe fonctionnelle : Ce qui font le travail
  • 30. Equipe support • IT, Poste de travail • Architecture d’entreprise • Faisabilité (POC) • Design applicatif • Dev ops • Framework • UX / UI • Performance / Testing Agilité et Scalabilité appliqué à l’Entreprise 30
  • 31. IT / Poste de travail • Assurer le bon fonctionnement des postes de travail • Fournir des solutions de partages de documents • Fournir des solutions de discussion et d’échange de groupe (Messagerie, Partage documentaire, Sharepoint) • Assurer la sécurité du réseau • Fournir les services réseaux et infrastructures adéquates Agilité et Scalabilité appliqué à l’Entreprise 31
  • 32. Architecture Entreprise • Recommandations et design de très haut niveau • Travail avec les équipes business sur les plans de route • Identifie et approuve les outils et composants à utiliser • Référence technique et guide sur les sujets complexes Agilité et Scalabilité appliqué à l’Entreprise 32
  • 33. Etude de Faisabilité (POC) • Créer des projets d’étude de faisabilités (POC) • Teste et améliore les solutions techniques apportées • Valide les nouvelles solutions et composants Agilité et Scalabilité appliqué à l’Entreprise 33
  • 34. Design applicatif • Examine les demandes métiers • Définit comment y répondre • Aligne le technique et le business sur la même longueur • Travaille donc avec le business Agilité et Scalabilité appliqué à l’Entreprise 34
  • 35. Dev ops • Automatise les builds, les tests unitaires • Environnements • Développement • Test • Qualification • Production Critique à la réussite du projet Agilité et Scalabilité appliqué à l’Entreprise 35
  • 36. Framework • Créer des boîtes à outils • Créer des structures applicatives et des templates • Faciliter la réutilisabilité Agilité et Scalabilité appliqué à l’Entreprise 36
  • 37. UX / UI • Reprendre le travail de l’équipe architecture • Le rendre joli et agréable à utiliser • Créer les lignes graphiques (wireframes) des applications métiers • S’assurer que l’interface utilisateur soit • Fonctionnel • Utilisable • Confortable et adaptable Agilité et Scalabilité appliqué à l’Entreprise 37
  • 38. Test de performance • Valide le bon fonctionnement des applications • Valide le temps de réponse • Valide toutes les couches des services et applications • Base de données, moteur de recherche, service REST • Assure le respect des SLA • Reporte aux développeurs Agilité et Scalabilité appliqué à l’Entreprise 38
  • 39. Support applicatif • S’assure que tout fonctionne correctement en production • Assiste les utilisateurs finaux • Intervient à différents niveaux • L1 directement aux près des utilisateurs • L2 analyse et support des personnes L1 • L3 Expert techniques, diagnostique et supporte les L2 • Tient des bases de connaissances de problèmes et les partage avec les différentes équipes • Escalade les problèmes complexes Agilité et Scalabilité appliqué à l’Entreprise 39
  • 40. L’équipe fonctionnelle • 3 Groupes • OTT, Delivery Team et Validation Agilité et Scalabilité appliqué à l’Entreprise 40 Produit 1 Produit 2 OTT Réalisation 1 Réalisation 2 Validation
  • 41. Le groupe OTT • Propriétaires du produit • Les analystes métiers (Business analyst ou SMES) • Les analystes fonctionnelles En livraison • Définie les épics et fonctions • Livre les cas d’utilisations ou histoires • Crée et maintient en vie le backlog • Prévoit et collabore à l’amélioration de l’expérience utilisateur Agilité et Scalabilité appliqué à l’Entreprise 41
  • 42. Les groupes Réalisation • Réalisent les services et outils demandés • Utilisent SCRUM • Divisent les histoires et cas d’utilisation en Tâches et estime le temps nécessaire • Ecrivent et valident les tests unitaires • Une collaboration nette doit exister avec le propriétaire du produit (proxy) pour clarifier les histoires • Effectuent les démo, explorent et cherchent à comprendre les fonctions non achevées à la fin de leur sprint Agilité et Scalabilité appliqué à l’Entreprise 42 Le maître des mêlées Les développeursLe Propriétaire du produit Proxy Les testeurs
  • 43. Le groupe Validation • Il est composé par • Qualiticiens • Intégrateurs : • Créé le story d’intégration ou le bon de livraison • Travaille avec les développeurs pour résoudre les problèmes d’intégration • Ecrit et exécute les tests d’intégration automatique • Effectue les tests de non régression Agilité et Scalabilité appliqué à l’Entreprise 43
  • 44. Les Interactions entre les groupes et les équipes Agilité et Scalabilité appliqué à l’Entreprise 44 Architecture UI/UX POC/Implémentation Performance testing Livraison Entrants Histoire utilisateurs Histoire utilisateurs Histoire utilisateurs Cas d’utilisation, conditions d’acceptances Code, Configuration Sortants Design pattern, Solution Design et Framework Maquette (Wireframes) Décision / Applicatifs Scripts de tests automatique, qa automatique fonctionnelle IC, LC, Envs Contact en entrée Business Equipe Architecture / OTT Architecture / UI Equipe développement Equipe Développement / Performance Contact en Sortie POC / UI POC Livraison Livraison Support
  • 45.
  • 46. Point sur le meetup Se réunir est un début, rester ensemble est un progrès, travailler ensemble est la réussite. https://www.meetup.com/fr-FR/Meetup-Leadership-agile- Luxembourg/

Notes de l'éditeur

  1. 1 – Un management désincarné Dans son le livre « Le Management désincarné » (Édition La Découverte), Anne-Marie Dujarier dénonce le management par les chiffres élaboré par des planeurs, des « faiseurs et diffuseurs de dispositifs » qui « planent ». Ils opèrent loin du terrain. « Dans le conseil, ce sont des diplômés de grandes écoles qui n’ont jamais mis les pieds en entreprise et passent leur temps à manipuler les algorithmes. L’inexpérience des réalités matérielles, sociales et existentielles du travail devient alors une compétence pour ce genre de postes. » 2 – Une application partielle La généralisation de la méthode Toyota peut conduire à un détournement de ses principes de base, souvent pour des raisons culturelles, selon Philippe Lorino, docteur en sciences de gestion et professeur à l’ESSEC. Par exemple la chasse aux gaspillages, souvent présenté comme un objectif, n’est en fait qu’une étape qui vient après deux autres : créer un système de production efficace, et créer des buffers pour éviter les événements indésirables. Il est ainsi conseillé de limiter à 80 % le taux d’utilisation des outils de production pour pouvoir absorber les aléas. 3 – Des risques pour la santé des travailleurs Travail plus intense, sur-sollicitation physique pour éliminer les temps d’attente, pression pour gérer les aléas génératrice de stress, manque de latitude pour les décisions personnelles, moindre solidarité…, autant d’éléments générés par le lean management qui seraient source de troubles psychosociaux et musculo-squelettiques, selon l’INRS. L’Institut national de recherche et de sécurité dénonce même l’apparition de nouveaux risques dus au rapprochement physique des outils de production des travailleurs pour en limiter les déplacements. L’INRS souligne toutefois que « dans le cas où une entreprise est consciente de ces points de vigilance et qu’elle adopte une vision globale de la performance sur le long terme, la mise en place d’une démarche de lean ou de certains de ses outils peut devenir une opportunité pour aborder et améliorer les aspects de santé et de sécurité au travail ». 4 – Un prétexte pour licencier Pour certains, le lean management n’est utilisé que pour identifier les postes en trop et débusquer les personnels inutiles. D’où le recours à des consultants extérieurs pour mettre en place la méthode. Utiliser le lean management pour réduire son personnel salarié serait pourtant une erreur :  il s’ensuivrait une perte de confiance et une démotivation des salariés. Conclusion : il vaut mieux utiliser le lean management « en temps de paix”. 5 –Une mutualisation des fonctions excessive Appliqué aux services, le lean management peut conduire à mutualiser les fonctions supports dans les grandes entreprises. Avec le risque de nuire à la relation client, notamment dans les entreprises qui décentralisent ces fonctions pour être au plus près du terrain. 6 – Un accompagnement indispensable Dans certaines entreprises, le lean management peut apparaître comme une véritable révolution. Sa mise en œuvre, sans préparation, sensibilisation ou formation des salariés, peut conduire à des blocages difficiles à surmonter. L’accompagnement du changement va constituer un facteur clé de succès.
  2. 1 – Un management désincarné Dans son le livre « Le Management désincarné » (Édition La Découverte), Anne-Marie Dujarier dénonce le management par les chiffres élaboré par des planeurs, des « faiseurs et diffuseurs de dispositifs » qui « planent ». Ils opèrent loin du terrain. « Dans le conseil, ce sont des diplômés de grandes écoles qui n’ont jamais mis les pieds en entreprise et passent leur temps à manipuler les algorithmes. L’inexpérience des réalités matérielles, sociales et existentielles du travail devient alors une compétence pour ce genre de postes. » 2 – Une application partielle La généralisation de la méthode Toyota peut conduire à un détournement de ses principes de base, souvent pour des raisons culturelles, selon Philippe Lorino, docteur en sciences de gestion et professeur à l’ESSEC. Par exemple la chasse aux gaspillages, souvent présenté comme un objectif, n’est en fait qu’une étape qui vient après deux autres : créer un système de production efficace, et créer des buffers pour éviter les événements indésirables. Il est ainsi conseillé de limiter à 80 % le taux d’utilisation des outils de production pour pouvoir absorber les aléas. 3 – Des risques pour la santé des travailleurs Travail plus intense, sur-sollicitation physique pour éliminer les temps d’attente, pression pour gérer les aléas génératrice de stress, manque de latitude pour les décisions personnelles, moindre solidarité…, autant d’éléments générés par le lean management qui seraient source de troubles psychosociaux et musculo-squelettiques, selon l’INRS. L’Institut national de recherche et de sécurité dénonce même l’apparition de nouveaux risques dus au rapprochement physique des outils de production des travailleurs pour en limiter les déplacements. L’INRS souligne toutefois que « dans le cas où une entreprise est consciente de ces points de vigilance et qu’elle adopte une vision globale de la performance sur le long terme, la mise en place d’une démarche de lean ou de certains de ses outils peut devenir une opportunité pour aborder et améliorer les aspects de santé et de sécurité au travail ». 4 – Un prétexte pour licencier Pour certains, le lean management n’est utilisé que pour identifier les postes en trop et débusquer les personnels inutiles. D’où le recours à des consultants extérieurs pour mettre en place la méthode. Utiliser le lean management pour réduire son personnel salarié serait pourtant une erreur :  il s’ensuivrait une perte de confiance et une démotivation des salariés. Conclusion : il vaut mieux utiliser le lean management « en temps de paix”. 5 –Une mutualisation des fonctions excessive Appliqué aux services, le lean management peut conduire à mutualiser les fonctions supports dans les grandes entreprises. Avec le risque de nuire à la relation client, notamment dans les entreprises qui décentralisent ces fonctions pour être au plus près du terrain. 6 – Un accompagnement indispensable Dans certaines entreprises, le lean management peut apparaître comme une véritable révolution. Sa mise en œuvre, sans préparation, sensibilisation ou formation des salariés, peut conduire à des blocages difficiles à surmonter. L’accompagnement du changement va constituer un facteur clé de succès.
  3. Et alors beaucoup se demanderont, pourquoi changer cela vue que cela a fait ses preuves ? Les risque de diviser des équipes en petites équipes et de reproduire les méthodes Agiles inadaptées à ce contexte, sont multiples et je les ai déjà rencontrées beaucoup d’entre-elles chez beaucoup de grandes sociétés française du CAC 40 ou chez des Fortunes 500 internationaux. Commençant donc par les énumérer et voyant ensuite comme se prémunir. Un problème de communication entre les équipes. Effective comme le caractère sacré de l’équipe est mis en avant par le manifeste agile, la communication interne à une équipe est plus que nécessaire, hors la communication entre les équipes est très problématique avec la plus part des méthodes car celle-ci n’est pas abordé par la plus part des méthodes agiles. Un problème de coordination et de planification (A quel projet donné de la priorité). Lorsque vous avez plusieurs équipes et projets en même temps vous pouvez facilement être confronté à des questions de prioritisassions et de coordination. Certaines méthodes agiles prévoient déjà des notions de planification, par exemple SCRUM met en place un sprint planning et un diagramme de suivi d’avancement, donc un projet menée par cette méthode vous permet rapidement et facilement d’avoir des remontées de bonne gouvernance, mais d’autres méthodes qui suivent la reproduction de tâches uniques voir de lots de tâches limités à un nombre de répétition très important comme Kanban, n’ont aucune notion de planning, alors à part à avoir un gymnaste comme chef de projet ou maître de mêlée, comment avoir un planning globale capable de suivre en même temps ces 2 équipes ? Ce problème de planning centralisée, est souvent accompagnée par un problème d’affectation des nouveaux besoins arrivants et hautement prioritaire, Pour qu’en se comprenne bien, permettez-moi de vous poser une question, si vous êtes manager de plusieurs projets et que toutes vos équipes ont du travail en cours, à qui donner la conception et la réalisation d’un nouvel outil capable de vous faire gagner 20 à 30% de votre Chiffre d’affaires en plus ? Vous voyez ce n’est pas chose aisée ? Autre problème de coordination, qui n’est pas à négliger, est le risque de surcharge donc que faire si un problème survient alors que l’équipe est déjà occupée ? La rupture de chaine, est souvent un ressentiment exprimé par la plus part des personnes qui travaillent dans équipes mixtes, en effet les managers qui ont différentes équipes à gérer, cherchent à appliquer une bonne méthode à l’ensemble et demande l’implication de toute leur équipe, cependant lorsque vous êtes des chercheurs ou des ingénieurs supports, vous ne pouvez pas partager le même mécanisme que les ingénieurs productions. Pour finir avec les limites de l’agilité appliquée à l’entreprise, je vais vous donner un petit conseil : L’agilité et la scalabilité au niveau des équipes mixtes ou de l’entreprise ne peut s’obtenir par le clonage, nous sommes des êtres humains donc tous uniques. Deuxième conseil, si vous entendez qu’une bonne méthode agile est une méthode sans gouvernance, et sans intelligence organisationnelle, c’est vrai au niveau projet, mais pas au niveau organisationnelle, et nous verrons que nous pouvons combiner agilité, scalabilité, bonne gouvernance, et intelligence organisationnelle.
  4. Comme toute méthode Agile, l’agilité et la scalabilité au niveau de l’entreprise est de promouvoir au niveau de l’entreprise la réalisation de produits de très haute qualité par des équipes mixtes De faire très attention à la marque employeur et d’assurer un bien être au travail : motivation, plaisir au travail, nouvelles valeurs… D’assurer et garantir La cocréation de valeur : la collaboration entre les services, avec un alignement continu avec le business… De permettre La prise de risque : sortir de sa zone de confort, innover… De garantir La maturité culturelle de votre entreprise et des individus : confiance, respect, écoute, compétence, droit à l’erreur… D’utiliser Des moyens, outils, processus et méthodes De fournir d’Une bonne gouvernance D’Assurer Une conduite du changement et une évolution du management Permettez-moi de partager avec vous, Un autre conseil important, Je vois dans beaucoup d’entreprises, des apprentis sorciers, chercher à mettre en place une méthode en cherchant à explorer, à faire des tests et des ajustements, mais comme toute méthode, L’agilité et la scalabilité appliquée à l’entreprise n’est et ne doit pas être une méthode applicable sans l’intervention d’un coach expert capable de vous apporter réellement toutes les valeurs ajoutées souhaitées. Car c’est seulement en respectant toute la démarche que vous pourrez espérer en tirer profit.
  5. Bien entendu et comme toute méthode, cette méthode n’est pas applicable à tous les projets et demande à respecter un certains nombre de règles et de bons usages. Nous verrons dans cette vidéo, comment mettre en place cette méthode, les meilleurs recommandations. Mais voyant maintenant les conditions d’application Tout d’abord, bien qu’elle a été conçue initialement au début des années 2010 par la société Cognizant pour des grands industriels de la pharmacie et des banques et qu’elle a été reprise et améliorer par des startup dans les années 2015 et 2016. Cette méthode s’applique selon moi pour des équipes allant de 10 à 120 Personnes avec deux centres de développement au maximum Pour le reste, je partage complétement avec Cognizant les limites qu’eux-mêmes exposent à savoir Vous devez avoir obligatoirement plusieurs projets et équipes de réalisation en même temps Un nombre limité d’équipe de validation ou d’exploitation Un nombre limité d’équipe de conception et de conduite Avoir déjà des équipes familiarisées avec les méthodes agiles
  6. Bienvenue dans un monde où tout change, au faite ca y est la vidéo que vous êtes entrain de regarder, est déjà obsolète. Non Sérieusement, ce monde qui nous entoure change à une vitesse grande V et tous les managers du monde entier, nous parle de vouloir adapter Agilité et Scalabilité à l’entreprise, mais est-ce possible ? Si vous regardez cette vidéo, c’est que vous savez qu’il existe des méthodes capable de vous donner des guides d’applications, je pourrais lister ScrumofScrum, qui par exemple consiste à faire faire du Scrum et d’avoir comme artefact des petits scrum. Ou encore SAFE qui assure le bon processus du développement continue, Mais je vais vous parler ici d’une autre méthode, pour une fois, d’une méthode qui vient des Etats-Unis, d’une méthode capable de vous assurer la scalabilité, la distribution et l’agilité au sein de votre Entreprise. Daikibo a été inventé en 2009 et avait été appliquée à l’époque par Cognizant à un très grand industrielle du domaine pharmaceutique, à des banques, et à des industrielles de tout domaine. En 2013, la 2éme version de DAIKIBO a été plus poussée par Cognizant et a été retenue et choisie par les 4 Plus grands cabinets d’audit aux USA, de là nous avons vue des groupes de travail voir le jour et de nombreuses amélioration ont été apportées à la méthode notamment La notion de groupe et non plus que d’équipe La structure optimale d’une équipe ou d’une organisation La notion de bonnes recommandations La notion de processus de mise en place La notion du modèle de maturité et son évaluation En 2015, la 3éme version est plus que plébiscité et la plus part des grandes sociétés américaines de fortune 500 l’ont adoptée et même des startup ont planifiées leur conversion vers cette méthode Nous pouvons citer comme apport, le SOSE (Scrum of Scrum) et des métriques de bonne gouvernance. De plus la méthode en Version définie les tailles idéales et maximale pour chaque équipe et les modèles de contraintes
  7. Les valeurs de DAIKIBO sont multiples et tirées des différentes et Framework qu’elle intègre Grâce à la méthode SCRUM La méthode met en avant sur la transparence et le même langage entre les équipes et les managers L’inspection tout doit être contrôlable et vérifiable. Les metrics et les artefacts de SCRUM sont grandement repris par DAIKIBO pour permettre ce suivi L’adaptation. DAIKIBO ne remets en cause aucun des Frameworks qu’elle combine mais elle donne un guide de bonne intégration et de bonne communication Grâce au Manifeste Agile
  8. DAIKIBO fait une place importante à l’alignement des services surtout entre le business qui connait ses besoins et son marché et le service informatique qui est le garant d’une bonne qualité et du respect des délais. DAIKIBO cherche à promouvoir un partenariat d’égal à égal En mettant en avant la bonne collaboration entre les différentes équipes en définissant des règles naturelles mais essentielles et en exposant certains danger lorsqu’un service l’emporte sur l’autre Premières régles exposés par DAIKIBO Les équipes business et IT doivent aller de pair Chaque service doit avoir autant de poids (importance, décision et personnes) Aucun service ne doit chercher à l’emporter sur l’autre et doit même être solidaire Dans le cas contraire, Cognizant met en avant quelque danger, parmi ceux-là nous pouvons citer Lorsque le business l’emporte sur l’IT Des demandes trop orientés marchés, sans cadence et sans gestion de la qualité et de délais souvent importés par les bonnes gouvernance de l’IT, risque fort de baisser la qualité des produits et de déséquilibrer les délais de livraison Mais Lorsque l’IT l’emporte sur le business Là aussi DAIKIBO, met en danger les différents décideurs qui seraient tenter de faire l’inverse de limiter les business en les imposants des contraintes de l’IT et en mettant plus en avant l’IT, à un risque réel et sérieux de dérapage avec une déconnexion réelle et sérieuse entre les besoins métiers et les fonctionnalités livrées Permettez-moi de vous poser une question Pensez-vous que vous pouvez travailler efficacement dans un sous marin à moins de 300 mètres sous l’eau (en immersion totale) avec les nombreux allers/retours de l’équipage, et la pression atmosphérique ? C’est la même chose dans votre entreprise, et c’est la grande valeur ajoutée de DAIKIBO Je le répète encore, mais tous les services doit être alignés et aucun service ne doit l’emporter sur les autres, sinon on risque de baisser la qualité du produit et de ne plus respecter les délais de livraison
  9. Au niveau des équipes de production, DAIKIBO repose sur SCRUM donc vous gagnez à ne pas reformer votre équipe à SCRUM
  10. Essayant de comparer les méthodes DAIKIBO et SCRUM Au quotidien les équipes de développement ne voient pas de changement à leur activité, en effet SCRUM reste appliqué et applicable Par contre, Là où DAIKIBO change par rapport à SCRUM c’est qu’il fait la différences entre les groupes et les développement. En effet il distingue les équipes de conception (OTT), de réalisation (Delivery) et de qualification (Validation) Grande autre différence entre DAIKIBO et SCRUM est le processus de création et de spécification des cas d’utilisation, en effet DAIKIBO héritent plus tôt de KANBAN ou XP, nous y viendrons plus tard L’héritage de Kanban ou XP pour les cas d’utilisations permettent à DAIKIBO de proposer trois nouveaux indicateurs d’estimation. En effet là où SCRUM s'arrête à estimer la complexité au niveau de la tâche, DAIKIBO, essaye d’apporter de l’estimation à tous les niveaux, ainsi on essayer d’estimation le temps nécessaire à l’implémentation d’une fonction, d’un cas d’utilisation et de la tâche Les estimations des tâches, des cas d’utilisation et des fonctions avec DAIKIBO doivent être fait avant le planning des sprints
  11. OK, nous avons vu quelque différences entre DAIKIBO et SCRUM, mais y a-t-il des points communs ? Et oui vous en doutez, il y a beaucoup de points communs et pas seulement le SCRUM of Scrum. Nous avons par exemple les réunions de prévision qui ont lieu en début de sprint pour prévoir ce qu’il aura à faire durant le sprint Daikibo a repris à SCRUM le rôle de Propriétaire de produit mais là mis dans une notion de famille qui a la même fonction. L’autre emprunt à SCRUM et aux méthodes agiles est l’importance accordé aux cas d’utilisations ou en anglais User Story Encore un autre emprunt est l’importance des métriques fournis par SCRUM, mais DAIKIBO est encore un peu plus structuré
  12. Du point de vue d’un développeur, son planning reste basé sur le sprint et son quotidien se résume sur 15 à 20 jours En règle générale comme avec SCRUM, le développeur divise son travail sur 3 phases La phase de conception et de validation des cas d’utilisation qui se déroule les 3 premiers jours Le premier jour avec le sprint planning
  13. Là où les méthodes agiles et notamment SCRUM s’arrêtaient à une seule équipe, DAIKIBO s’applique à l’ensemble des servcies et notamment la séparation d’une équipe interdisciplinaire en 3 sous équipes L’équipe Conception ou OTT composé de la famille des propriétaires de produit et des auteurs des cas d’utilisation, L’équipe développement / Livraison (Delivery) L’équipe Validation L’important et on voit bien comment les interactions vont pouvoir s’opérer et la présence dans chaque d’un propriétaire proxy qui aura pour rôle de représenter au quotidien le propriétaire et d’assurer la bonne coordination et synchronisation entre les différentes équipes.
  14. Comme nous l’avons dit DAIKIBO donne des bonnes recommandations et des guides. En effet rien ne sert de modéliser une organisation s’il n’y a pas de recommandations, de ce postulat, DAIKIBO s’est constitué d’un ensemble de recommandations et dont notamment la taille des équipes Pour cela DAIKIBO ne donne pas de contraintes obligatoires mais des recommandations Les équipes en idéale ne doit dépassé les 11 personnes avec une limite maximale de 15 personnes Au minimum idéalement les équipes doivent être de 7 personnes mais un minimum de 5 est tolérable Nous vous recommandons donc de bien ajuster en fonction du contexte et des besoins, votre équipe entre 5 et 11 personnes L’ajustement doit se faire dans le temps grâce aux feedbacks. Vous devez explorer, tester, et ajuster, il n’y a pas de règles en la matière
  15. Comme son nom l'indique, l'approche en cascade suit la logique d'une chute d'eau. Une fois que l'eau a dévalé le flanc de la montagne, elle ne peut plus remonter, mais seulement continuer son chemin. Ainsi, dès qu'une étape du projet est terminée, l'équipe passe à l'étape suivante ; il n'y a pas (ou peu) de retour en arrière. L'idée est d'avancer naturellement, étape par étape, jusqu'à atteindre l'objectif final en suivant une direction claire et précise. Vous vous rappelez dans ma vidéo sur les différents de vie, je vous ai dit que la méthode la plus connue qu’on retrouve encore pour le cycle en cascade est la méthode en V ou en spirale Nous avons vue également que le grand avantages de ce cycle en V est la bonne robustesse des livrables Concernant DAIKIBO, cette méthode s’approche plus des méthodes agiles, et en conséquence chaque équipe va entrer dans le jeu certes d’une façon plus planifiée et cadrée mais dès qu’elle le peut. Ainsi nous n’attendrons pas la fin de la conception et de la spécification des besoins pour commencer le développement et surtout on n’attendra pas la fin du développement pour commencer la validation.
  16. La direction informatique au sein d’une entreprise a différent noms peut avoir différents noms, en fait tout dépend de la politique et de son histoire. Nous entendons souvent DSI, Equipe Informatique, Recherche et Développement. Mais elle garde les mêmes caractéristiques Travailler avec les personnes du métier (personne externe à elle) pour réaliser les outils nécessaires à l’activité de l’entreprise. Une direction informatique peut être très complexe et avoir plusieurs équipes. DAIKIBO fournit un formidable outil couvrant toute l’activité de cette direction si importante aux entreprises d’aujourd’hui
  17. Voici un extrait de quelques règles d’or qu’on peut retrouver dans beaucoup de concept agiles, mais applicables également à DAIKIBO Une équipe doit avoir une vrai existence et ne doit en conséquence pas avoir pour objectif avoir une seule livraison mais bien au contraire avoir dans l’idée une existence qui sera persistée pour un an ou plus Une équipe doit avoir un vrai challenge à relever ensemble et résoudre des problèmes ensembles L’intervention doit être séquentiel, c’est-à-dire évolutif dans le temps La démarche d’une équipe doit être incrémentale en rythme de 5 sprints à savoir 4 Ajout de Fonctions 1 Innovation, Amélioration / Préparation et revues du plan de route Point commun avec les autres méthodes agiles, une équipe doit être une équipe et une somme de personnes travaillant sous le même responsable, donc être solidaire et coresponsable Je tiens à faire un point très important, qui vient à l’origine du manifeste Agile mais qui a été repris par DAIKIBO, une équipe ne partage pas ses ressources
  18. DAIKIBO organise les hiérarchies en 2 niveaux, les niveaux équipe et les niveau groupes. Le niveau équipe est le plus haut niveau et très cloisonnée, il n’y pas de possibilité de partager par exemple de personnes entre les équipes Une équipe est souvent décomposée en plusieurs groupes. Ces groupes n’ont d’existence qu’au sein même d’une équipe et a pour rôle d’assurer un service qui doit être rendu par l’équipe En règle générale dans une direction informatique il existe souvent 2 équipes. Nous avons l’équipe support qui a pour rôle de faciliter le travail de l’équipe fonctionnelle et nous avons l’équipe fonctionnelle qui a pour rôle de réaliser les outils et solutions métiers. Un catalogue de services pourrait être mis en place pour permettre d’identifier les groupes supports et d’assurer la fluidité de leur intervention
  19. Justement parlant de l’équipe support, de leur rôle si nécessaire à la réussite de votre travail. Nous pouvons par exemple cités les groupes suivants Poste de travail pour la fourniture de poste de travail fonctionnel Architecture entreprise pour la définition et la cartographie du système d’entreprise La conception et les POC, pour la conception de certains cas complexes Le prototypage pour la réalisation des prototypes Le design applicatif pour le design des applications à réaliser Dev ops pour l’opérationnel, la livraison des chaines de build et de déploiement Framework UX / UI pour l’interfaçage utilisateur Performance pour les tests de performance Support Nous allons voir plus en détail le rôle de chaque groupe
  20. Le groupe IT/ Poste de travail est connu par tout le monde, c’est lui quoi vous accueil le premier jour à votre arrivé et ses missions sont très nombreuses, nous pouvons par exemple cités Assurer le bon fonctionnement du travail Fournir des solutions de partages documentaire nécessaire pour les projets Fournir des solutions de discussions et d’échange de groupe (style Office, Skype, Yammer) Assurer la sécurité réseau Fournir les services infrastructures adéquates
  21. Le Groupe Architecture d’Entreprise Un autre service support aux équipes de développement est le groupe EA ou Architecture Entreprise Il a pour rôle de fournir des recommandations et de fournir des designs de très haut niveau Il doit souvent collaborer avec les équipes business pour définir les plan de route Il identifie, teste et approuve les outils et composants techniques intégrables aux solutions Il agit souvent comme des guides aux développeurs et fournit les recommandations et meilleurs pratiques sur les sujets très complexes
  22. Ce groupe moins connu, mais si nécessaire également, c’est le groupe « Etude de Faisabilité » Ce groupe a pour rôle de créer des projets d’étude de faisabilités, d’améliorer els solutions techniques mises en place et de valider tous les composants intégrables dans le SI de l’entreprise
  23. Ce groupe de concepteur souvent composé par des experts très poussé, il a pour rôle D’Examiner les demandes métiers, de valider avec le groupe prototype leur faisabilité De définir comment y répondre D’aligner la technique et le business toujours sur la même longueur Il travaille très souvent avec l’équipe business car il a besoin de connaitre l’évolution du marché de l’entreprise
  24. Le groupe dev ops, travaille de concert avec les équipes fonctionnelles pour automatiser les chaines de build et de livraisons continues. Ils réalise les outils et les scripts nécessaires Ils fournit les environnements demandées en fonction des besoins Ce groupe doit être constitué de très bon technicien capable de vous garantir le succès de vos projets
  25. Le groupe Framework a pour rôle de travailler sur la création des boites à outils qui seront réutiliser pour créer des solutions métiers, Ils fournit des structures types et des guide d’aide au démarrage Ils facilite la réutilisabilité dans l’entreprise des différents composants déjà créé
  26. L’équipe fonctionnelle est souvent divisée en 3 groupes Le Groupe OTT Le Groupe Delivery / Réalisation Le Groupe Validation
  27. Le Groupe OTT (Original Thought Team) ou en Français métier / Etude Il a pour rôle de concevoir les solutions métiers nécessaires, et il est souvent composé de 3 rôles importants Les propriétaires du produit qui ont pour rôle de coordonnées les projets Les Business SMES et analystes métiers ont pour rôle de spécifier les cas d’utilisations pour un métier donné Les analystes spécialistes des méthodes de conception et pouvant aider les business SMES à analyser un métier Il est le point entrant de votre chaine de votre production et intervient au démarrage En créant les épics et fonctions En rédigeant les cas d’utilisations et histoires En Créant et maintenant en vie le backlog En collaborant avec l’équipe UI à l’amélioration de l’expérience utilisateur Ce groupe utilise souvent une méthode proche de Kanban ou de LEAN
  28. Les groupes de réalisations participent à la réalisation mêmes des outils. Ils travaillent souvent en méthode Agile avec SCRUM Ils réalisent les services et outils demandés Ils utilisent SCRUM comme méthode Ils interviennent sur les histoire pour les diviser en tâches et donnent les estimations du temps nécessaires A la fin de leur développement, ils écrivent et valident les tests unitaires A la fin de leur sprint, ils effectuent au proxy la démonstration de ce qu’ils ont implémentés En cas de défaillance, ils cherchent à comprendre ce qu’il n’a pas été avec le proxy et apportent les amélioration en continue
  29. Le groupe validation, est en charge de la bonne intégration des outils, de leur validation et des tests des solutions métiers développées. Il est composé De Qualiticiens qui teste fonctionnellement les outils et services D’Intégrateurs qui récupéré les outils développées et s’assurent de la bonne livraison. Il créé le bon de livraison, les tests de validation automatique, et s’assurent de leur bonne exécution. Ils travaillent avec le Propriétaire Proxy pour compléter les histoires si nécessaire, et collaborent avec les développeurs pour identifier, suivre et analyser les problèmes d’intégration. Ils sont le garant des bons tests, de l’automatisation des tests d’intégration et d’acceptation et effectuent des tests de non régressions
  30. Aujourd’hui nous sommes 50 membres inscrits sur le groupe et c’est très bien. Dans la salle nous …. Pour aujourd’hui j’étais tout seul à animer, et je voudrais bien que des volontaires puisse présenter leur sujets au tout de l’agilité et du Leadership. Donc si vous avez une idée et que vous souhaitez organiser un point, n’hésitez pas à me contacter je vous mettrez comme animateur et nous pouvons travailler ensemble pour organiser la prochaine séance Pour la prochaine date, j’attend donc des volontaires et nous vous communiquerons ainsi une date et le sujet sur le meetup Si vous avez besoin de conseils, de coaching, de formation, voir d’un audit dans votre entreprise, je suis tout à fait d’accord pour qu’on en parle mais cela sera en dehors du cadre du meetup