Montrer la manière dont je veux travailler concrètement, à autrui et à moi-même
Bac à sable d'implémentation de (bonnes) pratiques de "Software Engineering", typiquement le ISE playbook de Microsoft en tant que point de départ
Confiance : Gagner confiance & "Keep me honest" dans ma capacité à faire
Attitude générale attendue
Collective Ownership
Tout appartient à tous : Anti-Silos. Il est encouragé que tout le monde soit curieux, s'approprie et cherche à contribuer à absolument TOUS les aspects du projet: fonctionnel, technique, gestion.
Exceptions : Celleux qui cherchent à rester sur un seul domaine d'expertise sont aussi bienvenu-e-s, mais iels représentent l'exception plus que la norme.
Responsables : Cependant, chaque aspect a un-e ou plusieurs responsables à un moment donné. Ils sont au moins RA en termes de RACI. Ils sont aussi chargés de diffuser la connaissance. Il est encouragé à ce que ces responsables tournent parmi les membres de l'équipe, les plus compétents aidant les moins compétents à devenir responsables.
SPOF humain : on fait tout pour éviter que la connaissance ou l'expertise sur un domaine donné soient détenues par une seule personne. cf responsabilité des responsables -> diffuser la connaissance.
Respect :
Humilité : respecter les écarts d'expertise et d'expérience, dans les 2 sens. Nous sommes fondamentalement égaux, personne n'est plus ou moins important.
Ecoute : tout le monde est entendu, aussi bien en termes d'idée, propositions, plan, qu'en termes de feedback : positif ou négatif, sur les aspects technique, fonctionnel, organisationnels, humain.
Donner une chance à autrui : de corriger une erreur, une action, inappropriée, sans jugement, sans réprimande, sans attribuer d'intention négative.
Communication non violente : observation vs évaluation, sentiment vs interprétation, besoins et responsabilité de ses propres sentiments, demander vs exiger. Recevoir et écouter
Les 4 accords : parole impeccable, ne pas prendre les choses personnellement, ne pas faire d'hypothèse, faire de son mieux
Collaboration
cf agile manifesto: Face to Face Communication is the best way to share information.
Pair & Mob Programming sont plus que bienvenus, ces pratiques encouragés. Une demande de pairing ne doit JAMAIS être refusée, sinon il y a un problème humain plus grave qu'il faut résoudre de toute urgence. Il est bon de travailler seul par moments, mais on évite de faire des choses dans son coin, SURTOUT si ça a un impact sur le design, l'archi, la manière de travailler ou un quelconque processus: soit nouveau, soit en place.
Réserver des créneaux dans la semaine pour des échanges dans l'équipe : tech, fonctionnel, orga. Typiquement après le daily
Pas d'obstructionnisme: On s'assure de comprendre autrui avant de refuser. Refus => responsabilité de proposer une alternative
Pas de "yakafocon": On n'émet pas de proposition "en l'air". Celui qui propose fait.
Nurture: les idées nouvelles sont fragiles, on laisse le temps et l'espace de les murir en bienveillance, sauf troll ou exception, on évite de les démonter immédiatement.
Transparence
Désaccord : Ne pas cacher un désaccord, technique, fonctionnel, organisationnel ou humain. Les recevoir, ne pas les esquiver
Critiques : Savoir les exprimer et les recevoir, dans le respect.
Démocratie : Toute décision doit être prise publiquement et tous les membres peuvent participer au-x débats et décisions : session ad-hoc, groupe de travail, retrospectives, etc.
"Make the Implicit Explicit" :
Trust but Verify
Agilité
Manifeste Agile: On essaie de suivre les principes du manifeste agile
collaboration avec les clients > négociation contractuelle
adaptation au changement > suivi d'un plan
Action Readiness
cf Definition of Ready pour rentrer un ticket dans le backlog
cf page dédiée pour "Definition of Done"
Acceptance Criteria à revisiter
Devops
Release Process
code review sauf si "expedite"
tests de composant lors du build
tests niveau composant et système après déploiement sur un env, rollback et notification si échec
approbation manuelle pour déploiement en prod
blue-green / canary et contrôle de bascule du traffic à prévoir à revisiter (patterns de déploiement sûrs)
single-click rollback
roll back automatiques à revisiter (sous quelles conditions on rollback, notifications on fait quoi du code ?)
full automatique, aucune action manuelle pour les actions
You Build it, You Run It
Pas de séparation dev / ops. Les devs s'occupent de la prod, du run et de répondre aux incidents. On peut mettre en
Craftspersonship
TDD / Test-First : et écrire les tests / vérifications / attendus avant de commencer le travail de manière générale
Pair & Mob Programming
Clean Code: On essaie de suivre, de manière pragmatique, les principes de Clean Code
Tests
fonctionnels : unit, "integration", composant, système / e2e, acceptance (à quel-s niveau)
cross-fonctionnels : perf (à détailler),
coverage: discussion & spike à prévoir sur un pourcentage minimum et une inclusion ou non à une quality gate.
You build it, you test it: l'écriture des tests est une responsabilité conjointe (3 amigos), mais l'écriture du code de test, sa bonne éxécution, sa fiabilité et son maintien est la responsabilité du dev.
Dette Technique
On évite d'en créer autant que possible
On se permet de le faire : création d'un ticket de remboursement de dette technique. Peut nécessiter un spike technique. Gouvernance à prévoir
Refactoring
Au fil de l'eau pour les refactos simples
Ticket quand c'est plus long ou si ça nécessite un spike technique
Quid de quand on tend plus vers le redesign / rearchitecture ? Ateliers, spikes, POCs et tickets à prévoir
Code Review
expedite: pas d'approbation si trivial ou particulièrement urgent.
etiquette de review à revisiter (show-stopper ou pas, reporter à PR de follow-up, ouverture de ticket, etc.)
p-e fait à n'importe quel moment
Design
Lors d'une "première tâche", s'accorder sur le design et la manière dont la tâche va être implémentée avec le reste de l'équipe ou un "responsable".
Documentation
Remplacer la Documentation par de l'Automatisation autant que possible
Des contrôles automatiques
Génération de la doc
Quand est-ce qu'elle est nécessaire ? Prérequis de PR, US, tâche, etc. ? Dans le DoR / DoD des work items ?
à revisiter
à compléter
Détails Techniques
Bug fix
Clean your own mess. Qqun d'autre peut s'en occuper, mais ça n'est ni attendu, ni demandé, sauf circonstances exceptionnelles.
PR sizing
Keep them as small as possible
Single focus - ne pas mélanger ajout fonctionnel et (grosse) refacto
Rester pragmatique - les petites refactos opportunistes mélées aux changes, ça passe.