Category Archives for "Delivery"

La théorie des contraintes : augmenter son rendement, diminuer son lead-time

Une belle théorie enveloppée dans un roman sympathique

Une lecture aussi enrichissante que distrayante

Réduire radicalement ses encours de développement et augmenter sa productivité pour un investissement minimum : telle est la promesse de la théorie des contraintes. Si l’on ajoute que cette méthode est simple et particulièrement compatible avec une approche agile dans une équipe logiciel, cela fait suffisamment de raisons pour la regarder d’un peu plus près.

La théorie des contraintes (ou ToC pour les habitués) ne date pas d’hier. A la manière du Lean, elle est née dans l’industrie il y a plus de 30 ans et n’a été importée dans le monde du développement que récemment, notamment à l’initiative de partisans de l’Agile. La bible des aficionados de la ToC s’appelle « le But », un roman d’entreprise remarquablement construit qui explique avec une clarté peu commune ses principes et sa mise en oeuvre. Son auteur, Eliahu Goldratt, a ensuite perfectionné son modèle et étendu cette approche au monde des services dans une douzaine d’ouvrages.

Continuer à lire

1

Kanban pour l’IT


Kanban pour l'ITSi la méthode Kanban – qui peut considérablement améliorer la performance d’une équipe – ne fait pas parti des cordes de votre arc. Je parle bien de la méthode Kanban à part entière et non pas uniquement du « tableau des tâches » kanban. Alors le livre « Kanban pour l’IT – Une nouvelle méthode pour améliorer les processus de développement » de Laurent Morisseau peut être une bonne option pour y remédier.

Bien que doté de quelques notions et expériences sur le sujet, ce livre m’a notamment transmis les principes fondamentaux permettant de mieux comprendre et mieux exploiter le Kanban. De quoi prendre conscience de la puissance de cette méthode à la fois en matière de conduite du changement (puisque le Kanban s’introduit sans rupture avec votre processus de travail existant, les rôles et activités. Y compris si vous fonctionnez en Cycle en V) et de performance car le Kanban peut véritablement permettre de donner à terme à votre équipe la précision d’une horloge Suisse.

Le coeur du livre décrit pas à pas la démarche de mise en oeuvre du Kanban. Avec une approche pédagogique qui mérite d’être soulignée. En effet, Laurent utilise un projet type (ou « Roman d’entreprise » pour reprendre le terme employé) permettant d’illustrer par l’exemple la mise en oeuvre des enseignements du livre. Il s’agit du cas d’une équipe Scrum décidant d’adopter le Kanban. Vous l’aurez compris, Scrum et Kanban ne sont pas incompatibles, bien au contraire.

 

1 8 conseils d'ami pour réussir son projet

Bonjour,

Aujourd’hui, je vous livre dans un document 8 CONSEILS POUR RÉUSSIR SON PROJET.

couv-8-conseils

Voici la Liste des conseils décrits en guise d’aperçu :
[list icon= »thumbs-up »] [list_item]Conseil N° 1 | Utiliser la loi de Pareto[/list_item] [list_item]Conseil N° 2 | Diviser pour mieux maîtriser[/list_item] [list_item]Conseil N° 3 | Se donner le droit à l’erreur[/list_item] [list_item]Conseil N° 4 | Se soucier des tests avant de développer[/list_item] [list_item]Conseil N° 5 | Être transparent et donner le volant au métier[/list_item] [list_item]Conseil N° 6 | Impliquer les utilisateurs[/list_item] [list_item]Conseil N° 7 | Utiliser une balle traçante[/list_item] [list_item]Conseil N° 8 | Trouver un visionnaire qui sait dire « non » ou « oui mais »[/list_item] [/list]

Pour télécharger gratuitement ce document, il vous suffit de vous abonner à la liste de diffusion de L’Agiliste (juste en dessous de ce paragraphe). Je vous rassure, je ne compte pas céder votre adresse à qui que ce soit ni saturer votre boite mail. En revanche votre avis m’intéresse car il me permet d’améliorer régulièrement ce site afin de le rendre le plus utile possible.

