Comment vous organisez-vous de façon structurée en tant que développeur solo ?

• Quand on travaille en équipe, des objectifs de court terme comme le scrum et un backlog de travail structuré aident vraiment à rester concentré et à suivre ce qu’il faut faire
• Mais en développant seul, je n’ai pas trouvé de bonne approche, et je me laisse souvent distraire en perdant de vue l’objectif
• Quels outils et quelles techniques utilisez-vous pour rester fidèle à vos objectifs ?

CharlieDigital

• Utilise un carnet papier
• Quand il n’y a pas besoin de partager l’information, rien ne vaut un carnet pour étaler toutes les idées et les revoir en boucle. Pas besoin de se connecter, on peut l’emporter partout, s’asseoir sur un banc pour réfléchir, aller à la salle et noter une idée.
• Il suffit d’écrire les objectifs du jour sous forme de checklist et de les cocher un par un. Pas besoin non plus d’un GitHub Project puisqu’il n’y a pas à partager l’état avec d’autres

olooney

• Utilise un fichier TODO.md
• Rédige la liste suivante en GFM (GitHub Flavored Markdown)

    1. [X] Dockerfile  
    2. [ ] Bulk Inference  
    3. [ ] CLI  
    4. [ ] Logging  
  

• Ajoute en haut une section « backlog » pour les idées futures, une section « bugs » pour les correctifs, et une section sans nom pour les éléments en cours
• Quand un jalon comme une release est atteint, supprime tous les éléments terminés

jasonb05

• Écrit énormément pour son moi du futur
  1. Trello avec des colonnes semaine, mois, trimestre et année
  2. Ouvrir le carnet posé à côté de la souris
     2a. Page de gauche : checklist quotidienne au stylo et papier (2 à 3 lignes par jour)
     2b. Page de droite : brouillons, croquis, Post-it, etc.
  3. Un journal de développement où noter recherche, URL, articles, réflexions, idées, avancement, extensions, etc.
  • Tous les projets GitHub ont un dossier dev/ pour ces notes, avec des fichiers nommés yyyymmmdd-n.txt
  • Crée un nouveau fichier par projet et par jour selon les besoins
  4. Des Post-it jaunes pour les idées temporaires (collés en bas de l’écran, sur le carnet ou le tableau blanc)
  • En général, une maxime qui indique la bonne direction du projet (par ex. « personne ne lira jamais le manuel »)
  5. Tableau blanc, colonnes par projet, impressions + aimants (diagrammes mensuels d’avancement), Post-it, idées pour de futurs projets, divers objets
• Il essaie de communiquer de manière excessive avec son moi du futur
  • Cela aide à clarifier ses attentes, son avancement, ses obstacles et son état d’esprit du moment
  • Le blocage, c’est lui, pas la tâche
  • Les tâches prennent généralement forme après une bonne phase de réflexion
• Travaille ainsi seul depuis 8 ans
  • Utilise un répertoire /dev et des fichiers .txt pour un journal de développement en temps réel depuis sa thèse, au début des années 2000. Cela lui a fait gagner un temps fou (grep).
• Ah, et il fait chaque jour les mêmes types de tâches. Presque tous les jours
  • Par exemple support client, promo, écriture, code, puis autre chose, sans avoir à réfléchir : il fait simplement la tâche puis passe à la suivante

liampulles

• Pour les side projects, le « développement guidé par le README » aide à garder la motivation et à limiter le périmètre

Tehnix

• Se fixe des objectifs quotidiens / hebdomadaires / mensuels, organisés avec des apps comme Linear, Todoist ou Notion
• Les objectifs mensuels sont très haut niveau et peu nombreux (par ex. « créer un PoC », « refondre et relancer le blog »)
• Les objectifs hebdomadaires sont plus précis et plus limités (par ex. « décider d’une approche pour appeler Rust depuis du code Swift » ou « finaliser le design et le style d’un article »)
• Les objectifs quotidiens sont très concrets (par ex. « configurer le pipeline UniFFI pour générer des bindings Swift » ou « déployer le nouveau thème sur toutes les pages du blog »)
• Il arrive que l’implémentation fasse émerger de nouvelles tâches, ce qui reporte l’objectif quotidien au lendemain
• Jusqu’ici, cette méthode s’est montrée efficace pour améliorer la concentration ; parmi de nombreuses tâches / issues en cours sur plusieurs projets, il choisit les objectifs du jour selon la priorité de la semaine
• En définissant chaque travail en cours comme un projet, puis en lui attribuant immédiatement une priorité lors de son ajout, il est facile d’avoir une vue d’ensemble des petits et grands projets en cours ou à venir
• Il aime le papier, mais seulement pour des choses temporaires. Il préfère une approche numérique, facile à alimenter sur téléphone quand une idée surgit en déplacement. Écrire au clavier est aussi beaucoup plus rapide, et il utilise divers outils comme dépôt d’informations pendant le travail ou la recherche

OogieM

