Les Objectives and Key Results sont une méthode pour décider des objectifs d'une entreprise et comment les mesurer.

En gros plutôt que de se concentrer sur le résultat, on se concentre sur ce que l'on veut améliorer puis les équipes proposent des idées et testent des choses pour remplir ces objectifs. Les résultats sont analysés avec les Key Results.

Exemple:

Objectif: Améliorer l'efficience de la plate-forme IoT
Key Result #1: Réduire le temps de configuration de 50%
Key Result #2: Corriger 90% des bugs en moins une semaine

Un article qui parle du cloisonnement malheureusement trop fréquent entre les idées de nouvelles fonctionnalités qui sont ingérée par un Product Manager qui décide seul de celles qui doivent être ajoutées au backlog.

Ça peut paraître évident pour certaines organisations mais l'équipe Tech doit être impliquée dans cette phase de triage afin d'avoir un avis technique mais aussi pour améliorer l'ownership de l'équipe

Très bonne analyse de ce qui me dérange dans SCRUM et le fonctionnement par sprints.

• Manque de souplesse car travail découpé en sprint inamovibles
• Perte de temps à estimer les tâches précisément

C'est le résultat d'une étude lancé par Google en 2012.

Les deux comportements des équipes qui fonctionnent le mieux sont:

• liberté d'expression: prise de parole et partage de point de vue
• empathie

Ces deux facteurs amène une sécurité psychologique qui améliore la qualité de vie au travail et aussi la productivité.

Meetup du CTO de BAM sur leur méthode pour réduire l'incertitude dans les cycle de développement.

En gros on est sur du développement centré autour des Epic (features) et non plus des Users Stories.

Mais surtout leur méthode implique de la modélisation de la logique applicative avec un subset de BPMN (ça ressemble à des diagrammes).

Ce langage commun utilisé par tous permet d'identifier les edge-case, de faire valider les features par le client, de discuter autour d'une feature, etc

Dans notre métier on a souvent envie de tout recommencer à 0, de faire un "gros refactor", de changer de stack technique.

Seulement si c'est fait pour les mauvaises raisons il y a de grandes chances que ça échoue et/ou coule le business.

Tant qu'il n'y a pas de contraintes techniques fortes il vaut mieux faire évoluer son legacy.

Un article qui tacle un peu la tendance d'avoir des CTO / VPE plus dans le management pur que la technique.

Il donne notamment 5 raisons:

• les capacités technique permettent un meilleur jugement sur les personnes ou les systemes
• l'importance de comprendre les enjeux d'un compromis
• plus de facilité à gagner le respect des équipes
• la passion pour la technique apporte une meilleure vision et plus de motivation
• plus facile de recruter des ingénieurs qualifiés

Un article assez critique sur l'organisation habituelle des Product/Feature Team.

Une de ses critique est que les Feature Team devraient plutôt se focaliser sur des problèmes à régler pour améliorer le business que sur des roadmap avec des features priorisées.

Il insiste aussi sur le rôle du Product Manager qui doit avoir une connaissance approfondi:

• du client
• de la donnée
• de l'industrie
• du business en particulier

Il a un rôle de designer du produit et de facilitateur car l'objectif est toujours de responsabiliser les équipes au maximum pour améliorer l'implication.

Un outil pour release automatiquement et gérer les releases Github via des labels sur les Pull Requests.

L'outil est très complet et supporte tout pleins de choses:

• releases canary (test) ou next (release candidate en plus des releases normales
• création des labels sur les repo
• support des anciennes versions majeures

Le fonctionnement de Gitlab en async.

Leur handbook est juste une mine d'or de bonnes pratiques, j'aime beaucoup la page Communication aussi

Un excellent document qui parle de tests unitaires et tests fonctionnels.

En règle général, il vaut mieux se concentrer sur les tests fonctionnels plutôt que les tests unitaires car ces derniers sont très couteux à maintenir, notamment leur de remaniement de l'architecture du code.

Quelques extraits:

Few developers admit that they do only random or partial testing and many will tell you that they do
complete testing for some assumed vision of complete. Such visions include notions such as: “Every line of code has been reached,” which, from the perspective of theory of computation, is pure nonsense in terms of knowing whether the code does what it should.

Tests should be designed with great care. Business
people, rather than programmers, should design most functional tests. Unit tests should be limited to those that can be held up against some “third-party” success criteria

The purpose of testing is to create information about your program. (Testing does not increase
quality; programming and design do. Testing just provides the insights that the team lacked to do a correct design and implementation.)

Don’t underestimate the intelligence of your people, but don’t underestimate the collective stupidity of many people working together in a complex domain.

Article très intéressant sur une sorte de classification des développeurs.

Cela se base sur le ratio entre savoir et expériences.

Junior: Un peu de savoir et aucune expérience.

Middle: Moyennement de savoir et un peu d'expérience

Senior: Beaucoup de savoir et d'expérience, légèrement plus d'expérience

Un article intéressant de Spotify qui avait besoin d'une manière de visualiser correctement les interactions entre leurs centaines de services.

Ils n'ont pas utilisé UML (thanks god!) mais plutôt le C4 Model qui est un diagramme à 4 niveaux:

• Contexte: comment s'intègre notre système avec d'autres systèmes (service mail externe, autre système métier, etc)
• Containers: quels sont les principaux composants de notre système (app mobile, base de données, frontend admin, etc)
• Components: principales briques métiers de chaque container (CartController, EmailService, etc)
• Code: classes composants les briques métiers

Je connaissais pas mais ça à l'air d'être un outil approprié pour définir visuellement des systèmes très complexes tout en offrant la possibilité de "zoomer" dans des niveaux plus détaillés

Un article présentant un framework pour micro-frontend avec tout le tooling pour se simplifier la vie.

Attention car même avec Piral, gérer un ensemble de micro-frontend est beaucoup plus compliqué.

Une telle décision d'architecture doit se reposer uniquement sur un besoin d'organisation d'une grande équipe en plus petites équipes focalisée sur un domaine de l'application.

Plus d'info sur les micro-frontend https://links.aschen.tech/shaare/AuKMeA

Une bonne introduction aux micro-frontends.

Finalement ça répond au même besoin que les micro-services, pouvoir scale son produit en plusieurs équipes qui peuvent travailler de manière indépendante sur des parties du produit.

Les micro-frontends sont au frontend ce que les micro-services sont au backend.

A utiliser avec parcimonie donc

Un excellent article à propos de la recherche de vos "vrai" concurrents.

Plutôt que de chercher les produits qui ressemblent au votre, il faut chercher les produits qui répondent aux même besoin que le votre.

Par exemple, pour Netflix, son plus gros concurrent ce n'est pas Amazon ou Hulu mais bien Fortnite!

Un site qui regroupe les anti-patterns de nommage des variables.

Par exemple, une fonction qui s'appelle getXXX mais qui ne retourne rien dans certains cas et mute directement un argument.

C'est plein de bon sens et à lire en complément de la recherche sur le naming des variables

Super résumé du fonctionnement des BSPCE, de comment les évaluer, les mettre en place, les pièges à éviter, etc

En gros, les BSPCE sont des bons qui donnent le droits d'acheter des actions à un prix définit.

Si on vous donne un BSPCE en 2022 avec un prix d'achat à 10€, alors vous aurez le droit d'acheter une action à 10€ à partir d'une date fixée par le contrat.

L'article termine avec d'autres modes de fidélisation des employés, par exemple des augmentations décidées à l'avance chaque année.

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