tag:blogger.com,1999:blog-5762312448351689453.post8741851117372181705..comments2024-03-23T05:42:07.989-07:00Comments on Emmanuel CHENU: RYTHME (IN)SOUTENABLEEmmanuel CHENUhttp://www.blogger.com/profile/00989041538576544218noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-5762312448351689453.post-5797507648087618922010-05-23T01:03:07.636-07:002010-05-23T01:03:07.636-07:00Bonjour,
Je suis a la recherche de conseil pour l...Bonjour,<br /><br />Je suis a la recherche de conseil pour le choix d'une méthode de gestion d'équipe/de projet.<br /><br />Voici un peu le point sur la situation actuelle: nous sommes < 5 developpeurs et on se partage une grosse farde avec tous les "dossiers" des programmes a écrire.<br /><br />Il n'y a pas de communication ni d'entrain, celui qui travaille le plus vite se recupere le plus de dossier. Celui qui a le plus de compétence récupère aussi les problemes (basique) que les autre ne savent pas corriger...(d'ailleurs des fois ils ne font même pas semblant de chercher a les corriger...)<br /><br />le chef de projet ne suit pas vraiment la chose : il se contente de demander si les développements avancent (il y a plus de 200 programmes / sous programmes...). Le projet a deja commencé en retard , les dossiers sont succincts / incomplets.<br /><br />On nous balance les dossiers comme si on donnait du grain a des poules.<br /><br />Le gros probleme c'est qu'au dessus (aux réunions ou les programmeurs ne sont pas invités) ils disent que ca va.... et de toute facon eux ils ont pondu des dossiers apres le reste c'est de la faute des programmeurs qui ne vont pas assez vite.<br /><br />J' essaye depuis peu la méthode pomodoro qui ne force un peu a (re-)travailler, mais si j'améliore mon travail en terme de rapidité je recupere celui des autres et de nouveau le rythme (et le moral) baisse.<br /><br />Avez vous qq conseils a me donner<br /><br />Alfred Dupont<br /><br />fox_kzrolb@trashmail.net<br /><br />MerciAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-5762312448351689453.post-7389124665589950482010-05-04T12:20:25.504-07:002010-05-04T12:20:25.504-07:00Un des principes important est que c'est l'...Un des principes important est que c'est l'équipe qui définie la charge qu'elle accepte de prendre (le nombre de story). <br />A partir de là cela marche si on la laisse réellement gérer correctement cela (et qu'elle connait les enjeux) et qu'on ne la juge pas négativement sur cet aspect (et oui, la vélocité doit rester un indicateur interne à l'équipe, pas un indicateur du management...), l'équipe va pouvoir s'autoriser elle même de "souffler" quand cela s'avère nécessaire. Je conçois que cela soit compliqué comme vision à accepter dans pas mal d'entreprise. Mais généralement les améliorations induites par le passage à Scrum permettent de le faire passer. Et oui, pour faire de l'Agile, il vaut mieux avoir un manager Agile !nicolas frankhttp://nfrank.blogspot.com/noreply@blogger.comtag:blogger.com,1999:blog-5762312448351689453.post-58498019643482052112010-04-29T09:16:50.411-07:002010-04-29T09:16:50.411-07:00Bonjour,
"des managers qui pensent que les d...Bonjour,<br /><br />"des managers qui pensent que les développeurs consomment le temps qu'il leur est alloué (loi de Parkinson). Ce modèle de management reste appliqué. Il s'agit de fixer des objectifs intenables pour être "sur" que les développeurs se donnent à fond. Changer ce schéma de pensée peut être une révolution culturelle pour certaines organisations."<br /><br />Agile et lean sont proches l'un de l'autre. Le second est sensé fonctionner avec des machines-outil. Quand on l'applique aux humains, en l'occurrence aux développeurs, c'est sur que ça peut être éprouvant.<br /><br />Si la loi de Parkinson n'est pas à jeter (peut être le manager ;-) ), il faut certainement l'aménager.<br /><br />Tout comme la machine-outil, la machine humaine supporte un certain rythme, c'est ce "bon" rythme que doit trouver le manager et édulcorer la loi de parkinson sur cette base, un peu comme le compte-tour d'une machine-outil sur lequel a été défini la zone rouge qui permet d'utiliser la machine à l'optimum de la capacité imaginé par ses concepteurs et la garder longtemps en bon état de fonctionnement. <br /><br />Une autre analogie que celle de la F1 de Christophe que je partage.Patrice Legouxhttps://www.blogger.com/profile/12278915246545011657noreply@blogger.comtag:blogger.com,1999:blog-5762312448351689453.post-22486427232723301452010-04-23T02:47:56.526-07:002010-04-23T02:47:56.526-07:00Je ne pense pas que nos difficultés soient liées à...Je ne pense pas que nos difficultés soient liées à la durée d'itération ou à la méthode utilisée. (Pour info, on pratique - entre autres - SCRUM avec des sprints - quelle horreur ce mot - de 20 jours ouvrés).<br /><br />Un des problèmes est qu'il n'y a pas de relâche. La rétrospective et la planification s'étalent sur 2 jours. Cette période est même plus stressante étant donné les enjeux. Et même si ces 2 jours étaient plus calmes, ils ne pourraient rattraper la succession de 17 sprints, agrémentés d'audits clients, de livraisons formelles et de démos.<br /><br />Certes, c'est au ScrumMaster de protéger l'équipe. Néanmoins, il est difficile pour lui de ralentir le rythme lorsque management et clients en veulent plus. <br /><br />C'est là la limite des principes: ils sont très louables mais ils se heurtent au contexte économique, aux pénalités de retard, au style de management, à l'horrible Loi de Parkinson et à la culture de l'entreprise.Emmanuel CHENUhttps://www.blogger.com/profile/00989041538576544218noreply@blogger.comtag:blogger.com,1999:blog-5762312448351689453.post-19764097027175211042010-04-23T02:12:42.764-07:002010-04-23T02:12:42.764-07:00Bonjour,
je conçoit que l'application d'u...Bonjour,<br /><br />je conçoit que l'application d'une itération courte peut amener à une dérive managériale d'augmentation de la pression. Ceci dit, pour partager mon expérience, nous avons plutôt obtenu un rythme nettement plus soutenable en passant à Scrum. <br />Les indicateurs sont valables sur 3 semaines (durée de nos sprints). Ce qui fait que certaines personnes vont avoir des "bons" sprints et d'autres des sprints + durs, mais celà tourne dans l'équipe et toutes les 3 semaines, nous repartons à 0.<br />Il est clairement nécessaire de ménager une période de respiration (ne serait-ce que la journée de retropsective + plannification ou la diminution de la dette technique), permettant de bien vivre ce changement de sprint.<br />J'aime bien l'analogie avec une course de F1. Pour arriver 1er, il ne faut pas avoir le pied tout le temps sur l'accélérateur et chercher à augmenter sa vélocité, mais il faut l'optimiser pour économiser l'essence et éviter les arrêts au stand. Pour nous, ce qui crame trop d'essence, c'est les période de développement "à l'arrache".<br />Enfin, c'est tout le rôle du ScrumMaster de ne pas entrer dans le jeu du management et de limiter les "mauvaises perturbations" de l'équipe (pression sur les charges, course à la vélocité, surcharge de backlog de sprintc...)<br />Je ne dis pas que c'est simple, mais les outils sont + nombreux et mieux adaptés pour limiter ce stress. La charge de travail est toujours en "dents de scie", mais sur des cycles + courts, les relâches existent + régulièrement.Unknownhttps://www.blogger.com/profile/01668946539354520032noreply@blogger.com