Agilité

Les Rôles Agiles

Ce qui suit est le transcript d’une présentation que je suis en train de préparer consacrée à la différences entre Rôles Traditionnels et Rôles Agiles au sein des équipes de développement informatique.

1 – Le mouvement Agile

La confluence de différents courants

  • Industrie: Lean, Cercles de qualité
  • Sciences: théories de l’émergence, cybernétique, systèmique
  • Psychologie: travaux sur la motivation, l’engagement individuel
  • Education: Fresnet, Montesori
  • Informatique: RAD, prototypage rapide, tests unitaires
  • Social, Politique: logiciels libres, Internet, communisme, anarchisme

Le rejet du modèle industriel pour le développement informatique

  • le modèle de l’usine ne convient pas à l’informatique
  • la conception et la mise en production ne sont pas distinctes
  • on ne fait jamais deux fois le même logiciel
  • les spécifications sont imprécises et changeantes
  • le paysage et l’environnement technique changent constamment.
  • un logiciel peut être mis à jour, pas un produit manufacturé

L’ Agile : sélectionner les meilleures pratiques (1)

  • développement par itérations ou sprint,
  • développement incrémental, objectifs courts
  • daily standup meeting (aka daily Scrum),
  • User Stories,
  • kanban (tableau d’affichage), burndown charts
  • retrospectives,

L’ Agile : sélectionner les meilleures pratiques (2)

  • integration continue, (tests automatisés)
  • livraison continue (toujours prêt pour la mise en production)
  • amélioration continue (des pratiques)
  • product backlog,
  • code smells, refactoring,
  • pair programming, revues de code

Le mouvement Agile : des méthodes convergentes

  • Lean
  • Kanban
  • eXtreme Programming
  • Scrum
  • Adaptive Software Development
  • Crystal
  • Feature Driven Development

Le manifeste Agile

  • Dégage les valeurs et principes communs aux approches précédemment indiquées,
  • met l’accent sur certaines valeurs et principes – parmi quantité de possibilités – que les Agilistes trouvent importants.
  • texte synthétique écrit à l’occasion d’une conférence en 2001.

Gros succès commercial : SCRUM

Le succès rencontré par SCRUM est probablement autant lié à son mode de propagation via des consultants « Scrum Master » qu’à ses qualités intrinsèques.

Attention: faire appel à un consultant Scrum ne suffit pas à être Agile.

C’est un peu comme le bio, le Scrum Master c’est l’étape conversion bio, mais les écueils sont nombreux et changer la culture d’une organisation est difficile. Lorsque l’agilité est « plaquée » surune entreprise pour des raisons de mode elle risque fort de rester une simple fiction, l’entreprise adoptant certaines pratiques ou rituels mais sans en retirer les bénéfices.

L’Agilité a un impact fort sur la culture d’Entreprise (1)

Raconté par Ken Schwaber (SCRUM) dans « The Enterprise and Scrum ».
À Adventure Works un produit commençait à émerger via des incréments réguliers de haute qualité. Le responsable du management avait imposé un rythme soutenable de 8 h par jour pour tous les employés.

La companie était une filliale d’une société japonaise. Pour un management Japonais une journée de travail de 8 h était inacceptable: les japonais ont donc demandé le retour à la journée de 12 heures.

L’Agilité a un impact fort sur la culture d’Entreprise (2)

Les défauts constatés ayant augmenté de 60%, le manager est revenu à la journée de 8h.

Voyant des parkings vides et des bureaux éteints les japonais ont conclus que les employés étaient paresseux et recommandé à la société mère de vendre la compagnie.

Deux mois après son rachat par les américains le produit a été mis sur le marché et rapporté deux fois le prix du rachat de la société.

L’Agilité a un impact fort sur la culture d’Entreprise (3)

Certains choix de managements de haut niveau relèvent des préjugés culturels des organisations. Ils peuvent compromettre la mise en place de l’agilité.

Le manifeste Agile est aussi une sorte de préjugé et ne devrait être jugé que sur ses résultats.

2 – Une distribution des rôles différente

Identifier un Agiliste en une seule question

Quel est votre job ?

  • Agiliste: je développe tel produit, puis commence à décrire le produit.
  • Traditionnel: Je suis un Architecte/Testeur/Analyste/Développeur/Chef de projet pour telle société.

Découpage systémique vs découpage par spécialité (1)

  • le but de l’équipe Agile est de créer un produit (un logiciel informatique)
  • la vision d’ensemble est partagée (par le Product Owner)
  • le produit (long terme)
  • l’objectif de l’itération (court terme)
  • l’équipe livre de la valeur client de bout en bout
  • User Story = cas d’usage détaillé
  • les US décrivent comment tester (des observables utilisateurs)

Découpage systémique vs découpage par spécialité (2)

  • tout le monde est responsable du bon fonctionnement du produit
  • à minima: en cas de problème on répare
  • pas très important de savoir qui a provoqué le problème
  • mais on peut réfléchir ensemble pour éviter que ça se reproduise

Découpage systémique vs découpage par spécialité (3)

  • si différentes technologies sont nécessaires l’équipe les maitrise toutes
  • développeurs full-stack: de l’interface utilisateur à la base de données
  • ou bien des spécialités qui se complètent au sein de l’équipe
  • maîtrise des languages et outils de programmation nécessaires

Découpage systémique vs découpage par spécialité (4)

  • les membres de l’équipe changent de « casquette » selon les besoins
  • tour à tour: développeur, analyste, architecte, testeur, manager, administrateur de base de données, designer web, etc.
  • pas d’équipe ou d’individu dédié à un rôle spécifique, mais des domaines de plus ou moins forte expérience/compétence

