Introduction

Cela fait depuis 2022 que je souhaite prototyper un outil de gestion de tâches (issues) avec certaines fonctionnalités que je n'ai trouvées dans aucun outils Open source ou closed-source.

En novembre 2022, j'ai commencé le tout début d'un modèle de données PostgreSQL, mais je n'ai pas continué.

Je souhaite, dans cette note, présenter mon idée de prototype, présenter les fonctionnalités que j'aimerais implémenter.

Nom du projet : Projet 24 - Prototyper le gestionnaire de projet de mes rêves

Ces idées de fonctionnalité sont tirées de besoin personnel que j'ai rencontré depuis 2018, dans mes différents projets professionnel en équipe.

Pour réduire mon temps de rédaction de cette note et la publier au plus tôt, je ne souhaite pas détailler ici l'origine de ces besoins.
Je souhaite juste décrire quelques fonctionnalités que je souhaite et quelque détail technique sans expliquer l'origine de mon besoin.

Sources d'inspiration

Mes principales sources d'inspiration :

• Certaines fonctionnalités issues et projects de GitHub et ses dernières améliorations.
• Certaines fonctionnalités Plan and track work de GitLab.
• Certaines fonctionnalités de Basecamp, par exemple, j'adore les Hill Charts (https://basecamp.com/hill-charts).
• Certaines fonctionnalités de Linear.
• Certaines fonctionnalités de OpenProject

Je me projette d'utiliser Projet 24 dans les framework de gestion de projets suivants :

• Scrum
• Shape Up
• SAFe
• Request for Comments, Best Current Practice, Architecture decision record

Ainsi qu'avec la technologie sociale Sociocratie 3.0.

Liste de fonctionnalités en vrac

• Permettre d'importer / exporter une ou plusieurs issues dans un format de fichier YAML.
  • Permettre d'importer / exporter ces fichiers via Git.
  • Permettre l'utilisation de branche : création, suppression, merge de branches.
  • Permettre la gestion des branches via l'interface web.
  • Visualisation web des diff entre deux branches.
  • Permettre de commit ou créer des snapshots d'une branche.
• Permettre d'attribuer à une issue une estimation basse et haute de temps d'implémentation.
• Permettre d'activer un Hill Charts sur toute issue.
• Permettre d'indiquer un niveau d'approximation d'une issue
• Permettre aux lectures d'une issue d'indiquer leur niveau de compréhension de l'issue
• Permettre de configurer la taille maximum en mots d'une issue. Pour forcer un certain niveau de synthèse.
• Permettre de calculer le poids d'une issue en faisant la somme basse et haute de toutes ses dépendances.
• Système inspiré de Tinder pour prioriser les issues. L'application présente deux issues choisies selon un algorithme Elo et invite l'utilisateur à désigner celle qu'il considère comme prioritaire.
• Implémenter un système de tags d'issues personnalisés où chaque utilisateur peut créer ses propres étiquettes. La visibilité de ces tags serait configurable : mode privé pour un usage personnel ou mode partagé pour les rendre disponibles aux autres utilisateurs.
• Permettre de créer des portfolios d'issue par utilisateurs.
• Pas de séparation des entités Epic (gestion de projet logiciel) / Issue contrairement à ce que fait GitLab.
• Permettre d'utilisation d'une extension Browser pour enrichir les pages GitHub, GitLab, Linear ou Forgejo avec les fonctionnalités de Projet 24.
• Permettre au Projet 24 d'améliorer une instance privé Forgejo avec un wrapper HTTP.
• Système de dashboard pratiquement identique à GitHub projects.
• Système de commentaire comme GitHub, mais avec un système de thread.
• Support de wikilink et alias au niveau de toutes les ressources texte.
• Support d'une fonctionnalité de publication de notes éphémères attachées à chaque utilisateur.
• Permettre la création d'issues ou de notes "flottantes". Une issue "flottante" n'appartient à aucune ressource spécifique — elle n'est rattachée ni à un projet, ni à un groupe. Cette fonctionnalité me semble essentielle et je compte la détailler dans une note dédiée prochainement.
• Proposer une extension Browser qui détecte automatiquement les issues liées à l'URL de la page actuelle. Cela permettrait d'accéder rapidement aux issues ou notes "flottantes" selon le contexte de navigation.
• Très bon support Markdown, contrairement aux implémentations de Slack, Notion ou Linear. Il devrait être possible de basculer entre le mode d'édition riche et le mode markdown. Le contenu copié doit générer du markdown valide dans le presse-papier.
• Respect strict des conventions Web : permettre l'ouverture de toutes les pages dans un nouvel onglet, etc.
• Mettre l'accent sur la performance de rendu des pages. Implémenter en priorité un système de métriques pour mesurer les temps de rendu.
• Proposer un système de génération de titre d'issue et de tag basé sur un LLM.
• Mettre en place un système qui utilise un LLM pour proposer automatiquement des titres d'issues et des tags.
• Alimenter une base de données vectorielle avec les descriptions d'issues et leurs commentaires pour activer la recherche sémantique.

