Accompagner la transition agile d’un grand projet
•
0 gostou•2,369 visualizações
Basculer en agile un très gros projet est un challenge, pour certains cela peut même apparaitre comme une ineptie. Pourtant c’est que le projet Linky a décidé de faire ! Un tel choix fait émerger des difficultés souvent absentes de projets plus petits : culture « cycle en V » omnisciente, grandes équipes, intégration dans l’architecture du SI, etc. Pourtant, si la route reste longue, les signes de succès sont réels. Au cours de cette session, nous allons aborder 12 leçons apprises lors de cette imporatnte transition agile toujours en cours, en y associant des conseils.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (20)
Semelhante a Accompagner la transition agile d’un grand projet
Semelhante a Accompagner la transition agile d’un grand projet (20)
Mais de Christophe Addinquy
Mais de Christophe Addinquy (15)
Accompagner la transition agile d’un grand projet
- 1. Accompagner la transition agile d’un grand projet L’expérience Linky
- 2. Qui suis-je ? Coach agile @ Zenika Computer addict depuis 1980 Agile maniac depuis 2001 Graves antécédents : développeur, analyste, modelisateur UML, chef de projet, design patterns fan-boy, formateur, directeur de projets, etc.
- 3. Le projet Linky Je ne suis pas ici pour vous en parler, mais… ✓Transition vers le « compteur intelligent » ✓Une nouvelle façon de gérer le réseau ✓Le plus gros projet ERDF depuis … très longtemps
- 4. Gros projet / Petit projet
- 5. Transition : comment ? 12 leçons (durement) apprises
- 6. Attention ! Il ne s’agit pas de recettes magiques ! Ca marche pour moi. Et pour vous ? Une base de reflexion pour adapter et apprendre.
- 7. 1 - Immersion agile Une journée pour appréhender les principes et les concepts agile Ne pas considérer les principes agiles comme « évidents » 1 jour tout de suite vaut mieux que 2 jours plus tard ! Des jeux et des discussions
- 8. 2 - Commencer lentement, délibérément Apprendre les « gestes » Scrum correctement Pas de compromis sur la qualité Le rôle du management : pas de raccourcis ! L’équipe cherchera spontanément à aller vite !
- 9. « Faites attention à ce que vous demandez, vous risquez de l’obtenir ! » Christophe Addinquy Durant les premières itérations Focus sur la qualité fonctionnelle et technique Attention sur la dynamique de groupe, le partage et le focus sur peu de User Stories Pas de mesure de vélocité. Nous avons même rendu toute comparaison directe entre équipe presque impossible !
- 10. 3 - Le droit à l’erreur Rassurer d’entrée de jeu Améliorations ➤ Expérimentation : Sortir du « non risque » et rechercher des expérimentations peu coûteuses Une erreur est une opportunité d’apprendre quelque chose Laisser les erreurs (et non l’échec) arriver
- 11. VOUS avez le droit à l’erreur ! Etre humble : personne n’aime les donneurs de leçons Vous allez découvrir de nouvelles situations Vous allez apprendre quelque chose de votre client Ca va vous arriver de toute façon…
- 12. 4 - Utiliser les tests d’acceptation Créer de la compréhension partagée Lever les ambiguïtés ensemble Discipline de maîtrise et de validation de l’avancement
- 13. 5 - La posture du management
- 14. 6 - Veiller sur l’auto-organisation
- 15. 7 - Craftsmanship Le « savoir-faire » est un pré- requis Prendre la température aux code-review Injecter de vrais craftsmen au sein des équipes Organiser la montée en compétence Les métriques de la plateforme d’intégration ne suffisent pas !
- 16. « Une interface doit être facile à bien utiliser, et difficile à mal utiliser. » Scott Meyers Responsabilité unique (classe, méthode) Le nom révèle l’intention Tests unitaires pertinents (TDD)
- 17. 8 - Le fond et non la forme « comment » « pourquoi » Rôles Cérémonies Post-it Collaboration Interactions Feedback Focus Implication Transparence
- 18. 9 - Apprendre à s’améliorer Comprendre Mesurer Explorer Le vrai challenge du Scrum Master
- 19. 10 - L’architecture compte ! Quelle efficacité dans votre cycle de développement ?
- 20. 11 - Off / On Transitions douces ?? L’autonomie de l’équipe Livrer en fin de sprint Pas de challenge insurmontable
- 21. 12 - Parfois, il faut plonger pour mieux réussir… On ne peut pas forcer les personnes à être aidées. Une phase de dégradation peut succéder à la mise en place. L’aide en seconde phase est plus perenne.
Notas do Editor
- Plus gros projet informatique ERDF depuis longtemps : plusieurs milliards d’euros C’est une transformation en profondeur d’ERDF ; une nouvelle façon d’opérer le réseau : de relever à distance des informations, de mieux connaitre les usages d’aller vers des « smart grids » adaptées aux énergies renouvellables et aux petits producteurs, etc.
- Dans les gros projets, les membres ont l’habitude d’être une goutte d’eau dans une armée : Plus de résignation par rapport à une organisation rigide et avoir moins son mot à dire sur la façon de faire les choses : enclencher l’auto-organisation est moins facile. Organisation compliquée : il faut souvent « faire avec »
- Je vais partager avec vous 12 leçons ou patterns, souvent durement appris. Pas des principes généraux, mais des choses actionnables. Vous allez voir que ces points ne sont pour la plupart pas indépendants. Ce n’est pas une liste exhaustive, mais ce sera déjà bien assez pour aujourd’hui !
- Des leçons apprises ne sont pas des recettes ; il est dangereux de les appliquer sans comprendre ce que l’on fait et les implications de ce que l’on fait (tout a des implications. Ce n’est pas de la magie Utilisez-les, mais réfléchissez à ce que vous faites
- Ne pas croire que l’agile « est naturel » et que les membres des équipes vont automatiquement comprendre en faisant Les équipiers risquent d’essayer de se fondre dans les rituels mais en gardant le vieil état d’esprit.. 1 jour pour comprendre les principes de base de l’agile et l’état d’esprit agile Des jeux Des discussions 1 jour tout de suite vaut mieux que 2 jours plus tard L’investissement qu’acceptent les grands marchands de viande par rapport aux personnes est 0 !
- Les équipes ont envie de rusher Focaliser agressivement les équipes sur le respect des règles du jeu. Demander explicitement à ne pas aller trop vite ! Donc c’est : Faire du bon travail Améliorer l’efficacité et la vélocité … mais progressivement ! Je n’aime pas le message « 600% » de Sutherland
- Utiliser un (ou quelques) indicateurs qui influeront sur le comportement de l’équipe. Il y a des indicateurs qu’il faut enlever pour ne pas induire de biais. Ne pas mesurer, ni ne regarder ce qui risque de tirer dans le mauvais sens. « passer le message » ne sert à rien => Les gens regardent les actions ; en cas de divergence entre le message et l’action... Idéalement, le bon nombre d’indicateur est « 1 ». Au fait, n’oubliez pas qu’un indicateur doit être actionnable, sinon => out ! Pas de notion d’indicateur « pour information » : il fait baisser la crédibilité des autres.
- La chose qui a déstressé les équipes lors du passage à l’agile. Penser : si je rate, quelles sont les conséquences. Des erreurs, on en fera ; pas de recette magique pour ne pas en faire. Je laisse aller au bout des erreurs (si elles ne mettent pas l’équipe en danger) : c’est la meilleure façon d'apprendre Exemple : beaucoup de stories en cours (optimisation de capacité) au premier Sprint ! Peu d’US terminées en fin de sprint : 1, parfois 0
- Dites-le : cela montre que vous êtes humble et que vous n’êtes pas au-dessus de la mêlée. Une bonne façon de faire pour que le client n’attende pas de la magie de votre part.
- Le bon truc pour obtenir quelque chose de terminé en fin d’itération. Problème du test en aval… => l’un des plus gros obstacles (on va revenir plus tard là-dessus) Mais pas seulement... Voir le « workshop des 3 amis » de Gojko Adzik Permet de débugger la spécification : un AT, c’est l’instanciation de la spécification En explorant les cas aux limites, on relève d’éventuelles incohérences On crée de la compréhension partagée Un bon AT est univoque : on est obligé de faire un choix par rapport à de l’information implicite et on relève les différences d’interprétation. Dans l’ancien modèle : spécification passée indépendamment à la réalisation et aux tests qui n’ont pas le droit de se parler !
- L’une des actions d’accompagnement les plus importantes ! Arrêter le « comment » ! Utiliser les outils de Jurgen Appelo Pas de droit de dire aux personnes ce qu’ils ont à faire => pas facile et frustrant. Comment travailler sur le cadre pour induire les comportements que l'on cherche à obtenir. anecdote du nombre des « en cours »...
- Combattre la culture « petits soldats ». Surveiller les symptômes : « on ne nous a pas demandé »... Qui est responsable de... Combattre les baronnies : les titres, les équipes transverses. Attitude ambivalente à ce sujet.
- Hélas peu mis en avant aujourd’hui dans les accompagnements agile. Pourtant l’excellence technique est cité par les auteurs comme un prérequis à Scrum. Bonne méthode : de l’infusion « par l’intérieur » avec des développeurs expérimentés qui travaillent avec les équipiers en se mettant à côté d’eux. La méthode « par l’extérieur » est aussi à essayer, via des BBL, des coding dojos, etc… Mais pas de succès flamboyants. Entre autre en terme de participation. Au moins, cela permet de prendre la température de l’intérêt du sujet. Ceux qui viennent ces BBL sont plutôt ceux qui en ont le moins besoin. Générer de l’intérêt pour ce sujet est difficile : faire du bon code est plus cher que de faire du mauvais code, c’est aussi plus de réflexion, etc... Meilleurs moyen : créer une spirale vertueuse pour attirer les bons talents Mais le contexte organisationnel et contractuel rend cela plus difficile Les contractualisation se font beaucoup avec les grosses boutiques possédant peu de ces talents, sur la base du « cost cutting ». Les talents que l’on recherche sont attirés par les contextes techniques alléchants et où l’organisation leur laisse la marge de manoeuvre pour qu’ils s’expriment (voir [6], point précédent).
- C’est ma boussole personnelle ; elle intrigue positivement les gens mais s’avère difficile à suivre Se focaliser sur des sujets que l’on hiérarchise. Traiter l’amélioration du code juste par Sonar, c’est rater de lui donner du sens ! La qualité reste un des sujets d’insatisfaction, entre autre parce que ce n’est pas un sujet d’insatisfaction au sein des équipes !
- Passer du « comment » au « pourquoi ». Le folklore Scrum, c’est du « comment » -> il est là pour aider à appréhender le pourquoi Se méfier des « audits » qui se focalisent sur le folklore (se méfier des audits en général, d’ailleurs -> rechercher leur « pourquoi »). Oui, il faut passer par la mise en place du « folklore » lors de la transition : il a été imaginé parce qu’il marche et constitue une bonne façon d’enclencher les bons comportements. Mais il faut regarder les choses importantes derrière ce folklore
- Le « 2nd challenge » des SM. Utiliser la « communauté des SM ». Rétrospectives -> une logique d’objectifs / mesures / revue en rétro suivante Eviter les gros chantiers -> on ne le faits jamais car on a le « vrai projet à faire. Préférer les petits pas. Ne pas cantonner les améliorations aux rétrospectives Le A3 Etre opportuniste => On remonte en cours de sprint des choses qui ne sortent pas forcément en rétro.
- On entends parfois qu’Agile est indépendant de la technologie ! En fait le technologie a un effet dimensionnant sur la mise en place de l’agile, même si à la base il s’agit d’un « mind set » humain. Des choix d’éditeurs rassurant => wrong Des choix basés sur une « feature list » => wrong again Des choix basés sur le retour d’expérience et l’opérabilité => bien mais pas suffisant Quid de l’utilisabilité en développement ? Testabilité ? Boucle de feedback ? Favoriser des outils qui peuvent se tester avec JUnit ! Penser en « coût de transaction » : si le coût de transaction est élevé => on fera de grosses tâches, de grosses user stories. Regarder aussi la modularisation que permet l’outil, cela peut avoir un impact sur la modularisation et la parallélisassions du travail. Quel temps / difficulté pour packager / déployer Quel réactivité pour le « start up » et donc quel impact sur la durée des tests ? Imaginez un environnement de travail qui vous impose que tout votre code Java ou C# soit dans une unique fichier source... Votre serveur d’application induit-il des comportements différents de ceux que vous allez constater « en local » ?
- J’ai cru pendant un certain temps que l’on pouvait introduire progressivement des concept agiles jusqu’à ce qu’un beau jour on constate que l’on est agile ! En fait, c’est insatisfaisant car on est pas agile et on introduit de l’incompréhension. Le meilleurs moyens, c’est la rupture franche, avec des contraintes et des précautions Contraintes : Obtenir un produit utilisable en fin d’itération : nécessité de rapatrier les tests dans l’itération ! l’ATDD est d’une grand aide ici. Mettre ensemble les personnes nécessaire au boulot et ne pas dépendre de ressources externes « matricielles » : le matriciel, c’est de l’optimisation de capacité ! Précautions : Pas de contrainte sur la vélocité au début (voir [2]) Accepter que ça ne va pas bien marcher au début (voir [3]) Ne pas se fixer de challenge impossible : les tests doivent tous être automatisés
- Dès que les équipes pensent « avoir compris », elles cessent de faire appel à vous. Surveiller les tendances : rigueur, interactions et collaboration, travail en cours Posez à l’occasion des questions dérangeantes. Mais cela n’a pas toujours d’impact. Quand les conséquences deviennent douloureuses => on vient vous voir ! Votre aide prendra beaucoup mieux à ce stade.