Introduction de la méthode Agile en entreprise

En réponse à Claude Alain dans son blog qui souligne l’importance du rôle d’un coach externe pour l’implantation de la méthode Agile.

Avoir un coach ou un mentor est certainement un facteur clé dans l’implantation d’Agile: comme c’est le cas pour tout changement dans les processus d’une organisation. Le succès repose aussi sur l’implication de l’équipe: le succès ou l’insuccès de changements commencent par les ressources. Je veux illustrer que l’implantation d’Agile est similaire à l’implantation d’un nouveau processus organisationnel et on se doit de mettre les efforts et l’infrastructure en place pour en faire un succès.

Souvent le terme « Agile » a une connotation de « frivole » alors qu’Agile demande beaucoup de discipline de la part de toute l’équipe, ceci contraste avec la pratique bien ancrée que les chargés de projets contrôlent tout et planifient tout. Savoir planifier et contrôler les projets s’acquiert par l’expérience: coacher des équipes pour qu’elles « s’autogèrent » et deviennent responsables  demandent des habilités autres que de savoir gérer des projets: il faut maintenant faire évoluer les équipes afin qu’elles deviennent responsables avec pour effet d’être plus  motivées et performantes à la satisfaction de tous. Si les gestionnaires en poste n’ont pas ces habiletés, alors, oui, un coach externe est absolument nécessaire: initialement aussi pour coacher les gestionnaires.

L’autre thème traité dans le blog de Claude est la difficulté d’avoir le support de la direction pour implanter Agile.

Ce qui importe dans le cas où le support de la direction n’est pas assurée ou qu’Agile n’obtient pas de haute priorité est de s’assurer des choses suivantes:

  • Avoir une équipe qui veut Agile: une équipe composée de tous les participants requis pour le projet choisi
  • S’assurer d’avoir l’information requise en ce qui a trait aux principes d’Agile et aux objectifs – comprendre les différences entre cette méthode et celle utilisée.
  • Recruter le meilleur « ami-client » et lui vendre Agile.
  • Commencer par un projet pilote.
  • Suivre à la lettre la méthodologie choisie: incluant les rétrospectives et surtout ajuster régulièrement.
  • Continuer à reporter le statut des projets à la haute direction de la façon habituelle. Ceci demande de l’imagination mais c’est possible. Il ne faut pas d’impact à ce niveau.
  • Après la livraison du projet, reporter le « cas vécu » et les bénéfices encourus, avec le client enthousiaste bien entendu.

Dans mon cas, les résultats d’un processus de livraison itératif avec une collaboration quotidienne avec le client ont parlé par eux-mêmes, on a obtenu le feu vert pour appliquer le processus à la grandeur de l’équipe et devenu un exemple pour le reste de l’organisation — sans coach externe mais avec une bonne équipe et un gestionnaire qui croyait en l’équipe.

Il ne faut pas mesurer après la première itération parce que le processus n’est pas au point, mais après 3 itérations, c’est solide et c’est intéressant de voir les membres de l’équipe évolués et se prendre en main eux-mêmes.

Fait cocasse: Il y a eu un projet urgent environ 6 mois plus tard et le client, non enclin à être Agile, a voulu revenir à l’ancien processus afin d’être plus confortable. On a accepté mais pour se rendre compte que l’équipe ne savait plus comment travailler sans Agile: on a dû trouver un compromis entre les deux processus.

Objectif: une équipe performante

Une équipe performante Agile est une équipe dédiée possédant les bonnes personnes, ayant le bon degré d’autonomie, ayant gagné la confiance et qui travaille à un rythme constant pour livrer des produits de qualité d’une quantité qui reflète une vélocité constante.

Une équipe de haute performance est caractérisée par :

  • L’adhérence de tous les membres à des comportements et des valeurs et qui les démontrent constamment même en face de l’adversité.
  • Une identité d’équipe qui est reconnue à l’intérieur et l’extérieur de l’équipe.

Au niveau de l’entreprise, les équipes de haute performance sont caractérisées par:

  • Une gestion de l’équipe qui identifie clairement les objectifs et mesure constamment la performance en rapport avec les objectifs de l’entreprise
  • Un environnement stimulant, qui soutient les comportements et les mesures de performance et qui contribue à entretenir une forte identité d’équipe