Développement Traditionnel: Spécialisation et division des tâches par spécialité

  • je noircis volontairement le tableau coté traditionnel
  • (et l’enjolive pour les équipes Agiles)

Traditionnel: Découpage par spécialité

  • chaque équipe ou individu à un rôle bien précis et n’en déborde pas
  • les développeurs sont souvent spécialisés dans une technologie précise
  • livraisons partielles et généralement technique à d’autres développeurs
  • chacun n’est responsable que de « sa partie »

Traditionnel: Découpage par spécialité : c’est pas ma faute! (1)

  • en cas de problème chacun essaye de rejeter la faute sur les autres

Traditionnel: Découpage par spécialité : c’est pas ma faute! (2)

  • « ce n’est pas un bug c’est ce qui était prévu, c’est l’analyse qui est mauvaise« .
  • « les spécifications ne sont pas assez complètes« 
  • « les développeurs ne testent pas assez leur code avant de l’envoyer à la QA« 
  • « je ne connais pas la technologie utilisée par l’autre équipe« 
  • « le manager a fixé un délai trop court« 
  • etc.

Equipe Agile : sans hiérarchie avec un but commun

  • l’équipe Agile : tous sur le même plan, auto-organisée (idéal anarchique)
  • le Client (Product Owner) décide quel produit faire
  • l’équipe de développement : décide comment réaliser les souhaits du Client
  • l’équipe s’engage et elle est redevable de ses résultats devant son Client

Equipe Agile : développemen incrémental

  • le développement est incrémental:
  • soit d’ajouter des fonctionnalités
  • soit modifier l’état précédent du produit,
  • mais toujours en donnant des objectifs concrets et testables
  • l’effet d’un échec est minimisé en se limitant à des objectifs à court terme.

Théorie : une équipe polyvalente

  • En théorie une équipe Agile est totalement polyvalente
  • n’importe quel membre peut tenir n’importe quel rôle.
  • rarement vrai en pratique
  • l’équipe s’organise, avec des rôles spécialisés
  • souvent proches des rôles traditionnels.

Théorie: l’échec fait partie du processus (1)

  • L’échec (à un objectif précis dans le cadre d’une itération) est un résultat possible et normal
  • c’est le cas de toute User Story non entièrement réalisée dans une itération.
  • Il n’y a pas d’échec partiel
  • c’est un échec de l’équipe
  • la tâche est mal définie ou trop complexe
  • il manque des compétences
  • les membres de l’équipe disposant des compétences n’ont pas pu se rendre disponible
  • il fallait plus de temps

Théorie: l’échec fait partie du processus (2)

  • Chaque échec (ou réussite) est une opportunité
  • d’apprendre des choses sur le produit
  • sur les compétences de l’équipe.
  • Il doit être valorisé plutôt que sanctionné.

Théorie: l’échec fait partie du processus (3)

  • A l’issue de l’itération le Product Owner décide
  • soit de continuer à essayer
  • de faire autre chose.
  • le modèle est basé sur la confiance mutuelle
  • chacun fait sa part au mieux de ses talents.

Théorie: l’échec fait partie du processus (4)

  • Les individus problématiques sont traités comme tels
  • indépendamment de la réussite ou échec des objectifs intermédiaire.
  • on cherche à les aider à fonctionner au mieux de leurc capacités
  • relève du travail de coaching

Pragmatique : des généralistes avec une spécialités

  • Présenter l’équipe Agile comme polyvalente laisse croire que tous ses membres devraient être identiques.
  • C’est angoissant pour des spécialistes se convertissant à l’Agilité…
  • illusion: l’équipe est polyvalente, pas forcément les individus
  • on supprime les barrière des définitions de poste spécialisée.
  • les individus travaillent dans leur domaine de compétence… si c’est utile à l’équipe.
  • ou apprennent de nouvelles compétences

Du poste classique à son équivalent Agile

Les rôles de spécialistes classiques ont des équivalent Agiles.

Les slides qui suivent présentent comment les rôles classiques se transforment.

Manager / Chef de Projet (Traditionnel)

  • le manager (ou le chef de projet) est le seul responsable de la livraison du produit
  • rédige le cahier des charges, s’engage sur les délais le budget
  • définit les dates de livraisons (à long terme: livraison du produit)
  • définit le périmètre fonctionnel (à long terme ensemble des fonctions du produit)
  • suit le dossier, intermédiaire entre équipe de développement et client
  • les ressources sont généralement fixées (équipe, argent)
  • rends des comptes à sa hiérarchie sur les délais le budget
  • participe ou non lui même au développement
  • distribue les tâches individuelles
  • gère son équipe pour chaque tâche et chaque individu

