Lorsque je commence un projet ou réponds à un appel d’offres, la lecture du cahier des charges est une **activité à récompense variable**. Trop léger, je crains que le client ne se lance tête baissée dans un projet aux contours flous ; trop rempli, je crains que la description du besoin soit figée.

Dans les deux cas, le **format écrit peut donner lieu à des interprétations différentes** et apporter plus de questions que de réponses. La communication finit par ressembler à une partie géante de Gartic phone, le jeu favori des Troopers pendant le Covid.

Cet écart est la raison pour laquelle je propose systématiquement de commencer la phase de cadrage par la **création d’une story map**.














## Qu’est-ce qu’une story map?
**Une story map est tout simplement la carte des besoins utilisateurs**. C’est aussi le livrable de l’atelier de story mapping qui est une méthode de description des besoins utilisateurs **de manière visuelle, chronologique et priorisée**. Concrètement la story map est un tableau géant de post-it qui permet de comprendre d’un coup d'œil ce que fait un utilisateur dans l’outil qu’elle décrit.

## Comment faire une story map ?
La **story map ressemble à une pièce de théâtre** : 
- les personnages sont appelés personas ;
- ils vivent des aventures que l’on appelle des récits utilisateurs ;
- ces récits sont regroupés dans des chapitres, appelés epics ;

Les chapitres ou récits ont lieu dans des décors, vous l’avez deviné ce sont les interfaces du logiciel et elles ne sont pas visibles en tant que tel dans la story map.

Prenons une pièce de théâtre dont vous êtes le héros quotidien : se préparer le matin.  Voici les epics :
- se lever ; 
- se laver ;
- s’habiller ;
- manger.   

Les récits utilisateurs possibles pour “se lever” sont :
- éteindre son réveil ;
- faire son lit ;
- ouvrir les volets ;
- faire quelques étirements.

## Avantages du story mapping
### Aligner les participants d’un projet sur une vision
Lors des ateliers de story mapping que j’ai pu animer, j’ai toujours constaté qu’il y avait plusieurs livrables. Le premier est bien sûr la story map, mais le second est plus surprenant.

Lorsque plusieurs personnes se mobilisent quelques heures pour imaginer leur futur outil, cela fait émerger toutes les **incompréhensions et angles morts du début de projet**. Mieux vaut que ces discussions aient lieu le plus tôt possible, et surtout avant la livraison ! Le format de l’atelier aide beaucoup et facilite les arbitrages avec la phase de priorisation.

Le choix des participants est donc primordial et c’est pour cela que j’insiste toujours pour faire venir de futurs utilisateurs, ou des personnes a priori non concernées comme le personnel administratif de l’entreprise.




### Communiquer facilement sur un projet complexe 
Le second avantage d’une story map est sa lisibilité. Le format de rédaction d’un récit utilisateur est compréhensible et exprime à la fois la solution et le besoin. 
- En tant que Troopers, je mange un fruit afin d’avoir de l’énergie.

Exemple plus réaliste : 
- En tant que comptable, j’exporte la facture afin de la partager au client.

Alors qu’un cahier des charges se lit, **une story map se consulte et se discute**. Cette discussion fait émerger de nouveaux post-it qui viennent alimenter la story map.

Au contraire, dans un cahier des charges, des synonymes ou des formulations peuvent créer des incompréhensions qui se révéleront désastreuses pour le projet. Cette phrase résume bien ma pensée : “Il nous arrive de considérer que tout ce que nous écrivons est clair et limpide. C’est parfois vrai et souvent faux.*”

### Prioriser son projet avec le story mapping
Lors de la création de la story map, différentes solutions émergent pour un même besoin. Pour reprendre l’exemple de votre début de journée, pour l’epic “manger” certains vont passer une demi-heure à table tandis que d’autres se contentent d’un fruit. Mais si vous savez déjà que vous êtes en retard pour aller au travail, vous allez sûrement vous contenter d'un ~~pain au chocolat~~ fruit !

L’option “fruit” devient une V1 (version 1) et “petit-déjeuner complet” une V2. Le petit déjeuner V2 sera possible une fois que la V1 est sécurisée et s’il reste du temps après que toutes les autres epics de la V1 soient finies.

Nous utilisons la même logique pour créer un logiciel : prioriser la **version qui répond au besoin en prenant le moins de temps possible**. Une fois que cette priorisation a eu lieu vient l’estimation. L’une des **grandes lois du développement logiciel** est “qu'il y a toujours plus à créer qu'il n'y a de personnes disponibles, de temps et d'argent à y consacrer.” Je fais donc estimer par l’équipe de développement la V1 de la story map.