Pour les gestionnaires qui veulent développer une équipe de haute performance, voici trois(3) facteurs clés :

    1. Vous devez être à la hauteur : Vous devez dégager une énergie positive, être constant et prêcher par l’exemple.
    2. Avoir les bonnes personnes dans l’équipe : Les aptitudes ne sont pas les seuls critères à considérer dans le choix des membres de l’équipe : l’attitude et l’esprit d’équipe des personnes doivent être pris en considération et sont très importants.
    3. Habiliter votre équipe : Votre équipe doit être capable d’utiliser leur jugement et de prendre des bonnes décisions, il faut leur laisser de la place pour prendre des initiatives et les aider à évoluer dans leur rôle.

Mais avant tout….

La confiance est la fondation d’une équipe de haute performance. La confiance est ce qui nous pousse à contribuer. La confiance vient en premier.

Références :

Building High Performance Teams
Attributes of a High Performing Agile Team
Building Project Teams – Project Management
how to build trust 

Revue du livre : User Story Applied de Mike Cohn

User Stories

Source Amazon.ca

«Software requirements is a communication problem.» extrait du livre User Stories Applied.

Nous avons besoin de remplacer les documents écrits par des communications fréquentes et les user story nous propose d’y écrire l’essentiel et de discuter avec le client pour comprendre les détails.

Ce livre nous permet de démarrer notre apprentissage avec les user stories, il recommande les meilleures pratiques et nous donne une marche à suivre pour bien démarrer.

Il est complet : théorie, exemples et mise en application. Il est clair mais en même temps n’est pas spécifique à des types de projets,  à des environnements spéficiques ou des méthodologies.

Ce que j’ai trouvé le plus utile dans ce livre est de comprendre les meilleures façons de briser les gros projets et l’importance d’avoir toujours comme objectif de livrer quelque chose que l’utilisateur peut voir à chaque itération.

Ce livre est très bien écrit, il est clair, précis et contient tous les aspects nécessaires pour bien structurer et commencer à développer des user stories.

Plusieurs chapitres du livre sont disponibles :

http://www.userstories.com/book

http://books.google.ca/books/about/User_stories_applied.html?id=SvIwuX4SVigC&redir_esc=y

Article de Mike Cohn : http://johnragan.wordpress.com/2010/05/27/user-stories-applied-for-agile-software-development-by-mike-cohn/

 

 

L’importance de la qualité du code

L’implantation de la méthode Agile a un sérieux impact sur le nombre de tests requis pour la livraison des projets puisque les projets sont brisés en morceaux de façon à apporter de la valeur au client le plus rapidement possible. Des fonctionnalités terminées, prêtes pour la production, sont également livrées ponctuellement pour permettre la révision et la planification de la prochaine itération (ou sprint pour la méthode Scrum).  La livraison fréquente augmente le nombre de tests requis avec comme effet qu’Agile accentue la visibilité de l’impact de l’introduction de bugs dans les logiciels et la nécessité d’incorporer la qualité dès le début du cycle de développement.

Le graphique ci-dessous montre le coût des bugs selon le temps où il est découvert

Coût des bugs

  • Exigences: À ce point-ci, le temps de correction sera rapide surtout si vous avez des conversations régulières avec le client.
  • Codage: Quand un bug est découvert au cours de cette étape, c’est le développeur qu’il découvre, il comprend déjà le problème et sait souvent comment y remédier.
  • Phase d’intégration: Les bugs trouvés à ce point-ci commencent à impliquer plus que le développeur : il implique le groupe de développement qui s’occupe de l’application ainsi que les testeurs si les tests sont exécutés au même rythme que le code est intégré.
  • Phase de test : Le nombre d’intervenants durant cette phase continue de croître ainsi que le nombre d’opérations nécessaires : les bugs sont souvent documentées, suivies et priorisées.
  • Étape de la production : Les utilisateurs sont maintenant impliqués, le service à la clientèle, les testeurs et le développement. En plus, il se peut qu’il n’y ait plus personne connaissant le système, donc il peut y avoir un apprentissage, donc un délai pour trouver le problème et le résoudre.

Faire un effort pour attraper des bugs au premier point dans le cycle de vie se traduira par un meilleur retour sur investissement (ROI).

Suggestions pour améliorer la qualité

  • Le développeur doit prendre le temps de tester le code surtout en fonction des critères d’acceptation listés pour l’exigence. Les outils de tests unitaires aident à découvrir les effets secondaires de modification dans le code. Le TDD (Test Driven Development) cible ces bugs.
  • Un bon système de gestion des sources facilite les déploiements et les « roll-back » en cas de problèmes d’intégration. Une nouvelle version du code ne devrait jamais être déployer sur l’environnement intégré s’il ne passe pas les tests unitaires. Alternativement, un outil qui automatise les tests fonctionnels de l’application peut aussi être utilisé pour vérifier si la nouvelle version est conforme aux fonctions critiques de l’application.