[animate animation= »pulse » delay= »0″ duration= »2s » iterations= »5″][button link= »http://www.agiliste.fr/abonnement/ » window= »false » color= »#018BD3″]Je veux recevoir les 8 conseils ![/button][/animate]

Amicalement
Florent

PS : Merci pour les messages d’encouragement des abonnés à la liste de diffusion qui ont reçu ce document avant sa diffusion officielle.

1 Le leadership serviteur n’est plus une option

[alert type= »info » show_close= »false »]Résumé en moins de 100 mots

Face à la complexité grandissante de nos projets, au besoin d’innovation par recours à l’intelligence collective, à celui de faire naître un véritable esprit d’équipe pour surmonter plus vite les obstacles rencontrés, le rôle de chef omniscient et omniprésent qui commande, contrôle et décide seul, atteint ses limites. Par ailleurs, les nouvelles générations semblent éprouver plus que jamais le besoin de savoir pourquoi elles travaillent, de sentir que leur avis compte. Autant de facteurs qui rendent le leaderhip serviteur (« servant leadership ») quasi incontournable.[/alert]

Mahatma Gandhi, grand leader indien.

Introduction

L’un des ingrédients clef de l’approche Agile est son mode de leadership. Le leader de l’équipe n’est pas la personne qui ordonne, contrôle et décide à la place de l’équipe. Au contraire, le leader Agile donne davantage de pouvoir à son équipe, met tout en oeuvre pour lever les obstacles qu’elle rencontre et la protège des perturbations extérieures. On parle donc de leadership serviteur. Dans cet article nous allons voir pourquoi ce mode de leadership n’est plus une option aujourd’hui.

Face à la complexité

Nos projets deviennent de plus en plus complexes tant du point de vue technique que du point de vue des besoins fonctionnels à couvrir. De nombreuses décisions difficiles et pourtant structurantes doivent être prises avant et pendant le projet. Le leader n’est plus en mesure d’être omniscient et omniprésent. Il doit donc déléguer une partie de son pouvoir à son équipe afin de rester concentré sur l’essentiel, comme lever les obstacles rencontrés par l’équipe et protéger cette dernière des perturbations extérieures afin de garantir qu’elle soit pleinement productive. Il doit également s’assurer que la méthodologie adoptée est correctement appliquée aussi bien côté technique que côté métier. Au besoin, il doit coacher les personnes qui nécessitent un accompagnement en enseignant par l’exemple.

Cette impuissance du leader seul face à la complexité est également le cas de nos figures politiques. Incapables de prendre les bonnes décisions seuls. Les défis environnementaux, économiques et sociaux nécessitent aujourd’hui des compétences qui dépassent largement celles de notre organe politique. Tout comme le leader Agile, il est nécessaire de donner davantage de pouvoir et d’autonomie à ceux qui sont au front, connaissent très précisément la situation et savent le plus souvent quoi faire. Cela nécessite donc de faire confiance.

« Si vous dites aux gens où aller, mais pas comment ils doivent y aller, vous serez impressionné par les résultats » – Général Georges Patton.

Intelligence collective et diversité

Donner à chaque membre de l’équipe le pouvoir d’exprimer son point de vue et influencer ainsi les décisions à prendre fait l’objet d’un excellent levier pour parvenir à la meilleure solution possible. La diversité de culture, d’expérience, de génération apporte une différence de point de vue permettant de voir les problèmes ou enjeux sous différents angles. La diversité est donc une richesse, un atout, elle est source d’innovation.

Esprit d’équipe

L’esprit d’équipe est fondamental pour surmonter plus vite et plus efficacement les difficultés. Là encore la complexité met de nombreux obstacles sur le chemin à parcourir. Cet esprit d’équipe est également nécessaire pour intégrer les nouvelles recrues et les accompagner dans leur montée en compétence et appropriation des principes et pratiques suivis par l’équipe. Dans le cadre d’un projet Agile, cet état d’esprit se cultive notamment à travers les mêlées quotidiennes, les rétrospectives et les travaux en binôme.

C’est pour cette raison que le recours au primes individuelles ou aux évaluations agrémentées d’une note (comme à l’école) sont à éviter. Ces pratiques ne font que fragiliser l’esprit d’équipe et par conséquent la réussite du projet. S’ouvrent alors d’autres possibilités d’évaluation telles que les évaluations par les pairs par exemple. Nous sommes invités à revoir les critères d’augmentation de grade et salaire souvent basés sur la note associée à la « performance » de l’individu. Pourquoi ne pas se concentrer sur l’avis des pairs et le degré d’expertise atteint (pour les profils « techniques ») ou de responsabilités acquises (pour les profils de « management »). Peut être devrions nous également revoir le terme « ressources humaines ». C’est frappant de constater à quel point un terme comportant le mot « humaines » peut véhiculer si peu d’humanité.

Enfin, l’esprit d’équipe annihile l’esprit de compétition, la rivalité entre les membres de l’équipe et augmente donc le plaisir au travail. Au contraire, la compétition limite l’innovation (« je garde pour moi ce qui me permet d’être meilleur que les autres ») et la productivité de l’équipe (« je n’aide pas mon voisin qui rencontre pourtant le même problème que j’ai surmonté hier »).

Plaisir au travail

La notion de plaisir au travail devient fondamentale. 8 heures ou plus par jour, 5 jours par semaine, sur plus de quarante ans de notre vie consacrés au travail (et aux transports en commun pour certains). Laissant si peu de place pour la vie personnelle. La nouvelle génération l’a compris et n’a pas l’intention de se sacrifier autant que les générations précédentes (même si la menace du chômage nous pousse à nous plier aux conditions de l’entreprise). Le plaisir au travail est donc capital pour soi, mais aussi pour l’entreprise qui peut perdre beaucoup en multipliant les transferts de compétences, les efforts de recrutement, les pertes de savoir faire, les arrêts maladie, le support technique sur des applications de mauvaise qualité car développées par des équipes démotivées ou sous pression, etc. Ce plaisir s’obtient généralement par l’épanouissement, qui lui même découle de l’expression de sa créativité, du développement personnel et de la participation aux décisions. Pour d’autres, une simple « bonne ambiance » suffit. Ce plaisir généré se retrouve dans le produit que l’organisation réalise ou dans le service qu’elle offre.

A l’occasion d’un recrutement, un élève terminant ses études m’a confié ceci : « Je ne cherche pas spécialement un emploi avec un super salaire et plein de responsabilités, ni même une promesse de carrière dans ce sens. Ce qui compte le plus pour moi, c’est de me sentir bien dans mon travail, avec du contact humain ».

Leader serviteur Vs Leader carpette

Il ne s’agit pas de basculer dans le chaos au sein duquel chacun y va de son point de vue et rien n’avance. Pour favoriser la convergence, l’équipe peut définir des valeurs fondamentales communes et sa mission. Si ces valeurs demeurent communes, la divergence de point de vue est alors une richesse permettant de faire de meilleurs choix au lieu faire tourner l’équipe en rond.

Le leader serviteur offre un cadre, des règles du jeu au sein duquel les membres de l’équipe (ou de la tribu à plus grande échelle) peuvent exprimer leur point de vue et participer aux décisions. La rétrospective est bien sûr un lieu d’expression et de décision tout comme la mêlée. Les décisions se prennent par consensus (tout le monde dit oui, ce qui est parfois difficile) ou par consentement (personne ne dit non). Lorsque le leader souhaite orienter l’équipe vers une autre direction, c’est à lui de convaincre comme les autres membres de l’équipe. Mais un leader qui applique les principes évoqués bénéficie d’un respect durable, la confiance est réciproque et l’équipe (ou tribu) se montre réceptive aux orientations proposées. C’est cette même confiance qui permet à un membre de l’équipe de révéler une difficulté qu’il rencontre plutôt que de la masquer (par peur des représailles), ce qui fait du leader serviteur un leader averti.

Leviers de motivation

En complément des principes évoqués plus haut, rappelons quelques leviers de motivation :

  • Donner du sens : Que nous l’exprimions ou pas, nous avons tous (ou presque) la même question en tête lorsque nous exécutons une tâche. D’autant plus si la demande associée vient de l’extérieur. Cette question est bien sûr « Pourquoi ? ». « Pourquoi dois je réaliser cette tâche ? ». Plus la réponse à cette question sera claire et en phase avec le porteur de la tâche, plus l’investissement de ce dernier et le résultat atteint seront grands.
  • Objectifs concrets, mesurables et atteignables à courts et longs termes : Une équipe a besoin d’un challenge positif auquel se mesurer. Celui ci s’obtient en fixant un ou des objectifs à long terme (donnant une vision, une perspective) mais également à court ou moyen terme permettant de se nourrir de petites victoires concrètes. Ces objectifs doivent être mesurables afin de rendre leur atteinte objective et non pas dépendante de l’opinion du leader ou du commanditaire.
  • Célébrer les petites victoires autant que les grandes : Les petites victoires sont aussi importantes que les grandes car elles nourrissent les efforts de l’équipe à long terme et contribuent à cultiver l’esprit d’équipe.
  • Rythme de travail soutenable : Participer à un projet est davantage comparable à une course de fond (type marathon) qu’à une épreuve du 100 m (même si le terme « Sprint » issu de Scrum est trompeur). La fatigue, ou pire encore, les sacrifices réalisés sur la qualité, peuvent sérieusement entamer la motivation d’une équipe. Nous devons donc promouvoir un rythme de travail soutenable en encourageant les membres de l’équipe à partir à l’heure le soir, à manger équilibré, à entretenir un sommeil de qualité. A cultiver une vie personnelle suffisamment riche pour ne plus penser au boulot (meilleure façon de porter un regard neuf sur son travail une fois de retour au boulot), à exercer une activité sportive. A rester concentré sur son travail de retour au boulot en désactivant les alertes email, tchat et sonneries de téléphone (en planifiant des pauses pour consulter ses messages et y répondre).
  • Choisir ses mots : En tant que leader ou manager, le choix des mots peut se révéler important. Chez les grandes entreprises, la tendance consiste à parler d’Industrialisation, d’Usines de développement, de Centres de services, etc. Les images véhiculées par ces termes ou d’autres peuvent se révéler néfastes auprès des équipes inquiètes de se retrouver cloisonnées, spécialisées et robotisées, que la menace soit réelle ou non. Encore une fois, le terme « Ressources Humaines » est également concerné, bien qu’universellement répandu.

Article connexe : « Introduction au leadership tribal ».

9

Instruments de pilotage de projet agile

L’offre de logiciels de gestion de projet Agile est aujourd’hui pléthorique. Difficile de ne pas céder à la tentation de tout outiller au risque de s’éloigner des valeurs Agile (« valoriser les individus et leurs interactions plus que les processus et les outils »).

Voici un outillage basique sous forme de deux documents Google Docs :

Il se veut simple et épuré avec les instruments de pilotage de projet agile Scrum courants. D’autres peuvent s’y ajouter. En principe, il suffit d’en faire une copie et c’est prêt à l’emploi.

Indicateurs de pilotage projet Agile

Article associé : Guide de démarrage Scrum

Les pièges de l'approche Agile

Bien qu’elles paraissent simples à mettre en oeuvre, tirer parti des méthodes Agiles n’est pas si évident. Voici une liste d’erreurs courantes à éviter.

[accordion sync= »true »] [accordion_item title= »Manifeste Agile mis de côté » open= »true »]

Le manifeste Agile contient l’essence de l’Agilité en termes de valeurs et principes. Lire ce manifeste et méditer dessus permet de mieux s’approprier l’approche Agile et de mieux la mettre en œuvre. Il est important de garder toujours à l’esprit son contenu. C’est l’application de ce manifeste qui permet de tirer l’ensemble des bénéfices d’une telle approche.

[/accordion_item] [accordion_item title= »Mauvaise base contractuelle »]

La contractualisation est souvent considérée comme un obstacle à une démarche Agile. En particulier de la cadre d’un contrat client/fournisseur au forfait fixant délais, budget et périmètre. Les méthodes Agile doivent cependant apporter une réponse aux attentes légitimes d’un client. A savoir le respect d’un budget et d’une date d’obtention pour un produit demandé. Plusieurs solutions existent, du forfait classique moyennant un principe de troc (voir retour d’expérience) à la régie, en passant par la forfaitisation de chaque itération. D’autres solutions plus créatives proposent des montages contractuels « win-win ». Quoiqu’il en soit, sans une base contractuelle saine il est difficile d’apporter la souplesse que peut attendre un client.

[/accordion_item] [accordion_item title= »Trop d’attentes vis-à-vis de Scrum »]

Scrum est de toute évidence la méthode Agile la plus utilisée. Cependant, elle ne propose pas grand chose en matière de conception et de développement. Se contenter de Scrum ne suffit pas, il faut également s’intéresser aux autres méthodes telles que XP. Par ailleurs, il est important de rappeler – même si les choses sont en train de changer – que la certification de ScrumMaster ne certifie pas grand-chose. Elle ne certifie en rien la capacité de mise en œuvre, ni même la bonne compréhension de la méthode Scrum par le certifié.

[/accordion_item] [accordion_item title= »Communication trop restreinte »]

Les vieilles habitudes sont souvent tenaces. La chute du mur séparant le métier et le technique (MOA et MOE) est nécessaire dans le cadre d’une approche Agile. Conserver les vieux réflexes (communication par email, équipes isolées géographiquement, mode guichet,…) peut coûter très cher. La conversation face à face est à privilégier dans la mesure du possible et du raisonnable.

[/accordion_item] [accordion_item title= »Négligence de la rigueur »]

Faire son marché dans les méthodes Agiles en retenant les pratiques fun et simples à mettre en œuvre au détriment des pratiques qui nécessitent une certaine discipline est une tentation assez grande. Or la rigueur fait partie intégrante des méthodes Agile, que ce soit de la part des développeurs (Tests, refactoring, simplicité, intégration continue, préparation des démonstrations face au client,…) ou de la part du garant du respect du processus Agile et de ses règles.

[/accordion_item] [accordion_item title= »Rythme insoutenable »]

Une équipe respectée (confiance), impliquée, émancipée (à travers plus de responsabilisation) et soumise à un rythme de travail soutenable offrira le meilleur d’elle-même en matière de productivité. A l’inverse, un rythme insoutenable (sous pression) engendre généralement une dégradation de la qualité et de la productivité à long terme.

[/accordion_item] [accordion_item title= »Conservation des vieilles habitudes »]

Nous résistons tous naturellement au changement, parfois même inconsciemment. Il faut prendre conscience de nos vieux réflexes à mettre de côté tels que le cloisonnement MOA/MOE, le fait de coller au plan initial plutôt que s’adapter, le fait de penser « contrat »,…

[/accordion_item] [accordion_item title= »Membres de l’équipe trop spécialisés »]

Dans la mesure du possible, les membres de l’équipe ou au moins certains d’entre eux doivent être capable de travailler sur plusieurs fonctionnalités différentes. Cette approche relève ni plus ni moins d’une gestion des risques. En cas d’arrêt maladie conjugué à un bug critique en production ou à l’intégration d’une fonctionnalité importante, le risque de criticité est couvert. De plus 2 cerveaux compétents ou plus sur un domaine valent mieux qu’un pour concevoir une solution ou investiguer un problème. Cette multi compétence peut notamment s’acquérir par l’utilisation du « pair programming », de la relecture de code ou encore par un système de rotation. L’objectif étant d’atteindre la notion de « propriété collective du code ».

[/accordion_item] [/accordion]

Outils de gestion de projet

Ces dernières années nous assistons à une explosion de l’outillage en matière de gestion de projet de développement. Que ce soit en terme d’outils techniques (intégration continue par exemple) ou d’outils collaboratifs de gestion de projet. On assiste même à une normalisation du cycle de vie d’un projet avec le principe d’ALM (Application Lifecycle Management).

Il est difficile d’établir un comparatif exhaustif étant donné la quantité d’outils sur le marché, je n’ai donc pas creusé les outils de type client lourd ainsi que les outils « hors de prix » qui riment souvent avec lourdeur d’utilisation. Ce comparatif intéressera donc principalement les projets à taille humaine nécessitant un outil relativement facile à mettre en place, et à utiliser.

Les besoins

  • D’un projet à un autre nos besoins différent peu, nous avons besoin :
  • D’organiser le travail par un découpage en exigences puis tâches
  • De planifier le travail dans le temps
  • De suivre l’avancement des développements
  • De dessiner un beau graphique d’avancement du projet pour le client
  • De tracer les demandes de changement et évaluer leurs impacts
  • D’organiser et dérouler les plans de test
  • De suivre les anomalies
  • De partager les informations clefs du projet (calendrier, annuaire, raccourcis vers les différents environnements, consignes,…)

ALM (Application Lifecycle Management)

Définition

« Désigne l’ensemble des disciplines qui conduisent à l’aboutissement d’une application : gestion des exigences, modélisation, développement, tests, gestion de configuration, gestion du changement. Plus qu’une simple collection d’outils, la gestion du cycle de vie orchestre les différents processus du développement. Dans une vision étendue à l’entreprise, l’ALM prend en compte les gestions du portefeuille de projets, de l’assurance qualité et de la performance des applications. »

Voici le résultat plutôt instructif sur le retard de la France en terme d’adoption du principe d’ALM :

Etes vous familier avec la gestion du cycle de vie des applications ?

Enquête ALM

Enquête menée en mars 2008 sur 1 017 entreprises.

Les outils ALM

Etant donné la quantité de fonctionnalités à couvrir lorsque qu’on s’attaque à l’ALM dans son ensemble, il est difficile d’éviter les grands éditeurs tels que IBM, Borland ou SERENA. Il existe cependant quelques alternatives « raisonnables » en termes de coût.

Team Foundation Server (Microsoft)

Team Foundation Server (TFS) est un outil ALM qui jouit d’une bonne réputation. La gestion des exigences ne semble cependant pas être sa force.
Il peut donc être complété par un outil spécialisé tel que Caliber de Borland.


Pour TFS, il faut compter environ 8 000 € pour une équipe de 10 personnes sur 1 an.

Polarion ALM

Polarion ALM est un outil Open Source payant. En tant qu’outil ALM, il couvre par définition l’ensemble du cycle de vie du projet soit l’ensemble des besoins cités plus haut. Le côté « tout en un » est séduisant, limitant ainsi les coûts de mise en oeuvre et de maintenance. Programmé en J2EE, il peut être personnalisé par un bon développeur au besoin. Mais est ce vraiment nécessaire tellement cet outil semble complet et flexible ? Il repose essentiellement sur le gestionnaire de version SVN aussi bien pour le code source que pour les exigences (sauf erreur de ma part). Il propose également un accompagnement CMMI sous forme d’indicateurs.

Polarion a sorti une version Track+Wiki à moins de 700$ pour 10 licences nominatives. Sachant qu’à cela on peut éventuellement ajouter une licence Enterprise pour un chef de projet par exemple, histoire de bénéficier de l’ensemble des fonctionnalités (reporting, planning,suivi d’activité,…) pour 2 000 € de plus. Pour des licences flottantes évidement les prix montent (par exemple, on passe de 2 000 à 5 000 € pour une licence Enterprise).

Qui dit « outil ALM » dit « écran chargé » mais il parait que ça ne doit pas faire peur.

Les outils Agiles

L’agilité apporte une bonne contribution à l’outillage. L’un des atouts majeurs des outils agiles du marché consiste en un accompagnement méthodologique. Car chacun sait qu’un outil ne suffit pas à garantir la réussite d’un projet. L’autre avantage que peut présenter le choix d’un outil Agile et la légèreté native (simple et intuitif) de ce dernier, je rappelle que l’une des valeurs Agile est « Personnes et interaction plutôt que processus et outils ».

Pour ceux qui souhaitent faire des économies au risque de faire des concessions sur les conditions de support en cas de problème, il existe quelques logiciels pas mal du tout comme IceScrum.

ScrumWorks

Danube propose deux versions de ScrumWorks, une version limitée appelée Basic et une version complète payante appelée Pro. Pour la version payante pour une équipe de 10 personnes sur un an, il faut compter 2 050 €. A ce prix là, j’ai presque envie de dire : « pourquoi s’en priver ? » mais tout dépend du coût du projet bien évidemment. ScrumWorks ne couvre cependant pas les besoins suivants : organisation et déroulement des plans de test, suivi des anomalies, wiki (centralisation des informations du projet).

Rally

Rally est une offre assez séduisante sur le papier (à vérifier à l’usage). Il se présente sous forme de SAAS, autrement dit aucun coût d’infrastructure n’est nécessaire puisque vous n’hébergez pas l’outil chez vous ou chez votre client. Rally s’engage bien sûr à garantir performance et confidentialité. Si nécessaire, il peut cependant être vendu dans sa version d’installation sur site, les tarifs diffèrent sans doute dans ce cas de figure. En offre SAAS, il faut compter environ 2 500 € pour une équipe de 10 personnes pour un an. La licence se paye au mois, ce qui offre une grande souplesse en cas de turn over d’équipe.

La couverture en terme de fonctionnalités est trés large et les possibilités d’intégration avec d’autres outils sont relativement nombreuses (Gestionnaires de version, de plan de test, outils d’intégration continue,…). Une version Community gratuite mais limitée permet de se faire une bonne idée de l’outil.

Un autre avantage avec Rally est l’accompagnement méthodologique Agile. Rally est particulièrement actif dans la communautés Agile : livres blancs, séminaires, articles, etc.

Mingle

Je n’ai pas encore creusé Mingle, il semble plus intuitif que Scrumworks pour un prix également plus élevé.

JIRA + GreenHopper

Une solution assez intéressante également consiste à associer JIRA à son plugin GreenHopper (Plugin de gestion de projet Agile).
Cette solution est intéressante dans la mesure où – pour une entreprise – il n’y a pas de limite d’utilisateurs en terme de licence. Elle peut donc présenter un coût élevé à l’achat mais pour un nombre d’utilisateurs illimité ainsi qu’une utilisation illimitée dans le temps. Il faut compter environ 5 000 €. JIRA sait gérer plusieurs projets à la fois. Les tarifs descendent vite dans les versions plus limitées jusqu’à la gratuité pour les communautés Open Source en passant par la moitié prix pour les établissements d’enseignement.

Pour en savoir plus