Transformation : le « Manager » classique est une fonction vague et devient plusieurs rôles Agiles plus définis

  • Chef de Projet Agile (ou Project Manager) : se concentre sur l’objectif du produit à atteindre
  • plutôt un rôle interne à l’équipe
  • Manager Agile, plutôt un rôle hiérarchique externe à l’équipe: pas de tâche de développement, mais un interlocuteur.
  • C’est à lui qu’on rend des comptes.
  • Représente le commanditaire ou les actionnaires: interlocuteur pour les moyens, les budgets
  • Coach Agile (Scrum Master) : se concentre sur l’organisation de l’équipe et les processus.
  • Attention: confondre ces rôles est délicats, car il existe des conflits d’intérêts entre eux (risque par exemple de définir à la fois la dead line et les moyens ou d’imposer un processus à l’équipe.

Chef de Projet Agile : ce qu’il fait (1)

  • suivi du projet, suivi des activités de l’équipe: vélocité, burndown charts
  • vision d’ensemble de l’avancement et prévision de livraison : Master Story List
  • communique l’avancement du projet et les prévision au reste de l’entreprise: commerciaux, actionnaires, marketig, etc.

Chef de Projet Agile : ce qu’il fait (2)

  • protège l’équipe des pressions extérieures négatives en cas de difficultés
  • prend en charge les difficultés pratiques quotidiennes:
  • locaux, ordinateurs plus performants, logiciels ou documentations nécessaires,
  • planification des tâches annexes (hors US) : refactoring lié à une dette technique, infrastructure, corrections de bug ou support technique niveau 2
  • rappelle les User Stories oubliées par le Product Owner (exemple: tâches techniques préalables à la réalisation de User Stories fonctionnelles)

Chef de Projet Agile : ce qu’il ne fait pas (1)

  • pas d’affectation des tâches individuelles, les membres de l’équipe prennent les tâches définies pour l’itération en cours.
  • pas de micro management des individus, il gère le projet pas les individus.
  • la pression collective et les démos suffisent normalement à motiver les individus
  • les problèmes individuels (défaut d’engagement, de comportement, de compétences par exemple) sont à discuter entre le Scrum Master ou le Coach Agile et l’individu concerné, généralement en 1-to-1, pas à régler par le Chef de Projet.
    Le Chef de projet se concentre sur le projet.

Chef de Projet Agile : ce qu’il ne fait pas (2)

  • Il ne doit pas servir d’intermédiaire obligé (obstacle) entre les demandes du client (PO) et l’équipe
  • il peut faciliter le dialogue si c’est utile.
  • Un contact direct programmeur/client est préférable.
  • un bon Chef de Projet Agile devrait pouvoir partir en vacances une semaine ou deux sans que cela change grand chose au fonctionnement de l’équipe (ni même que personne s’en rende compte).
  • le projet continue à avancer
  • les gens travaillent comme d’habitude

Coach Agile : ce qu’il fait (1)

  • Organisateur des différentes réunions et rituels d’équipe: Daily Scrum, Réunion de début d’itération, rétrospective, etc.
  • observe l’équipe et cherche les difficultés et points d’amélioration : pb de compétences, d’engagement, de comportements. Doit respecter une stricte neutralité, force de propositions (mais n’impose rien)

Coach Agile : ce qu’il fait (2)

  • coache les individus en 1-to-1 (pour améliorer des comportements, jamais par rapport à des objectifs individuels de production ou d’efficacité).
  • interface avec le reste de l’entreprise pour les sujets organisationnels

Coach Agile : ce qu’il fait (3)

  • force de changement: primordial pour les conversions Agiles (Form/Storm/Norm/Perform), moins indispensable pour les équipes matures (le rôle peut être tenu par un membre de l’équipe ou tourner)

Coach Agile: ce qu’il ne fait pas

  • rentrer dans la technique du produit
  • prendre la responsabilité des livraisons, tenues de budget
  • pas de micro-management individuel, d’affectation de tâches
  • peut aider à rédiger les User Stories (au niveau formalisation pas celui du contenu)
  • peut tenir des graphes d’avancement ou de vélocité, mais attention pas de mesures individuelles.

Manager / Chef de Projet Traditionnel: les leviers du Chef de projet

  • levier principal: demander plus de ressources en début de projet
  • levier secondaire en cas de retard: allonger les journées des développeurs
  • en cas de retard on ne peut jouer ni sur les fonctions ni sur les délais: ils sont souvent contractuels
  • levier secondaire en cas de retard: la qualité n’est pas contractuelle: on essaye de jouer dessus
  • les leviers secondaires aggravent généralement le problème (cercle vicieux)

Les leviers du Chef de projet Agile (1)

  • la Master Story List : (outil d’action)
  • de taille limitée, quand un item rentre, un autre doit sortir
  • ou bien la date de livraison changer (la taille de la MSL augmente)
  • ajouter des ressources est généralement inefficace et n’agit qu’après un délai
  • jouer sur la Qualité (Definition of Done) ou temps de travail a généralement l’effet inverse (accroît les problèmes). Pas un levier.

Les leviers du Chef de projet Agile (2)

  • la velocité: (outil de mesure)
  • se mesure en points ou tailles de T-shirt, surtout pas en temps
  • mesure des performance d’équipe,
  • dans la durée d’une itération l’équipe est capable de réaliser un certains nombres de points de User Story
  • permet d’anticiper sur les dates de livraison, détecter les dérapages

Les leviers du Chef de projet Agile (3)

attention: surtout pas une mesure de performance individuelle: nuit à la communication, concurrence, plus de bugs, moins de collaboration, moins de compétences, moins de partage des connaissances… chacun sa merde

Les leviers du Chef de projet Agile : la vélocité (4)

attention:

La vélocité est un résultat du fonctionnement de l’équipe: chercher consciemment à l’augmenter est délétère. Les résultats sont imprévisibles. Même embaucher dans l’équipe peut réduire la vélocité.

On modifie les ressources ou les processus pour répondre à un besoin, pas pour changer la vélocité.

Tout changement dans l’équipe ou les pratiques peut avoir des conséquences imprévisibles sur la vélocité, ce n’est une mesure utile que pour les équipes stables

Les leviers du Chef de projet Agile: le Rôle du Tracker (1)

  • le Tracker est un rôle Agile décrit dans eXtreme Programming sans équivalent direct en Scrum. Il a pour but de détecter des difficultés individuelles (US qui n’avancent pas) avant qu’elles deviennent problématiques.
  • Eviter un responsable hiérarchique comme tracker (stresse généralement le programmeur)
  • En Scrum ce type de problème est supposé remonter lors du Daily Scrum (dans la pratique ce n’est pas toujours vrai)

Les leviers du Chef de projet Agile: le Rôle du Tracker (2)

  • la difficulté peut être technique (problème difficile, mauvaise compréhension, mauvaise approche, connaissances techniques manquantes) ou personnelles ou émotionnelles (événement extérieur perturbateur, désintérêt du sujet et manque de motivation). Les difficultés des développeurs font les US qui n’avancent pas.
  • la qualité principale du Tracker c’est son contact et la confiance qu’on lui accorde, pas forcément sa compétence technique. Les discussions avec lui ne doivent ni dériver en discussions techniques ni stresser le programmeur.

Les leviers du Chef de projet Agile: le Rôle du Tracker (3)

  • l’équipe a le devoir d’assister les User Stories en difficulté: réorganiser le travail, réaffecter les tâches, modifier la User Story avec le PO pour tourner la difficulté.
  • La prise de décision sur quoi faire ne relève pas du tracker (elle relève du Manager en mode traditionnel, c’est une responsabilité d’équipe en Agilité).

Les leviers du Chef de projet Agile: le Rôle du Tracker (4)

  • éviter les coupables ça ne sert à rien…
  • Toute équipe a son « boulet ». S’il part un autre prendra sa place.
  • Ils peuvent généralement s’améliorer. S’en débarasser risque de briser la confiance dans l’équipe.
  • Ceux qui ne s’améliorent pas partent souvent d’eux-même, ce n’est pas une place confortable.
  • possibilité de quitter l’équipe sans quitter l’entreprise

Vision traditionnelle de l’Analyste Programmeur (1)

  • les développeurs plus diplômés, plus expérimentés vont plus vers l’Analyse, l’Architecture produit, les développeurs débutants (ou moins qualifiés) vont plus vers la programmation.
  • la phase d’Analyse est clairement séparée de la phase de réalisation: séparation par individu, séparation dans le temps

Vision traditionnelle de l’Analyste Programmeur (2)

  • découpage des gros projets en équipes correspondant aux différentes couches : Interface utilisateur, back-end, etc.
  • équipes souvent liées à la technologie qu’elles utilisent : langages de programmation, bibliothèque
  • livrables partiels entre équipes
  • on peut retrouver la même organisation au niveau individuel à l’intérieur d’une équipe

Vision traditionnelle du programmeur

  • L’analyste et l’Architecte ont fait tout le travail de réflexion en amont: il n’a plus qu’à coder.
  • la programmation est vue comme l’analogue de la phase de fabrication dans une usine et le programmeur est l’ouvrier.

Vision Agile du programmeur

  • La vision Agile (théorisée par eXtreme Programming)
  • l’analogue de la fabrication c’est la compilation… qui est entièrement automatique.
  • la programmation est une phase de conception a part entière, qui s’attache plus aux détails qu’au plan d’ensemble.
  • Mais les détails sont importants.
  • Rôle central: le seul vraiment indispensable

Le développeur Agile (1)

  • le développeur Agile est tour à tour Analyste et Programmeur
  • Deux phases d’Analyse: l’une en amont lors de la création des User Story, l’autre en aval lors des choix d’implémentation.
  • pas la peine de passer trop de temps sur une analyse a priori : elle sera de toute façon mauvaise (principe 70/30 on peut parvenir à 70 de la solution idéale en 30% du temps… passer plus de temps avant d’expérimenter la solution ne sert quasiment à rien)

Le développeur Agile (2)

  • mettez en œuvre la première (la plus simple) solution qui a une chance de marcher
  • testez là et améliorez la ensuite si nécessaire
  • la qualité première du code est la capacité à être modifié, maintenu et amélioré
  • on repassera de nombreuses fois sur les mêmes portions de code dans le cadre d’améliorations incrémentales.

Développeur Agile: ce qu’il fait (1)

Il est responsable et prend des engagements vis-à-vis du client

  • indique le temps nécessaire pour réaliser une User Story
  • met en œuvre les User Stories: la mise en œuvre doit correspondre à ce qui est défini…
  • mais la définition de la User Story peut être modifiée, et le développeur doit en discuter avec le Client Interne/PO. Il peut aussi suggérer des simplifications.

Développeur Agile: ce qu’il fait (2)

  • participe aux réunions d’équipe
  • définition en équipe d’un travail « Terminé » (DoD: Definition of Done).
  • démo du produit au client interne, seul le client sait ce que le logiciel doit faire
  • éventuellement support niveau 2 (problèmes rencontrés sur les logiciels livrés et en exploitation).

Développeur Agile: ce qu’il fait (3)

  • codage des fonctions
  • tests unitaires des fonctions réalisées (TDD dans l’idéal), ce qui n’est pas testé n’existe pas.
  • amélioration continue du code (refactoring)
  • Attention: le refactoring est très dangereux sans tests unitaires

Développeur Agile: ce qu’il fait (4)

  • le but n’est pas de montrer ce qu’on a codé,
  • ni de présenter des schémas de principe
  • on cherche à réduire le Fragilité/ la Rigidité et l’Immobilité.
  • Fragilité: modification -> régressions
  • Rigidité: petit changement -> gros changements de code
  • Immobilité: factorisation de code -> tout casser
  • ce sont souvent des objectifs conflictuels.

Développeur Agile: ce qu’il fait(5)

  • objectif: transmission des compétences
  • réduire le truck number
  • principe de propriété collective du code: ne pas s’approprier telle ou telle partie du code du logiciel.
  • mais dans la pratique un développeur travaille plus facilement sur un code qu’il connaît bien
  • le Pair Programming ou les revues de code permettent de mitiger le problème.
  • assistance aux autres développeurs de l’équipe (Pair Programming, ou assistance ponctuelle).
  • Transmet ses compétences aux autres développeurs de l’équipe (autoformation).

Vision traditionnelle de la QA (Assurance Qualité)

  • en charge des tests fonctionnels du produit
  • le corollaire est souvent que les autres équipes testent peu ou pas … et écrivent encore plus rarement des tests automatisés
  • la QA perçoit sa responsabilité comme « ne pas laisser passer de bugs »
  • hostile aux changements (=risques)
  • hostile aux nouvelles fonctionnalités (=risques)
  • en bout de chaîne: subissent la plus forte pression de livraison
  • les développeurs voient l’équipe QA comme un coût … qui « vole » un temps précieux.

Testeur Agile, QA Agile

  • Le bras droit du client,
  • participe aux User Stories: comment les tester ?
  • ce pour quoi aucun critère de test n’a été défini n’existe pas
  • Définit et automatise les tests de recette
  • Conseille le client sur la testabilité d’une fonctionnalité
  • Utilisation d’outils différents pour scripter
  • Garant du sentiment de réussite sur le projet
  • Tests fonctionnel réussis
  • Progression
  • Communiquer pour motiver (graphique de progression…)

Testeur Agile, Compétences Requises

  • programmeur hétéroclite (doit maîtriser l’outillage de tests)
  • connaissances générales en écosystème informatiques: OS, clients Web, Réseaux, matériel, Smartphones, etc. doit comprendre l’environnement ou le logiciel va tourner.
  • rigoureux et intègre
  • Perle rare

Testeur Agile ce qu’il fait

  • suivi des tests et maintenance des tests: les tests sont aussi du code
  • définition des tests de recette (à partir des User Stories)
  • intégration continue (mesures de couverture de code, mesures de qualité et suivi des bonnes pratiques, etc.)
  • rythme durable: éviter les coups de bourre lors des livraisons, l’activité de test n’est pas une phase séparée

Le Client Interne Agile : Qui est-il ?

  • Pas nécessairement le client contractuel
  • Assistant à maîtrise d’ouvrage
  • Représentant des utilisateurs
  • A défaut quelqu’un pour agir comme client « artificiel »
  • Chef de projet
  • Ingénieur chargé des spécifications

Client Interne/Product Owner : ce qu’il fait (1)

  • Définit les objectifs, la vision produit à long terme
  • travaille avec l’équipe à élaborer les User Story
  • en communication permanente avec l’équipe de développement
  • en cas de doute ou d’ambiguïté, c’est lui qui sait
  • il définit les besoins fonctionnels, les priorités,
  • les contraintes de time to market (arbitrage sur quoi supprimer en cas de retard)

Client Interne/Product Owner : ce qu’il fait (2)

  • Tests de recette (avec le Testeurs):
  • But : préciser les contours des scénarios
  • Données concrètes levant les ambiguïtés
  • Preuve que le système fait ce qu’il demandait
  • A chaque fin d’itération tous les tests de recette doivent passer avec succès

Client Interne / Product Owner : ce qu’il ne fait pas

  • il ne définit pas les temps ou ressources nécessaires:
  • c’est de la responsabilité de l’équipe de dév
  • mais si les temps sont trop longs il peut devoir remonter l’information
  • c’est rarement le bon interlocuteur pour parler budget ou contrat

Client Interne / Product Owner : avantage du Feedback

  • Intégré à l’équipe de développement
  • Plus de cahier des charges vagues ou incompréhensible
  • Plus de démo truquée
  • Explique ce qu’il souhaite aux développeurs donc:
  • Vision plus rapide du résultat
  • Prise de conscience en cas d’erreur

L’Analyse Agile : focalisé sur les User Stories

  • l’Analyse Agile se focalise sur les User Stories,
  • les Users Stories Agiles sont beaucoup plus détaillées que les Use Case traditionnels,
  • elle sont au coeur de la définition fonctionnelle du produit.
  • Elles devraient être faciles/courtes à réaliser dans le temps pour tenir dans une itération
  • la difficultéde l’US est évaluée en points/tailles de T-Shirt au début de l’itération par les dev.
  • Libre au PO de créer des User Stories alternatives si le résultat ne le satisfait pas.

L’Analyse Agile : le danger de l’effet tunnel

Attention: il faut découper les US longues/complexes faute de quoi on introduit un effet « tunnel », dévastateur:
– plus de démonstrations,
– plus de livraisons
– sentiment de stagnation
– perte de visibilité

L’Analyse Agile : binôme Product Owner et developpeurs (1)

  • il reste une phase d’analyse relevant du développeur
  • le rôle de l’Analyste Métier traditionnel est proche de celui de Product Owner et il est fréquent que des Analyste Métier se recyclent en tant que PO.
  • Mais l’Analyse doit rester un dialogue entre PO et équipe de développement (a minima pour que les développeurs comprennent ce qui est demandé).

Analyse Agile : binôme PO et developpeurs (2)

  • pour dire combien de temps est nécessaire les développeurs doivent comprendre quoi faire.
  • comment tester: comment puis-je être certain que ce que le produit fait répond aux demandes du Product Owner. Le développeur se base sur ces critère pour savoir qu’il a fini et que la fonctionnalité peut être livrée et peut passer à autre chose.
  • S’il manque encore des détails le développeurs doit encore avoir un interlocuteur par la suite.

L’Architecture Owner Agile

En plus du PO on a parfois besoin d’un Architecture Owner qui prendra en compte les problèmatiques système et architecture du produit.

Par exemple un produit à installer par le client, fonctionnant sur des systèmes dédiés ou sur des machines virtuelles dans le cloud en mode SAAS (Software As A Service) aura un impact fort sur la mise en oeuvre, mais ce type de décision n’est généralement pas libre de toutes contraintes pour l’équipe de développement.

Dans les cas simples ce rôle peut être tenu en collaboration par le PO et l’équipe de développement ou encore par le Chef de Projet

Conflits entre les rôles de Chef de Projet Agile / Coach Agile / Manager Agile (1)

Il est préférable qu’une même personne ne porte pas les casquettes de Project Manager / Coach Agile / Manager. En effet certains aspects de ces rôles sont conflictuels.

Il est par exemple difficile pour un Chef de Projet de conserver une stricte neutralité envers un individu dont le comportement nuit à l’avancement du projet et donc de trouver les bons leviers pour changer le comportement de la personne (ou trouver ce qui la gêne). À l’inverse choisir de se passer d’un individu qui nuit à l’équipe mais possède de fortes compétences individuelles est délicat pour un chef de projet.

Conflits entre les rôles de Chef de Projet Agile / Coach Agile / Manager Agile (2)

Du point de vue du Chef de projet les réunions et autres rituels Agiles, outils fondamentaux pour le Coach Agile, peuvent être vus comme une perte de temps.

le « Manager Agile » est un responsable hiérarchique et a des comptes à rendre, il risque de tricher avec la réalité de l’avancement du projet ou être tenté par le micro-management (essayer de jouer sur la qualité ou la longueur de la journée de travail).

Conflit entre les rôles de Client Interne et développeur

Il est préférable d’éviter qu’une même personne porte les casquettes de Product Owner et développeur
– risque de demander, non ce que veut l’utilisateur, mais ce qui est facile à développer
– risque de biaiser l’évaluation d’une fonctionnalité (en général vers « c’est facile« )
– risque de dire à l’équipe de développement comment faire
– même si les conseils du PO sont bons c’est déresponsabilisant pour l’équipe

Conflits entre rôles

Lorsque c’est possible on évite donc de faire porter les casquettes de Product Owner et Dev/Chef de projet et Coach à une même personne car il y a des risques de biaiser le processus dans un sens ou un autre. Être conscient de ces conflits est une aide en soi.

Dans la pratique on est parfois obligé de le faire, dans ce cas une option consiste à faire tourner la casquette. C’est souvent le cas pour le rôle de Coach Agile dans les équipes matures. Certains rôles peuvent aussi être partagés entre plusieurs équipes (souvent Coach Agiles). Il y a aussi des écueils.

En résumé

  • le Product Owner : définit ce qu’il faut faire
  • le Testeur s’assure que la demande est concrète et testable
  • le Développeur : définit comment le faire et combien de temps il faut (si c’est dur ou pas)
  • le Chef de Projet Agile: s’assure que le projet est cohérent et avance
  • le Coach Agile s’assure que l’équipe fonctionne, suit les bonnes pratiques et l’aide à évoluer

Q&R

Agilité et Motivation: un paradis pour les générations Y et Z

Motivation Agile (ou 3.0) :

On peut se demander si l’effet premier des méthodes Agiles ne tient pas plus à la motivation des individus qu’aux détails d’organisation préconisées et autres pratiques. En effet les méthodes Agiles cadrent particulièrement bien avec les connaissances actuelles sur la motivation (cf livres Daniel Pink).
Les modes de fonctionnement préconisé par les méthodes Agiles sont également très favorable pour tirer le meilleur de personnes des générations Y ou Z.
En fait elles risquent aussi de marcher moins bien pour des personnes de la génération X ou précédente: trop de changements et d’instabilité, pas assez de hiérarchie. et un haut niveau de polyvalence est largement préférée à la spécialisation.

Motivation Traditionnelle (Carrotte/Baton)

  • les systèmes de punition/récompenses fonctionnent pour les tâches répétitives
  • mais pas bien pour les tâches créatives

Motivation Traditionnelle (Carrotte/Baton)

  • déresponsabilisant
  • démotivant
  • travail pour la prime, faible motivation intrinsèque
  • incite à la concurrence, l’individualisme
  • pousse à tricher sur les résultats
  • recherche de l’effort minimal pour le salaire

Motivation Agile (ou 3.0)

  • Les principes Agiles mettent en place naturellement un cadre de motivation intrinsèque
  • autonomie dans l’activité
  • maîtrise de l’activité
  • finalité (vers un objectif supérieur) et participation à une entité supérieure (l’équipe)

Motivation Agile (ou 3.0)

On retrouve les étages de la pyramide de Maslov
Besoins Physiologiques : Le rythme durable des principe Agile, qui implique aussi un salaire suffisant pour vivre (ou les gens partent)
Sécurité: importance des tests, du droit à l’échec, dans un cadre qui en minimise les effets (solidarité d’équipe, tâches courtes).
Appartenance à un groupe: tout est centré sur l’équipe
Estime de soi: responsabilité, liberté dans son travail, reconnaissance du travail réalisé (démos et produit réel), minimise le travail inutile (frustrant).
Amélioration: une grande part des principes Agile est basé sur l’amélioration continue, à la fois de l’équipe dt de l’individu.

Agilité et Génération Y et Z (1)

  • les pratiques Agiles sont particulièrement adaptées au fonctionnement des génération Y et Z

Agilité et Génération Y et Z (2)

  • équipe autonome
  • pas de hiérarchie au sein de l’équipe
  • opportunités d’amélioration personnelle
  • communication directe
  • changement permanent

Agilité et Génération Y et Z (3)

  • objectifs à court terme (tronçonnés si nécessaires)
  • rythme durable (compatible vie de famille)
  • objectifs pas exprimés en temps mais en tâches à réaliser
  • évite la mise en concurrence entre individus
  • valorise la transparence

Q&R

Fausse Agilité

Agile en toc! (1)

Les exemples ci-dessous montrent comment on peut facilement donner l’impression qu’une équipe est Agile sans l’être

Agile en toc! (2)

  • derrière le bureau du chef il y a un Kanban couvert de post-its montrant l’avancée de la Roadmap.
  • tous les travaux réalisés sont attachés à une User Story ce qui permet une visibilité optimale sur l’activité des équipes pour le Product Owner
  • les User Stories sont définies au début de la phase d’Analyse et placées sur la Roadmap

Agile en toc! (3)

  • l’équipe utilise un logiciel de tableau de bord Agile (Rally/VersionOne/Jira/etc.), les pratiques sont adaptées au logiciel
  • l’équipe est encadrée par des Coachs Agiles, des Scrum Masters et des Product Owners.
  • une partie des équipes a suivi une formation à l’Agilité.

Agile en toc! (4)

  • on travaille en itérations d’une semaine et on respecte les trois réunions principales: début d’itération, le Scrum Quotidien et la rétrospective.
  • on définit une vélocité qui permet de connaître l’efficacité de l’équipe et l’efficacité respective de chaque membre

Agile en toc! (5)

  • le Scrum Master est l’interlocuteur privilégie pour les demandes faites à l’équipe, cela fait partie de son rôle de protecteur de l’équipe
  • on définit des User Stories, elles sont estimées en heures, ce qui permet d’être plus précis sur la date de livraison.

Agile en toc! (6)

Les exemples ci-dessous sont franchements des contre-sens et font partie de ce qu’on peut appeler le ouvement Sabotagile!

Agile en toc! (7)

  • les équipes de développement livrent autant de fonctionnalités que possible à chaque itération.
  • le but de l’Agilité c’est d’augmenter la productivité et de développer plus vite.
  • utiliser des méthodes Agile permet de sous-traiter le développement logiciel offshore.

Agile en toc! (8)

  • la méthode Agile consiste à les tâches à faire sur des post-it et les coller sur un tableau blanc.
  • Pour une équipe Agile, de cas de retard il suffit de jouer sur la qualité et de tester moins pour gagner du temps.
  • Le Coach Agile découpe les demandes du Product Owner en tâches et les distribue à l’équipe

Agile en toc! (9)

  • Dans une équipe Agile, il est préférable d’avoir une équipe dédiée par composant et technologie: ex: interace utilisateur, back-end.
  • Le diagramme de Gantt est un outil privilégié des équipes Agiles
  • la meilleure motivation pour une équipe Agile ce sont les primes individuelles au résultat

Agile en toc! (10)

  • les tests sont de la seule responsabilité de l’équipe QA.
  • Si une tâche est complexe il est normale qu’elle dure plusieurs itérations
  • ce qui compte ce sont les heures de présence, les meilleurs employés arrivent tôt et repartent tard.

Sabotagile!

Comment faire comprendre aux cadres et autres comités de direction le décalage entre le discours assurant qu’une entreprise pratique les méthodes Agiles et la réalité des pratiques (Sabotagile)? L’encadrement est généralement très occupé à faire du « vrai travail » et rarement disponible pour prendre du recul et se lancer dans une reflexion de fond sur les pratiques.

Une approche ludique comme le calcul du quotient Sabotagile peut les faire
réfléchir et au moins se rendre compte qu’il y a un problème.

Source (en anglais):
http://smoothapps.com/index.php/2017/01/sabotagile-waste-loss-challenge/
http://smoothapps.com/index.php/2016/11/sabotagile-quotient/

Q&R

Par défaut
Agilité

SABOTAGILE! MANIFESTO

Manifeste pour le sabotage du développement logiciel Agile

Nous défendons le Status Quo et visons à défendre nos carrière,
les experts de l’industrie ont découvert les techniques suivantes
permettant de simuler l’agilité sans rien changer en pratique.

Ce faisant nous en sommes arrivés à valoriser:

1) L’Engagement contractuel de responsabilité via des spécifications, des dates et des coûts fixes et prédéterminés plutôt que les individus ou les interactions.