Expérience utilisateur

Comme SilverBullet.mb, un outil fait dans un premier temps pour les hackers.

Détails techniques

• Stockage dans Elasticsearch pour faciliter les recherches par tags et plain text.
• Utilisation de nanoid de 5 caractères pour identifier les issues.
• Utilisation de Git hook pre-receive côté serveur pour importer des données (issues, notes, etc)

Cette semaine, deux amis m'ont partagé deux expressions que j'ai trouvées pertinentes.

La première est une déclinaison de « c'est à nous de le faire » : « C'est à nous de ne pas le faire ! ».

Elle s'utilise quand une équipe a la responsabilité d'un périmètre, ne fait pas le travail et empêche d'autres équipes de le faire.

La seconde expression est la « Vérité partagée » (au sein d'un groupe).
Je trouve cette expression remarquablement simple et directe, ce qui la rend très pratique.
Je pense que « les vérités partagées » sont essentielles pour créer une équipe.

Je pense que plus le nombre et la force « des vérités partagées » au sein d'une équipe sont élevés, plus cette équipe sera performante.

Il me paraît difficile, voire impossible, de mener à bien un projet politique, de gérer une entreprise ou de développer une application informatique si l'équipe ou l'organisation manque de vérités partagées.

Ayant développé depuis avril 2024 une relation particulière avec le mot vérité, je préfère à l'avenir utiliser l'expression « croyance partagée ».

Voici quelques principes qui me guident. Je pense qu'ils contribuent à rendre une organisation efficace et efficiente.

1. La loi empirique de Gall :

« Un système complexe qui fonctionne se trouve invariablement avoir évolué depuis un système simple qui fonctionnait.
La proposition inverse se révèle également exacte : Un système complexe développé de A à Z ne fonctionne jamais et vous n'arriverez jamais à le faire fonctionner. Vous devez recommencer depuis le début, en commençant par un système simple. »

source

2. Je suis convaincu de la pertinence du modèle de Tuckman pour comprendre comment les équipes se construisent et évoluent au fil du temps. En conséquence, je crois qu'une organisation doit accorder suffisamment de temps aux équipes pour qu'elles atteignent leur phase de performance, puis veiller à maintenir la composition de l'équipe sur la durée.

3. Le modèle du triangle de gestion de projet qui je trouve est très bien expliqué dans le livre Getting Real :

Voici un moyen simple de lancer le projet dans les délais et le budget impartis : ne pas les modifier. Il ne faut jamais consacrer plus de temps ou d'argent à un problème, mais simplement en réduire la taille (le périmètre).

Il existe un mythe qui dit que l'on peut lancer un projet dans les délais, en respectant le budget et le champ d'application. Cela n'arrive presque jamais et, lorsque c'est le cas, la qualité s'en ressent souvent.

Si vous ne pouvez pas tout faire tenir dans le temps et le budget impartis, n'augmentez pas le temps et le budget. Au contraire, réduisez le champ d'application. Il sera toujours temps d'ajouter des choses plus tard - plus tard est éternel, maintenant est éphémère.

Il vaut mieux lancer quelque chose d'excellent dont la portée est un peu plus réduite que prévu que de lancer quelque chose de médiocre et plein de trous parce qu'il fallait respecter une fenêtre magique de temps, de budget et de portée. Laissez la magie à Houdini. Vous avez une véritable entreprise à gérer et un véritable produit à livrer.

source

En mars 2024, je me suis interrogé sur les points communs et les différences entre les termes suivants : "Mission", "Projet", "Objectif", "Goal", Epic et North Star.

Dans cette note, je souhaite partager quelques réflexions sur le concept de North Star.

La principale caractéristique de la North Star — ou étoile polaire — est son unicité. Ainsi, je définis un objectif comme une "North Star" lorsque celui-ci constitue l’unique objectif principal d’une organisation.

D'autre part, en faisant des recherches j'ai constaté que "North Star" est surtout utilisé dans l'univers Startup pour décrire une metrics unique et principale, nommée "North Star metric".

North Star semble peu utilisé pour décrire un objectif principal.

#JaiDécouvert Nautilus un outil de "time-blocking".

#JaiLu avec attention l'intégralité de l'article How I learned to plan better (and what to do when your head doesn’t get lists), j'adore, très inspirant !