Tuleap, un outil de choix pour développer Ring

En novembre dernier, dans le cadre du «Paris Open Source Summit», nos développeurs de Ring ont rencontré l’équipe d’Enalean, qui développe l’outil open source Tuleap, utilisé pour le développement de Ring. Voici en quelques paragraphes notre discussion à bâtons rompus avec Manon Midy, membre de l’équipe Tuleap.

Je m’appelle Guillaume Roguez, directeur technique du projet Ring, au siège montréalais de Savoir-faire Linux, une entreprise fournissant des solutions en systèmes d’informations, spécialisée dans le déploiement, la personnalisation, l’intégration et l’élaboration de stratégies pour l’implantation des meilleurs outils et projets en logiciels libres et open source, afin de répondre aux besoins de nos clients. Notre objectif est d’être le premier acteur des technologies développées, étendues, supportées ou connectées par les logiciels libres et open source. Pour y parvenir, nous nous devons d’être sans cesse créatifs, innovateurs et garder notre acuité en matière de Recherche et Développement. Ring est l’un de nos projets maison en R&D.

Rapidement, Ring est un logiciel de communication libre, distribué et universel, disponible sous la licence GNU GPL v3. Les utilisateurs de Ring peuvent communiquer de différentes façons, en l’utilisant comme un téléphone (VoIP), un outil de partage de médias (audio et vidéo), une messagerie, ou encore comme un socle de communication pour les objets connectés. Ring peut être alors vu comme une alternative libre et open source à Skype.

En tant que responsable du développement, je gère tous les aspects du projet Ring et je coordonne les tâches imparties à chaque membre de l’équipe. Par ailleurs, je vais à la rencontre des contributeurs en faisant des présentations publiques dans les universités de Montréal (Polytechnique, Université du Québec à Montréal, McGill University, École de Technologie Supérieure etc.). Ring est aussi un objet de recherche, un laboratoire permanent pour les étudiants de maîtrise à Montréal. Ils ont eu la possibilité de parfaire leurs habilités en programmation tout en contribuant au développement de Ring (le programme Google Summer of Code en est un exemple probant). En fait, aux yeux de Savoir-faire Linux, il est important de travailler avec des enseignants-chercheurs et leurs étudiants pour étendre la communauté autour du projet.

Pour continuer, je voudrais profiter de cet article pour parler brièvement de l’environnement technique – Tuleap- sur lequel nous avons choisi de nous reposer. Tout simplement, Tuleap est la plateforme de développement de projet logiciel que je recommande. Il facilite notre travail collaboratif, il nous fait gagner énormément de temps et il nous aide dans la gestion de nos activités quotidiennes.

De Redmine à Tuleap, défis et d’opportunités

Au début du projet Ring, nous utilisions la plateforme Redmine, commune à tous les projets chez Savoir-faire Linux. Toutefois, au fur et à mesure de son utilisation, nous nous sommes rendus compte que nous faisions fausse route. Redmine a une conception assez rigide, qui ne peut permettre aux utilisateurs d’adapter facilement les champs de suivi pour des usages spécifiques. D’une manière générale, Redmine est assez limité et restrictif. Par exemple, faire des modifications dans le système de suivi requiert plusieurs manipulations. Une fois terminées, on ne peut pas facilement revenir en arrière. Or, j’ai toujours voulu quelque chose de plus souple pour mon équipe.