Une fois le résultat obtenu, je sais si le budget est suffisant pour livrer toute la V1, si c’est le cas alors certains récits ou epics  relégués en V2 pourront être conçus.

### Et l’éco-conception dans tout ça ?

Le story mapping est un très bon allié pour réduire l'impact environnemental de son projet. Le référentiel général d’écoconception des services numériques (RGESN) préconise en effet de :
- définir les cibles utilisatrices (critère 1.2) ;
- leurs besoins et attentes réelles (1.3) ;
- et d’optimiser leurs parcours (4.4).

Pas de problème ! La conception d'une story map nécessite toutes ces actions, notamment l’optimisation du parcours utilisateur, pour lequel on livre une V1 avant d’ajouter des fonctionnalités de confort.

## Inconvénients du story mapping
### La story map et les sujets techniques
Parfois, un système ou une fonctionnalité doit être créée sans qu’elle n’ait aucune interface utilisateur. C’est le cas d’un algorithme de rapprochement de candidats et d’offres d’emploi ou un mécanisme de génération de commandes.

Dans ces cas-là, je trouve que la story map est plus difficile à manier. Je finis généralement par créer un post-it recensant le fonctionnement complet. La réalité est que **l'approche agile trouve ses limites dans ce cas**. Un système qui n’est codé que sur la base de besoins exprimés manque un peu de vision. Il faut aller plus loin **en anticipant tous les cas possibles et en s’inspirant de solutions existantes**.

### Estimation et budget
La story map est en revanche **plus dure à estimer aussi finement qu’un cahier des charges** car la description des besoins est moins fine. Les récits utilisateurs sont en effet complètement décrits au fur et à mesure du projet alors que dans un cahier des charges le fonctionnement est figé avant le début du développement.

Faut-il faire un cahier des charges ou une story map ? Pour une **prestation au forfait**, elle garde sa pertinence pour aligner les parties prenantes, éviter les découvertes en cours de projet et faciliter le suivi du développement. Pour les **produits gérés en agilité**, j’organise des ateliers d’Extreme Quotation pour obtenir des estimations et répartir l’effort sur le planning.

Si une story map est simple à comprendre, en créer une demande un peu d’expérience et je conseille de faire appel à une personne expérimentée pour l’animer. Cet atelier fait souvent émerger des **visions contradictoires** et un facilitateur externe aidera à **faire de cet atelier une pierre fondatrice du produit**.

*Culture produit, Octo, Samuel Retière - Xaviera Meyer Bosque - Benoit Ricaud

Comment prioriser son projet avec une story map ?

**Vous éditez un site ou rédigez du contenu que vous publiez dans WordPress, Drupal etc ? Avez-vous déjà copié-collé du contenu d’un outil à l’autre faute d’une solution unique pour communiquer vers tous les supports ? Ou désinstallé un plugin car il avait cassé votre site ?**


