Semer la graine agile en entretien et évolution de systèmes
•Download as PPTX, PDF•
0 likes•479 views
Présentation faite par Christian Savard à l'Agile tour 2014 de Québec
Recommended
Recommended
More Related Content
What's hot
What's hot (6)
Similar to Semer la graine agile en entretien et évolution de systèmes
Similar to Semer la graine agile en entretien et évolution de systèmes (20)
More from CGI Québec Formation
More from CGI Québec Formation (20)
Semer la graine agile en entretien et évolution de systèmes
- 1. Semer la graine Agile en entretien et évolution des systèmes
- 2. Introduction
- 3. © Facilité Informatique inc. Vos présentateurs
- 4. © Facilité Informatique inc. Présentation du projet d’entretien
- 5. © Facilité Informatique inc. • 10 ans • SCRUM • Itération de 1 mois • Livraison aux 12 à 18 mois • On remplace des processus et non des systèmes • L’équipe d’entretien prend en charge le logiciel livré en production Le projet de développement
- 6. © Facilité Informatique inc. Le projet de développement Développement Mois 2 Mois 4 Mois 6 Mois 8 Mois 10 Mois 18 Entretien Entretien Entretien Entretien Entretien Entretien Rythme de livraisons
- 7. © Facilité Informatique inc. Le projet de développement Unitaire Fonctionnel Acceptation Affaire Formation Unitaire Fonctionnel Acceptation Développement Entretien Production Préproduction
- 8. © Facilité Informatique inc. Le début du projet d’entretien • 8 ressources externes • Équipe multidisciplinaire • Analyste organique • Analyste fonctionnel • Développeurs/Analystes • Coordonnateur
- 9. © Facilité Informatique inc. Le début du projet d’entretien • Sql Server 2000/2005/2008 • Émulateur UNIX (SUA) • Powerbuilder • Cobol • Access • C# • VB.NET • Clipper (Dbase) • Word (programmation) • Excel (Programmation) • Sql Server Reporting Services • Sql Server Integration services et DTS • Asp classique • VBA • Infomaker • VbScript • Visual Basic 6 • C++ • Crystal Reports Plus de 100 systèmes différents à prendre en charge
- 10. © Facilité Informatique inc. • Équipe d’entretien = nouvelle réalité • Demandes FIFO + Qui cris le plus fort! • Urgences? • Différents types de demandes • Pas de processus établi Le début du projet d’entretien
- 11. © Facilité Informatique inc. L’évolution du processus
- 12. © Facilité Informatique inc. L’évolution du processus
- 13. © Facilité Informatique inc. • Hybride ScrumMaster/Coach • Observateur • Fait grandir l’équipe • Aide l’équipe • Pas à temps plein ScrumMaster / Coach
- 14. © Facilité Informatique inc. Mise en place du processus Un processus évoluant de façon itérative
- 15. © Facilité Informatique inc. • Support à la production : Urgent • Demande de modification de données : Ajustement manuel des données de production • Petites demandes non urgentes <= 3,5 jour • Projets: Grosses demandes non urgentes > 3,5 jour Le processus
- 16. © Facilité Informatique inc. Mode projet versus les demandes
- 17. © Facilité Informatique inc. Faire évoluer le processus Met en lumière les bloquants Ajout d’un système de priorisation Découpage projet/demande Visibilité des demandes de modification de données Visibilité des support en production Capacité adaptative Délégation au client Séparation de l’alimentation et de la réalisation
- 18. © Facilité Informatique inc. Notre PO
- 19. © Facilité Informatique inc. Mêlée quotidienne
- 20. © Facilité Informatique inc. Montée en compétence de l’équipe
- 21. © Facilité Informatique inc. Éducation des utilisateurs
- 22. © Facilité Informatique inc. • Amélioration continue • S’autocritiquer • S’évaluer • Remettre en question le processus • Moments jugés opportuns, base régulière • Mis à l’ordre du jour par le ScrumMaster et le PO Rétro / Ateliers
- 23. © Facilité Informatique inc. Règles de conduite et climat de travail
- 24. © Facilité Informatique inc. Relation internes / externes
- 25. © Facilité Informatique inc. • Comité de priorisation des demandes • Augmentation du nombre de membres • Séparation du mode projet et entretien • Transfert de connaissance Entretien/Développement • Plus d’Agilité! Le prochain coup!
- 26. Des questions?
- 27. © Facilité Informatique inc. Le présentateur mystère
Editor's Notes
- Pourquoi « Semer la graine agile ». L’agilité dans notre projet c’est un peu comme une graine qu’on a semé, qui a germé et lentement grandis… jusqu’à devenir une pouce…. Presqu’une plante Partage de notre expérience Mise en place du projet Le Kanban Support au projet de développement: Rythme de livraison différent Bien fonctionné. Moins bien, le prochain coup ------- Cette présentation se veut le partage de notre expérience dans l’implantation d’une équipe d’entretien en milieu gouvernemental au cœur d’un projet de refonte majeur des systèmes où l’emphase est mise sur le développement. Nous présenterons le processus de mise en place du projet et de son Kanban. Comment celui-ci permet de prendre en charge l’entretien des systèmes actuels et de gérer les problèmes de production mais aussi de supporter les équipes de développement le tout en tenant compte des rythmes de livraison différents. Dans le cadre du projet de développement en mode SCRUM, l’équipe d’entretien est appelée à collaborer aux itérations de développement en prenant en charge le logiciel nouvellement développé, les tâches d’interfaçage et de conversion ainsi que l’implantation de correctifs à même le logiciel en développement. Les réalités des deux équipes étant très différentes, l’équipe d’entretien a dû s’adapter et trouver des méthodes permettant l’arrimage inter-équipe. Nous tenterons également dans la présentation de mettre en lumière ce qui fonctionne bien, ce qui a moins bien fonctionné ainsi que notre vision des étapes à suivre dans l’évolution de l’équipe tenant compte de la réalité gouvernementale. Cette présentation se veut effectivement un retour sur notre expérience mais aussi une présentation de notre vision des idéaux en entretien et évolution de systèmes faisant fi des contraintes du projet actuel.
- Alexandre Dias 13 ans Pb + Web Depuis 2009: Équipe d’entretien Devp puis analyste Je possède plus de 13 années d’expérience en programmation PowerBuilder et Web. Depuis 2009, je me suis joint à une équipe d’entretien (Celle dont nous vous présenterons le projet) d’abord comme développeur et plus récemment comme analyste fonctionnel. Christian Savard 15 ans Devp web Organismes public puis Facilité Coordonnateur équipe d’entretien Coach agile Scrumban Certifié SM Je possède 15 années d’expérience en TI, dont la majeure partie dans le cadre de projets de développement de systèmes et applications WEB. J’ai travaillé pour différents organismes publics, avant de joindre Facilité informatique en 2009. Depuis ce moment, j’ai été impliqué comme coordonnateur d’une équipe d’entretien de Facilité Informatique ayant pris en charge l’ensemble des applications patrimoniales d’une organisation en mode AGILE, en plus d’assurer celle des résultats d’un projet majeur de refonte des systèmes en question. Depuis peu, j’assume le rôle de Coach aidant des équipes de développement à effectuer une transition vers l’agilité et plus particulièrement en ScrumBan. Je suis certifié Scrum Master Richard Gagné On en parlera plus tard Présenter à la fin
- Entretien: Consultants Devp: Internes Équipe interne en pleine conversion BD 8 ressources externes Transfert minimal Organisation: Plusieurs changements RICHARD: C’Koi le projet de développement??? (Après que j’ai parlé des changements dans l’organisation) ----------- En septembre 2009, Facilité informatique a été appelée à prendre en charge l’entretien et l’évolution des systèmes patrimoniaux (Par systèmes patrimoniaux, nous entendons, tous les systèmes actuellement en place dans l’organisme) dans le but de libérer les gens actuellement en place pour le début du nouveau projet de développement. Au moment de prendre la relève des systèmes, les ressources internes étaient en pleine phase de tests suite à une conversion de système de base de données. L’équipe ciblée a donc dû terminer cette phase puis livrer les systèmes en production. L’équipe initiale était composée de 8 ressources, toutes externes, ayant peu d’expérience en milieu gouvernemental. De ce fait, celle-ci n’avait aucune connaissance en tant qu’équipe sur les systèmes qu’elle devait prendre en charge. Évidemment une période de transfert de connaissance minimal fut organisée entre les ressources internes et l’équipe. Au même moment, côté affaire, l’organisme a procéder à plusieurs changements administratifs ont provoqués une perte d’expertise notable chez les clients.
- Au même moment ou l’équipe d’entretien faisait ses premiers pas, le projet de développement prenait lentement forme. Je passerai très rapidement sur celui-ci, mais il est toutefois utile d’en savoir quelques détails pour bien comprendre la suite des choses. Initialement d’une durée de 10 ans celui-ci fut démarré en s’appuyant sur la méthodologie SCRUM. Chaque itération dure 1 mois et les livraisons en production s’effectuent environ aux 12 à 18 mois. En finalité, un nouveau système sera livré. Un des enjeux majeurs est que non seulement un nouveau logiciel est développé, mais aussi tous les autres systèmes sont ajustés afin de bien s’arrimer au nouveau. En effet, l’organisation a décidé de remplacer des processus de travail et non pas des systèmes entiers. En ce sens, à chaque livraison, des morceaux de systèmes sont retirées jusqu’à l’abandon complet des dits systèmes plus tard dans le temps. À chaque livraison de l’équipe de développement, le nouveau logiciel développé devient donc la responsabilité de l’équipe d’entretien. Celle-ci prend donc aussi le relais des anciens systèmes ajustés par l’équipe de développement ou par l’équipe d’entretien elle-même. L’équipe d’entretien ne participant pas de façon active au projet de développement doit toutefois se garder au fait des changements technologique ainsi que de l’avancée du projet afin d’être prêt à prendre en charge celui-ci dès sa livraison en production.
- Illustre la différence de rythme de développement
- Développé au même moment Livré à des rythme différents Mis en place un système de silos structurés Devp son côté, Entr de l’autre Répliquer Certaines technologies plus difficile --------- Le même logiciel doit être entretenu et développé au même moment mais ne sera pas livré à des rythmes identiques. C’est pourquoi nous avons mis en place un système de silo de développement structuré. Comme vous le voyez sur l’image, pendant que l’équipe d’entretien travaille dans le silo d’entretien, l’équipe de développement travaille de son côté dans le silo de développement. La livraison en production de l’équipe de développement étant de 12 à 18 mois, l’équipe d’entretien peut potentiellement livrer plusieurs versions pendant que l’équipe de développement en livre une. Il est donc de la responsabilité de l’équipe d’entretien de continuellement répliquer ses interventions dans le silo de développement. Malheureusement, les diverses technologies ne possèdent pas toutes des mécanismes de fusion avancé permettant de répliquer facilement le code d’un silo à l’autre. Il faut donc que les modifications et ajustements soient très bien documentées afin que celle-ci puissent être répliquées facilement avec qualité.
- Multidisciplinaire Devait occuper diverses fonctions Nombre restreint de ressources Chacun a développé un cercle d’expertise Plus facile a ce moment de laisser a l’expert ------- À ses débuts, l’équipe était composée de ressources ayant des profils complémentaires et multidisciplinaires soit : Analyste organique Analystes fonctionnel Développeurs/Analystes (web, client/serveur) Coordonnateur d’équipe Dans tous les cas, tous et chacun se devait, dans la limite de ses compétences, occuper différentes fonctions à différents moments vu le nombre restreint de ressources dans l’équipe. Tous se sont alors très rapidement développé un cercle d’expertise bien à lui. En effet, vu la charge de travail, il était généralement plus facile de laisser celui s’y connaissant le plus régler toujours les mêmes problèmes.
- Pour illustrer l’ampleur du projet Plus de 100 systèmes Toujours 8 ressources ----------- Rapidement, afin de bien illustrer l’ampleur de projet et ses défis, voici quelques unes des technologies supportées par l’équipe : À noter que nous prenons alors en charge plus de 100 systèmes répartis dans ces différentes technologies.
- Notion nouvelle Pas de structure établie à imposer Avant: L’analyste préféré, maintenant: qui? Chiffrier excel FIFO + Crier Pas de processus établi. Tous de leur mieux mais différences Difficile de prioriser, catégoriser les types de demandes, gérer les urgences Suffisant pour travailler entre temps. -------- La mise en place d’une équipe dédiée à l’entretien des systèmes étant une notion nouvelle, celui-ci n’avait pas de structure établie à imposer à l’équipe. Celle-ci s’est donc auto-organisée afin de répondre le mieux possible à la demande. Le début de projet ayant démarré assez rapidement pour l’équipe, l’organisation de celle-ci fut assez minimale. Un chiffrier Excel fut utilisé afin de suivre les demandes. Les demandes étaient réalisées selon la formule « première arrivée, première prise en charge » et « À celui qui crie le plus ». En effet, auparavant, les utilisateurs étaient en contact avec un analyste responsable d’un système. Lorsque le changement vers l’équipe d’entretien s’est effectué, ceux-ci ont perdu leur lien direct. La mise en place d’une façon de faire s’imposait alors. Cette méthode ne permettait pas de prioriser adéquatement les demandes urgentes ou de bien gérer les différents types de demandes (Support à la production, demandes d’information, correctifs ou projets) mais était toutefois suffisante pour permettre à l’équipe de travailler en attendant la mise en place d’un mécanisme plus complet d’autant plus que le volume de demande était, à ce moment, assez bas. À ce moment, les différentes phases du développement (Évaluation, réalisation, test, etc) ne faisaient pas parti d’un processus établi. Tous faisaient de leur mieux mais nous percevions des différences bien marquées dans l’efficience et le rendement. (bien expliquer qu’en fait, les étapes étaient faites juste pas dans un processus) Usagers call un responsable du système s’ils ont un problème. Maintenant, ils call qui? Il n’y a plus de responsable. On doit mettre un processus un place. Tous doivent connaitre les systèmes.. etc
- 2 ans après: Virage Agile Connaissance Agile très limité: Lecture, tierce personne Premier tableau Kanban But premier: Rendre visible Premier temps: réticence (rétrograde) (Force la standardisation) (Illustre le besoin de priorisation) RICHARD: On peut tu le voir ce tableau là? ------------ Environ deux ans après le démarrage du projet, l’équipe a tenté un virage Agile. À ce moment, les connaissances en Agilité des membres de l’équipe étaient plutôt limitées et provenait de lectures et d’informations obtenues de personnes interposées. L’équipe a donc mis en place son premier tableau Kanban. Un des buts premiers de cette implantation était de rendre plus visible le travail de l’équipe afin de pouvoir répondre aux interrogations de la direction. Dans un premier temps, certains membres de l’équipe ont démontré une certaine réticence à cette nouvelle réalité. Certains allant jusqu’à trouver qu’il s’agissait d’une méthode rétrograde (Papier et tableau versus système informatisé). L’implantation a toutefois eu comme effet de forcer la standardisation du processus de travail de tous et a très vite illustré le besoin de priorisation de nos demandes.
- Tableau: Mal adapté, incomplet Besoin de méthodes de contournement Demandes bloquées: Exclues du tableau Coordonnateur: Recevoir demandes, prioriser, lien client ----- RICHARD - Cue: C’est ben le bordel votre affaire… Vous avez fait quoi pour arranger ca?---- -------- Ce tableau était, malgré les efforts pour le mettre en place, mal adapté voir incomplet. Les membres de l’équipe étaient quant à eux mal outillés côté « connaissances Agiles ». La réalité quotidienne forçait donc régulièrement les membres de l’équipe à trouver des solutions de contournement au processus imposé par le tableau afin de mener à bien leurs demandes. Entre autre, lorsqu’une demande se trouvait bloquée, celle-ci était souvent exclue du tableau; aucune particularité de celui-ci ne permettait d’illustrer les bloquants. De plus, à cette étape un membre de l’équipe agissait à titre de coordonnateur. Son rôle était de recevoir les demandes des usagers et d’assigner celle-ci aux personnes afin de passer en réalisation. Il faisait aussi office de lien entre le client et l’équipe et qui devait privilégier certaines demandes à d’autres et de le justifier aux clients. Question d’accorder notre vocabulaire, le coordonnateur « pousse » les tâches aux personnes qui auront à les réaliser.
- Au début: Pas de SM Direction: Mis un Coach à notre disposition Rôle Hybride: Beaucoup observateur Contribué à faire grandir l’équipe Au début: Équipe réticente: SM = Venir dire comment travailler ------- Au cours des premiers balbutiements de l’agilité au sein de l’équipe, aucun rôle de ScrumMaster n’avait été mis en place. Voyant les efforts faits par l’équipe dans la mise en place de ses méthodes « semi »-agiles, la direction a mise à notre disposition les services d’une Coach Agile. Malgré l’incompréhension quaisi générale de l’équipe, celui-ci se fit accorder un rôle hybride de Coach/ScrumMaster. À ce moment, la mise en place du processus était déjà assez avancée et l’équipe quand même assez mature et très autonome, habituée à gérer ses bloquants. L’équipe a donc adapté le rôle afin de le rendre cohérent avec les besoins de celle-ci. En finalité son rôle s’avère beaucoup plus observateur que participatif. En apportant ses commentaires, observations, trucs et recommandations, celui-ci a beaucoup contribué à faire grandir l’équipe et à poursuivre l’amélioration de son processus. Au premier contact, l’équipe était plutôt réticente à l’arriver d’un nouveau joueur « externe » venant « leur dire comment travailler ». Toutefois, celle-ci a rapidement compris que ce n’était pas le cas et que ca présence était facilitante et bénéfique. Celui-ci venait aider l’équipe à prendre ses décisions et à s’organiser et non pas décider pour celle-ci.
- Complètement mis en place par l’équipe Façon itérative Continuellement améliorer Plusieurs essais / erreur Finalement: Illustre les bloquants, urgences et surcharges ---- Le processus d’entretien et d’évolution a complètement été mis en place par l’équipe en tenant compte de la réalité du client et les siennes. Cette mise en place s’est effectuée de façon itérative en tenant compte des commentaires des membres, des clients et de la direction en gardant en tête de continuellement améliorer celui-ci. Plusieurs essais et erreurs ont été fait pour en arriver à un processus mature permettant de facilement illustrer les bloquants, les urgences et les surcharges.
- Plusieurs types de demandes simultanément Tous ont un cycle de vie similaire Différences de grosseur marqué entres les Petites et les grosses demandes --------- L’équipe prend en charge plusieurs types de demandes simultanément dont les principaux types sont : Demandes d’intervention : Toute demande d’amélioration ou de développement non urgentes d’au plus 3,5 jour. Support à la production : Toute demande urgente ou une action immédiate est requise en raison d’un arrêt ou mal fonctionnement en production. Demande de modification de données : Ajustement manuel des données de production dans des cas de mal fonction ou lorsque les opérations ne peuvent pas être réalisé via les systèmes interactifs. Demandes de travail : Toute demande d’amélioration ou de développement dont la durée est de plus de 3,5 jours. À quelques exceptions près, l’ensemble de ces demandes ont un cycle de vie similaire. Outre les demandes urgentes, l’ensemble des demandes sont livrées sous forme de trains de livraison. Ces trains de livraison ont lieu chaque mois ou deux mois et regroupe un maximum de demandes dans le but de minimiser les fermetures de systèmes.
- Cohabitation grosses et petites demandes Essayé pleins de choses Mais on tentait de passer des melons et des pommes sur le même tableau Solution: Grosses demandes: Découpage ou SCRUM. Le tableau ne suit que la vision MACRO Comment gérer la capacité? Temps partiel grosses / petites = Perte de productivité mais plus dispo urgences Solution: Temps plein. Plus risqué pour les urgences Doit adapter la capacité section grosses / petite en fonction du nombre de grosses ouvertes Voit mieux l’impact Nécessite que les membres soient plus polyvalents RICHARD: C’Est bien beau.. On peut le voir lui aussi? -------- Piste : Les grandes demandes gérés style scrum? Mais visible au tableau? Tel que mentionné, en ce qui a trait à l’amélioration et au développement, l’équipe travaille avec deux grands types de demandes. Les petites demande d’intervention (<= 3.5 jours) et les demandes de travail (> 3,5 jours). La réalisation de demandes de grande envergure, vu le nombre de membre restreint de l’équipe, provoquait un grand bouleversement de l’équipe et de sa capacité de prise en charge des demandes. Au début du projet, ces demandes étaient prise en charge au travers des autres avec comme seul barème, le besoin de réalisation de la demande. Une solution à cette problématique était donc requise. Plusieurs tentatives ont étés faites. Dans un premier temps, nous avons tenté une assignation à temps partagé entre les petites demandes et les grosses pour les gens ayant à travailler sur celles-ci. Nous avons alors constaté que de façon générale, une baisse de productivité s’est fait sentir. Le partage de temps entre les différentes demandes, permettait en effet, d’avoir des ressources disponibles pour le support à la production mais, vu les changements continuels de dossier, ainsi qu’une grande perte de temps et de productivité (manque de concentration). Quelques autres essais et erreur s’en sont alors suivis pour finalement en arriver que, malgré tout, un engagement à temps plein sur les demandes de grande envergure fût préférable. Il a donc été nécessaire d’estimer la capacité de l’équipe et de la baise de capacité causé par le retrait d’un membre au profit d’une demande de travail. Nous avons donc décidé d’illustré nos deux réalités sur le même tableau Kanban. De cette façon les impacts d’un des types de demandes sur l’autre devenait alors plus visible. Depuis ce temps, lorsque des membres s’engagent à la réalisation de demandes de grande envergure, visuellement sur le tableau, la capacité réservée aux demandes de travail est alors diminuée. Ce fait nous permet alors de mieux planifier et anticiper les problèmes. Respectant les principes Agiles, il est maintenant plus facile de visualiser l’impact des demandes de grande envergure urgentes sur les supports à la production.
- D’une façon itérative, l’équipe a tenté d’améliorer son tableau. Nous avons donc cherché à : Mettre en lumière les bloquants Ajouter un système de priorisation Améliorer le découpage entre le mode projet et demande Accroitre la visibilité pour les demandes de modification de données Accroitre la visibilité pour les supports en production Rendre la capacité du tableau adaptative en fonction de la répartition projet/demande Permettre la délégation de responsabilité d’une demande au client lorsque requis sans affecter la capacité de l’équipe (sur le tableau) (Insérer ici une image du nouveau tableau) De cette façon tous savent maintenant ce qu’ils ont à faire.
- Alimentation et Réalisation séparé. Représentation du mode projet vs demandes Capacité adaptative (projet/demandes) Priorisation Bloquants Délégation au client Expliquer ce que ca a donné: Organiser le Chaos Plus clair pour nous Plus clair pour la reddition de compte Temps de cycle amélioré Temps bloqué est diminué Délai de prise en charge diminué Création d’attentes réalistes fait plus rapidement Plus d’infos: à la fin ---- RICHARD : Mais vous priorisez comment le travail?-----
- On se trouvait bien original, on réinventais peut-être le ScrumBan? RICHARD: Ckoi ca ScrumBan??? Pis PO?? PO = SCRUM, Kanban = ? Au début: Pas de PO Direction: nommé une personne pour faciliter le suivi Profité de l’occasion pour transformer le rôle en PO (Expérience affaire du PO) Le nouveau PO décharge l’équipe (relation clientèle, priorisation) L’équipe reste autonome: microplanification --------- ceux qui ne sont pas familier avec l’abréviation, nous utiliserons l’abréviation PO pour identifier la personne devant agir comme « propriétaire du produit » (Product owner). Le PO joue en rôle très important au sein des équipes de développement SCRUM. Il ne s’agit toutefois pas d’un rôle défini en mode Kanban. Certains nous parlerons alors de ScrumBan, cadre que l’équipe ne connaissait pas à ce moment. Au démarrage du projet, l’équipe ne possédait pas de PO. L’équipe se rapportait directement au coordonnateur du développement et faisait elle-même l’ensemble de la planification, de la priorisation et de la relation clientèle. Afin de faciliter le suivi de la direction sur l’avancement et la charge de travail de l’équipe, celle-ci a nommé une personne responsable de cette tâche. Profitant de l’occasion, l’équipe en collaboration avec la direction a aidé à transformer son rôle afin de profiter de son expérience affaire et de sa connaissance de la clientèle. En effet, l’équipe a réussi à déterminer un rôle de PO adapté à son mode Kanban (qui était en fait du ScrumBan). Ce nouveau PO a permis de décharger l’équipe d’une multitude de tâche administratives, de relation clientèle et de la priorisation des demandes. De cette façon la productivité de l’équipe s’en est trouvée accrue. Toutefois, même avec le nouveau rôle, l’équipe est demeurée autonome en ce qui a trait à la relation clientèle dans le cadre de ses tâches quotidiennes. Même si la tâche de planification incombe désormais à la PO, l’équipe a conservé son autonomie à faire de la micro planification dans le cadre de ses opérations quotidiennes (ex : support production, demandes urgentes, etc)
- Mêlée quotidienne 15 min 3 questions Animé: SM Présent: Tous Ce qu’on a fait de différent: Nous on a inclus le PO. On lui a donné le droit de parole après le SCRUM. Pourquoi? Notre PO est le lien direct avec la clientèle Utilise l’info pour prioriser Peut mieux gérer les attentes des divers clients Peut prendre en charge immédiatement certains bloquantes à la place du SM Ouvre une fenêtre d’opportunité pour effectuer un travail de priorisation -------------- Nous avons aussi fait la mise en place de mêlées quotidiennes sous la même forme qu’elles auraient été mise en place dans un projet en SCRUM. Ces mêlées d’une durée de 15 minutes ayant pour but de partager le travail accompli, à faire et bloquant permettent un partage d’information précieux et contribue à la vélocité de l’équipe. Ces mêlées sont animées par le ScrumMaster et tous y participent y compris le PO. Effectivement, comme l’ensemble des demandes sont quotidiennement repriorisées par le PO, sa présence est souhaitable afin que celui-ci connaisse l’état de la situation et puisse réaliser ses tâches plus adéquatement.
- Autonomie Responsabilisation À Cœur de bon fonctionnement Déblocage des bloquants WIP Gestion du risque Partage d’info Plus seulement un seul PRO Les gens peuvent prendre les taches avec lesquelles sont pas nécessairement habitués. Essayer et voir si ils ont des aptitudes. Servir a l’équipe. Boucher des trous Faire grandir le gens Donc 2 pour 1 Par contre Autonomie (Auto-organisation) ≠ Autogestion Personne ne tente d’intervenir pour prendre en charge des tâches spécifiques SM, PO et reste de l’Équipe: Doit mettre en lumière si l’autonomie nuit au processus (personne prend en charge une demande car non forcé) Cas exceptionnel: Doit imposer: ex lois. L’équipe comprend
- Valeur: Autonomie = Auto-organisation Personne ne tente d’intervenit pour prendre en charge des tâches spécifiques SM, PO et reste de l’Équipe: Doit mettre en lumière si l’autonomie nuit au processus (personne prend en charge une demande car non forcé) Cas exceptionnel: Doit imposer: ex lois. L’équipe comprend ----- Une des valeurs véhiculées par celui-ci est l’autonomie des membres de l’équipe. En ces sens, dans le cadre normal des opérations, ni le ScrumMaster, ni l’équipe, ni le PO ne tente d’intervenir directement auprès des membres de l’équipe afin que ceux-ci prennent en charge des tâches spécifiques. Toutefois, il reste de la responsabilité de ces mêmes intervenants de continuellement mettre en lumière les situations ou cet octroi d’autonomie peut causer préjudice au processus. Par exemple, une certaine demande n’est pas prise en charge par personne alors qu’elle le devrait. En finalité, le PO conserve un droit d’imposer des tâches lorsque des problématiques surviennent. Toutefois, il s’agit de cas exceptionnels et l’équipe comprend le bien fondé de ces interventions.
- Faut compléter ici…. Autonomie Responsabilisation À Cœur de bon fonctionnement Déblocage des bloquants WIP Gestion du risque Partage d’info Plus seulement un seul PRO ------- Autonomie Sur une note plus positive, il a apporté une très grande responsabilisation des membres de l’équipe. Ceux-ci ont à cœur le bon cheminement de leurs demandes ainsi que le bon fonctionnement du processus. De plus, ce même processus, secondé par le tableau, a apporté une visibilité accrue non seulement de l’équipe mais aussi de chaque membre. La mise en lumière des bloquants favorise leur déblocage et évite la perte de temps en favorisant le partage d’information entre les membres de l’équipe. Amélioration du nombre de tâches simultanées (WIP) (Les demandes passent plus vite) Avec l’aide de notre Coach et du tableau mieux adapté, l’équipe a été en mesure de diminuer la quantité de travail débuté simultané mais non terminé. En se concentrant au maximum sur les tâches ouvertes et les bloquants, le temps de cycle des demandes a été grandement amélioré. Respect du processus De plus, tous ont maintenant à cœur le respect du processus et de ses règles. Gestion du risque En tentant d’appliquer au maximum la règle obligeant les membres de l’équipe à respecter les priorités établies par le PO, nous avons favorisé le partage et l’acquisition de connaissances. De cette façon il n’y a plus un seul « pro » ayant à lui seul l’ensemble de la connaissance d’un traitement ou système. Plusieurs personnes et même souvent la majorité des membres ont aussi la connaissance diminuant le risque en cas de surcharge ou absences.
- Besoin d’éduquer les utilisateurs Les demandes de ceux-ci ne doivent pas court-circuiter le processus Pas de demandes sur le bord du paravent Utilisateurs doivent avoir des attentes réalistes vu la nouvelle réalité (Équipe réduite) La mise en place du processus au sein de l’organisation, même si celui-ci ne touche que les utilisateurs de façon indirecte, a nécessité une bonne éducation de ceux-ci. En effet, la capacité réduite de l’équipe ne permettait pas que certaines demandes court-circuitent le processus établi. Les « anciennes » habitudes des utilisateurs (ex : demander un « service » rapide sur le bord d’un paravent), ont dû être éliminées au profit d’un processus couvrant bien tous les types de besoins. De plus, vu les différents demandeurs, les utilisateurs ont dû apprendre à avoir des attentes réalistes en ce qui a trait aux délais de réalisation de leurs demandes considérant les priorités de l’organisation.
- SCUM = Itératif = Rétro Kanban = Pas itératif = Pas de retro? Quoi différent: Décidé d’en faire à des moments jugés opportuns: Livraisons problématiques, etc…. Doit être une base régulière ----- L’agilité en mode Scrum utilise la rétrospective suite aux itérations dans un but d’amélioration continue. Vu l’absence d’itération en KanBan, l’équipe de choisi de procéder à des ateliers (équivalent aux rétro de livraison scrum) à certains moment jugée opportuns (livraisons, problématiques d’équipe, etc) dans le but de forcer les membres de l’équipe à s’auto critiquer et s’évaluer ainsi que de constamment remettre en question le processus. Bien que la majorité du temps, ces Ateliers coïncides avec les livraisons majeure en production, il n’existe pas de moment ou celles-ci sont obligatoires. L’équipe (assisté du ScrumMaster et du PO) se charge de mettre à l’ordre du jour un tel atelier dès que nécessaire en gardant en tête que celle-ci doivent impérativement avoir lieu sur une base régulière. Contrairement au ScrumBan, les rétrospectives n’ont pas lieu selon un cycle fixe.
- Règles formelles et amicales Climat sain Activités d’équipe récurrente (IMPORTANT) Contribue à créer une équipe serrée Si ton chum se plante.. Tu veux l’aider.. Idem Équipe de hockey. Faut que les gens aient le gout de participer a l’équipe Si tu t’implique pas envers l’équipe, l’équipe s’impliquera pas envers toi L’inverse: tendance à rejeter: Couteau à deux tranchants Gros coups à donner: Ca dérange pas car tu sais que les autres vont d’épauler ---------- À travers tout ceci, conservant la même base (auto-organisation), l’équipe s’est dotée de règles autant formelles qu’amicales. Ces règles, acceptées de tous, contribuent à maintenir un climat sain dans l’équipe en retirant toute ambigüité et soudant l’équipe entre elle. Des activités d’équipe récurrentes ont apporté à l’équipe un sentiment « de famille » permettant de décharger la pression et de partager ses frustrations. Ces petites activités anodines contribuent au bon fonctionnement de l’équipe et sont primordiales qu’elles soient réalisées en milieu de travail ou non.
- Membres externes égalité interne / externe ------------- L’équipe est composée exclusivement de ressources externes à l’organisation. Nous avons eu la chance d’avoir une direction qui considérait les ressources externe au même titre que les ressources internes (autant que possible). Tous étaient donc considérés sur un même pied d’égalité ce qui a grandement facilité la mise en place et l’évolution de l’équipe. Ce fut un facteur déterminant jumelé au fait que, dès son arrivée, l’équipe a été reçue positivement comme une équipe complémentaire par les ressources internes.
- Essais et erreurs. Possible de beaucoup d’autres façons SI à refaire: Comité de priorisation + membres Séparation mode projet et entretien Transfert de connaissances Entretien/devp Pousser plus loin l’agilité Impliquer les clients plus tôt dans la mise en place de l’équipe et définition du processus. Plus impliquer le client dans le processus ---------- Comme vous l’avez vu, celui-ci est issu d’une multitude d’essais et erreurs et d’une certaine façon a été réalisé de façon itérative exactement comme l’agilité nous encourage à le faire. Il aurait probablement pu être réalisé de beaucoup d’autres façons. Il ne s’agit évidemment pas de l’unique façon de faire toutefois nous sommes très fiers du résultat. Il est difficile de prévoir quels seront les besoins futurs de l’équipe. Toutefois, si le tout était à refaire, plusieurs changements et améliorations seraient envisagés dont, entre autre la mise en place d’un comité formé des responsables des systèmes et qui aurait pour but de procéder à la priorisation des demandes en mode projet, déchargeant par le fait même le PO. Parmi les autres ajustements possibles, notons l’augmentation du nombre de membres de l’équipe permettant ainsi que la séparation explicite du développement en mode projet et support. Finalement, il serait souhaitable d’augmenter le transfert de connaissances entre l’équipe d’entretien et celle de développement. Bien qu’aucune méthode n’ait été officiellement retenue, divers scénarios sont possibles dont l’intégration de membres de l’équipe d’entretien dans l’équipe de développement pour une période déterminée.
- Pas la seule façon de faire! ------- RICHARD -------- -------- Merci d’avoir assisté à cette présentation de notre projet d’entretien et évolution. Nous espérons que notre expérience vous sera bénéfique dans vos projets respectifs. Comme vous l’avez celui-ci est issu d’une multitude d’essais et erreurs et d’une certaine façon a été réalisé de façon itérative exactement comme l’agilité nous encourage à le faire. Il aurait probablement pu être réalisé de beaucoup d’autres façons. Il ne s’agit évidemment pas de l’unique façon de faire toutefois nous sommes très fiers du résultat. Richard : Vous êtes pas sensés être trois?
- Richard 10 ans Public, parapublique, privé Web, Intégration progiciel comptable, Intégration CRM, ERP Je cumule plus de dix années d’expérience en développement de système informatique, tant dans les secteurs publics, parapublics que privés. Au cours de cette période, j’ai participé principalement au développement de système orienté Web (prestation électronique de service, intranet, site Web applicatif) avec la plateforme de .NET de Microsoft, ainsi qu’à l’intégration de progiciel comptable, de gestion de relation clientèle (CRM) ou de planification de gestion de ressource (ERP). Depuis 2010, je m’intéresse à la méthode de développement Agile.