Revue du livre: Agile Retrospectives:Making Good Teams Great

Agile Retrospectives: Making Good Teams Great

La rétrospection suite à un sprint ou une itération ainsi qu’à la fin d’un projet occupe une place importante dans les méthodes agile puisqu’elle permet d’apprendre de nos erreurs et de s’améliorer.

Agile Retrospectives

Agile Retrospectives

Ce livre parle spécifiquement de la façon de faciliter les réunions. D’autres livres de la liste du PMI pour la certification PMI-ACP parlent aussi de rétrospectives mais ce livre va plus loin en nous donnant des conseils spécifiques pour bien préparer ces rencontres afin qu’elles soient efficaces pour atteindre les objectifs de ces rencontres.

C’est aussi un livre de référence pour y puiser des idées sur les jeux. Certains processus dans le livre semblent assez longs, par contre d’autres que j’ai personnellement essayé ont fait la différence dans le déroulement d’une rencontre et ont donné des résultats améliorés.

L’auteur traite du sujet sur Internet, j’ai mis des liens à un « slideshare » et à un résumé du livre.

Au sujet du livre

Agile Retrospectives (slideshare de l’auteur)
Agile Retrospectives : Making Good Teams Great (résumé du livre)

Lectures reliées
(français)
La rétrospective de sprint
Développer une culture du feedback continu

(anglais)
Un autre livre de la liste du PMI qui traite le sujet dans un chapitre :
The Art of Development : Retrospectives
Key Elements of a Successful Agile Retrospective: Preparation and Participation
Retrospective Plans

Pour une meilleure compréhension entre le groupe de développement et les clients

Les résultats produits sont directement reliés aux conversations:
•Que nous avons
•Que nous n’avons pas
•Que nous n’avons pas fait correctement

Mon blog dit : « un pas vers la simplicité ». Je vais donc rester simple et vous donner deux(2) recommandations pour une meilleure compréhension des besoins et pour faire en sorte de livrer des fonctions/itérations/projets conformes aux attentes des clients.

Définition des responsabilités client-développeur

Un des plus gros changements à apporter pour améliorer la compréhension des besoins est de définir les responsabilités du client et celles de l’équipe du développement. La voici :

  • Le « quoi » est la responsabilité du client (ou du directeur de programme)
  • Le « comment » est la responsabilité de l’équipe de développement

Ces responsabilités ne sont pas toujours respectées avec comme impact que le développeur ne produit pas le résultat voulu, que la solution développée ne soit pas évolutive ou que le développeur prend des décisions d’affaires.

Client : Les développeurs ont le droit de « comprendre » ce qu’ils font : il est beaucoup plus utile d’expliquer pourquoi que d’essayer de déterminer la façon de l’implanter. Si le développeur comprend l’objectif, le résultat sera plus conforme aux attentes. Pour améliorer l’évolution d’une solution, il est aussi important de fournir des informations sur les objectifs à moyen ou long terme s’ils sont connus : ceci donne de bonnes indications sur l’architecture d’une solution aux développeurs même si les fonctions ne sont pas développées immédiatement.

Développeur : Le « client » détermine les besoins, il connait ses besoins et ses objectifs d’affaire. Vous avez le droit de suggérer des façons de faire afin d’accélérer le travail par exemple, mais surtout ne jamais imposer votre façon de voir les choses. Vous devez informer le client des impacts si nécessaire mais garder en tête que votre responsabilité est « comment » développer.

Critères d’acceptation

Trop souvent, on prend les besoins, on livre et le client n’est pas satisfait parce qu’il manque une option ou une règle d’affaire que vous auriez dû connaître, etc… «Je ne connais pas tout de ce que je ne connais pas»

Et si vous faites une liste des critères d’acceptation AVANT le développement? Au moment de la revue, les critères sont déjà établis donc tout le monde va maintenant compiler les changements pour la prochaine itération.

Il est certain que dans un mode Agile, les besoins se précisent au fur et à mesure du développement, il en est ainsi pour les critères. Ceci donne l’opportunité de combiner les visions sur une base quotidienne et ne plus avoir de surprise quand c’est livré. Les changements sont toujours la bienvenue parce qu’ils font partie de la normalité, ils ne sont plus traités en exception.