Si oui, vous avez sans doute besoin d’un CMS headless. Chez Troopers, nous développons des sites appuyés sur un [CMS headless](https://troopers.agency/expertises/cms-headless) pour aider les chargés de communication, content managers et autres rédacteurs de toutes sortes à se concentrer sur le contenu. Pourquoi ? C’est principalement [pour des raisons techniques](https://slash.troopers.agency/article/notre-comparatif-des-cms-headless) que nous avons fait ce choix, mais un CMS headless présente aussi des avantages pour les éditeurs de contenu.

L’un de mes arguments en faveur du headless (qui frise l’anti-vente) est qu’un CMS headless fait moins de choses qu’un CMS classique. 

**_Avec un CMS classique, vous voyez ceci :_**

**_Avec un CMS headless, vous voyez cela :_**

Il y a de bonnes chances que vous n’ayez pas besoin d’un CMS headless si :
- une seule personne gère votre site ;
- c’est votre premier site Web ou vous démarrez l’activité pour le financer ;
- vous devez faire un site très simple comme un site vitrine.

**En revanche vous avez besoin d’un CMS headless si :**
- différents profils (techniques ou non) s’occupent de votre site ;
- vous gérez de grandes quantités de contenu comme un site corporate ;
- vous devez vous connecter de manière personnalisée à d’autres services (moteur de recherche, solution e-commerce).



## Quels avantages au CMS headless pour les éditeurs de contenu ?

Si vous n’êtes pas à l’origine du choix d’un tel CMS en tant qu’éditeur de contenu, vous êtes en première ligne pour l’utilisation. Il y a trois avantages principaux, vous pouvez :
1.  composer des pages sur-mesure ;
2.  gérer tous vos contenus au même endroit avec une logique de multi-diffusion ;
3.  ne pas (trop) vous préoccuper des questions techniques.

Détaillons ces points en profondeur à la première personne car c’est vous le héros !

### 1. Composer des pages sur-mesure

Dans l’interface du CMS, **je choisis le type de page** que je souhaite créer (landing page, produit, article, etc.) et remplis le gabarit (ou template) préparé par les développeurs. Comme dans un CMS classique, **j’insère des images et mets en forme mon contenu avant publication.**

Je peux **insérer à la carte de nouveaux blocs de contenus** : un bouton, un formulaire, un encadré, une citation, etc. C’est ce qu’on appelle couramment un “page builder”, c’est-à-dire un constructeur de pages. À chaque fois les informations SEO de mes pages (par exemple la balise “alt” d’une image) sont éditables dans la même interface. 




### 2. Avoir toutes les infos au même endroit

Le deuxième effet bénéfique est qu’un CMS headless est un peu comme un guichet unique : **puisque tout mon contenu se trouve au même endroit, je peux le réutiliser pour différents canaux de communication**. Ainsi, une newsletter pourra être assemblée sur la base d’autres contenus présents dans le CMS sans les saisir une seconde fois. C’est aussi vrai pour les différents sites sur lesquels vous contribuez. Les CMS headless se configurent plus facilement pour **gérer plusieurs sites** (comme un site vitrine et son blog), **le multilingue et le multisite**. Chez Troopers, nous gérons notre blog et notre site depuis la même interface.

Nous avons le cas d’un client organisateur d’un salon qui doit copier-coller plusieurs champs sur la centaine d'évènements saisis dans son outil de gestion vers un WordPress pour simplement publier en ligne le programme de l'événement. Comme vous l’avez compris, dès que nous aurons passé ce client sur un CMS headless, cette corvée n’existera plus ! Son équipe pourra gérer les évènements et mettre le site à jour sans dupliquer le contenu.


### 3. Ne pas (trop) se préoccuper des questions techniques

Ah cette sensation d’avoir “cassé le site”… souvent suivi d’une dépublication dans l’urgence en perdant son contenu. **Avec un CMS headless, le site ~~n’est jamais~~ est rarement cassé et le contenu n’est jamais perdu car il est stocké dans une base de données s-é-p-a-r-é-e du reste du site.**

**Finis aussi les cocktails exotiques de plugins** : vous n’y avez plus accès car toutes les connexions sont paramétrées dans le code et seule l’équipe de développement y a accès. Si vous avez besoin de paramétrer alors vous pouvez les contacter, si le besoin est plus fréquent alors un développement spécifique vous permet d’agir sans danger sur des paramètres précis.

Enfin, les changements de technologie, de serveur etc ne vous empêchent plus d’accéder à votre interface car elle est indépendante. Il en va de même pour les migrations ou les refontes, **le contenu est à l’abri et utilisable à loisir sans attendre comme une mise à jour logicielle ou le redémarrage du serveur.**


## Quels inconvénients présentent les CMS headless ?

Beaucoup d’éditeurs de contenus arrivent de WordPress et sont habitués à une grande liberté d’action. Au fil des projets où nous avons installé des CMS headless, nous avons eu plusieurs retours d’utilisateurs :

### 1. Éditer un contenu long est parfois plus difficile 

Pour éditer un contenu, chaque contributeur dispose d’un éditeur de texte assez classique dans lequel il est possible d’ajouter des images. Pour ajouter une image accompagnée de sa balise alt et sa légende, l’ajout d’une section est indispensable et nécessite de séparer son texte en deux, pour qu’il entoure l’image. Votre texte sera alors dans plusieurs sections ce qui peut créer un peu de confusion quand il faut retrouver un passage en particulier.

Certains éditeurs se plaignent aussi de l’interface de l’éditeur de texte qui a un rendu markdown. Les développeurs y sont plus habitués que les autres métiers. Heureusement, il est toujours possible de faire une prévisualisation sans publier son contenu et d’utiliser les boutons de l’éditeur pour faire ces mises en forme.




### 2. Il est dur de savoir quel type de contenu ou blocs il faut utiliser

Que ce soit Strapi ou Prismic, les deux proposent des blocs de contenus librement intégrables. Cette liberté vient avec un revers : on ne sait pas toujours quel sera le rendu graphique d’un contenu ni quelle est l’utilité éditoriale du bloc que l’on sélectionne.

Évidemment, il est impossible d’hésiter entre un bloc “formulaire” et un bloc “newsletter”, mais entre un “CTA” et un “CTA push”, il y a matière à hésiter sans que le nommage du bloc soit forcément en cause. Imaginez ce que ça donne quand certains de nos clients ont une trentaine de ces blocs et tout autant de gabarits.

Nous avons mis en place des catalogues de gabarits et de blocs sous forme de PDF ou de Storybook. Les éditeurs de contenu ont ainsi un aperçu du rendu graphique du blog et des recommandations éditoriales.



**Heureusement, la possibilité de prévisualiser les contenus existe toujours et permet de tester rapidement un contenu.** Prismic est plus en avance sur ce point et propose depuis peu les variations avec un affichage du rendu lors de la phase de sélection.

## La place du contenu dans un projet de site avec un CMS headless

**En tant que rédacteur de contenu, les CMS headless vous mettent à l’abri des soucis techniques.** Pour autant, il ne faut pas vous cantonner au contenu. Que ce soit à la création ou à la refonte d’un site, faites remonter vos besoins auprès des développeurs pour être sûr d’être satisfait lors de votre première utilisation. **En effet, c’est vous qui connaissez le mieux votre site et la structuration du contenu, notamment les blocs de contenu les plus utiles ou ceux qui vous manquent.**

La création des blocs de contenu demande beaucoup de rigueur et un peu de temps. Il vous faudra parfois choisir entre liberté totale et liberté guidée pour vos blocs de contenus. Par exemple, vous aurez rarement besoin de créer de nouvelles catégories d’articles de blog et pouvez solliciter les développeurs pour le faire, mais vous avez besoin de pouvoir modifier le nom des rubriques du menu du site sans passer par eux.



Avantages et inconvénients des CMS headless pour les éditeurs de contenu

[![Conf-Web2day-Amnesty-Troopers.png](https://strapi.troopers.coop/uploads/Conf_Web2day_Amnesty_Troopers_f0e764617d.png)
Le Lean Agile Procurement : un appel d’offres cent pour cent agile - Web2Day 2019](https://tube.troopers.agency/w/pyhfkYQgLRNvxef4yYVAPn)


Un appel d’offres complet en deux semaines, sans dossier papier, avec mise à l’épreuve… Incroyable mais vrai !

La preuve en est, nous l’avons vécu. Nous avons eu le plaisir de participer à la consultation lancée par Amnesty International France en décembre dernier. L’objet était la recherche d’un nouveau partenaire pour gérer l’ensemble de leurs projets digitaux (design/web/mobile). Nous avons eu la chance de remporter ce marché, nouvelle annoncée quelques jours avant Noël…

Un appel d’offres idéal : celui auquel on aurait plaisir à répondre, que l’on mettrait en premier dans notre To Do list, dont on parlerait autour de nous dès que possible…

Irréaliste vous dites ? Découvrez le Lean Agile Procurement !

## Lean Agile Procurement (LAP)

Il s’agit d’une toute nouvelle approche pour les consultations : simple et efficace.

La procédure est basée sur la méthode agile. Elle s’applique à toute taille ou type de projet et est optimisée pour que le meilleur partenaire se démarque.

Voici les principaux avantages :

### Rapidité

D’ordinaire, une consultation peut s’étaler sur plusieurs mois : envoyer la demande, donner un délai pour la rédaction des dossiers, les recevoir, les lire, … et enfin les départager.

Grâce au LAP, tout peut être organisé en deux semaines : de la notification à la signature.

### Échanges

D’ordinaire, une consultation autorise une seule rencontre avec le prestataire, et encore !

Avec le LAP, l’entreprise et le prestataire sont toujours dans l’échange : ils apprennent à réellement se connaître et testent même leur synergie sur un projet concret.

### Co-création

D’ordinaire, l’entreprise émet la consultation et reçoit nombre de propositions sous forme de dossiers, propositions figées ne pouvant évoluer. Elle doit ensuite faire son choix dans ce panel, à son goût ou non.

Le LAP, lui, permet à l’entreprise de s’impliquer réellement dans l’élaboration du partenariat, elle va co-construire la réponse avec le futur prestataire en fonction de ses attentes.

Une petite révolution dans ce domaine !

## Déroulement

Amnesty International France a organisé l’exercice en deux étapes :

1.  Un rendez-vous d’une heure (proposé à l’ensemble des candidats pré-sélectionnés)
2.  Une journée d’ateliers (proposé aux deux finalistes)

Le tout, réponse incluse, en deux semaines !

Nous pouvons l’avouer aujourd’hui, nous avons été très surpris. Mais aimant les défis, nous avons plongé dans l’inconnu sans hésiter…

Le premier rendez-vous est appuyé par un formulaire général permettant de mieux cerner le prestataire (taille, compétences, méthodes, …). Il offre la possibilité, en une heure, de le découvrir : son évolution, ses clients, ses projets en cours et sa philosophie. A l’issue des rencontres, seuls deux candidats sont retenus.

La journée d’ateliers, elle, est intense. Elle a demandé la participation d’une équipe plus étoffée composée des différents métiers de l’agence.

Pour optimiser le résultat, il est important qu’elle soit organisée dans un lieu neutre (ni dans les locaux de l’entreprise, ni chez le prestataire) et par un acteur neutre (société tierce).

Nous avons eu la chance d’être encadrés, guidés et soutenus par la chaleureuse équipe de la société Goood, experts agiles.

L’objectif est une réelle immersion, pour toutes les parties, dans l’objet de la consultation.

Les activités nous ont permis :

*   d’apprendre à connaître nos interlocuteurs de façon naturelle,
*   d’approfondir nos connaissances sur Amnesty (contexte, méthodes de travail, technologies, besoins, …),
*   de réaliser un POC (Proof Of Concept) : ici travailler sur un projet découvert sur le moment mêlant parcours utilisateurs et développement,
*   d’aborder et de résoudre les éventuels désaccords pouvant surgir au cours du projet en toute sérénité (retard de livraison, processus de recette et de garantie, …),
    *   et bien sûr de compléter le **Lean Procurement Canvas**.

## Lean Procurement Canvas (LPC)

Le canvas est le coeur du partenariat, il synthétise la réponse du prestataire.

Il s’agit d’un document qui définit l’ensemble des besoins de l’entreprise, des compétences du prestataire, des objectifs de la consultation, des modalités de la réponse proposée, …

Tout gravite autour de cet élément. La journée permet une co-construction du canvas, celui-ci évolue tout au long des ateliers, jusqu’à la dernière minute.

La partie gauche concerne le prestataire qui répond à la consultation.

La partie centrale regroupe les objectifs du projet (True North).

La partie droite concerne l’entreprise en recherche de prestataire et ses besoins.

Lorsque le canvas est plié en deux dans le sens de la largeur, les besoins de l’entreprise et les compétences du prestataire se superposent et se répondent parfaitement.



Le canvas est présenté au format XXL : sur un mur complet. Cela permet de décupler les échanges : plusieurs personnes peuvent y travailler, y discuter, y apporter des modifications simultanément.



### Partie droite : l’entreprise

L’entreprise prépare en amont : ses besoins, les délais souhaitées, les conditions et surtout les objectifs de la consultation. Ces derniers sont représentés par une liste ordonnée. Ils sont suivis d’indicateurs précis permettant d’évaluer leur réalisation.

Cette section s’est donc rapidement complétée.

### Partie gauche : le prestataire

Le prestataire complète sa partie au fur et à mesure de la journée.

En premier lieu, il indique ses compétences. Dans notre cas, il s’agit de nos services (AMOA, design, webmarketing, développement d’applications web métier et d’applications mobiles, …). Nous sommes entrés dans les détails, en listant les langages maîtrisés, les outils utilisés, les méthodes de travail, … et avons groupé tout cela par thèmes.

Une section est réservée aux récompenses obtenues, c’est-à-dire tous les événements/retours extérieurs reçus appuyant la qualité des services et l’image du prestataire (conférences, formations, meetups, ...).

Ensuite, le prestataire présente les intervenants qui seront amenés à échanger avec l’entreprise au cours du projet, il les ajoute au canvas.

Il renseigne les éléments qui le différencient de ses concurrents. Nous avons mis en avant notre organisation sous forme d’entreprise libérée, nos ateliers design thinking, notre certification en tant qu’organisme de formation, ainsi que notre implication dans le monde de l’open-source.

La dernière case permet de définir les coûts, elle doit donner toutes les indications tarifaires que les coûts soient fixes ou variables.

Fait particulièrement intéressant, ce canvas se précise au fur et à mesure des discussions, des besoins évoqués par l’entreprise, et des négociations.

Nous avons été impressionnés par la richesse du canvas final par rapport à ce que nous imaginions initialement.

Une fois finalisé, il est le support idéal pour rédiger un contrat classique avant signature. Tous les aspects ont été abordés avec précision, ce qui permet un réel gain de temps.

En fin de journée, entreprise et prestataire ne forment plus qu’une seule et même équipe, une base solide pour une relation saine. Une équipe qui se comprend, qui sait échanger, qui connaît les attentes et les contraintes de chaque partie, et qui a hâte de commencer ce nouveau partenariat, dans ce climat de confiance et de bienveillance.

Le Lean Agile Procurement : la clé de la réussite et de la performance ?

Oui, très certainement.

En savoir plus sur le Lean Agile Procurement : [https://www.lean-agile-procurement.com](https://www.lean-agile-procurement.com)

Amnesty International FR - Découvrez les campagnes en cours : [https://www.amnesty.fr/](https://www.amnesty.fr/)

Goood - 20 rue Bachaumont 75002 Paris : [https://www.goood.com/](https://www.goood.com/)


Un appel d’offres 100 % agile ? On a testé pour vous

## Historique rapide de gitlab
Initialement un simple système de gestion de code source, Gitlab est devenue en quelques années et sous licence MIT une plateforme permettant de gérer des projets web de A à Z.

À l'origine, le produit était nommé GitLab. En juillet 2013, le produit est scindé en deux : GitLab Community Edition et GitLab Enterprise Edition. Si GitLab CE reste un [logiciel libre](https://www.wikiwand.com/fr/Logiciel_libre), GitLab EE passe sous licence propriétaire en février 2014 et contient certaines fonctionnalités assez intéressantes et non présentes dans la version CE.

## Par rapport à Github ?

J'ai découvert Gitlab il y a plusieurs années et je n'en avais vraiment pas un bon souvenir. C'est pourquoi, lorsque nous avons envisagé Gitlab il y a un an, nous avions des aprioris négatifs. Nous pensions, au regard de ce que nous avions observé dans le passé que Gitlab était une version low cost de Github et qu'il fallait forcément l'héberger sur son propre serveur et donc maintenir une infrastructure.

En fait, Gitlab présente presque les mêmes fonctionnalités que Github et offre même un avantage fort sur le sujet primordial pour nous :


En effet ! Gitlab vient avec GitlabCI, un système d'intégration continue très puissant et gratuit.

Pour l'avoir testé sur plusieurs projets et pendant quelques temps, ce système est tout à fait remarquable, n'a presque rien a envier à TravisCI ou CircleCI.

Au contraire, grâce à son système innovant de Runners, il est possible de paralléliser l'exécution des tests et d'accélérer significativement le processus de pull request (ou plutôt Merge request dans le jargon de gitlab). Nos runners sont installés sur des serveurs ubuntu classiques... pas des foudres de guerre ni un cloud hors de prix... mais des serveurs qui font largement l'affaire ; et ensuite on configure le runner afin qu'il autorise plusieurs lancements.

En bref, le CI de Gitlab est mieux que les concurrents car:

- **Intégré gratuitement** dans toutes les versions, [version SAAS](https://gitlab.com/) comme [version hébergée CE](https://gitlab.com/gitlab-org/gitlab-ce)
-  **Scalable:** Le système de runners permet de distribuer l'exécution des tests sur plusieurs machines
-  **Jobs parallèles:** Cette fonctionnalité coûte vraiment très cher chez CircleCI ou Travis puisqu'on paye le runner 50$. Pour nous, cela nous couterait 1000$ par mois...
-  **Continuous Delivery (CD):** définition d'environnements multiples, déploiements manuels ou automatisés... on n'a pas encore joué avec ça mais ça donne envie bien évidemment !

## Pour l'organisation et le suivi des projets : les boards

Gitlab avec les **boards** n'invente pas grand chose ! Ce n'est ni plus, ni moins qu'un système de tableaux comme font tous les systèmes de gestion de projets agiles comme Trello, Taïga et Jira avec le plugin Agile scrum et même Github depuis quelques mois maintenant avec leur **Projects.**

Mais c'est une des briques qui manquait à Gitlab afin de pouvoir l'utiliser en tant qu'outil de gestion de projet. Le système de ticket a le mérite d'exister mais on ne gère pas un projet de grande ampleur avec une liste de choses à faire procédurale. On a besoin de faire passer un ticket dans des états différents afin de notifier aux collègues, clients ou plus généralement partenaires de l'avancée des travaux sur la tâche et qu'une intervention est peut-être requise pour continuer l'avancée.

[![GitLab_Issue_Board.png](https://strapi.troopers.coop/uploads/Git_Lab_Issue_Board_8f1a340045.webp)](https://www.youtube.com/watch?v=UWsJ8tkHAa8)

## Suffisant pour la méthodo SCRUM ?

Chez Troopers, nous sommes très attachés à la méthodologie Agile SCRUM qui consiste en quelques mots à séparer un projet en plusieurs blocs (appelés sprints) de taille équivalente et d'itérer, sprint après sprint, afin de construire le projet. L'enjeu est de garder une forte relation entre le client et l'équipe de développement afin d'assurer de bonnes interprétations du cahier des charges.

Pour des projets d'envergure, il est primordial de planifier plusieurs sprints d'avance afin de réussir à définir au mieux le planning ainsi que le périmètre fonctionnel des sprints à venir.

Dans Gitlab ou Github, pour parler d'un sprint SCRUM, la bonne pratique est d'utiliser les **Milestones**. On utilise ensuite le système de Board pour filtrer sur la milestone en cours et cela fonctionne bien et le résultat va ensuite être très intéressant !

En effet, les User stories vont être reliées aux branches de développement et aux **Merge requests**.

Cela va simplifier grandement le processus de validation d'une fonctionnalité et permettre de toujours garder l'historique des développements pour une **User story** donnée.

Mais aujourd'hui, pour satisfaire pleinement la méthodologie appliquée ici, chez Troopers, il manque plusieurs choses :

1.  un système de time tracking comme on peut l'avoir sur JIRA par exemple
2.  un système d'export csv afin de récupérer des rapports (liste des tickets relatifs à une recherche, période, milestone/sprint, catégorie, auteur...)
3.  des graphiques d'analyse de projet en méthodo agile par exemple (burndown chart...)

La bonne nouvelle, c'est que le système de time tracking (avec des hooks dans les messages de commits et de merge requests) est prévu pour la prochaine version: [https://gitlab.com/gitlab-org/gitlab-ee/issues/92...](https://gitlab.com/gitlab-org/gitlab-ee/issues/921) ; et qu'un système d'export de rapport est aussi prévu dans cette même release.

La mauvaise, c'est que ces points seront réservés à l'édition EE (Entreprise Edition) qui n'est pas la notre...

Nous ne boudons tout de même pas notre plaisir. Il s'agit d'un produit d'une qualité rarement égalée et qui plus est gratuit. Aussi nous ne serons pas trop gourmands et continuerons donc de mesurer notre temps avec des outils externes comme les excellents [RescueTime](https://www.rescuetime.com) et [Toggl](https://www.toggl.com).

## Version SAAS (gitlab.com) ou version CE / EE ?

Pour tester quelques jours, utilisez la plateforme gitlab.com, vous aurez un apercu de toutes les fonctionnalités en très peu de temps et pourrez prendre conscience du potentiel de l'outil.

Néanmoins, gitlab.com est victime de son succès.... le site est lent... horriblement lent aux heures de pointes (quand tout le monde fait son commit entre 16h et 18h30) et parfois instable. Si le produit vous plait, sautez le pas plus rapidement que nous ! Installez-la version CE chez vous. Cela nous a pris une demi-journée pour le faire de A à Z et [l'installation par docker](https://hub.docker.com/r/gitlab/gitlab-ce/) est d'une simplicité déconcertante et les performances seront au rendez-vous.

De plus, passer sur un système hébergé vous permettra d'avoir la main complète sur les Runners partagés et vous permettront de vraiment tirer partie du système d'intégration continue qui est bridé à 1 Runner partagé dans la version [SAAS](https://gitlab.com).

Le blog de Troopers

Comment prioriser son projet avec une story map ?

Avantages et inconvénients des CMS headless pour les éditeurs de contenu

Un appel d’offres 100 % agile ? On a testé pour vous

Gitlab CE, l'outil ultime de gestion de projet web & open source ?