À mes yeux, GitHub est trop simplifié, et plusieurs fonctionnalités manquent à l’appel. Cet outil, est, encore une fois, trop rigide. Cependant, du point de vue du design, c’est alléchant, mais c’est trop cher pour des projets à long terme. C’est peut-être le bon outil pour des projets de petite et moyenne taille. Néanmoins le design restrictif de GitHub limite la marge de manœuvre d’une équipe travaillant sous un mode Agile. Si on doit adapter notre manière de travailler à l’outil, ce n’est pas la bonne option pour nous.
Avec Tuleap c’est différent. L’outil est bien plus souple tout en permettant de guider les utilisateurs avec un flux de travail défini. Par exemple, si on utilise Git dans Tuleap, il y a la possibilité d’imposer une procédure de développement de façon à ce que les développeurs respectent des étapes importantes et apprennent les bonnes pratiques. Par exemple, nous pouvons imposer aux messages de transaction (Commit messages) de contenir une référence aux incidents soumis dans Tuleap. Ainsi, on peut avoir une vue d’ensemble du cycle de vie du développement et suivre précisément les anomalies. Certains peuvent y voir une limitation, mais en réalité, cette possibilité permet aux membres de l’équipe d’ajuster leurs efforts dans la bonne direction et respecter l’esprit du projet. Tuleap n’est pas un outil fermé sur lui-même. Bien au contraire, grâce au design qui le sous-tend – acceptant beaucoup de greffons – cet outil donne à l’équipe de développement la possibilité d’interagir avec d’autres logiciels bien connus comme Jenkins et Gerrit.

Les avantages étaient clairs dès le départ pour Jérôme Ouffela, notre directeur technique. Il a proposé l’adoption de Tuleap, après avoir exposé ses raisons. Honnêtement, quand on cherche à changer fondamentalement les méthodes de travail d’une équipe, il faut s’attendre à quelques frictions. Mais, au regard de nos expériences passées, le niveau de flexibilité des collaborateurs augmente lentement mais sûrement, en suivant la courbe d’apprentissage. Il y a toujours un prix à payer pour un quelconque changement.

Parmi les autres défis auxquels nous avons du faire face, il y a eu la question d’une documentation manquante. Cet accroc a laissé quelques traces, comme la difficulté de mettre en place des procédures de suivis et la lenteur des réparations de bogues subséquente. Fort heureusement, l’équipe de développement de Tuleap a vite répondu à nos difficultés. Ils nous ont aidés à configurer un outil sur mesure et ainsi bénéficier d’une flexibilité nous permettant d’ajouter et/ou changer nos mesures de suivi. Tuleap a cette particularité : évoluer de manière qualitative avec le projet de l’utilisateur. Plus nous utilisions sa flexibilité et sa capacité d’évoluer, plus cela nous a conforté dans notre choix à l ‘égard de Tuleap.

Enfin, le dernier élément décisif et non des moindres, Tuleap est un outil open source porté par une communauté de développeurs très dynamique et riche. Par exemple, Tuleap a sorti au début du mois de janvier une nouvelle version 9.3, jetant les premières bases du nouveau langage de requêtes du système de suivi. Les développeurs pourront ainsi faire des recherches avancées dans les procédures de suivi de Tuleap, intégrant les caractères « AND », « OR » and « () ». Nous pourrons être en mesure d’obtenir tous les tickets correspondant à des requêtes complexes du type (summary = “tracker” OR summary = “query”) AND submission = “language”.

A mon avis, une visite sur le site de Tuleap vaut le détour :
a) pour ses tutoriels faciles à comprendre , qu’ils sont en vidéo ou en texte tout simplement,
b) pour l’accès à une somme importante d’informations sur les nouvelles fonctionnalités et les bogues réparés et clairement identifiables et
c) pour discuter avec la communauté Tuleap, et ainsi entamer une conversation très technique.

Tuleap, une utilisation Agile

Pour développer le logiciel Ring, nous suivons la méthodologie Agile. En utilisant l’environnement de planification Scrum de Tuleap, nous pouvons ainsi suivre nos versions actuelles et à venir et avoir un œil sur les bogues, les améliorations, le wiki et les forums de manière efficace. Et nous l’avons associé au système de revue de codes pour gérer les correctifs.

Au jour le jour, il y a une dizaine de développeurs de Savoir-faire Linux qui utilisent Tuleap pour développer Ring. J’en fais partie, avec plusieurs chapeaux, directeur technique du projet, développeur, Scrum master. À cette équipe s’ajoutent des développeurs motivés, d’autres membres de la communauté comme ceux maintenant la plateforme, les utilisateurs, les abonnés etc. Tout ce beau monde réparti sur la planète s’aide pour contribuer à ce projet innovant communautaire qu’est Ring.