• Gère tout dans des dossiers au sein d’un Obsidian Vault
• Les dossiers contiennent des éléments communs du même type
  • Une note Kanban, via le plugin Kanban, pour la structure des écrans (quelles fonctions ou activités se trouvent sur chaque écran)
  • Une note de roadmap avec les détails de chaque fonctionnalité
  • Des notes générales contenant diverses tâches liées à l’application ou au composant
• Utilise le plugin Tasks pour suivre précisément ce qui est en cours
  • Le dossier contient aussi des documents annexes comme des captures d’écran, des références et d’autres notes liées à l’application concernée
• Ses projets sont un ensemble de logiciels de gestion d’élevage et de registres de races rares
  • Il a donc des dépôts GitLab séparés pour Farm Mobile (Android), Farm Desktop (Python), le registre web (Flask), le registre desktop (Python) et le schéma de base de données (SQLite)
• Trois collaborateurs se sont ajoutés depuis, et le Obsidian Vault est maintenant partagé via Obsidian Sync. Le système pensé pour le solo a pu s’étendre au travail d’équipe

robomartin

• Utilise depuis des années un simple fichier texte inspiré du kanban
• A tout géré ainsi, des petits projets jusqu’à des projets à plusieurs millions de dollars
• Chaque projet a un fichier journal principal, et un fichier dédié pour chaque domaine (électronique, mécanique, optique, fabrication, test, etc.)
• Contenu des fichiers

  <Nom du projet> fichier journal  
  -------------------------------- WORKING ON NOW   
  <Tâche en cours>  
  
  -------------------------------- TO DO   
  - <Chaque tâche commence par un tiret>  
    - <Indenter les sous-tâches ou notes associées>  
  
  -------------------------------- IDEAS  
  <Notes en format libre>  
  
  -------------------------------- RESOURCES  
  <Ressources en format libre>  
  
  -------------------------------- DONE  
  <Déplacer ici ce qui est terminé>  
  <Ajouter un horodatage si souhaité>  
  

kkfx

• Gère tout avec Emacs/org-mode/org-roam
• Utilise org-agenda sur la note de l’année en cours ; les notes sont organisées à raison d’un fichier par jour, un répertoire par an, avec des fichiers découpés par heure dans un répertoire org-roam commun
• Cela réduit le nombre de fichiers qu’org-agenda doit parcourir et diminue aussi, dans la note récapitulative annuelle, le volume de contenu qui se prolonge d’une année sur l’autre

makz

• Avant de quitter le travail, laisse un commentaire dans le code : « je suis en train de faire ceci, et pour que ça fonctionne, il faut faire A, B, C… »
• Ainsi, à la prochaine ouverture de l’éditeur, il sait exactement quoi faire

qntmfred

• Utilise un modèle de routine quotidienne dans Obsidian Daily Note. Cela aide à se concentrer sur la journée et à l’aborder avec enthousiasme
• Le premier [X] qu’il se donne chaque jour, c’est de terminer la checklist de routine quotidienne
  • Une victoire gratuite pour lancer une journée productive
• Il rédige en pratique la plupart de ses notes avec la dictée vocale de Windows, donc cela ressemble à un stand-up quotidien
• Il fait aussi souvent un live stream toute la journée, même si le seul spectateur est lui-même (puisqu’il s’agit d’un live privé, fait chaque jour, pour se rappeler ce qu’il faisait ou pensait environ 20 minutes plus tôt avant de partir dans une rabbit hole ; en fait, Windows Recall est aussi pratique)
• Sa journée ressemble donc à celle d’une organisation de deux personnes ou plus travaillant avec des collègues — autrement dit, avec des réunions

mentos

• Utilise un tableau Trello avec trois listes : Done / Doing / ToDo
  • Dresse la liste de tout ce qu’il faut faire
  • Définit les priorités
  • Déplace l’élément du haut vers la liste des tâches en cours et commence à travailler
  • Une fois terminé, le déplace dans Done, puis prend l’élément suivant et recommence
• Utilise aussi d’autres listes Trello pour gérer des cartes de recherche ou retirer de ToDo les fonctionnalités non nécessaires pour la v1

macNchz

• Aime travailler comme avec une petite équipe
  • Gère des issues GitHub, vaguement regroupées par jalons, avec des checklists contenant de nombreux éléments
    • Comme c’est proche du code, il est facile d’ajouter des notes pour se souvenir d’où reprendre : liens vers des numéros de ligne, blocs de code à copier-coller ou brouillons de PR liés
    • C’est très facile d’accès depuis n’importe quel appareil, donc si une idée surgit ou qu’un e-mail signale un bug, il peut créer rapidement une issue sur le moment depuis son téléphone ou un autre appareil
    • Il est aussi simple de faire intervenir quelqu’un d’autre au bon moment pour travailler immédiatement dessus
    • Il y a une bonne API et de nombreuses intégrations (par ex. créer ou lier directement une issue depuis un système de suivi d’erreurs)

rerdavies

• Utilise GitHub Projects
  • Sans forcément le recommander avec enthousiasme
  • Mais gérer une liste de tâches et de bugs, ce n’est pas de la science des fusées
  • Il a déjà utilisé des solutions de gestion de projet coûtant des centaines de milliers de dollars, et elles étaient bien pires
