j'utilise Redmine pour nos projets interne IT, avec une utilisation essentiellement des tickets, wiki (quelques projets sont liés avec du code sous git). On ne s'amuse pas (encore) à faire tout ce qui est suivi d'activité/gestion du temps.
L'administration et utilisation c'est quand même bien pratique, la création de projets se fait très facilement, la syntaxe wiki est simple, le suivi d'activité suffisamment lisible.
A l'usage, autant sur les gros projets ça fonctionne bien, autant j'ai du mal sur les petits trucs de sysadmin du quotidien (correction d'un script, upgrade d'un service). Faut dire on a GLPI & Shinken pour tout ce qui est gestion incidents, des fois ça peut faire doublon (double système de tickets). Après il faut surtout s'y tenir pour que ce soit vraiment parlant (beaucoup d'actions ne sont pas logguées, ce qui peut fausser les stats).
Dernier point ou il faut faire attention, c'est justement la facilité de création de sous-projets... à force de trop en mettre on s'en sort plus. Chaque sous-projet à son wiki/gestionnaire de version, et donc si y a de la doc qui concernent plusieurs projets, il peut y avoir redondance d'infos, bref on s'y retrouve plus trop.
[^] # Re: Suivi de l'activité de quoi ?
Posté par Re_ . En réponse au message Mise en oeuvre de redmine pour le suivi d'activité. Évalué à 1.
Salut,
j'utilise Redmine pour nos projets interne IT, avec une utilisation essentiellement des tickets, wiki (quelques projets sont liés avec du code sous git). On ne s'amuse pas (encore) à faire tout ce qui est suivi d'activité/gestion du temps.
L'administration et utilisation c'est quand même bien pratique, la création de projets se fait très facilement, la syntaxe wiki est simple, le suivi d'activité suffisamment lisible.
A l'usage, autant sur les gros projets ça fonctionne bien, autant j'ai du mal sur les petits trucs de sysadmin du quotidien (correction d'un script, upgrade d'un service). Faut dire on a GLPI & Shinken pour tout ce qui est gestion incidents, des fois ça peut faire doublon (double système de tickets). Après il faut surtout s'y tenir pour que ce soit vraiment parlant (beaucoup d'actions ne sont pas logguées, ce qui peut fausser les stats).
Dernier point ou il faut faire attention, c'est justement la facilité de création de sous-projets... à force de trop en mettre on s'en sort plus. Chaque sous-projet à son wiki/gestionnaire de version, et donc si y a de la doc qui concernent plusieurs projets, il peut y avoir redondance d'infos, bref on s'y retrouve plus trop.