Si vous mettez en pratique ses 2 conseils, vous aurez amélioré la compréhension des besoins et la relation avec le client.

 

User Stories

Pour aller plus loin dans les besoins avec les méthodes Agile, habituellement les besoins sont consignés sous forme de User Story. Par définition un user story est une petite fonction mesurable et testable.

Souvent elles ont la forme de :

Exemple :

« En tant qu’utilisateur, je peux ajouter un produit dans mon panier d’achat. »

Elle permet de décrire en une ou deux phrases une fonctionnalité qui représente la fonction du point de vue de l’utilisateur, elle est complétée par les critères d’acceptation qui peuvent être sous cette forme :

– « Vérifier que l’utilisateur est authentifié sur le système » ;
– « Vérifier que le panier d’achat est présenté à l’utilisateur avec le produit qui vient d’être ajouté » ;

Pour en savoir plus sur les user stories :

User Story (Slideshare)
User Story vs Use case : soyez Agile !
Agilité: 10 stratégies pour avoir des User Stories suffisamment petites

Jeux d’innovation pour améliorer la compréhension des besoins

Cet article Souviens-toi du Futur… Mon Ombre et moi: mettre l’Expérience Utilisateur au cœur du Jeu ! propose des jeux d’innovation pour mieux cadrer le contenu d’une release et pour en apprendre davantage sur l’expérience d’utilisation des solutions par les utilisateurs.

Série PMI-ACP: Revue du livre Coaching Agile Teams

Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Signature Series (Cohn))

Coaching Agile Teams

Source: Amazon.ca

De toute la liste de livres recommandés par le PMI, ce livre est celui qui focus le plus sur les notions de coacher les équipes en opposition à les superviser ou les gérer. Le livre soulève l’importance de permettre aux membres de l’équipe d’acquérir des capacités d’être responsables et de prendre en charge leur rôle dans l’exécution des projets.

Il est beaucoup question de la transition du rôle de gestionnaire de projets dans le monde Agile : le gestionnaire a plus un rôle de coordination entre les équipes et les groupes extérieurs et un rôle de coach pour obtenir des équipes efficaces et autonomes.

Le livre est plus un livre de référence qu’un livre qu’on lit de bout en bout. Il a un ton plutôt académique et structurée et est plus proche des gestionnaires de projets.

Articles reliés traitant du même sujet que le livre:

Coach Agile : Bien plus qu’un Coach ?

Coaching d’équipe, Intelligence Collective

Définition de « fini »

Vous êtes un développeur et avez fini le code pour le nouveau rapport du comptable.

Tout fier, vous dites : « J’ai fini ! »

Le comptable accède tout de suite son système et ne voit pas son nouveau rapport.

Où est le problème ? Qu’est-ce qui est fini ?

J'ai fini !

J'ai fini !

« Fini » ne signifie pas la même chose pour tout le monde. Les équipes doivent définir leur notion de « fini », en discuter et la communiquer ou l’afficher. La décision de considérer un élément comme fini dépend de la définition élaborée par l’équipe. Si elle inclut la mise en production et la disponibilité d’une version en plusieurs langues alors on pourra dire « C’est fini » seulement quand toutes les tâches seront finies. Si ce n’est pas spécifié, c’est libre à l’interprétation des gens et apporte son lot d’incompréhension.

Quand une entreprise investit pour le développement d’un nouveau rapport, selon l’exemple ici, la valeur qui est recherchée est les bénéfices récoltés par l’utilisation de ce rapport : avant cette étape, il n’y a aucune valeur : seulement un investissement. D’un point de vue d’une entreprise, « fini » veut donc dire que c’est livré et opérationnel avec tout ce que ceci implique. Il est certain qu’avant cette étape, plusieurs tâches ont été réalisées et finies, il faut simplement être clair dans les énoncés. Dans le cas de projets plus gros, il y a nécessité d’avoir plusieurs définitions : au niveau des activités, au niveau des itérations, au niveau des projets. L’idée ici est de simplement prendre le temps de les définir.

Articles reliées :

What is Definition of Done (DoD)?

Definition of done – Zhu Wei

Certification Agile de l’institut PMI – PMI-ACP

PMI-ACP, la certification de l’institut PMI, la même que pour la certification PMP en gestion de projets, signifie Agile Certified Practitioner et se veut une reconnaissance  « de la formation dans les méthodologies Agile, de l’expérience dans des projets Agile ainsi que de la capacité des individus à répondre aux besoins des entreprises en gestion de projets par le biais de méthodes diverses. » (PMI-ACP_Handbook)