Des nouveautés prometteuses

Si nous pouvions changer quelque chose sur Tuleap,  il s’agirait peut-être de l’interface utilisateur (UI). Actuellement, pour réaliser ce qui est programmé, il y a beaucoup trop de clics à faire. De plus, cette interface (UI) est assez complexe. Aux dires de Manon, l’équipe réfléchit déjà à une refonte complète. Ce qui est une bonne nouvelle pour nous. Si l’on se fie aux dernières versions et les mises-à-jour (9.2 et 9.3 ) cela semble être le cas. Nous croyons que Tuleap est un projet très prometteur pour des générations de développeurs à venir.

Priorités et tolérance aux risques dans votre projet de développement

Chaque projet, chaque client est différent. Ce qui est important pour l’un l’est moins pour l’autre et c’est normal. Par ailleurs, le développement logiciel est une science expérimentale, donc inexacte, et chaque décision prise en cours de développement aura une incidence sur toute la durée de vie du logiciel. Pour comprendre votre réalité, donc, et répondre le mieux possible à vos besoins, vos développeurs doivent connaitre vos priorités.

visuel-priorites-tolerance-risques-01

Un conseiller financier s’enquiert généralement du niveau de tolérance aux risques du marché financier d’un client avant de lui proposer un placement. De la même manière, nous devons évaluer votre niveau de tolérance face à certains risques avant de réaliser votre projet logiciel. Il serait beaucoup plus couteux, en temps et en argent, de s’apercevoir à la toute fin que l’on avait omis de prendre en compte un détail important au départ. Par exemple, si l’on pense à optimiser le référencement de notre site seulement après son lancement, cela pourra s’avérer long et très couteux car il faudra probablement modifier le processus de création des pages ainsi que leur contenu.

Voyons cela plus en détails.

Leviers communs à tous les projets de développement

visuel-priorites-tolerance-risques-02

Voici, dans ce petit schéma, une partie des leviers qui permettent d’évaluer clairement notre tolérance au risque. Ils sont communs à tous les projets de développement (ou presque). Certains mentionnent également la qualité en tant que levier, mais comme celle-ci est difficilement mesurable et que diminuer la qualité a un impact considérable à moyen et à long terme, je préfère ne pas la proposer comme levier.

Portée (scope)

La portée d’un projet de développement logiciel, c’est l’ensemble des demandes formulées. Lorsque cet élément est tout en haut de la liste, toutes les demandes doivent être exécutées, même si ça implique des délais supplémentaires et des dépassements de coûts.

Budget (du projet en entier)

Le budget d’un projet de développement, c’est l’argent que l’on devra lui consacrer. Lorsque cet élément est tout en haut de la liste, il est primordial de ne pas dépasser le budget, quitte à laisser tomber quelques demandes au passage.

Budget (d’une demande en particulier)

L’évaluation d’une demande peut se faire de trois façons. Il y a l’évaluation optimiste : « Si tout va bien, ceci va nous prendre une journée. » Il y a, à l’inverse, l’évaluation pessimiste : « Même si l’on tombe sur plein d’embuches, on aura certainement terminé au bout de cinq jours. » Et il y a, enfin, l’évaluation moyenne : « Ceci devrait nous prendre environ deux jours. » Le temps de développement, par contre, ne changera pas, quelle que soit l’option d’évaluation utilisée, mais le risque de dépassement de coût sera très différent.

Délai

Le délai d’un projet de développement, c’est le temps qui s’écoule entre la demande initiale et le « produit fini ». On peut parfois diminuer le délai proposé par votre consultant, mais pas toujours — et il y a toujours un impact sur le budget et/ou la portée du projet.

Documentation exhaustive

La documentation est créée en même temps que le code est écrit. Plus on porte d’importance à la documentation, plus le délai et le budget augmentent.