2) Le suivi de l’état d’avancement des projets et des programmes à partir de diagrammes de Gantt, de pourcentages de complétion et de tableaux de bord synthétiques Rouge/Orange/Vert plutôt qu’un logiciel qui marche.

3) La définition de processus rigoureux avec des Dates de Livraison, des Recettes Partielles et des traces auditables plutôt que la collaboration avec le client.

4) Empêcher l’émergence du chaos et bloquer tout changement plutôt que l’adaptation au changement.

Nous reconnaissons que les méthodes de développement Agile fonctionnent peut-être pour d’autres et
nous acceptons d’utiliser son vocabulaire car c’est la mode du jour, mais en aucun cas nous ne changerons de comportement. Nous sommes des gens sérieux, nous construisons et déployons des logiciels dans le monde réel à notre manière depuis des décennies et nous avons la ferme intention de continuer à faire exactement pareil à l’avenir que ça soit efficace ou pas.

PRINCIPES SABOTAGILE!

Principes sous-jacents au manifeste Sabotagile!

Nous suivons scrupuleusement ces principes:

  • 1) Notre priorité absolue c’est que nos ressources informatiques livrent les fonctionnalités promises, auxquelles nous nous sommes contractuellement engagés, dans les temps et sans dépassement de budget.

2) Tout écart par rapport au plan initial doit être repéré et réprimé. Nous obligerons les développeurs à tenir leurs engagements sans décaler les livraisons prévues.

