Dans le dernier billet du blog « 5 Practices that help with agile software development », nous avons déjà parlé du travail de l’équipe de développement et de ce qu’il faut changer pour qu’elle fonctionne mieux. Dans ce poste, nous examinons l’interaction des équipes de développement avec le soutien et la gestion.
Sommaire
L’organigramme
Nous avons des équipes auto-organisées qui construisent des produits. Je l’ai illustré dans l’image ci-dessous :
Les équipes de produits vertes construisent les produits et l’équipe de soutien rose soutient les autres équipes. Ces produits peuvent aller du logiciel au matériel informatique. Un produit est défini par le fait qu’il y a un utilisateur (usager) qui tire un profit du produit. Sa vie devient meilleure, plus facile ou il peut faire son travail plus rapidement grâce au produit.
Dans le contexte général, cela ressemble à ceci :
Les utilisateurs sont marqués en rouge (il est à espérer qu’ils sont nombreux, car c’est généralement un signe de la réussite du produit).
La direction a marqué en gris. J’entends par là toutes les fonctions de soutien qui existent généralement dans une organisation : RH/Ressources humaines, Ventes, Distribution, Marketing, Contrôle de gestion, Paie, Informatique interne, Leadership sur site, Feel-Good-Officers et Management.
Si nous disposons d’un organigramme comme celui présenté ci-dessus, nous avons déjà réalisé beaucoup de bonnes choses :
- Le client est si important pour nous qu’il figure également dans notre organigramme. → Cool
- La gestion est placée en dessous. Cela suggère qu’ils aident leurs employés à faire du bon travail. → Cool
Retour à l’abus de confiance…
L’algorithme de confiance selon Larry Maccherone
Dans ce contexte, l’algorithme de confiance de Larry Maccheronee est un bon concept. Librement traduit de ma part, il ressemble à ceci :
Les différents termes doivent être compris comme suit :
- Crédibilité = Dans quelle mesure savez-vous réellement de quoi vous parlez ?
- Fiabilité = À quelle fréquence et à quelle vitesse faites-vous ce que vous dites ?
- Empathie = Dans quelle mesure montrez-vous que vous vous souciez des intérêts des autres.
- Intérêt personnel = Est-il évident que vos paroles et vos actes sont dans votre propre intérêt ?
Pour l’instant, je ne veux pas trop m’attarder sur le thème de la confiance. Toutefois, pour tous ceux qui souhaitent approfondir ce sujet, je peux recommander le cours « Professional Scrum Master », par exemple.
Pourquoi la direction ne nous fait pas confiance et comment nous pouvons changer cela
Si l’équipe de développement souhaite faire une Mêlée, mais qu’elle n’y est pas vraiment autorisée…
Si nous voulions être agiles, mais que quelqu’un nous en empêche…
… alors c’est généralement de notre faute, et c’est souvent lié à notre fiabilité.
Posons-nous la question :
- Pouvons-nous déployer en permanence des logiciels stables en production ?
- Sommes-nous très peu (<5%) préoccupés par les incidents et les bugs ?
- Pouvons-nous présenter les chiffres du marché, des utilisateurs, des démonstrations et des caractéristiques de nos produits dans une revue Sprint toutes les deux semaines ?
Les réponses à ces questions ont une grande influence sur notre fiabilité. Parce que nous, l’équipe de développement, sommes endettés. En anglais, on dit « Walk the Talk ». Cela signifie que les paroles doivent être suivies d’actes.
Nous devrions donc réfléchir à la manière dont nous pouvons obtenir une plus grande fiabilité, car c’est ainsi que nous pourrons nous rapprocher du client et faire preuve d’empathie. Cela renforce notre crédibilité, car nous parlons sa langue et montrons que nous sommes tous dans le même bateau. Après tout, nous sommes une entreprise et il est également dans notre intérêt que tout se passe bien. N’est-ce pas ?
5 étapes pour plus de fiabilité
Pour accroître la fiabilité, je recommande les mesures suivantes :
1 Une définition claire du terme « fait » par produit
Vous pouvez lire ici comment une tâche est définie comme terminée.
2 Une intégration continue par produit
L’intégration continue est une pratique technique où tout changement de produit (code, configuration) doit déclencher un événement qui reconstruit, intègre et teste automatiquement l’ensemble de votre produit. « Plus d’informations sur l’intégration continue
3 Une livraison stable et continue par produit
La livraison continue signifie que le système est toujours maintenu dans un état prêt à la production pendant le développement, en attendant la libération du propriétaire du produit, afin de mettre le produit entre les mains de l’utilisateur avec un minimum d’effort. « Plus d’informations sur la livraison continue
4 Déploiement continu et suivi technique en production
Le déploiement continu signifie, en plus de l’intégration continue, la prise en charge ou le déploiement automatique de chaque changement de produit dans la production. Le statut « déployé » (distribué) est une préoccupation technique qui s’applique à l’équipe et signifie que le produit a été déployé dans un environnement sélectionné. Les différents environnements ont des communautés d’utilisateurs différentes : production, environnement de test et environnement d’intégration.
5 Surveillance des utilisateurs et résolution des incidents en direct
Où en êtes-vous sur ces cinq étapes ? Et que vous manque-t-il pour la prochaine étape ? Dans le cadre du cours « Professional Scrum Developer », nous vous montrerons comment le faire à l’aide d’un exemple pratique pendant trois jours.