Leviers spécifiques à certains types de projets

Je travaille principalement avec des projets web, et c’est donc ceux-ci que je connais le mieux. Voyez avec votre consultant les différents items spécifiques à votre type de projet. En ce qui me concerne, il s’agit généralement de ceux-ci :

visuel-priorites-tolerance-risques-03

Apparence

Vous « voyez » ce que je veux dire, n’est-ce pas? Rien n’intéressera plus nos designers que de réaliser pour vous un site ou une application web devant lesquels on fait « WOW! » et qu’on aime regarder.

Utilisabilité

C’est tout ce qui relève de l’expérience utilisateur. Au-delà de l’apparence, ceux-ci préfèrent les sites ou les applications qu’ils aiment utiliser, qui ont une interface intuitive, des parcours bien balisés, etc.

Accessibilité

Il existe de plus en plus de normes d’accessibilité. Si vous êtes une entreprise publique ou une grande entreprise publique disposant de bureaux au Québec ou en Ontario, par exemple, vous vous devez de respecter les standards d’accessibilité en vigueur dans ces provinces. Cela inclut tout ce qui touche l’utilisation de votre site ou de votre application par des gens avec un handicap visuel (dont le daltonisme), auditif, moteur, voire même cognitif.

Facilité d’administration des contenus et fonctionnalités

Souvent, lorsqu’on crée un site web, on s’appuie sur un système de gestion de contenus (CMS), ou bien l’on y insère des zones éditables dans lesquelles les administrateurs du site peuvent créer et man*.ipuler des contenus. Cette facilité d’utilisation a cependant parfois un coût en complexité de développement.

Référencement du site

C’est tout ce qui peut affecter notre score dans les moteurs de recherche, ce qui fait en sorte qu’on arrive sur la première page lorsqu’on fait une recherche sur Google, Bing ou autre.

Exprimer ses priorités et sa tolérance au risque

Maintenant que nous avons passé en revue tous ces paramètres, vous comprenez certainement qu’une bonne façon de s’assurer que le projet soit un succès résultant d’un processus agréable consiste à clarifier vos attentes sur chacun de ces aspects. Votre consultant est là pour vous aider à dresser votre liste de priorités, vous conseiller et vous aiguiller. Si nous croyons que vos priorités ne sont pas réalistes compte tenu de vos contraintes, nous vous proposerons des options permettant d’ajuster les différentes variables afin de vous permettre d’atteindre vos réelles priorités.

Pourquoi et comment établir un processus de design web?

Processus de design dans le cadre de projet web adaptatif

Depuis l’agrandissement du bureau Savoir-faire Linux de Québec subséquent au rachat de L3interactive, une entreprise spécialisée dans le développement web en logiciel libre, l’équipe design et, plus largement, frontend travaille et améliore son processus de design.

Ce processus est souvent passé en revue et amélioré en fonction des post-mortem ou des simples observations consignées au fil du déroulement des projets.

Pourquoi établir un processus de design?

Les raisons sont multiples mais, principalement, cela nous permet d’optimiser le déroulement du travail au cours d’un projet et de contrôler la qualité du produit livré. Les étapes de création deviennent aussi très claires pour le client.

Un processus peut-être considéré comme une feuille de route théorique des étapes et des bonnes pratiques à suivre, dotée d’une certaine flexibilité en fonction des équipes, du projet ou du client.

Le processus en détails

Pour chaque projet nous adoptons la méthodologie agile, ce qui permet principalement de voir le projet se monter au fur à mesure des itérations et de le réorienter au besoin. Chaque étape de ce processus est de plus soumise à une assurance qualité du visuel et des fonctionnalités garantissant la conformité et la qualité de nos livrables.

Processus de design - Site web responsive - Savoir-faire Linux

1. Recherche et définition

Recherche et définition en début de projet web

Un premier rendez-vous est nécessaire pour apprendre à se connaître, pour nous assurer que nous comprenons le secteur d’activité et la nature de l’entreprise cliente. Nous abordons entre autres les motifs de la refonte, les objectifs à atteindre, les cibles visées et les appareils à supporter.