3) Nous pouvons augmenter l’efficacité des développeurs et réaliser des économies d’échelle en livrant moins souvent des produits plus riches fonctionnellement. Les livraisons intermédiaires sont inutiles.

4) Toujours passer par des intermédiaire entre les commerciaux et les développeurs. Les commerciaux peuvent ainsi se concentrer sur les clients et accomplir un vrai travail.

5) Utiliser le talent de prévision des managers, les objectifs de performances individuels et les courbes de Gauss pour maximiser la productivité des ressources.

6) Le mode privilégié de communication avec les équipes de développement passe par des spécifications écrites, des documents de référence et les e-mails. Ceux-ci laissent des traces auditables et forcent les développeurs à tenir leurs engagements.

7) La mesure des progrès réalisés c’est le tableau de bord synthétique de la direction qui répertorie les fonctionnalités prévues mises dans le produit.

8) Les développeurs travaillent tard le soir, les week-ends et annulent leurs congés pour tenir les deadlines.

9) Les développeurs tiennent leurs engagements en mettant le produit en production le jour dit, puis en fournissant rapidement les correctifs de bugs aux clients.

10) Profiter des économies d’échelle en s’assurant que les ressources mettent autant de fonctionnalités que possible dans chaque version. Même si personne ne les utilise c’est toujours bien sur la fiche technique.

