Meetup daikibo 1
•Transferir como PPTX, PDF•
0 gostou•163 visualizações
Vidéo du meetup Daikibo
Recomendados
Mais conteúdo relacionado
Semelhante a Meetup daikibo 1
Semelhante a Meetup daikibo 1 (20)
Mais de Michel Bruchet
Mais de Michel Bruchet (20)
Meetup daikibo 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
- 3. Présentation
- 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
- 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/
Notas do Editor
- 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.
- 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.
- 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.
- 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.
- 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
- 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
- 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
- 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
- Au niveau des équipes de production, DAIKIBO repose sur SCRUM donc vous gagnez à ne pas reformer votre équipe à SCRUM
- 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
- 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é
- 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
- 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.
- 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
- 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.
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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éé
- L’équipe fonctionnelle est souvent divisée en 3 groupes Le Groupe OTT Le Groupe Delivery / Réalisation Le Groupe Validation
- 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
- 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
- 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
- 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