Dès cette première réunion, nous établissons les protocoles de communication, les étapes, les livrables, les échéanciers, les rôles et les attentes.

Les informations utiles sont retranscrites dans la documentation.

2. Documentation

Documentation projet web

Véritable bible, le document de référence est mis à jour dès le début du mandat et jusqu’à la fin des maquettes filaires. Il permet d’expliquer, d’annoter tout ce qui est nécessaire à la bonne compréhension du projet. Chaque intervenant, chez Savoir-faire Linux comme chez le client, est ainsi à même de bien comprendre le projet. L’arborescence des sites est intégrée au document.

Exemple de documentation

3. Les maquettes filaires (wireframes)

Exemple de wireframe

Une fois que nous avons tous les éléments en main, des premières maquettes filaires (ou wireframes) cliquables sont produits. Afin de réduire le coût, nous ne produisons que celles qui sont nécessaires à la couverture de l’ensemble des besoins. Elles sont déclinés dans les deux résolutions extrêmes (ordinateur de bureau et mobile).

Même si le projet comporte la portabilité sur tablette, en règle générale, nous ne nous attaquons à celle-ci qu’à partir du prototype. Le projet ayant déjà été pensé aux deux résolutions extrêmes, nous réutiliserons alors les comportements conçu soit pour le mobile, soit pour l’ordinateur de bureau.

Exemple de maquette filaire

4. Le prototype

Exemple de prototypage rapide

Cette étape permet de projeter rapidement les wirefames et d’être sûr que tout fonctionne bien. Le prototype est un bon outil pour vérifier les hypothèses établies en phase de wireframe. Plus tôt l’on se rendra compte des ajustements à faire, moins cela aura d’impact sur le projet en termes de calendrier ou de budget.

Exemple de prototype html

Exemple de prototypage rapide (animation de jpeg) target= »_blank »

5. Les maquettes graphiques

Exemple de maquette graphiques

En accord avec la charte graphique de l’entreprise ou selon la direction que celle-ci souhaite donner à son projet web, nous développons des maquettes graphiques pour ordinateur et mobile. Toutes les maquettes filaires ne sont pas forcément déclinés. Le but consiste à couvrir les gabarits nécessaires de façon à donner une projection cohérente du futur site web. Souvent, au lieu de faire une page, nous extrayons ses composants que nous designons directement dans une page UI, composée de tous les éléments nécessaires du site web.

Exemple de maquettes graphiques

6. Le guide de style

guide-de-style

La création d’un guide de style est une pratique plutôt émergente mais nécessaire, surtout dans le cadre d’un projet adaptatif ou d’un site comportant beaucoup de contenu. Ce guide rassemble une collection de règles ou de composants définissant les conventions de style à utiliser pour le projet. En général, on retrouve les éléments de la page UI, mais de façon interactive. Cette étape est faite par un intégrateur graphique, qui retranscrit les éléments des maquettes en code pouvant être interprété par les navigateurs. On cherche ainsi à réduire le coût tout en augmentant la qualité. Le client pourra par ailleurs réutiliser ce document pour d’autres projets.

Guide de styles

7. L’intégration graphique

intégration graphique

Nous finalisons l’intégration graphique en repartant du prototype développé et y intégrant les éléments du guide de style, en commençant par la version mobile afin d’optimiser ses performances. Nous faisons en sorte que tout le contenu soit régi par la feuille de style (CSS), que son intégration soit conforme aux normes du W3C ainsi qu’aux principes d’accessibilité. Le respect de ces standards à notamment un impact positif sur le référencement.

Site web de la SSQ

8. Lancement

La récompense de tant d’efforts est arrivée. Nous avons pour coutume de dire que la mise en ligne n’est pas la fin d’un site internet, mais au contraire, son commencement. En effet, un site web est une matière vivante qui nécessite une entretien régulier afin d’être toujours à son meilleur.

Exemples de réalisation