11) Mieux vaut embaucher à prix d’or des Architectes Logiciels brillants pour concevoir le produit, des développeurs débutants moins coûteux pourront se charger de la réalisation sous leur direction.

12) A la fin du projet – si le temps le permet – on peut envisager des analyses postmortem avec les ressources, bien entendu ça ne doit pas affecter pas la capacité des ressources à accomplir un vrai travail.

13) Apporter une certaine fraicheur aux ressources en utilisant à leur intention le vocabulaire à la mode cette décennie, que ce soit pour décrire les processus, mettre à jour les manuels de procédure, ou bien dans les formations ou les communications de la direction, ceci sans changer en rien notre manière de penser ou nos comportement.

Ceci est une simple traduction, je fournis les liens vers le contenu original:
http://smoothapps.com/index.php/2017/01/sabotagile-waste-loss-challenge/
http://smoothapps.com/index.php/2016/11/sabotagile-quotient/

Par défaut
Uncategorized

Les 8 reines : galop d’essai en D

Premier essai en langage D. Même ceux qui ne connaissent pas D auront deviné que c’est un language de la famille du C. Disons que D pourrait prendre la suite du C, en considérant que C++ est un échec technique même si c’est une réussite en termes de parts de marché.

Mais ce sujet mérite d’être développé dans un autre billet. Pour le moment il s’agit juste de présenter le résultat de mon premier kata en D. La résolution du classique problème des 8 huits reines : placer 8 reines sur un échiquier sans qu’aucune d’entre elles ne se menace, selon la règle de déplacement des reines aux échecs, c’est à dire lignes droites et diagonales.

