Bienvenue sur Développement Agile

Référence sur le développement logiciel Agile. Nous traitons de conception, de programmation, de pratiques de génie logiciel, d'essais et d'autres sujets connexes.

Agile 2015: Nos impressions et les tendances (partie 3/3)

Publié le jeudi 17 septembre 2015 à 08:30

Agile2015

À la fin du mois d’août, Pascal et Félix-Antoine sont allés à la plus grande conférence mondiale sur l’Agilité: Agile 2015 à Washington D.C.

Ils y sont allés pour apprendre, ramener les réponses des plus grands noms aux questions de nos clients, mais surtout pour voir ce qui émerge et y déceler quelques tendances.

Voici donc nos impressions… Évidemment, ceci est notre interprétation, nos hypothèses! Pour des résumés factuels, consultez nos résumés.

 

Trop du côté droit?

Des critiques (écoutez l’entrevue avec Ron Jeffries et Chet Hendrickson) ont été entendues lors de la conférence sur le fait que la communauté focalise peut-être parfois un peu trop sur des sujets qui figurent du côté “droit” du manifeste… Avons-nous perdu de vue l’essence de l’Agilité?

Paradoxalement, comme nous le disions dans un précédent article de la série, on note en même temps une prise de conscience et un retour au Craftsmanship.

Avons-nous parfois tendance à voir l’Agilité comme étant seulement un cadre (Scrum, SAFe ...) tout en laissant de côté ses origines, fondements, valeurs et principes?

 

Excellence Technique

Je ne sais pas si nous devrions être réconfortés ou non, mais il semble que nous ne sommes  pas les seuls dans le monde à être interpellés par le manque de connaissances techniques et particulièrement concernant les concepts d’abstraction, du polymorphisme, d’architecture, etc.

Plusieurs conférenciers en parlent et sont même parfois découragés… Plusieurs se sont vidé le coeur lors des “conférences éclair” avec des sujets comme : “Les IFs sont le diable”, “Abstraction vs Duplication (Tim Ottinger)” ou “Arrêtez de faire saigner votre code”.

 

Les jeux

C’est une certaine tendance depuis déjà quelques années, mais on peut constater que les jeux comme activité d’accompagnement ou d’équipe sont toujours très présents. Et si vous n’arrivez pas à convaincre votre patron que c’est une technique pédagogique très sérieuse, voici une recommandation d’un présentateur:


(Image de @hintbw)

 

Autres billets

<< Billet 1 (Craftsmanship et Lean)
<< Billet 2 (BDD, Story Mapping et UX)

Les valeurs de XP, Scrum, Kanban et ... les tiennes

Publié par Louis-Philippe Carignan le jeudi 28 février 2013 à 07:19

Oui, oui, je sais. On est super loin du code lorsqu’on parle des valeurs des méthodologies. Pourquoi m’embêtes-tu donc avec ça Louis-Philippe quand j’éprouve un grand plaisir à juste coder pendant ma journée?

C'est qu'il y a quelques années, j’étais à une formation de Lyssa Adkins où elle m’a demandé pourquoi j’étais impliqué dans l’Agilité. Je n’ai pas su quoi répondre et en haussant les épaules, Lyssa a vogué vers un autre groupe de personnes, sachant qu’elle venait de me faire réfléchir.

Plus tard dans la journée, Lyssa présentait une pyramide inversée qui expliquait que les valeurs étaient à la source des principes et des pratiques mis en place par la suite. J’ai encore cette photo bien que cela fasse plus de deux ans que j’aie assisté au cours.

Process Architecture

D’ailleurs, j’avais aimé le commentaire de Lyssa suite à ce dessin. Elle a fait référence au Projet Management Body of Knowledge (PMBoK) qui « presents a set of standard terminology and guidelines for project management » selon l’article sur Wikipedia. À mon avis, le PMBoK contient un tas de pratiques mais elles ne sont pas supportées par des principes et des valeurs, contrairement à l’Agilité qui a un manifeste et 12 principes.