• Même si GitHub Projects a des comportements étranges et n’est pas très aimé, ses fonctions minimales suffisent
  • Il y a beaucoup de choses qu’on pourrait penser automatisables
    • Comme faire basculer un sprint vers le suivant en quelques clics sans avoir à modifier manuellement toutes les requêtes du board scrum
  • Mais on peut faire ce qu’on veut en faire
    • C’est bien mieux que de subir un processus rigide défini par d’autres
    • D’une certaine manière, ce minimalisme peut même être un avantage
• Mentalement, c’est un problème de gestion de liste. Pas si compliqué. Et GitHub Projects fait très bien les listes
• Une raison de recommander GitHub Projects plutôt qu’une liste papier ou des cartes physiques, c’est
  • Que les utilisateurs peuvent voir publiquement comment les bug reports et les feature requests sont traités
  • Et qu’il est très facile de transformer un sujet venu du forum de discussion en bug report, ou en tâche de développement (en attente ou active)
• Les règles classiques du scrum s’appliquent. Tous les bugs sont corrigés avant de commencer de nouvelles tâches, et une tâche ne passe à terminé que lorsqu’elle est complètement finie
• Il faut une liste. Il aime y superposer une structure de sprint, car elle fournit des jalons utiles pour les mises à jour intermédiaires et les releases continues

leros

• Il sépare ses rôles de product manager, project manager, développeur logiciel, marketing, opérations business et dirigeant de l’ensemble de l’entreprise, et ne joue qu’un seul rôle à la fois
• Par exemple
  • Il peut s’asseoir en tant que dirigeant de l’entreprise et décider de la direction stratégique souhaitée
  • Puis mettre sa casquette de product manager et décider quoi construire
  • Puis gérer ce projet et le prioriser
  • Puis redevenir product manager / designer pour détailler les fonctionnalités priorisées
  • Puis réserver un temps entièrement distinct (souvent une journée entière) pour développer la fonctionnalité
  • Une fois la fonctionnalité livrée, mettre la casquette marketing et s’occuper du product marketing associé
  • C’est en quelque sorte le cycle de vie de développement d’une fonctionnalité
• Le danger, c’est de sauter d’un rôle à l’autre en permanence. Cela peut nuire à la productivité
• Il y a des moments pour être stratégique, des moments pour être créatif, et des moments pour simplement exécuter ; chacun exige un espace mental différent
• Il planifie tout dans Notion avec plusieurs tableaux kanban selon l’usage

urda

• Utilise un système de « connaissance » en cascade :
  • Note les pensées aléatoires, mémos, bouts d’idées, diagrammes, etc. dans un carnet Moleskine de poche
  • Cela finit ensuite soit en « ticket » dans l’issue tracker, soit en « wiki » ou « mise à jour du wiki » sur son serveur wiki
  • Ce qui mène ensuite à des snippets, notes de configuration, documents de référence, archives, runbooks, etc.
• Au final, maintenir la documentation à jour ou placer un problème dans le bon backlog est devenu quelque chose de « naturel »

[xguru]

Je pense que, pour ce genre de choses, la meilleure méthode est celle qu’on arrive à transformer en routine pour soi-même. Quand il y a déjà beaucoup de préparation à faire, si ouvrir un document de suivi et se lancer prend du temps et devient pénible, on finit peu à peu par s’en éloigner. Même le simple fait de sortir et d’ouvrir un carnet rangé quelque part après avoir débarrassé le bureau peut donner l’impression d’être une tâche en soi.

Dans cette optique, comme VS Code est presque toujours ouvert sur mes ordinateurs à la maison et au travail, noter et effacer des choses dans le fichier "à-faire.txt" affiché dessus fait partie de mon quotidien. Je trouve ça bien parce que je n’ai pas à réfléchir à ce qu’il faut ouvrir, c’est devenu une routine. Le contenu est synchronisé via un dépôt privé GitHub.

[mytory]

Je note toutes les tâches de mon projet dans Google Sheets en les découpant en unités de 30 minutes à une heure, puis j’indique le temps qu’il a fallu pour les terminer. C’est pratique pour faire des prévisions, et c’est aussi satisfaisant de les valider une par une.

[devsepnine]

J’utilise surtout Trello, je liste les tâches et j’organise la description...
Comme c’est accessible de partout...

[tested]

Je crée un serveur personnel sur Discord, puis je l’organise par catégories/canaux et je l’utilise à des fins personnelles comme les TODO.

[porteleaf]

J’ai essayé plusieurs méthodes, mais je n’ai pas encore réussi à m’installer durablement sur une seule. En ce moment, je prends mes notes dans Obsidian, et pour le travail concret, j’écris au besoin dans LegalPad.
Comme ce sont aussi des notes destinées à remplacer une mémoire volatile, j’ai l’impression qu’avec le temps, il m’arrive souvent d’oublier ce que j’avais noté..
Je vais essayer de remettre un peu d’ordre dans mon système en m’appuyant sur cet article..

[hwan0317]

Même sans développer entièrement en solo, ce sont des contenus utiles pour gérer de façon générale la motivation et la planification !