Un aspect agréable du D dans l’optique d’un kata, c’est que les tests unitaires sont intégrés au langage.

Bon, voici directement le résultat final.

 

import std.stdio;

struct Pos { uint x, y; };

pure bool menace(immutable Pos q1, immutable Pos q2)
{
    return (q1.x == q2.x)
    || (q1.y == q2.y)
    || (q1.x - q2.x == q1.y - q2.y)
    || (q2.x - q1.x == q1.y - q2.y);
}

bool queen(uint szx, uint szy, Pos [] result, uint remaining)
{
    if (remaining == 0){
        return true;
    }
    uint curx = cast(uint)result.length - remaining;
    uint y = 0;
    nexty: while (y < szy){
        foreach (Pos item ; result[0..$-remaining]){
            if (menace(item, Pos(curx, y))){
                y++;
                continue nexty;
            }
        }
        result[curx] = Pos(curx, y);
        if (queen(szx, szy, result, remaining - 1)){
            return true;
        }
        y++;
    }
    return false;
}

unittest
{
    enum nbqueens = 1;
    Pos [nbqueens] result;
    bool exist = queen(1, 1, result, 1);
    assert(exist == true);
    assert(result[0] == Pos(0, 0));
}

unittest
{
    enum nbqueens = 2;
    Pos [nbqueens] result;
    bool exist = queen(2, 3, result, 2);
    assert(exist == true);
    assert(!menace(result[0], result[1]));
}


