Tosca est un outil en ligne pour gérer les appels et les demandes de ses clients. Il est tout à fait indiqué dans le cadre d'une Tierce Maintenance, d'un suivi personnalisé ou quand votre messagerie électronique déborde sur plusieurs niveaux.
Il est utilisé en production depuis sa naissance par l'Open Source Software Assurance, qui a guidé son développement. Il permet de gérer des tickets/demandes, des engagements, des temps de réponses, des logiciels, des périmètres, etc.
Il a été développé avec et pour des logiciels libres. Ce qui veut dire, entre autres, que l'on peut créer et suivre un reversement sur un logiciel libre. Tosca intègre une gestion complète de ce processus et permet ainsi de savoir quelles contributions ont été réalisées et dans quel contexte. Depuis quelques mois, il est utilisé par plusieurs équipes réparties sur le territoire. L'outil s'est industrialisé en conséquence et dispose désormais de fonctionnalités facilitant tant le travail d'un membre d'une équipe que celui d'un responsable ou celui des commerciaux.
C'est un outil de 7.000 lignes de code réalisé en Ruby On Rails. Il intègre de nombreux effets AJAX, mais la plupart restent très discrets. Il utilise de nombreux greffons connus de l'univers RoR et dispose de son propre système de greffons. Certaines fonctionnalités ne sont ainsi accessibles qu'en les installant, ce qui a permis d'adapter les dépendances requises selon les besoins. Ce système de plugin est assez intéressant et peu commun dans les applications open source utilisant cette technologie.
La population cible de cet outil est constituée essentiellement de ceux qui ne font pas ou n'aiment pas l'informatique. Il a donc été adapté en conséquence, parfois en tranchant dans le vif des fonctionnalités, pour être d'une simplicité extrême.
Pour preuve, aucun de ses utilisateurs n'a jamais demandé comment s'en servir ! (NdM : traduire par "vous êtes invités à contribuer à la documentation utilisateur qui reste à rédiger sur le wiki ?)
Aller plus loin
- TOSCA (237 clics)
- Démonstration (274 clics)
- Statistiques du projet (16 clics)
- Open Source Software Assurance (24 clics)
- Les reversements (11 clics)
# Intéressant
Posté par paul . Évalué à 2.
Une question cependant : je vois que le tracker de développement est RedMine, donc vous connaissez ce dernier. Tosca est-il si différent de RedMine pour nécessiter un développement complet ? Ne pouvait-il pas être développé pour étendre RedMine ?
[^] # Re: Intéressant
Posté par Coren . Évalué à 5.
Comme dit dans la dépêche : "Tosca est un outil en ligne pour gérer les appels et les demandes de ses clients."
Ce n'est pas vraiment un bugtracker et encore moins un outil de développement. C'est un outil de production. RedMine est un outil pour développer un logiciel. Tosca est un outil pour l'assurer, une fois qu'il est fini.
Ce sont des problématiques et des points de vue très différents. On peut citer par exemple la confidentialité : cette notion ou chacun est isolé dans l'univers qui le concerne.
De la même manière, on n'envisage pas de le relier à des gestionnaires de version (cvs,svn,etc) mais plutot à des dépots debs ou rpms.
Dans un bugtracker, le projet est mis au coeur du système. Dans Tosca, c'est le client qui est au coeur du système.
Nous utilisions par le passé un bugtracker pour faire ce métier d'assurance logiciel libre (mantis), et ça ne convenait pas du tout à notre besoin. Tout le monde s'y perdait, et c'était impossible d'envisager de signer avec 50 clients.
Maintenant, peut-être qu'un jour on trouvera le moyen de réunir ces différents univers dans un seul et même outil. Mais c'est loin d'être simple, et ils sont beaucoup plus éloignés qu'on pourrait le croire intuitivement.
L'un de nos concurrents cité plus bas, OTRS, fait exactement la même chose. Ils utilisent bugzilla assurer le développement et ils s'utilisent pour assurer la production.
[^] # Re: Intéressant
Posté par Bozo_le_clown . Évalué à 3.
Merci pour ces précisions.
Dans ce cas ne faudrait-t'il pas modifier votre page d'accueil car ca prête à confusion ?
What is Tosca ?
Tosca is an Open Source bugtracker. It is designed to be user friendly, professional and multi-projects. It is made with Ruby on Rails.
[^] # Re: Intéressant
Posté par Coren . Évalué à 2.
[^] # Re: Intéressant
Posté par Bozo_le_clown . Évalué à 2.
issue tracking system
http://en.wikipedia.org/wiki/Ticket_tracking
et un
bug tracking sytem
http://en.wikipedia.org/wiki/Bug_tracking_system
Une question à ce propos:
Votre outil permet t'il de s'intégrer avec des outils de bugtracking de de gestion des changements.Sinon , est-ce que c'est prévu ?
Lorsqu'un client ouvre un ticket dans votre outil, il faut pouvoir l'associer avec une ou plusieurs demande de changements (bugtracker) sur différents projets qui seront à leur tour associés à un ou plusieurs changements sur le depôt (version control system) de chaque projet.
Il est important de conserver la tracabilité entre ces divers outils pour faire remonter au client la prise en compte de sa demande.
Comment se positionne votre outil par rapport à ce workflow ?
Englobe t'il la partie bug tracking ou se content t'il seulement de la partie gestion des tickets ?
[^] # Re: Intéressant
Posté par Coren . Évalué à 2.
On a un développeur bugzilla dans nos locaux qui est aussi intéressé.
Pour l'instant, elle n'existe pas. Les demandes peuvent être liées à un ou plusieurs bugtrackers communautaires par le système de contributions, mais c'est bien pauvre comparé à ce que l'on pourrait faire.
Surtout que, contrairement à launchpad qui résoud le problème en centralisant le tout chez lui, nous pensons plutôt à une version décentralisée, avec des liens maintenus, de la surveillance d'évènements, ce genre de choses. Ça nous semble plus coller au fonctionnement actuel des projets libres.
Mais c'est carrément plus délicat à mettre en place, ce n'est pas une fonctionnalité qui marchera du feu de dieu avant quelque temps.
[^] # Re: Intéressant
Posté par Beretta_Vexee . Évalué à 2.
J'ai un peut l'impression que ça peut être génial comme module pour ERP, mais que un soft a part peut vite devenir une horreur a gérer par la suite si la structure grandie et se retrouve avec deux systèmes en parallèle.
[^] # Re: Intéressant
Posté par Coren . Évalué à 2.
Pour l'instant, on a utilisé cet outil sur des logiciels ou des offres que nous ne développons pas nous même. On les a intégré, amélioré, configuré, adapté, reversé, etc, etc, mais on ne les a pas forké. Le logiciel continue dans son coin, sur ses outils propres, et donc ce problème de doublon ne s'est pas posé.
Sur les logiciels que nous développons nous même, comme OBM ( http://www.obm.org ), la question ne s'est pas non plus posée.
Il faut bien voir que ce sont 2 systèmes bien différents. Ce ne sont pas les bugs déposés par les clients qui guident le développement d'un projet mais bien son équipe. Par ailleurs, la plupart des demandes concernent une façon d'utiliser le logiciel ou l'influence de son contexte.
Peut-être que vous avez raison dans d'autres contextes ou d'autres utilisations, mais pour nous, ce n'est vraiment pas une "horreur à gérer" et bien plus un "raaaaaah qu'est-ce que c'est cool de pouvoir y passer si peu de temps".
Les commerciaux adorent être prévenus des dates de renouvellement.
Les ingénieurs adorent le fait de ne voir que les x contrats sur lesquels ils travaillent, ils nous l'ont signalé tout de suite quand la fonctionnalité a régressé sur le serveur de test ;).
Enfin, les manageurs peuvent connaître en un seul écran le flux total de leurs contrats.
Et rien n'empêche de mettre la référence de l'un dans l'autre, si les 2 outils sont utilisés. C'est ce que fait le projet OpenOffice.org avec leur traqueur BugZilla et leur outil EIS. C'est vraiment un développement minime, et que d'ailleurs nous utilisons pour lier les contributions des anciennes demandes à notre ancien mantis.
[^] # Re: Intéressant
Posté par Beretta_Vexee . Évalué à 2.
Répartir des taches, faire les relations client, contrat, tache, personnel affecté, etc.. c'est un peut le genre de chose que doit faciliter un ERP. Pourquoi avoir développer un soft depuis rien, plutôt que l'adaptation d'un module de tickets pour qu'il colle a vos besoin spécifiques sur un ERP. N'est ce pas risqué si un jour vous comptez justement utiliser un tel soft, puisqu'il faudra faire une jonction ERP, Tosca?
[^] # Re: Intéressant
Posté par Coren . Évalué à 2.
Vous semblez avoir une meilleure expérience, ceci dit ;).
Par ailleurs, Tosca utilisant Ruby On Rails, il parle nativement le R.E.S.T. et (le) faire communiquer avec d'autres applications sera assez simple (comparativement à ce qu'il aurait fallu faire avec SOAP, XML-RPC & Co). Il est d'ailleurs question devant certaines machines à café bien placées de le relier à OBM, pour pouvoir facturer directement depuis Tosca.
Enfin, j'ai du mal à voir en quoi utiliser un outil adapté est risqué. Si un jour on doit migrer, il y a de très bons ETL qui nous permettront de le faire. Et si on doit faire une jonction, ma foi, elle ne devrait pas être trop différente de celle avec les bugtrackers communautaire.
On a développé cet outil from scratch car aucun de ceux que nous avons consulté ne répondait à nos attentes. Il y a 2 ans et demi, OTRS n'en était pas où il était. Et même maintenant, sa vision n'est pas assez complète pour répondre à nos attentes. La dé-corrélation entre les différentes interfaces peut aussi poser de nombreux problèmes.
[^] # Re: Intéressant
Posté par Philippe F (site web personnel) . Évalué à 2.
(Sinon, super que vous soyez présents pour répondre à nos questions, ,c'est vraiment agréable).
[^] # Re: Intéressant
Posté par Coren . Évalué à 2.
On s'inspirera probablement de RedMine, qui l'implémente déjà de façon très complète.
[^] # Re: Intéressant
Posté par paul . Évalué à 1.
Que je sache, le seul bugtracker existant qui a fait cette intégration correctement est celui de debian.
# Différences avec OTRS ?
Posté par nojhan (site web personnel, Mastodon) . Évalué à 1.
Quels sont les principales différences entre ces deux logiciels ?
[^] # Re: Différences avec OTRS ?
Posté par Coren . Évalué à 3.
Dans ce qui va pour OTRS :
* Tosca n'a pas de workflow paramètrable
* Tosca ne supporte pas la réception d'emails
* Tosca ne fonctionne qu'avec MySQL
* Tosca n'a pas de jouli calendrier En fait si, depuis quelques heures, Tosca a un très joli calendrier dans ses outils d'administration !
Évidemment, on compte bien combler ces lacunes, RoR intègre nativement le nécessaire pour y répondre.
Dans ce qui va pour Tosca :
* OTRS n'utilise pas de framework de développement, ce qui pose plein de problèmes pour les questions d'évolution énoncées dans les commentaires précédents.
* OTRS n'a pas de système de plugin, il est donc plus difficile de l'adapter à ses besoins. Et encore plus difficile de conserver ses adaptations lors d'une montée de version. Un exemple d'actualité très flagrant est la migration d'un bugzilla modifié.
* OTRS semble assez pauvre en reporting : pas de camemberts, pas de barre de progressions, pas d'alertes sur des CNS en cours de dépassement
* OTRS semble dur à utiliser au quotidien : pas de vue comme celle des "demandes à traiter", qui permet instantanément de savoir ce que l'on a faire au quotidien. Tous les commentaires sont affichés lors de la consultation d'une demande : une hérésie totale quand on en est à notre 9ème commentaire de la journée.
* OTRS n'a pas des notions comme le périmètre d'un client (ses logiciels), les compétences des intervenants, les vms utilisées pour ce client, la gestion d'étiquette pour regrouper un paquet de demandes ou la notion de crédit-temps, lorsque l'on facture un client au compte-goutte.
* OTRS n'a pas d'AJAX : il n'y a pas de champs dynamique, d'adaptation du logiciel au profil de l'utilisateur ou de petits effets. En conséquence, son interface peut paraitre surchargée.
Pour voir les autres concurrents, libre ou non, wikipedia est là :
http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_sy(...)
[^] # Re: Différences avec OTRS ?
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
* OTRS n'a pas d'AJAX : il n'y a pas de champs dynamique, d'adaptation du logiciel au profil de l'utilisateur ou de petits effets. En conséquence, son interface peut paraitre surchargée.C'est faux depuis la 2.3.1 :
« Reduced reloads by using AJAX technology. »
# Différences avec RT
Posté par Raphaël SurcouF (site web personnel) . Évalué à 3.
[^] # Re: Différences avec RT
Posté par naif . Évalué à 1.
Elle est intéressante aussi cette question sur RT.
Est-ce que ce produit est né d'une réaction NIH ?
On dirait en tout cas...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.