Ericsson, Enalean et Obeo ont annoncé lors de la conférence EclipseCon France (18 et 19 juin 2014) à Toulouse la sortie prochaine du premier outil Open source de gestion de projet agile intégré à Eclipse.
Cette innovation a vu le jour grâce au partenariat avec Ericsson qui a participé au financement des développements, et à la collaboration technique des équipes d’Enalean et d’Obeo. Les ingénieurs Enalean ont complétement retravaillé l'API REST de Tuleap et Obeo s'est chargé de l'intégration dans Eclipse.
L'objectif de ce connecteur est d'accéder aux outils agiles de la forge logicielle Tuleap directement depuis l'environnement de développement Eclipse. Grâce au connecteur Tuleap Agile Planner pour Eclipse, les développeurs accèdent aux outils agile de Tuleap (versions, sprints, mur des tâches, graphique burndown) tout en restant dans Eclipse, évitant les allers-retours entre les différents outils.
Tuleap Agile Planner est intégré avec l'environnement Eclipse Mylyn. Il conserve ainsi l'expérience utilisateur d'Eclipse dénommée « interface centrée sur les tâches » (task-focused interface). Dans Eclipse, cette vue ne montre au développeur que ce qui concerne la tâche en cours, tout en apportant les fonctionnalités spécifiques de Tuleap pour la gestion de projet agile. Un développeur peut facilement lier un cas d'utilisation avec un nouvelle tâche et son code source ou mettre à jour ses cartes sur le mur des tâches par cliquer-glisser. Chacun peut suivre l'avancement d'un sprint ou d'une version ou consulter le graphique du reste à faire (burndown).
Tuleap est la première forge logicielle à proposer un connecteur agile pour Eclipse sous licence Open source.
Tuleap Agile Planner pour Eclipse est entièrement contribué en Open source sous licence EPL. Il sera disponible début juillet 2014. Vous pourrez l'installer en quelques clics depuis le marché Eclipse directement depuis l'interface Mylyn discovery.
Aller plus loin
- Site officiel (405 clics)
# Agile ?
Posté par or zax . Évalué à 2.
Le mot agile est sûrement de trop si on considère que le seul outil utilisé dans les méthodes agiles sont un mur et des post-it. Donc principalement une manœuvre marketing pour surfer sur l'engouement des méthodes agiles pour vendre de la presta sur de l'ALM.
J'ai vue des tentatives d'implémentations de méthodes agiles échouer à cause de ce genre d'approche. Dans le pire des cas on supplante le board sur le mur par l'outils, pour le coups on gangrène les points quotidiens. Dans d'autre cas on rassure le middle management avec ces outils pour leurs assurer de la transparence, on oblige donc à une redondance d'outils.
Dans le cas de Scrum, c'est le rôle du scrum master de protéger l'équipe de cette perturbation du fait de la redondance d'outils, et fait la saisie, comme çà tout le monde est content. Mais là on veut obliger à ce que cela vienne jusqu'à l'écran du développeur …
Le tout pour cacher le fait que le middle management n'a pas de visibilité sur ce qui se passe par absence de product owner.
Bref, soit on se repose sur l'outil d'ALM soit on fait de l'agile. Boire ou conduire il faut choisir, aucun choix n'est mauvais, mais on ne peut tout faire en même temps.
[^] # Re: Agile ?
Posté par tontonMax . Évalué à 0.
[^] # Re: Agile ?
Posté par ckyl . Évalué à 5. Dernière modification le 19 juin 2014 à 18:30.
Non tu l'implémentes comme tu veux et comme ca fait le plus de sens pour ton contexte.
Si le middlemanagement ou quelqu'un veut ruiner l'esprit de l'approche, ce n'est pas un outil qu'il faut blamer. C'est un peu comme prendre le "stand up" au pied de la lettre. A partir du moment ou tu as compris le but du truc (et peu le comprenne…) et que tu t'éfforces de le garder court. Que tu sois débout, assis, allongé ou à poil ca ne change rien. Il ne faut pas confondre but, outil et technique.
Après je sais pas ce que vaut tuleap.
[^] # Re: Agile ?
Posté par or zax . Évalué à 1.
Dans le cas d'une équipe distribuée, donc qui ne peux se rassembler… On ne fait pas d'agile. Ça ne marche pas, l'agilité n'est pas une recette magique qui marche tout le temps.
Ensuite le mur électronique, pousse à remplacer la communication par des processus, donc l'opposé de la philosophie agile.
Cet outil est sûrement très bien et peux être génial dans pas mal de cas. Par contre si tu fais des recherches tu verras que l'agilité et les murs dans des soft ça marche pas. On peut essayer l'implémenter de cette façon… Mais le résultat est décevant.
Mon point n'est pas de dire n'utilisez pas cet outils, mais de dire, attention il n'est pas adapté à une pratique réellement agile. L'agilité n'est pas non plus une approche à utiliser dans tous les cas. Dans le cas d'une équipe réellement distribué en consulting, ce serait un nogo pour agiliser une société.
[^] # Re: Agile ?
Posté par ckyl . Évalué à 4. Dernière modification le 20 juin 2014 à 09:19.
Ah mince. Ce qui est con quand on te prévient pas c'est que tu fais des trucs impossible… On faisait sûrement de la grosse merde…
Non c'est un état d'esprit; des valeurs et des principes.
Si ton n'équipe n'a pas assimilé le fondement des choses et les buts; c'est ça le problème pas l'implémentation d'un point précis que tu choisis. Des gens appliquer bêtement ce qu'on leur a dit sans avoir rien compris, j'en ai vu autant avec du tout papier que du tout électronique.
Explique moi la différence profonde entre "Écrire quelque chose sur un post-it papier" et "Écrire quelque chose sur un post-it informatique". C'est comment tu t'en sers qui est important.
N'importe quoi. C'est toi qui est complètement obnubilé par les processus et une implémentation unique de la chose.
Dire qu'un board électronique n'est pas réellement agile c'est aussi con que dire que si je fais mon stand up assis je suis pas agile… Le choix de l'implémentation par défaut poussée par les gentil petits formateurs à uniquement pour but de faciliter la mise en pratique initiale. Individuals and interactions over Processes and tools
[^] # Re: Agile ?
Posté par or zax . Évalué à 2.
Dans un cas tu es tout seul devant un écran les autres se poussent derrière toi. Le principe d'un vrai mur, c'est que :
1) Tu encourages le principe des stand-ups : autrement dit les réunions se font de manière active, pas en se planquant derrière son poste.
2) Le mur devient un point de rassemblement physique.
Comme je l'ai déjà dit, tu peux essayer de l'implémenter de cette façon là. Après tout … pourquoi pas. Mais il y a un grand principe dans l'agile : le feedback. Et le feedback de la communauté agile t'indiquera que certaines approches sont meilleurs que d'autres.
Le discours que tu me tiens c'est du même ordre que : on peut utiliser tous les langages de programmations pour coder un produit donner, mon point c'est : attention écrire des drivers graphique en php c'est pas bon, on peut le faire pour le défi mais ….
Dans le cas de l'informatisation du board, si tu aimes le défi … mais le feedback est claire, la plupart se casse la pipe avec.
[^] # Re: Agile ?
Posté par djano . Évalué à 3.
Mince plein de gens ne sont pas au courant qu'ils font n'importe quoi! Et en plus tu sais quoi? Ça marche que quand même!
Bref l'outil ou la méthode n'ont rien a voir, ce qui compte ce sont les gens qui l'animent.
Des projets développés de manière distribuée peuvent fonctionner avec des méthodes agiles sans mur physique.
D'ailleurs j'ai vu des équipes avec des murs physiques qui échouaient quand même, comme quoi ce n'est pas la panacée.
Maintenant, je ne comprend pas bien pourquoi tu mets tant d’énergie a affirmer si énergiquement que ça ne marche pas alors que l'on te dit que l'on y arrive au jour le jour.
As tu une expérience a partager?
[^] # Re: Agile ?
Posté par or zax . Évalué à 1.
Ce n'est pas n'importe quoi, c'est une autre façon de faire.
Beaucoup de gens veulent faire de l'agile alors que cela ne convient absolument pas. La recette miracle qui marche pour tous les cas de figure …
L'agilité revient à travailler en respectant certains principes, issus du monde industriel. Je ne pense pas, et toi non plus sûrement (?) que l'informatique dans tous les cas ne partage pas ces problématiques.
Beaucoup de personnes pensent faire de l'agilité alors que ce n'est pas le cas, et quelque part … tant mieux … car la vrai finalité est de travailler d'une façon efficace qui convienne à tous.
As tu une expérience a partager ?
Oui plusieurs même. Le cas où on a forcer les développeurs à utiliser un outil électronique, ils l'ont fait un temps, mais la première conséquence, c'est le fait de miner le daily meeting … je te laisse imaginer le résultat …
Un autre cas, çà a été le fait que çà a élimer la force du scrum master, les développeurs font le travail, le feedback par l'outil, l'historisation tout. Pour le coups on a pas embauché un autre scrum master, qui devait s'occuper juste d'animer des réunions … un scrum master pour 6 équipes …. Résultat quand il y a eu un coups de pression, il était seul pour essayer de faire le tampon entre la direction et les équipes, sur un plan personnel, çà été très dur pour le Scrum Master, les équipes en ont fait les frais. Je ne parle pas de l'absence de product owner …
[^] # Re: Agile ?
Posté par djano . Évalué à 2.
En gros, on est tous d'accord que l'outil pour l'outil ça ne passe pas.
Et l'agile ne passe pas partout non plus.
Tes exemples tiennent plus a la culture d'entreprise ou a la dynamique d'entreprise qu'a l'outil lui même.
;
Dans mon expérience, j'ai vu des gens faire de l'agile en découpant le travail en taches minuscules et a passer plus de temps a gérer ces taches minuscules (en les passant de sprints en sprints et en les requalifiant sans cesse) qu'a faire son autre travail, tout ça dans des meeting super long avec plus de 5 personnes. Tout ça au nom de l'agile!! C'est ce que j'appelle la "bureaucratie agile" qui nous était vendu comme un consultant comme quelque chose d'agile. Si l'on en arrive la, c'est tout sauf agile pour moi. Ce n'est pas pour autant que je rejette les méthodes agiles en bloc.
Pour moi, le truc le plus important et de trouver une dynamique de travail qui permette d'avancer régulièrement et de communiquer ce que l'on fait sans alourdir le travail au jour le jour.
Avoir une personne qui joue uniquement le rôle de scrum master et qui ne fait rien d'autre parce que gérer le processus agile est trop chronophage, c'est exactement l'anti-agile pour moi. Cela fait partie de ce que j'appelle la bureaucratie agile. Il faut alléger un tel processus agile (!?!)
[^] # Re: Agile ?
Posté par or zax . Évalué à 1.
Je partage entièrement ton avis.
C'est très courant malheureusement, c'est le syndrome de la recette magique. Pour beaucoup il suffit de découper pour rendre les choses plus gérables .
J'aime beaucoup ta façon de voir les choses. Communication, élimination du gaspillage (parfois cela consiste à supprimer des boards à des gens qui n'en ont pas besoins …), et je rajouterai le progrès continue.
Je n'ai jamais dit qu'il ne devait faire rien d'autre. La double compétence est quelque chose que je trouve au contraire de limite vitale, mais c'est un goût personnel. L'agile n'a pas de processus, pourtant c'est ce que l'on constate dans beaucoup d'implémentation. Beaucoup d'entreprise se lance par exemple dans scrum alors que ce n'est pas forcément le plus indiqué, c'est une approche anti-agile de l'agilité.
Je pense que l'on a une vision très proche des choses, par contre j'ai un discours plus tranché sur les boards, il faut une équipe très expérimenté ou prendre des dispositions pour compenser l'aspect électronique (projection, écran géant etc …) sans que cela fasse partir ce qui est le but du board : rassembler pour qu'ils se parlent.
[^] # Re: Agile ?
Posté par djano . Évalué à 2.
Oui je pense que l'on n'est sur la même longueur d'onde sur les grands principes.
Et j'ai tendance a vouloir une équipe avec des gens super autonomes et super compétent.
Sûrement une déformation de ce qui est la "norme" selon mes standards.
[^] # Re: Agile ? Perte d'information et tâches à la truelle
Posté par or zax . Évalué à 1.
Il fait quoi ton Scrum Master ? C'est so rôle de fournir l'historisation de tout ça, et ça un wiki permet de le faire au top.
Le board est une vision instantanée.
Pour les tâches à la truelle même chose, le Scrum Master s'assure que l'équipe a a sa disposition des tâches claires et exploitable.
Maintenant si tu fais tout toi même, l'outil électronique est très bien, mais on est à ce moment dans un contexte très courant on dit faire de l'aile mais on en fait pas.
[^] # Re: Agile ? Perte d'information et tâches à la truelle
Posté par djano . Évalué à 2.
Pourquoi prétends tu que ça ne peut pas être agile?
Tu m'as l'air bien dogmatique, ce qui est un comble pour un agiliste.
[^] # Re: Agile ? Perte d'information et tâches à la truelle
Posté par or zax . Évalué à 0.
apprendre de l'expérience des autres n'est pas un dogme.
ressource AgileAlliance sur les task boards
[^] # Re: Agile ? Perte d'information et tâches à la truelle
Posté par djano . Évalué à 3.
C'est mieux avec des références!
Voici mon analyse des références:
dans le premier article, les problèmes décrivent des problèmes classiques d’implémentation d'un application (performances de l'application ou donner du feedback a l'utilisateur), et les autres problemes sont tous spécifiques a l’implémentation de leur board qui a l'air un peu boiteuse, et qui surtout n'a rien a voir avec les implémentations actuelles de board.
le second article mentionne qu'"utiliser un board electronique peut avoir de mauvaises conséquences sur les équipes qui ne gèrent pas bien la transition". C'est une phrase tellement generale que tu peux l'appliquer a tout ce que tu veux en remplaçant "board electronique" par "windows", "linux", "rasoir USB", etc.
En gros, ces deux articles ne remettent pas en cause les board electroniques selon moi. Et je maintiens que les membres de l'equipe sont plus important que n'importe quel outil ou processus.
[^] # Re: Agile ? Perte d'information et tâches à la truelle
Posté par or zax . Évalué à 1.
Le board électronique est ce que l'on appelle un "common pitfall" pour reprendre mot pour mot la référence.
Par contre il ne faut pas être dogmatique dans le sens où board électronique, c'est mon rêve mais genre un mur tactil …, il faut rassembler les gens.
Ou alors y'a pleins de cas ou l'agile ne sert à rien, car les ressources sont éparses etc … mais rien n'empêche à celui qui gère le produit d'utiliser des boards style agile, et en électronique çà aura bien plus de sens.
Mais rassembler des gens autour d'un écran … je trouve çà space, ou alors genre méga écran ….
Bref surtout, ne pas faire que les gens consulte le board depuis leurs postes, c'est dommage …
[^] # Re: Agile ? Perte d'information et tâches à la truelle
Posté par djano . Évalué à 3.
Aaaaaaahh! Je comprend mieux ta critique maintenant.
Oui nous utilisons des boards électroniques, mais nous nous réunissons tous autour d'un unique écran pour chaque sprint planning.
Nous ne faisons pas de sprint planning car l’équipe est suffisamment petite pour qu'on le fasse de manière informelle au jour le jour, parce que les membres de l’équipe sont très autonomes et parce que nos contraintes sont faibles de ce cote la.
Heureusement, la taille de l’écran a bcp grossie dernièrement :)
Oui en effet ce qui compte c'est que l’équipe communique. La notre communique très bien, et l'entraide et très présente donc tout va bien de ce cote la.
Je confirme, ce serait glauque si chacun restait devant son écran.
[^] # Re: Agile ? Perte d'information et tâches à la truelle
Posté par claudex . Évalué à 3.
Sinon, tu as parfois des salles de réunions avec des écrans très grand (genre télévision), c'est tout à fait possible de faire de l'électronique là-dessus. Sinon, tu as aussi les tableau blanc interractifs.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Agile ? Perte d'information et tâches à la truelle
Posté par vieuxshell (site web personnel) . Évalué à 0.
Je ne veux pas rentrer dans la polémique papier (ou tableau blanc) vs. digital.
En tant que dev. Tuleap, je peux juste dire que cet utilisation (tout le monde autour du cardwall numérique) est notre façon de travailler et promouvoir l'outil.
D'ailleurs, la partie Cardwall vient avec un mode plein écran ou l'on vire tout (header, footer, …) sauf les cartes afin de maximiser l'info visuelle pendant les stand-ups. Ce genre de truc ne sert à rien tout seul sur son poste.
Après, avoir un lien entre ta story et ton commit quand tu fais une revue de code, ou un git blame, c'est quand même bien pratique!
Au final, c'est plus pour le Product Owner que la digitalisation du backlog et de l'interface sont important AMHA
[^] # Re: Agile ? Perte d'information et tâches à la truelle
Posté par ariasuni . Évalué à 5.
J’ai pas trouvé de traduction valable pour standup.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Agile ? Perte d'information et tâches à la truelle
Posté par djano . Évalué à 2.
Un "restez debout" :)
[^] # Re: Agile ? Perte d'information et tâches à la truelle
Posté par ariasuni . Évalué à 2.
Pour le sens de «one-man-show», j’ai vu comme proposition de traduction «deboutée». Ça vous plait? :3
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Agile ? Perte d'information et tâches à la truelle
Posté par djano . Évalué à 2.
Excellent! :D
[^] # Re: Agile ? Perte d'information et tâches à la truelle
Posté par vieuxshell (site web personnel) . Évalué à 1.
Tu n'as pas traduit commit non plus, qu'est-ce à dire que ceci ?
Sinon le terme couramment usité pour daily stand-up en français est "mêlée quotidienne"
[^] # Re: Agile ? Perte d'information et tâches à la truelle
Posté par ariasuni . Évalué à 2.
Difficile de traduire commit, sachant qu'il est aussi utilisé pour les bases de données. D'ailleurs je ne sais pas quels les critères, mais il n'est pas indiqué comme anglicisme sur le Wikionnaire.
Écrit en Bépo selon l’orthographe de 1990
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.