void main()
{
    enum nbqueens = 8;
    Pos result[nbqueens];

    bool res = queen(8, 8, result, nbqueens);
    if (!res){
        writeln("No result found");
    }
    for (uint q = 0 ; q < nbqueens ; q++){
        writeln("Q", q, "[", result[q].x, ",", result[q].y, "]");
    }
}

 

L’écriture du kata a probablement été un peu trop directe (je suis passé au résultat final en seulement 2 tests). C’est peut-être aussi lié au fait que les problèmes de nature algorithmique se prêtent souvent mal à la forme kata, car il y a souvent un saut conceptuel entre les première étapes et la solution générale choisie.

 

 

 

 

Par défaut
Kata

Kata NombreEnLettres en Perl

Une fois n’est pas coutume, ce Kata a un nom français. Disons que vous travaillez pour une banque, sur une machine a rédiger les chèques. Dans le cadre de la défense de la langue Française le ministère de la culture demande que désormais les machines indiquent le montant en toute lettres, comme les êtres humains, en suivant les recommandations orthographiques de 1990. En gros, les séparateurs entre composants des chiffres sont des tirets au lieu de parfois des espaces e.g. on écrit vingt-et-un et dix-sept au lieu de vingt et un et dix-sept.

Pour ceux que cela intéresse on peut trouver les règles d’écriture détaillées des nombres en français ici.

Lire la suite

Par défaut
Kata

Présentation du KataCRUD

CRUD ce sont les initiales des quatres verbes Create Read Update and Delete.  Autrement dit le strict minimum nécessaire pour gérer un fichier structuré du point de vue de l’administrateur du dit fichier. Un kata intéressant parceque c’est un archetype d’un problème courant et pour la multiplicité des environnements techniques dans lesquel on peut le mettre en oeuvre.

Lire la suite

Par défaut