/dev-manifesto

L'équipe tech tokarde apprécie et valorise les points suivants chez les (futurs-)tokars

dev-manifesto

L'équipe tech tokarde apprécie et valorise les points suivants chez les (futurs-) tokars:

1. Production / méthode

Être agile, ce qui signifie:

  • travailler sur ce qui apporte le plus de valeur à Toucan à l'instant t

    Exemples

    Pour le savoir je me pose les questions suivantes :

    • est-ce que ce que je suis en train de faire profitera dès son lancement à un utilisateur/client/concepteur/Tokar ? Si oui est-ce que cela lui permettra de faire quelque chose qu'il ne pouvait pas faire avant ? Est-ce que cela lui permettra de faire quelque chose deux fois plus vite qu'avant ?
    • à contrario, ce que j'ai fait est-il une amélioration marginale, ou qui ne profite à personne dans l'immédiat ?
    • est-ce que ce sur quoi je travaille est mergé/intégré au produit ? Ou est-ce finalement abandonné ?

  • se donner des échelons très progressifs et s'y tenir

    Exemples
    • ma feature a été découpée, le découpage est écrit dans la carte Trello, il est univoque et chaque étape est courte
    • ma feature n'était pas découpée, j'ai vite vu que c'était plus compliqué que prévu, j'ai repassé la carte Trello en découpage

  • délivrer ces petits échelons le plus souvent possible

    Exemples
    • je peux faire une v0 de ma fonctionalité et la présenter en quelques jours
    • je peux commencer un projet en ayant confiance que la PR sera proposée le soir
    • je me concentre sur l'essentiel dans les PRs et évite de faire des modifications en plus "en passant"

  • bien communiquer son but et son avancement au reste de l'équipe

    Exemples
    • je communique via les daily sur mes projets en cours, mes difficultés
    • je mets à jour Trello, le wiki
    • mes PRs sont claires et autosuffisantes (screenshots, urls de tests, exemples d'usage des APIs, exemples de confs)
    • je sais retrospectivement dire les projets et tâches sur lesquels j'ai participé

2. Autonomie

Être autonome signifie que lorsqu'on prend un sujet, on s'engage dessus et on y met l'énergie nécessaire pour aller jusqu'à son rendu. Cela ne signifie PAS travailler seul.

En particulier, nous recommandons:

  • d'identifier précisément le besoin auquel on répond : quelle est la démo de ma feature ?

  • d'identifier précisément les points sur lesquels une assistance est nécessaire

    Exemple
    • Je sais faire mon auto-critique quand une tâche n'avance pas et je sais le communiquer

  • d'aller voir ses collègues avec des questions précises et claires

  • de prendre les tâches en haut du backlogs communs que je peux prendre et m'engager à traiter

3. Apprentissage

Être volontaire et moteur de son apprentissage, et participer à celui de ses collegues, c'est :

  • prendre le temps de pair-programmer le plus souvent possible

    Exemples
    • Bien communiquer avec le reste de l'équipe pour se synchroniser avec son binôme en fixant des events dans le calendrier

  • documenter au cours de son apprentissage pour les suivants

  • suivre son apprentissage (grâce à un board par exemple) et le communiquer au reste de l'équipe, puis prendre le lead sur des sujets nouvellement acquis pour les valider

4. Attitude

Avoir une bonne éthique de travail, être honnête envers soi-même et ses collègues sur:

  • ses compétences
  • ses difficultés (ce qui va servir à les résoudre)
  • sa capacité à délivrer (rien ne sert d'annoncer la lune, si ce n'est à décevoir)

Pour aller plus loin... references