Les 4 différentes organisations possibles avec un architecte (la dernière c'est ne pas avoir d'architecte du tout)
De mon expérience, tant que les membres de l'équipes (AKA les développeurs) sont aussi capable de faire l'architecture alors on a la meilleure configuration possible car les mêmes personnes réfléchissent aux choix architecturaux et à la manière de coder.
Il vaut toujours mieux réduire la bureaucratie et se concentrer sur ce qui apporte vraiment de la valeur au produit, c-a-d les lignes de codes produites pour réaliser une fonctionnalité.
Une liste des erreurs les plus courantes lors de la mise en place de processus Agiles.
Mon top:
- Focus on output: ce qui compte c'est l'impact réalisé par les livrables et non les livrables eux-mêmes
- Agile is IT only: l'ensemble des équipes (marketing, sales, product) doivent travailler en Agile
- Implementing immutable processes and tools: la base de l'Agilité c'est justement la capacité à évoluer
Si on résume la pensée de l'article, être Agile c'est:
- Focus sur la valeur ajoutée aux clients
- Implication forte des équipes au plus prêt du produit
- Être capable de constamment remettre en question le mode de fonctionnement
L'article revient sur toutes les raisons qui font partir les employés d'une organisation.
Les plus importantes de mon point de vu:
- employer des managers qui ne savent pas faire de logiciels ou trop de managers
- mauvaise specification des tâches
- trop de réunions (voir manager vs maker schedule)
Les 3 métiers du Product Management
- Product Manager
- Product Designer
- Product Owner
L'article parle des tâches et responsabilités de chaque rôle puis fait un focus sur les missions du Product Manager: concevoir, piloter et délivrer un produit.
Vous êtes plus exposé au burnout si vous avez:
- de trop grandes attentes
- un grand besoin de reconnaissance
- besoin de faire plaisir aux autres
- du mal à déléguer
- surtout le travail en tant qu'activité
81% des développeurs ont fait un burnout (déclaré officiellement ou pas) pendant la pandémie de covid
Une technique simple et efficace pour créer des liens et faire circuler les idées: choisir un sujet et préparer des questions pour en débattre pendant 30 min
Un bon article sur la collaboration entre le métier et la technique
Comment lutter contre la frustration et le syndrôme de l'imposteur que peuvent avoir les nouveaux tech leads recrutés.
Bonnes pratiques pour optimiser les réunions dans son entreprise.
Pleins d'excellent conseils de Gitlab pour éviter le burnout
Excellente vidéo sur la revue de code.
- Vous n'êtes pas votre code: laissez votre égo de côté
- Vous embarquez votre status social en revue de code
- Soyez empathique
Désavantages imprévus de la revue de code:
- perte d'ownership des développeurs sur leur code
- moins d'opportunité d'apprendre de ses erreurs
Un board Jira contient des tickets représentant des hypothèses de création de valeur pour un client.
Comme pour tous, il n'y a pas de dogme. Il ne faut pas hésiter à challenger un board Jira en gardant en vue l'objectif principal: créer de la valeur pour le client
Article intéressant pour évaluer des KPI pour une équipe projet
- Earned Business Value: nombre fixe de points à répartir entre vos features et leurs sous tâches
- Cycle Time: temps nécessaire pour réaliser une feature
- Cumulative Flow: répartition des tâches en fonction des états (todo, in progress, done, etc)
Article du CTO de Alan et de son évolution dans une startup passée de 2 à 500 personnes en 6 ans.
Il parle notamment de "se virer" tous les 6 mois d'une partie du produit pour passer la main et faire avancer une autre partie de l'entreprise
Sur quoi faut-il porter son attention lors d'une revue de code
La Quick Response Team (QRF) est en charge de la gestion des priorités qui arrivent au fil de l'eau et permet ainsi au reste de l'équipe de se concentrer sans interruption sur des tâches plus conséquentes
Article très intéressant qui compare l'emploi du temps d'un manager et celui d'un "maker" (par exemple un développeur).
TLDR;
Les "makers" ont besoin de se concentrer dans des périodes de temps plus longues et parfois une simple réunion au millieu de l'après-midi est suffisante pour perturber la productivité de l'après-midi entière.