5. mbruchet@live.fr
michelbruchett91@gmail.com
Linkedin+ /in/michelbruchet
Limite de l’agilité appliquée
à 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’intélligence organisationnelle
Agilité et Scalabilité appliqué à l’Entreprise 5
6. mbruchet@live.fr
michelbruchett91@gmail.com
Linkedin+ /in/michelbruchet
Pourquoi combinerAgilité 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
Comme toute méthode, l’agilité / scalabilité appliquée à l’Entreprise doit être
conduite par des experts
Agilité et Scalabilité appliqué à l’Entreprise 6
7. mbruchet@live.fr
michelbruchett91@gmail.com
Linkedin+ /in/michelbruchet
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
La famille Agile contient plusieurs méthodes dont notamment Scrum, FDD, RUP, Kanban, Lean,
Scrum-ban, XP, sAFE, DSDM, AM
Agilité et Scalabilité appliqué à l’Entreprise 7
9. mbruchet@live.fr
michelbruchett91@gmail.com
Linkedin+ /in/michelbruchet
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 9
11. mbruchet@live.fr
michelbruchett91@gmail.com
Linkedin+ /in/michelbruchet
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 11
13. mbruchet@live.fr
michelbruchett91@gmail.com
Linkedin+ /in/michelbruchet
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 13
14. mbruchet@live.fr
michelbruchett91@gmail.com
Linkedin+ /in/michelbruchet
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 14
15. mbruchet@live.fr
michelbruchett91@gmail.com
Linkedin+ /in/michelbruchet
Planning type d’un développeur
Livraison
• Rétrospective jour 15
ou 20
• Démonstration jour 15
ou 20
Développemen
t
• 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écificationTechnique
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 15
16. mbruchet@live.fr
michelbruchett91@gmail.com
Linkedin+ /in/michelbruchet
Structures d’équipes
Agilité et Scalabilité appliqué à l’Entreprise 16
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’équipeValidation
Le
Propriétaire
Proxy
Les qualiticiens
Développeurs
d’automates de test
20. mbruchet@live.fr
michelbruchett91@gmail.com
Linkedin+ /in/michelbruchet
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 20
Attention une équipe est sacrée, on ne partage pas les personnes dans plusieurs équipes
21. mbruchet@live.fr
michelbruchett91@gmail.com
Linkedin+ /in/michelbruchet
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 21
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
23. mbruchet@live.fr
michelbruchett91@gmail.com
Linkedin+ /in/michelbruchet
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 23
29. mbruchet@live.fr
michelbruchett91@gmail.com
Linkedin+ /in/michelbruchet
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 29
30. mbruchet@live.fr
michelbruchett91@gmail.com
Linkedin+ /in/michelbruchet
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 30
31. mbruchet@live.fr
michelbruchett91@gmail.com
Linkedin+ /in/michelbruchet
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 31
33. mbruchet@live.fr
michelbruchett91@gmail.com
Linkedin+ /in/michelbruchet
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 33
34. mbruchet@live.fr
michelbruchett91@gmail.com
Linkedin+ /in/michelbruchet
Les groupes Réalisation
■ Réalisent les services et outils demandés
■ Utilisent SCRUM
■ Divisent les histoires et cas d’utilisation enTâ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 34
Le maître
des mêlées
Les développeursLe Propriétaire
du produit
Proxy
Les
testeurs
35. mbruchet@live.fr
michelbruchett91@gmail.com
Linkedin+ /in/michelbruchet
Le groupeValidation
■ 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 35
36. mbruchet@live.fr
michelbruchett91@gmail.com
Linkedin+ /in/michelbruchet
Les Interactions entre les groupes
et les équipes
Agilité et Scalabilité appliqué à l’Entreprise 36
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
37. mbruchet@live.fr
michelbruchett91@gmail.com
Linkedin+ /in/michelbruchet
Les autres vidéos
■ Cette vidéo s’inscrit dans une liste de 5 vidéos
Vidéo 1 : Les différents cycles de développement
Vidéo 2 : L’agilité et la scalabilité au niveau de l’entreprise Présentation de DAIKIBO
Vidéo 3 : Mise en place de DAIKIBO
Vidéo 4 : Bonne Gouvernance
Vidéo 5 :VSTS et Usine logiciel
Agilité et Scalabilité appliqué à l’Entreprise 37
Bienvenue sur cette deuxième Vidéo dédiée à l’agilité et à la scalabilité au sein des entreprises. Nous allons aborder dans cette vidéo la méthode DAIKIBO.
Bonjour, je suis Michel Bruchet, architecte transverse et directeur technique de la société ModeAMoi.com. Cette vidéo appartenant à une série de 3 vidéos a pour objectif de présenter comment l’agilité et la scalabilité des processus peut s’appliquer à l’entreprise et non plus uniquement à un projet informatique.
Cette vidéo s’adresse à toute personne intéressée par les méthodes d’organisation de travail capable de faire émerger les bonnes conditions à l’essor de l’autonomie des collaborateurs, à l’augmentation de la qualité des produits réalisés et à l’amélioration de la marque employeur et client.
Bonjour, permettez-moi pour commencer de faire une petite parenthèse sur l’agile.
Agile oui mais voilà, malgré que l’agile a fait ses preuves chez les plus grandes sociétés comme les petites, Les managers du monde entier ont toujours eu tendance à restreindre l’applicabilité du manifest Agile.
On a donc pendant très longtemps mis en avant les méthodes agiles pour les petites projets, pour les projets qui devaient se dérouler localement ou à un seul point, dès que les sociétés devaient appliquer une méthode sur les grands projets plusieurs dizaines ou centaines de personnes, ou que les projets devaient faire intervenir plusieurs centre de développement en avait tendance soit à se tourner naturellement vers d’autres méthodes soit à diviser les équipes en petites équipes et reproduire les méthodes que les petites équipes à coordonner tout cela avec une autre méthode de gestion tant bien que mal.
J’ai vue cette division menée par des experts reconnus du manifeste agile et qui ne jurait que c’est la seule condition pour ne pas faire fausse route.
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 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