Note importante : Ce site n’est pas destiné à vous donner des informations sur le questionnaire PMI-ACP, j’estime que les gens qui vont le réussir le feront parce qu’ils auront vraiment acquis les connaissances nécessaires, de cette façon la certification gardera sa valeur. En même temps, ce sujet est passionnant, alors l’approfondir est un plaisir.

J’aimerais vous parler d’un livre qui n’est pas sur la liste du PMI mais est mon préféré, il s’agit de :

Kanban: Successful Evolutionary Change for Your Technology Business

Kaban : Successful Evolutionary Change for Your Technology Business

Source: Amazon.ca

Je trouve ce livre très bien écrit, facile à lire. Il ne nous donne pas des principes mais nous convainc du bienfondé de certaines pratiques. Bien que le titre soit Kanban, les concepts qui sont décrits dans ce livre s’appliquent à toutes les méthodologies et même à tout ce qui n’a pas de méthodologie. Par exemple :

– L’importance de régler les problématiques ou l’ambiguïté des besoins.

– L’efficacité accrue quand on travaille que sur une chose en même temps.

Ce livre traite de notions qui font partie des sujets évalués pour la certification.

Ce livre est tellement facile et intéressant à lire qu’il va être apprécié par les personnes techniques et non-techniques. La logique expliquée dans ce livre se prête à toutes sortes d’entreprise : tout le monde peut en bénéficier.

Bonne lecture !

Pour en savoir plus sur Kanban lisez Tableau Kanban de l’Institut Agile

Devenir Agile

Ce site s’adresse aux gestionnaires responsables du développement dans les entreprises, aux développeurs ou au gestionnaire de projets qui voudraient avoir la certification du PMI appelé PMI-ACP.

Je vous propose Agile plus en terme de philosophie qu’en terme de méthodologie parce que ce qui compte est d’atteindre une bonne performance mais surtout être motivé de le faire.

Il faut voir tous les aspects en même temps:

Pour les gestionnaires:
Vous êtes convaincu d’aller vers Agile mais…

  • Est-ce que vous vous sentez inonder par les définitions d’Agile ?
  • Est-ce que vous aimeriez que quelqu’un vous suggère où commencer ?

Pour les développeurs:
Vous voulez Agile mais ça n’arrive pas assez vite:

  • Comment est-ce que vous pouvez faciliter le passage à l’ère Agile ?
  • Comment convaincre les gens qu’être Agile n’est pas être indiscipliné?

Je vous promet des conseils judicieux qui sauront vous remettre sur pied et prendre le virage Agile en adoptant tout de suite la bonne philosophie…le reste suivra.

Pour ceux qui désirent être certifié par l’institut PMI sur Agile, la certification s’appelle PMI-ACP (Agile Certified Practitioner). J’ai créé une section de mon blog pour vous donner mes commentaires sur les lectures que le PMI a suggéré. Un peu de français dans la préparation ne fera pas de tort. 🙂

Commençons par décrire une situation qui arrive dans toutes les compagnies et le premier conseil qui suit……

Mini-Cas
Vous êtes un développeur et vous développez une nouvelle fonctionnalité pour le service de marketing par l’intermédiaire de Christian qui doit aussi vous fournir des messages ou des textes. Vous vous êtes assis avec Christian, tout est compris. Vous développez depuis 2 jours et ils vous manquent certaines informations, alors vous prenez quelques décisions pour aller plus vite.

Aller plus vite ? et si vous vous êtes trompés, Christian peut se sentir mis à part, il peut ne pas être d’accord sur les décisions prises et vous devrez rechanger le code. Est-ce bien plus rapide que d’avoir posé la question?

Conseil
Le code qui est développé est un élément pour atteindre un objectif d’affaire: ce n’est pas la totalité de la solution, c’est seulement une partie, et ce n’est pas suffisant pour atteindre un objectif d’affaire. Faites équipe avec les gens  (même s’ils ne développent pas !) mais qui doivent aussi s’impliquer pour atteindre un objectif, de cette façon, la confiance s’établira et le produit fini plaira à tout le monde.

Dans le manifeste Agile, ceci est écrit comme:
Les individus et leurs interactions plus que les processus et les outils

 

  • Archives

  • Catégories

  • Méta

  • Sur Twitter

  • Articles récents

  • Entrer votre adresse email ici pour recevoir les notifications.

    Rejoignez les 3 autres abonnés
  • Agile