Ha la la, que de souvenirs dans mes précédentes expériences ! Personnellement, j'aime beaucoup ce genre de contexte, mais c'est vrai que c'est parfois très compliqué. En particulier, réussir à associer ces utilisateurs ET la direction qui va souvent jouer dans le camp de l'inertie. Mais quel plaisir à chaque progrès (aussi satisfaisant que de nettoyer et ranger sa cuisine placard par placard 🥰)
Tres intéressant. Vous avez fait un vie ma vie dans mon equipe ? Je confirme qu'il est très difficile de garder les développeurs ( même d'en trouver des nouveaux ) sur une application legacy !
C'est la magie de Scrum Life ! Chaque contexte est différent, mais dans les grandes lignes tout le monde rencontre les mêmes types de problème... Comment dans ton équipe vous y prenez vous pour garder les développeurs et en trouver des nouveaux ? Etant conscients du problèmes, qu'essayez-vous de faire ? -- JP
Une question, un doute, quelque chose à ajouter ? Ajoute-le en commentaire ! ⌨👇 Nous en échangerons lors du 🔴Live jeudi : sl.run/6By8QU
Рік тому
12:10 règle d'extreme programming ( ce truc pas toujours connu qui a tant inspiré les "pratiques" de ceux qui font du scrum) Client sur site : Un représentant du client doit, si possible, être présent pendant toute la durée du projet. Il doit avoir les connaissances de l'utilisateur final et avoir une vision globale du résultat à obtenir. Il réalise son travail habituel tout en étant disponible pour répondre aux questions de l'équipe.
Hello, merci pour cette vidéo encore un sujet super intéréssant. En effet, les outils legacys restent majoritaires! On ne peut pas se permettre de toujours tout refaire tout depuis le début ;). Je trouve que c'est aussi ça le challenge! Réussir à Transformer l'organisation et la gestion du produit legacy vers de l'agilité. Certes, la technique peut etre un frein, mais on peut très bien à la fois travailler de l'exploration (Personas, parcours utilisateurs, story mapping), le confirmer avec de la mesure via du log app ou meme des extractions de logs de données (meme si c'est manuel au début pour tester, expérimenter)! Et vite valoriser les changements que l'on fait et garder une motivation élevée. Via en effet un mindset de découpage des changements les plus précis et valorisés. Je suis tout à fait d'accord sur le besoin de transparence vis à vis des devs que l'on recrutent et leur partager la stratégie sur la gestion du produit. Par expérience, l'agilité est un vrai plus pour du Legacy, car on peut plus facilement le faire évoluer au fil de l'eau, valoriser la réduction de la dette technique, de chantiers de migration technique etc... à condition bien sur de bien faire le lien avec les parcours utilisateurs! Du sens, du sens, du sens en partageant la valeur pour les Utilisateurs, l'entreprise ET L'EQUIPE!
Tout va dépendre du contexte (équipe, produit...). Car selon ce contexte cela peut être très motivant d'être sur du legacy plutôt que de partir d'une feuille blanche. Par soucis de confort, à équipe, management équivalents, la page blanche permet d'etre directement sur un produit qui correspond à nos critères de qualité m, d'organisation et que l'on maîtrise. Ce qui est rarement le cas lorsque l'on reprend un produit legacy
Chez scrum life, on ne laisse pas bébé dans un coin... Je pense que travailler sur du legacy appelle deux type de travaux forts : une redéfinition de la valeur du produit (faut-il le conforter dans un usage actuel ou bien faire évoluer vers d'autres usages ?) les ateliers type event storming sont souvent nécessaires. C'est aussi un appel à de nouvelles pratiques (CI/CD, décomposition monolithique, etc...). L'agilité est bien souvent la seule voie possible pour sortir mais ça en appelle souvent à un ADKAR préalable pour accompagner la transition agile. Le travail en itération a souvent l'intérêt de limiter l'espace de risques, dans ce cadre cela va obliger à marquer la transition de méthodes et passer d'anciennes méthodes à de nouvelles pratiques.
Travailler sur du code legacy c’est terrible , surtout dans une équipe scrum on est parfois obligé de faire du scrumbut , tellement tout est touffu , idéalement du Kanban pour progresser au fil de l’eau . Lorsque c’est possible on produit un logiciel avec de la valeur , quand c’est pas possible j’essaie souvent de faire jouer mes atouts business pour inciter la direction / l’orga à pivoter , par la création d’un autre produit à terme , plus propre et qui se servira de la source de données existante , de telle sorte qu’on ne puisse pas perdre les users , et leurs données essentielles mais qu’on puisse se relancer vers de nouveaux sentiers parce que à terme , maintenir du legacy c’est très coûteux , la dette n’est pas que technique elle est surtout financière .
Il faut effectivement mettre en place une stratégie pour "quitter" le Legacy. C'est un monde à part entière ! Je comprends dans ton message que pour toi ce n'est pas le genre de challenge qui te passionne, j'ai bien compris ? -- JP
Il faut aussi une bonne confiance du PO dans les projets legacy pour que l'équipe de dev est la légitimité et le soutien pour transformer des parties existantes. Dans l'autre sens, il faut que les devs comprennent que stopper le dev fonctionnel, c'est très rarement une bonne idée et cela précipite souvent le projet dans la tombe
Mais vous avez fait un stage dans mon ancienne société ou quoi ? Ce n'est pas possible ahaha mot pour mot je croirai entendre des anciens collègues, et la direction aussi ! De bonnes pistes intéressantes à mettre en place, faut-il encore convaincre la direction ! Je me souviens de notre PM qui voulait justement un environnement de test pour elle pour pouvoir répondre aux questions des clients sans nous déranger... elle n'a pas été très écoutée dommage... Je suis arrivée dans cette boîte avec ce contexte "on refait tout mais on change juste la techno et la peinture, mais on fait ça vite aussi car on est pressés". Résultat c'est du légacy qui est en train de se construire... et nous avions lutté pour ne pas "refaire que la techno et la peinture" mais on nous a prit dans une salle en nous disant clairement qu'il ne fallait pas réfléchir sur ce projet et foncer 😁 3 ans après la quasi totalité de l'équipe est partie...
Les devs juniors se concentrent pour faire fonctionner leur code dans le système actuel Les devs expérimentés tentent de convaincre le PO de jeter la solution actuel et d'implémenter la derniere stack à la mode qui règlera tous les problèmes Les devs seniors font évoluer le système existant module par module, ligne par ligne, en isolant puis en supprimant les parties douloureuses petit à petit
Рік тому+1
J'ai toujours un problème avec "les précédents ont fait de la m*rde". Soit c'est faux , ils ont travaillé avec des contraintes et objectifs différents, soit ils ont été laxistes, volontairement ou fléchissants face à une pression classique (il faut aller vite) Ne cherchez pas à juger les développeurs précédents parce que ça ne fera pas avancer les choses. Soit, vous n'aurez pas compris que c'est le contexte qui a changé, soit vous conforterez les pressuriseurs qu'ils avaient raison, que c'était bien les dev d'avant qui étaient mauvais. Attaquez-vous au code, pas aux gens
Il n'y a jamais de solution universelle, mais trop souvent on veut faire une "refonte" complète alors qu'on pourrait, on devrait refaire l'application petit à petit, morceau par morceau, progressivement et itérativement. As-tu une expérience avec ce genre d'application "legacy" ? Quelle a été ton expérience ? -- JP
@@ScrumLife Je n'ai justement aucune expérience la dessus, je n'ai fait que du from scratch durant mes études et stages. Lors d'un entretien j'ai remarquer qu'il s’agissait d'une application legacy et ça me faisait un peut peur étant donné que le recruteur ne me le disait pas explicitement et que je l'ai su par moi même. J'en ai parlé à un amis et il m'a partagé votre vidéo x).
Ha la la, que de souvenirs dans mes précédentes expériences !
Personnellement, j'aime beaucoup ce genre de contexte, mais c'est vrai que c'est parfois très compliqué. En particulier, réussir à associer ces utilisateurs ET la direction qui va souvent jouer dans le camp de l'inertie. Mais quel plaisir à chaque progrès (aussi satisfaisant que de nettoyer et ranger sa cuisine placard par placard 🥰)
Tres intéressant. Vous avez fait un vie ma vie dans mon equipe ? Je confirme qu'il est très difficile de garder les développeurs ( même d'en trouver des nouveaux ) sur une application legacy !
C'est la magie de Scrum Life ! Chaque contexte est différent, mais dans les grandes lignes tout le monde rencontre les mêmes types de problème...
Comment dans ton équipe vous y prenez vous pour garder les développeurs et en trouver des nouveaux ? Etant conscients du problèmes, qu'essayez-vous de faire ?
-- JP
Une question, un doute, quelque chose à ajouter ? Ajoute-le en commentaire ! ⌨👇
Nous en échangerons lors du 🔴Live jeudi : sl.run/6By8QU
12:10 règle d'extreme programming ( ce truc pas toujours connu qui a tant inspiré les "pratiques" de ceux qui font du scrum) Client sur site :
Un représentant du client doit, si possible, être présent pendant toute la durée du projet. Il doit avoir les connaissances de l'utilisateur final et avoir une vision globale du résultat à obtenir. Il réalise son travail habituel tout en étant disponible pour répondre aux questions de l'équipe.
Hello, merci pour cette vidéo encore un sujet super intéréssant. En effet, les outils legacys restent majoritaires! On ne peut pas se permettre de toujours tout refaire tout depuis le début ;). Je trouve que c'est aussi ça le challenge! Réussir à Transformer l'organisation et la gestion du produit legacy vers de l'agilité. Certes, la technique peut etre un frein, mais on peut très bien à la fois travailler de l'exploration (Personas, parcours utilisateurs, story mapping), le confirmer avec de la mesure via du log app ou meme des extractions de logs de données (meme si c'est manuel au début pour tester, expérimenter)! Et vite valoriser les changements que l'on fait et garder une motivation élevée. Via en effet un mindset de découpage des changements les plus précis et valorisés.
Je suis tout à fait d'accord sur le besoin de transparence vis à vis des devs que l'on recrutent et leur partager la stratégie sur la gestion du produit.
Par expérience, l'agilité est un vrai plus pour du Legacy, car on peut plus facilement le faire évoluer au fil de l'eau, valoriser la réduction de la dette technique, de chantiers de migration technique etc... à condition bien sur de bien faire le lien avec les parcours utilisateurs! Du sens, du sens, du sens en partageant la valeur pour les Utilisateurs, l'entreprise ET L'EQUIPE!
Merci pour ce partage !
Dirais-tu que tu préfères travailler sur du Legacy ou au contraire sur du nouveau ? (on parle aussi de "greenfield")
-- JP
Tout va dépendre du contexte (équipe, produit...). Car selon ce contexte cela peut être très motivant d'être sur du legacy plutôt que de partir d'une feuille blanche. Par soucis de confort, à équipe, management équivalents, la page blanche permet d'etre directement sur un produit qui correspond à nos critères de qualité m, d'organisation et que l'on maîtrise. Ce qui est rarement le cas lorsque l'on reprend un produit legacy
Chez scrum life, on ne laisse pas bébé dans un coin...
Je pense que travailler sur du legacy appelle deux type de travaux forts : une redéfinition de la valeur du produit (faut-il le conforter dans un usage actuel ou bien faire évoluer vers d'autres usages ?) les ateliers type event storming sont souvent nécessaires. C'est aussi un appel à de nouvelles pratiques (CI/CD, décomposition monolithique, etc...). L'agilité est bien souvent la seule voie possible pour sortir mais ça en appelle souvent à un ADKAR préalable pour accompagner la transition agile. Le travail en itération a souvent l'intérêt de limiter l'espace de risques, dans ce cadre cela va obliger à marquer la transition de méthodes et passer d'anciennes méthodes à de nouvelles pratiques.
Travailler sur du code legacy c’est terrible , surtout dans une équipe scrum on est parfois obligé de faire du scrumbut , tellement tout est touffu , idéalement du Kanban pour progresser au fil de l’eau . Lorsque c’est possible on produit un logiciel avec de la valeur , quand c’est pas possible j’essaie souvent de faire jouer mes atouts business pour inciter la direction / l’orga à pivoter , par la création d’un autre produit à terme , plus propre et qui se servira de la source de données existante , de telle sorte qu’on ne puisse pas perdre les users , et leurs données essentielles mais qu’on puisse se relancer vers de nouveaux sentiers parce que à terme , maintenir du legacy c’est très coûteux , la dette n’est pas que technique elle est surtout financière .
Il faut effectivement mettre en place une stratégie pour "quitter" le Legacy. C'est un monde à part entière !
Je comprends dans ton message que pour toi ce n'est pas le genre de challenge qui te passionne, j'ai bien compris ?
-- JP
Il faut aussi une bonne confiance du PO dans les projets legacy pour que l'équipe de dev est la légitimité et le soutien pour transformer des parties existantes.
Dans l'autre sens, il faut que les devs comprennent que stopper le dev fonctionnel, c'est très rarement une bonne idée et cela précipite souvent le projet dans la tombe
Mais vous avez fait un stage dans mon ancienne société ou quoi ? Ce n'est pas possible ahaha mot pour mot je croirai entendre des anciens collègues, et la direction aussi ! De bonnes pistes intéressantes à mettre en place, faut-il encore convaincre la direction ! Je me souviens de notre PM qui voulait justement un environnement de test pour elle pour pouvoir répondre aux questions des clients sans nous déranger... elle n'a pas été très écoutée dommage...
Je suis arrivée dans cette boîte avec ce contexte "on refait tout mais on change juste la techno et la peinture, mais on fait ça vite aussi car on est pressés". Résultat c'est du légacy qui est en train de se construire... et nous avions lutté pour ne pas "refaire que la techno et la peinture" mais on nous a prit dans une salle en nous disant clairement qu'il ne fallait pas réfléchir sur ce projet et foncer 😁 3 ans après la quasi totalité de l'équipe est partie...
Les devs juniors se concentrent pour faire fonctionner leur code dans le système actuel
Les devs expérimentés tentent de convaincre le PO de jeter la solution actuel et d'implémenter la derniere stack à la mode qui règlera tous les problèmes
Les devs seniors font évoluer le système existant module par module, ligne par ligne, en isolant puis en supprimant les parties douloureuses petit à petit
J'ai toujours un problème avec "les précédents ont fait de la m*rde". Soit c'est faux , ils ont travaillé avec des contraintes et objectifs différents, soit ils ont été laxistes, volontairement ou fléchissants face à une pression classique (il faut aller vite) Ne cherchez pas à juger les développeurs précédents parce que ça ne fera pas avancer les choses. Soit, vous n'aurez pas compris que c'est le contexte qui a changé, soit vous conforterez les pressuriseurs qu'ils avaient raison, que c'était bien les dev d'avant qui étaient mauvais. Attaquez-vous au code, pas aux gens
😱 Promo-SM!!!
Si on ne refait pas tout de zero est ce que le châteaux de carte ne risque pas de tomber un jour.
Il n'y a jamais de solution universelle, mais trop souvent on veut faire une "refonte" complète alors qu'on pourrait, on devrait refaire l'application petit à petit, morceau par morceau, progressivement et itérativement.
As-tu une expérience avec ce genre d'application "legacy" ? Quelle a été ton expérience ?
-- JP
@@ScrumLife Je n'ai justement aucune expérience la dessus, je n'ai fait que du from scratch durant mes études et stages.
Lors d'un entretien j'ai remarquer qu'il s’agissait d'une application legacy et ça me faisait un peut peur étant donné que le recruteur ne me le disait pas explicitement et que je l'ai su par moi même.
J'en ai parlé à un amis et il m'a partagé votre vidéo x).