Ouverture de Tosca

Posté par . Modéré par Nÿco.
Tags :
11
25
sept.
2008
Ruby
Après 2 ans de développement interne, le code de Tosca est rendu disponible sur un serveur public, sources incluses, en licence GPLv2+.

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 ?)
  • # Intéressant

    Posté par . Évalué à 2.

    Un nouveau bugtracker libre, c'est très bien.
    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 . Évalué à 5.

      C'est une bonne question.

      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 . Évalué à 3.

        Ce n'est pas vraiment un bugtracker

        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 . Évalué à 2.

          Effectivement. C'est corrigé.
          • [^] # Re: Intéressant

            Posté par . Évalué à 2.

            Vraiment mieux surtout avec le lien vers Wikipedia qui permet de comprendre la différence entre un
            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 . Évalué à 2.

              C'est la fonctionnalité majeure à laquelle nous pensons depuis longtemps. Elle est dans toutes nos présentations, dans la page "Perspectives", juste avant la conclusion.

              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 . Évalué à 2.

              J'ai un peut le même genre de question. Quel est l'avantage par rapport au gestionnaire de ticket du premier ERP venue ?

              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 . Évalué à 2.

                Ne connaissant pas trop les ERP, ma réponse risque de ne pas convenir.

                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 . Évalué à 2.

                  La question était plus dans le sens:
                  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 . Évalué à 2.

                    Je n'ai pas connaissance d'ERP libre digne de ce nom. Par ailleurs, les quelques clients qui m'ont parlé de leur ERP étaient tous d'accord sur un point : c'est une horreur dont ils aimeraient pouvoir s'extirper.
                    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 (page perso) . Évalué à 2.

        Un des gros atouts de ORTS qui m'a attiré est de gérer tout le processus par mail. Comment se place votre logiciel par rapport à cela ?

        (Sinon, super que vous soyez présents pour répondre à nos questions, ,c'est vraiment agréable).
        • [^] # Re: Intéressant

          Posté par . Évalué à 2.

          On ne peut pas gérer le processus par mail. Ça fait partie de la roadmap.

          On s'inspirera probablement de RedMine, qui l'implémente déjà de façon très complète.
          • [^] # Re: Intéressant

            Posté par . Évalué à 1.

            Si je peux me permettre une suggestion, je pense qu'il vaut mieux articuler votre outil autour d'une véritable mailing-list que de faire l'inverse. Redmine fait actuellement l'inverse, c'est à dire qu'il s'efforce de reproduire le comportement d'une mailing-list en renvoyant par email à des "abonnés" les contributions etc. Du coup tout ce qui caractérise les ML est à ré-implémenter.
            Que je sache, le seul bugtracker existant qui a fait cette intégration correctement est celui de debian.
  • # Différences avec OTRS ?

    Posté par (page perso) . Évalué à 1.

    En lisant comme ça vite fait, j'ai l'impression que Tosca a des point communs avec OTRS → http://otrs.org

    Quels sont les principales différences entre ces deux logiciels ?
    • [^] # Re: Différences avec OTRS ?

      Posté par . Évalué à 3.

      Il y en a beaucoup, je vais essayer de rester succinct.

      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 (page perso) . É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 (page perso) . Évalué à 3.

    Puisqu'on parle d'OTRS, quelles sont les différences de Tosca par rapport à RT ?
    • [^] # Re: Différences avec RT

      Posté par . Évalué à 1.

      Ben y'a plus personne ?
      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 à ceux qui les ont postés. Nous n'en sommes pas responsables.