Plusieurs mois après son cours, je complétais ma demande pour être formateur chez Scrum.org. Le formulaire m’a presque posé la même question que Lyssa. Cependant, j’y avais réfléchi longuement (merci Lyssa) et la réponse fût facile à écrire. Pour moi, les valeurs dans l’Agilité étaient en lien avec mes valeurs personnelles. Cela était donc facile pour moi de m’approprier ce truc puisque c’était comme si je parlais de moi. Je savais qu’en l’enseignant, les participants sentiraient vraiment mon intérêt pour ces approches et que cela ferait de moi un bon professeur (du moins, je l’espère).

À partir de ce moment, j’ai toujours cherché à identifier les valeurs présentes dans une équipe, un département ou une organisation dans laquelle je me retrouvais. Par exemple, si j’entendais une phrase comme « On a essayé Scrum mais ça ne marche pas », j’essayais d’identifier les valeurs dans l’équipe ou le département pour voir si la culture en place a tout simplement étouffée l’initiative.

Les valeurs de la méthode Kanban

J’ai été agréablement surpris de trouver un billet publié en janvier 2013 à propos des valeurs de Kanban. L’auteur, Mike Burrows, décortique les pratiques et principes de la méthode Kanban pour énoncer 9 valeurs qui supportent Kanban.  En lisant les commentaires sur le groupe Yahoo! Kanbandev, les réactions face à ce billet étaient majoritairement positives.

Voici donc les 9 valeurs de la méthode Kanban :

  • Transparency
  • Respect
  • Understanding
  • Leadership
  • Flow
  • Customer Focus
  • Agreement
  • Balance
  • Collaboration

À titre comparatif, j'ai créé le tableau ci-dessous pour mettre en parallèle ces valeurs à celles de Scrum et Extreme Programming. Les valeurs d'Extreme Programming sont détaillées dans la page Wikipedia tandis que les valeurs de Scrum ne sont pas listées. Bon, pour le bien de l’article je vais mettre les trois pilliers de Scrum ainsi que l’engagement (Commmitment) et le focus dans les valeurs de Scrum.

XP

Scrum

Kanban

Communication

Respect

Feedback

Courage

Simplicity

Transparency

Inspection

Adaptation

Commitment

Focus

Transparency

Respect

Understanding

Leadership

Flow

Customer Focus

Agreement

Balance

Collaboration

Si on revient au dessin de Lyssa au début du billet, les pratiques mises en place par ces méthodes sont supportées par un ensemble de valeurs qui leur sont propres. Par exemple, dans la méthode Kanban, l’un des principes est de visualiser le travail. On s’appuie sur la transparence pour établir ce principe et il y aura sûrement toutes sortes de pratiques qui émergent de ce principe. Mais si des gens dans l’équipe n’aiment pas montrer où ils sont rendus, et cela existe, ils auront de la difficulté à embarquer. Parce que naturellement, au fond d’eux-mêmes, ils vont résister parce qu’ils ne connectent pas avec cette valeur.

Dans un autre exemple, je me suis déjà retrouvé dans une équipe de développement où il était mal vu de dire qu’on allait dépasser nos estimés. Bien que les membres de l’équipe aient du courage pour admettre que certaines parties du logiciel étaient mal programmées, la culture de l’entreprise ne permettait pas de cultiver cette valeur. Difficile alors de mettre en place des dojos pour faire du refactoring lorsque la culture s’attend à ce que le travail soit parfait du premier coup.

Et c’est là que toi, la personne qui lit ce billet, doit se demander quelles sont tes valeurs personnelles, celles de tes collègues, celles de ton département, et voir si elles concordent avec les valeurs de la méthode que tu essaies de mettre en place. Tu veux de l’Agilité. Parfait. Tu veux mettre en place la méthode Kanban. Parfait. Mais avant d’envoyer ton monde en formation, je t’invite à identifier les valeurs de la méthode qui sont moins présentes dans ton équipe/département. C’est peut-être là que les premiers problèmes vont surgir lorsque vous allez mettre la méthode en place.

Mots-Clés :
  • Plus récents
  • 1
  • Plus anciens

Archive