Reprise du message précédent :

 
 
bon point
Donc Confluence  puis Export ^^

Question bête : y'a t-il un réel avantage à utiliser Confluence et Jira par rapport à des produits libres et gratuits comme Mediawiki, Mantis et subversion (par ex) ?
 
Je pose la question car je n'ai jamais utilisé ces outils.

 
+1
Du coup, on est tous d'accord que la méthode Agile ne sert pas à grand chose et peut même être contre productive pour par exemple des développeurs dont l'activité consiste principalement à développer des ptits outils (max 5/6 jours de dév en général) pour un service donné (trading, assurance, etc...)?
Et encore plus dans une équipe où chacun a des projets totalement différents à la fois techniquement et d'un point de vue métier (parceque j'ai connu des chefs de service vantant le mérite des daily dans ce cadre pour permettre d'avoir plus de back up sur les taches de chacun....genre des daily de 15min peuvent permettre ca )

Pas du tout, je dirais même le contraire : une méthode agile ou tu affines ton programme au retour des tests de tes utilisateurs, c'est efficace. Un petit daily (ou j'en suis & ou je veux en arriver aujourd'hui), un sprint de 2/3 semaines, avec un sprint planning pour voir qui fait quoi (c'est toujours utile de pas bosser siloté) [mais bon, les sprints ça marche bien que si ceux qui préparent les use cases font leur boulot] et si on ne charge pas une équipe au delà de ses capacités et surtout, une retro en fin de dev pour tirer les leçons de ce qui a été fait (ce qui a marché, ce qui est a améliorer, ce qu'il ne faut plus faire).
Bref toute les 2/3 semaines 1 a 2h de sprint planning + 1h de retro + 10/15mn de daily quotidien, c'est une charge d'organisation tout a fait acceptable.
Par contre, ça suppose d'avoir en sus des devs des PO/PPO qui font correctement leur boulot (et c'est souvent là que ça coince dans une organisation agile : projet insuffisamment préparé en amont). J'ai connu ça et ça fonctionne bien (et on remonte une organisation agile actuellement dans mon équipe, après un abandon temporaire suite a une valse des haut managers).
Par contre, surtout éviter de rentrer dans un système SAFE avec ses multiples rôles et réunions, sinon on se choppe plus de taches administratives et organisationnelles que de temps de dev (j'ai connu aussi ça)
Grosso modo, par expérience si on t'organise, un daily ou tout le monde doit parler à tour de rôle, ton organisation agile est mal barrée, car ça dénote à la base un manque d'agilité de ceux qui l'organisent. Si par contre n'y parlent que ceux qui ont des choses a dire (et pas plus de 3mn chacun) c'est bon signe. Et une dizaine de devs au grand maximum par équipe agile (8 est assez optimal), au delà ça devient ingérable (réunions trop longues et dispersées). Plutôt qu'une équipe de 12, deux de 6 ça marche mieux (les organisateurs pouvant piloter les deux).
A+,

Ben oui, parce qu'il y a toute couche d'intégration.
Confluence + Jira + BitBucket (+ Jenkins + Teams) ça tourne très bien ensemble. Par contre, ça peut être assez coton à paramétrer, en particulier Jira (on peut très facilement fabriquer un truc lourd et pas efficace avec. C'est vraiment le truc le plus coton de l'ensemble, et ça demande un admin assez expérimenté pour bien le configurer en faire quelque chose d'efficace).
Bon, je connais pas Mantis. Mais si bien utilisé, Jira permet de bien bosser avec la méthodologie agile par exemple. Donc ça se limite pas au bug tracking, mais a la mise en places des taches et leur suivi. Et subversion, euh... je suis pleinement satisfait par git.
 
A+,
 

C'est marrant de lire ça 15 ans après, depuis j'ai fait de l'agile, et pas qu'un peu.
J'y ai connu le pire SAFe ou toute l'agilité est diluée dans des réunions et une organisation complexe (bref de l'agilité qui plait à un management obsédé par le contrôle de ses équipes) et le meilleur, de l'agilité à la Scrum, qui fait de gros gains de qualité (et donc de productivité, grâce au temps économisé en corrections itérées).
Mais bon, si on veut de l'agilité efficace, il faut se (ré)organiser en fonction, et c'est pas toujours un effort que les boîtes sont prêtes à faire, surtout si l'info n'est pas leur cœur de métier.
Pour moi l'agilité consiste en
- du découpage [en amont] de taches en sous-taches petites, estimables, testables individuellement (et achevables)
- du focus sur une ou deux taches en parallèles pour un dev
- du dialogue avec ses testeurs/utilisateurs pour vérifier que ce qui est fait répond aux besoins
- de la visibilité sur ce qui est à faire et l'état des devs (sprint planning, daily)
- de l'amélioration continue en tenant compte de l'expérience acquise (rétro de sprint) [ce dernier point est fondamental pour moi. Si il y a pas d'amélioration continue, il y a pas d'agilité]
( - et je dirais aussi, de la non-imposition d'un planning externe de livraison. Il y a une semaine encore, j'ai eu une réunion technique de planification qui a démarré avec "On doit le tester en prod le 12", je leur ai immédiatement dit "Ça va pas être possible avant l'année prochaine, c'est moi qui vais vous dire quand ça pourra être testable, au vu de nos estimations de coût en temps et des possibilités de notre planning". Si il y a pas cette latitude d'organisation, ça aboutit a des sprints de stakhanovistes et a une réalisation de mauvaise qualité qui au final sera plus couteuse vu le temps perdu en maintenance)
A+,

Je préfère la méthode à Robert, elle est mieux, c'est plus rapide et plus efficace.
La méthode à Gilles c'est reloud, Gilles n'est jamais là

Bonjour,

Dans ma boîte on a opté pour ProjeQtOr, qui gagnerait à être plus connu je pense.

L'avantage c'est que c'est un outil complet de gestion de projet aussi bien administratif que pilotage et suivi des dev.
Manque qu'un couplage avec un outil de vesionning tel que git ou avec Teams, même si on s'en passe très bien.

C'est gratuit et français.
https://www.projeqtor.org/fr/

Après, l'outil n'est pas "axé" AGILE : c'est pas l'outil qui fait la méthode projet.
Par contre il permet de très facilement découper les projets en tâches simples, et propose un certain nombre de fonctionalités dites "AGILE" : Kanban, réunion Poker, etc.

Chez nous il s'adapte très bien à nos différents domaines d'activité (R&D où on est plutot full AGILE, mode "projet" de quelques jours à 24 mois et TMA - ticketing, petites évolutions -).
L'un des gros avantages c'est que tout est dans le même outil, y compris la sacro sainte saisie des temps, ce qui permet en temps réel de voir quelles parties du planning doivent être révues, ainsi que le staffing des équipes sans forcément devoirr polluer les daily avec ce genre de problématiques : on a déjà l'info)

Vous pensez quoi des PI Planning ?
 
Perso ça fait plusieurs fois que je dis à ma hiérarchie que ça ne sert à pas grand chose pour plusieurs raisons :
.bcp de temps pour le préparer
.des PM qui en cours de sprint vont te dire qu'il y a une nouvelle US super importante et qu'il faut la prioriser pour hier
.parfois cette US super importante "qui doit être livrée pour le 15/08/xxxx" et donc tu as fait en sorte de libérer de la CAF, mais au 15/08/xxxx t'as toujours pas les US dans JIRA
.que ça coûte un paquet de CAF les 2 jours de PI Planning
.que les "jeux" de cohésion, ça fait un peu école primaire

2 j de PI Planning ? Si c'est une fois tous les 4/6 mois, et que toute les parties impliquées sont présentes, ça peut être assez efficace, et nécessaire. J'ai fait cela sur un gros projet ou l'agilité est arrivée en cours de route, les 2 dernières années.
Ça demande la présence de toute les équipes et pas mal de boulot en amont en effet, mais c'est un des points de coordination inter-équipes nécessaire (et inviter des représentants des utilisateurs finaux leurs donne du feedback sur les priorités choisies, les points critiques, les problématiques etc)
A+,