Daylight avec ses partenaires, l’ENSIIE, l’IAE Lille, CIO Online et Le Monde Informatique, ont décidé de lancer l’université d’été « les fondamentaux pour réussir les projets stratégiques à dominante SI ».
Les 13 14 et 15 septembre 2010 à Paris, J'animerai une session Extreme Programming.

Extreme Programming

Loin de la vision réductrice d'XP (TDD et pair programming), cette session présente les principes d'XP version 2 et toutes les pratiques : cycle trimestriel...

Rendez-vous le 15 septembre, session du matin pour découvrir XP, méthode agile réellement complète :

• principes d'adaptation d'XP (Flot continu, diversité, économie...)
• pratiques de planification (cycle trimestriel...)
• pratiques de développement

Pour info, Alexandre Boutin animera une session Lean.

Plus d'informations :
http://daylight-group.com

Alistair Cockburn propose un serment de non-allégeance.

I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation.

Les personnes plus importantes que les processus, mêmes agiles.

Ce quatrième principe pose la collaboration quotidienne entre Métier et Développeur. Entre le Product Owner ou un délégué et les Développeurs dans Scrum.
Il reprend la pratique Client sur Site de l'Extreme Programming.
La non application de ce principe est certainement à l'origine de bon nombre d'échecs.

Quatrième principe

Ce quatrième principe est très simple et, pour une fois, objectif, peu sujet à interprétation.

Business people and developers must work together daily throughout the project.

Si vous connaissez un tant soit peu la langue anglaise, vous savez que l'emploi de "must" signifie une obligation forte.

Collaborer tous les jours... Pourquoi ?

J'ai noté une forte tendance qui consiste à pratiquer Scrum sous forme de courts cycles en V.
Le PO est présent lors du sprint meeting...
... Et on le retrouve lors de la revue pour compter les points.
C'est certainement une amélioration, mieux vaut un cycle en V de trois semaines que de six mois.
Pour autant, ce n'est pas de l'agilité dans la mesure où ce 4ème principe n'est pas respecté.
Et alors...
La question n'est pas d'être agile pour être agile, dans je ne sais quel esprit un tantinet orthodoxe voire rigide.
La question est celle de l'efficacité.

Je suis ici pour m'exprimer

Voila ce que pourrait dire le Product Manager dans XP, le PO dans Scrum.
Le Client est là pour exprimer ses besoins puis accepter le produit fabriqué par les Développeurs. Ici, l'équipe est bien composée des Développeurs et du Product Owner qui ne reste plus dans sa tour d'ivoire en regardant les autres jouer sur le terrain.
Or, l'expression de besoins dans XP et aujourd'hui dans Scrum passe par la technique des user stories.

Une User Story, comment ça marche

Vous connaissez peut-être le fameux 3 C de Ron. Jeffries.

• Carte : la carte ou post-it support physique de la story, que l'on retrouve par exemple dans le produit IceScrum
• Conversation : la story est une promesse de conversations pour reprendre l'expression du même Ron. J.
• Confirmation : ce qui va permettre l'acceptation de la réalisation, les critères puis tests d'acceptation*.

La dynamique des 3C

C'est dans la "dynamique" de ces 3C que l'on retrouve l'application de ce principe agile de collaboration quotidienne.
Il ne s'agit pas de reproduire un mini "cycle en V" dans lequel

1. le PO rédige la story et les tests (avant le développement)
2. le Développeur fabrique le produit correspondant
3. le PO valide (après le développement)

Évidemment, on adorerait, en tant que Développeur, disposer de tous les tests d'acceptation avant le développement. La vraie vie ne marche pas ainsi.
Le principe d'émergence des exigences (principe agile) se retrouve dans cette collaboration pendant laquelle :

• le PO écrit la story et quelques tests avant le développement
• le PO participe activement aux développement, il examine par exemple les écrans en cours de fabrication pour pouvoir donner un feedback concret et rapide
• au fur et à mesure, il découvre alors des facettes de cette story et les transforme en (nouveaux) tests d'acceptation

La difficulté réside dans la question
Est-ce toujours la même histoire ?

Reste à pratiquer intelligemment. Parfois le Développeur préfère avancer seul. Attention à ce que cela ne dure pas trop longtemps.

Ainsi, le PO est présent pendant le développement.

Réactif... Et pro-actif

Le PO n'est pas uniquement réactif. Si son rôle est de répondre rapidement aux questions et sollicitations du Développeur, il est aussi pro-actif. Il ne se repose pas uniquement sur la capacité des Développeurs à s'interroger, à détecter des manques.
Son tôle est aussi - spontanément - de voir le produit en cours de fabrication.

On peut aussi déléguer

Si le PO est en dernière analyse responsable du produit, il peut déléguer la participation à l'équipe sur certains points, par exemple pour participer au développement des stories d'un thème donné.

De nouvelles activités

Je crois que l'une des difficultés de l'agilité est cette perception de continuité dans les activités, alors que nous pratiquons des activités qui n'existaient pas officiellement en tant que tel.
L'agilité n'est pas un vernis appliqué sur le cycle en V.
Un Développeur n'écrit pas du code, il fabrique un produit qui doit avoir de la valeur pour ses Utilisateurs.

Billets consacrés aux principes agiles

Note : J'ai fini par comprendre que "acceptance" se dit "acceptation" en bon français. Si quelqu'un a la traduction en occitan, je suis preneur

Ce quatrième principe pose la collaboration quotidienne entre Métier et Développeur. Entre le Product Owner ou un délégué et les Développeurs dans Scrum.
Il reprend la pratique Client sur Site de l'Extreme Programming.
La non application de ce principe est certainement à l'origine de bon nombre d'échecs.

Quatrième principe

Ce quatrième principe est très simple et, pour une fois, objectif, peu sujet à interprétation.

Business people and developers must work together daily throughout the project.

Si vous connaissez un tant soit peu la langue anglaise, vous savez que l'emploi de "must" signifie une obligation forte.

Collaborer tous les jours... Pourquoi ?

J'ai noté une forte tendance qui consiste à pratiquer Scrum sous forme de courts cycles en V.
Le PO est présent lors du sprint meeting...
... Et on le retrouve lors de la revue pour compter les points.
C'est certainement une amélioration, mieux vaut un cycle en V de trois semaines que de six mois.
Pour autant, ce n'est pas de l'agilité dans la mesure où ce 4ème principe n'est pas respecté.
Et alors...
La question n'est pas d'être agile pour être agile, dans je ne sais quel esprit un tantinet orthodoxe voire rigide.
La question est celle de l'efficacité.

Je suis ici pour m'exprimer

Voila ce que pourrait dire le Product Manager dans XP, le PO dans Scrum.
Le Client est là pour exprimer ses besoins puis accepter le produit fabriqué par les Développeurs. Ici, l'équipe est bien composée des Développeurs et du Product Owner qui ne reste plus dans sa tour d'ivoire en regardant les autres jouer sur le terrain.
Or, l'expression de besoins dans XP et aujourd'hui dans Scrum passe par la technique des user stories.

Une User Story, comment ça marche

Vous connaissez peut-être le fameux 3 C de Ron. Jeffries.

• Carte : la carte ou post-it support physique de la story, que l'on retrouve par exemple dans le produit IceScrum
• Conversation : la story est une promesse de conversations pour reprendre l'expression du même Ron. J.
• Confirmation : ce qui va permettre l'acceptation de la réalisation, les critères puis tests d'acceptation*.

La dynamique des 3C

C'est dans la "dynamique" de ces 3C que l'on retrouve l'application de ce principe agile de collaboration quotidienne.
Il ne s'agit pas de reproduire un mini "cycle en V" dans lequel

1. le PO rédige la story et les tests (avant le développement)
2. le Développeur fabrique le produit correspondant
3. le PO valide (après le développement)

Évidemment, on adorerait, en tant que Développeur, disposer de tous les tests d'acceptation avant le développement. La vraie vie ne marche pas ainsi.
Le principe d'émergence des exigences (principe agile) se retrouve dans cette collaboration pendant laquelle :

• le PO écrit la story et quelques tests avant le développement
• le PO participe activement aux développement, il examine par exemple les écrans en cours de fabrication pour pouvoir donner un feedback concret et rapide
• au fur et à mesure, il découvre alors des facettes de cette story et les transforme en (nouveaux) tests d'acceptation

La difficulté réside dans la question
Est-ce toujours la même histoire ?

Reste à pratiquer intelligemment. Parfois le Développeur préfère avancer seul. Attention à ce que cela ne dure pas trop longtemps.

Ainsi, le PO est présent pendant le développement.

Réactif... Et pro-actif

Le PO n'est pas uniquement réactif. Si son rôle est de répondre rapidement aux questions et sollicitations du Développeur, il est aussi pro-actif. Il ne se repose pas uniquement sur la capacité des Développeurs à s'interroger, à détecter des manques.
Son tôle est aussi - spontanément - de voir le produit en cours de fabrication.

On peut aussi déléguer

Si le PO est en dernière analyse responsable du produit, il peut déléguer la participation à l'équipe sur certains points, par exemple pour participer au développement des stories d'un thème donné.

De nouvelles activités

Je crois que l'une des difficultés de l'agilité est cette perception de continuité dans les activités, alors que nous pratiquons des activités qui n'existaient pas officiellement en tant que tel.
L'agilité n'est pas un vernis appliqué sur le cycle en V.
Un Développeur n'écrit pas du code, il fabrique un produit qui doit avoir de la valeur pour ses Utilisateurs.

Billets consacrés aux principes agiles

Note : J'ai fini par comprendre que "acceptance" se dit "acceptation" en bon français. Si quelqu'un a la traduction en occitan, je suis preneur

Ce troisième principe est directement inspiré de la pratique "versions fréquentes" de l'Extreme Programming.
C'est un corollaire du premier principe qui précise le rythme des livraisons.

Troisième principe agile

Nous livrons fréquemment un logiciel opérationnel, le cycle de livraison étant de quelques semaines à quelques mois.

Ne pas confondre rythme des livraisons et rythme des itérations.

Versions fréquentes : attention à préserver un rythme viable, y compris pour les Utilisateurs.

Pourquoi livrer fréquemment ?

Deux raisons principales

Retour sur Investissement au plus tôt

Des fonctionnalités implémentées et non exploitées, c'est du stock au sens industriel du terme : de l'argent "qui dort".

Feedback concret et rapide

Ce principe XP se retrouve dans l'agilité. Ici le feedback provient des "Utilisateurs" du produit livré.

• Utilisateurs (les "rôles" sur lesquels travaille le PO pour ses features et stories)
• Exploitants : supervision...

Les livraisons forment le véritable rythme agile.
Les itérations forment le rythme de développement.

Exemple de cycle de vie agile

Ce cycle de vie est directement inspiré de ce que propose XP. Diapo extraite de la présentation XP de ce site.

Retrouvez tous les billets "Principes agiles".

Ce troisième principe est directement inspiré de la pratique "versions fréquentes" de l'Extreme Programming.
C'est un corollaire du premier principe qui précise le rythme des livraisons.

Troisième principe agile

Nous livrons fréquemment un logiciel opérationnel, le cycle de livraison étant de quelques semaines à quelques mois.

Ne pas confondre rythme des livraisons et rythme des itérations.

Versions fréquentes : attention à préserver un rythme viable, y compris pour les Utilisateurs.

Pourquoi livrer fréquemment ?

Deux raisons principales

Retour sur Investissement au plus tôt

Des fonctionnalités implémentées et non exploitées, c'est du stock au sens industriel du terme : de l'argent "qui dort".

Feedback concret et rapide

Ce principe XP se retrouve dans l'agilité. Ici le feedback provient des "Utilisateurs" du produit livré.

• Utilisateurs (les "rôles" sur lesquels travaille le PO pour ses features et stories)
• Exploitants : supervision...

Les livraisons forment le véritable rythme agile.
Les itérations forment le rythme de développement.

Exemple de cycle de vie agile

Ce cycle de vie est directement inspiré de ce que propose XP. Diapo extraite de la présentation XP de ce site.

Retrouvez tous les billets "Principes agiles".

Merci au site Toolinux de relayer l'article publié au départ sur le site Orsys.

Merci au site Toolinux de relayer l'article publié au départ sur le site Orsys.

L'association XP-France était créée en 2000. En 2009 elle devenait Agile-France. Entre temps, d'autres associations nationales ou locales apparaissaient pour promouvoir l'agilité.
C'est une forme, parmi d'autres, de communauté.
D'une certaine manière, le Web et l'omniprésent google forme aussi une communauté, virtuelle.

D'un manifeste à l'autre

Le Manifeste agile pose en 2001 la définition de l'agilité, en tant que tronc commun à différentes approches des années 90, qualifiées au préalable de légères en opposition aux méthodes traditionnelles, lourdes. Comparez le poids en Kg de la documentation dans chacun des cas.

Depuis, le manifeste pour l'artisanat du logiciel, en 2009, a permis de préciser l'esprit du manifeste agile.

Ce Manifeste évoque entr'autres une communauté de professionnels.
Manifeste pour l'artisanat du logiciel

Si l'agilité était une n-ième mouture de méthode "command & control", cette communauté pourrait être "simplement" une communauté au sens "technique". Nous échangeons nos expériences sur le développement, les outils...

Mais l'agilité va bien au-delà.

• Auto-organisation
• rythme viable
• qualité non négociable

sont autant de principes agiles frontalement opposés aux pratiques habituelles de la profession.
Et au-delà de la profession, opposés au système social actuel.
Je ne parle pas de la version "démo" des sociétés actuelles dites "démocratiques". Non, je parle simplement de ce qui ressort des discussions avec les personnes que je rencontre chaque jour, en formation ou en accompagnement.
Qui parlent de

• rythme insoutenable
• manque de qualité
• command & control par des personnes qui ne savent pas de quoi elles parlent
• Bref... de processus inadaptés à ce qu'est le logiciel.

Autrement dit, l'agilité ne se réduit pas à une compréhension partielle de son premier principe,en termes de mise en exploitation plus fréquentes donc retour sur investissement plus rapide.

Communauté de professionnels ?

Syndicat

Nous voyons donc que le propos de l'agilité est aussi la question du droit des Développeurs et au-delà des personnes parties prenantes du logiciel.

Si un Développeur agile est directement concerné par les outils d'intégration continue ou bien la dette technique du code, la dimension sociale est tout aussi importante.
Voire plus.
Quelle est la finalité, si elle ne s'accompagne pas d'une véritable auto-organisation ?

Et si la solution était beaucoup plus sociale qu'exclusivement technique en terme d'ingénierie ?
Et si la solution passait par une communauté telle qu'un syndicat ?

Syndicat : soyez agiles !
Déboulonnez les anciennes idoles pour créer votre syndicat !

L'association XP-France était créée en 2000. En 2009 elle devenait Agile-France. Entre temps, d'autres associations nationales ou locales apparaissaient pour promouvoir l'agilité.
C'est une forme, parmi d'autres, de communauté.
D'une certaine manière, le Web et l'omniprésent google forme aussi une communauté, virtuelle.

D'un manifeste à l'autre

Le Manifeste agile pose en 2001 la définition de l'agilité, en tant que tronc commun à différentes approches des années 90, qualifiées au préalable de légères en opposition aux méthodes traditionnelles, lourdes. Comparez le poids en Kg de la documentation dans chacun des cas.

Depuis, le manifeste pour l'artisanat du logiciel, en 2009, a permis de préciser l'esprit du manifeste agile.

Ce Manifeste évoque entr'autres une communauté de professionnels.
Manifeste pour l'artisanat du logiciel

Si l'agilité était une n-ième mouture de méthode "command & control", cette communauté pourrait être "simplement" une communauté au sens "technique". Nous échangeons nos expériences sur le développement, les outils...

Mais l'agilité va bien au-delà.

• Auto-organisation
• rythme viable
• qualité non négociable

sont autant de principes agiles frontalement opposés aux pratiques habituelles de la profession.
Et au-delà de la profession, opposés au système social actuel.
Je ne parle pas de la version "démo" des sociétés actuelles dites "démocratiques". Non, je parle simplement de ce qui ressort des discussions avec les personnes que je rencontre chaque jour, en formation ou en accompagnement.
Qui parlent de

• rythme insoutenable
• manque de qualité
• command & control par des personnes qui ne savent pas de quoi elles parlent
• Bref... de processus inadaptés à ce qu'est le logiciel.

Autrement dit, l'agilité ne se réduit pas à une compréhension partielle de son premier principe,en termes de mise en exploitation plus fréquentes donc retour sur investissement plus rapide.

Communauté de professionnels ?

Syndicat

Nous voyons donc que le propos de l'agilité est aussi la question du droit des Développeurs et au-delà des personnes parties prenantes du logiciel.

Si un Développeur agile est directement concerné par les outils d'intégration continue ou bien la dette technique du code, la dimension sociale est tout aussi importante.
Voire plus.
Quelle est la finalité, si elle ne s'accompagne pas d'une véritable auto-organisation ?

Et si la solution était beaucoup plus sociale qu'exclusivement technique en terme d'ingénierie ?
Et si la solution passait par une communauté telle qu'un syndicat ?

Syndicat : soyez agiles !
Déboulonnez les anciennes idoles pour créer votre syndicat !

Dans un précédent billet, nous avons étudié le premier principe agile qui rejoint le Lean sur l'aspect réduire le Lead-Time (tout en définissant l'incrémental - et non pas l'itératif - en tant que base).
Voyons maintenant le deuxième principe qui pose l'accueil du changement.

Le 2ème principe agile

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Bienvenue aux changements. Pas n'importe quel changement.
Avantage compétitif du Client.

Un changement de vision

Dans une approche classique, les exigences sont traduites par un "dossier de spécifications" sensé être complet, parfait.
L'agilité - empirique - va à l'encontre de ce besoin de tout modéliser au début de projet :

• le déroulement par le plan qualité de plusieurs dizaines de pages
• le planning par un Gantt de plusieurs centaines d'activités
• ...

Dans ce cas, un changement est vu comme un trublion.
Qu'en est-il ?
Les exigences sont le résultat d'une maturation.
Comment voulez-vous qu'un Product Owner spécifie parfaitement tout un produit qu'il est en train d'inventer et qui a pour but d'automatiser un savoir-faire probablement lui aussi en cours d'évolution ?
Ce que l'on retrouve dans cette donnée qu'il est bon de garder derrière l'oreille : en fin de vie d'un logiciel le constat est que plus de 60 % des spécifications implémentées l'ont été après la première version.

Émergence des exigences

Ce deuxième principe a pour corollaire un autre principe que nous verrons un peu plus tard et qui pose l'émergence des exigences.

C'est en utilisant le produit que l'on peut mieux le spécifier.

Pratiques Maintien du backlog

Une pratique essentielle est donc le maintien du backlog produit.
On présente habituellement une itération comme ce qui permet d'obtenir une nouvelle version du produit "potentiellement" déployable.
Or, un backlog réellement à jour est nécessaire en fin d'itération, tout simplement pour mener correctement le prochain plan d'itération (sprint meeting).
Donc... pendant que le PO participe journellement aux développements des stories en cours (spécifications par les tests, passage de tests, conversations..) il maintient également son backlog.
La démonstration (revue de sprint) est aussi un moment privilégié pour recueillir le feedback des participants et ainsi détecter des possibilités d'évolution du backlog.

Planification par la Valeur Métier

L'autre pratique importante ici est la planification par la Valeur Métier, sur des cycles courts. Voir par exemple les pratiques XP :

• Cycle trimestriel (versions fréquentes)
• Cycle habdomadaire (itérations).

Une question de choix

Pour certains, cette maturation des exigences est insupportable : "Comment ? On ne sait jamais où on va ?"
Pour d'autres, il est préférable de jouer sur un feedback concret et rapide

• itération
• version

et ainsi d'éviter de développer des choses inutiles car envisagées au départ... par ignorance.

Retrouvez tous les billets "Principes agiles".

Dans un précédent billet, nous avons étudié le premier principe agile qui rejoint le Lean sur l'aspect réduire le Lead-Time (tout en définissant l'incrémental - et non pas l'itératif - en tant que base).
Voyons maintenant le deuxième principe qui pose l'accueil du changement.

Le 2ème principe agile

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Bienvenue aux changements. Pas n'importe quel changement.
Avantage compétitif du Client.

Un changement de vision

Dans une approche classique, les exigences sont traduites par un "dossier de spécifications" sensé être complet, parfait.
L'agilité - empirique - va à l'encontre de ce besoin de tout modéliser au début de projet :

• le déroulement par le plan qualité de plusieurs dizaines de pages
• le planning par un Gantt de plusieurs centaines d'activités
• ...

Dans ce cas, un changement est vu comme un trublion.
Qu'en est-il ?
Les exigences sont le résultat d'une maturation.
Comment voulez-vous qu'un Product Owner spécifie parfaitement tout un produit qu'il est en train d'inventer et qui a pour but d'automatiser un savoir-faire probablement lui aussi en cours d'évolution ?
Ce que l'on retrouve dans cette donnée qu'il est bon de garder derrière l'oreille : en fin de vie d'un logiciel le constat est que plus de 60 % des spécifications implémentées l'ont été après la première version.

Émergence des exigences

Ce deuxième principe a pour corollaire un autre principe que nous verrons un peu plus tard et qui pose l'émergence des exigences.

C'est en utilisant le produit que l'on peut mieux le spécifier.

Pratiques Maintien du backlog

Une pratique essentielle est donc le maintien du backlog produit.
On présente habituellement une itération comme ce qui permet d'obtenir une nouvelle version du produit "potentiellement" déployable.
Or, un backlog réellement à jour est nécessaire en fin d'itération, tout simplement pour mener correctement le prochain plan d'itération (sprint meeting).
Donc... pendant que le PO participe journellement aux développements des stories en cours (spécifications par les tests, passage de tests, conversations..) il maintient également son backlog.
La démonstration (revue de sprint) est aussi un moment privilégié pour recueillir le feedback des participants et ainsi détecter des possibilités d'évolution du backlog.

Planification par la Valeur Métier

L'autre pratique importante ici est la planification par la Valeur Métier, sur des cycles courts. Voir par exemple les pratiques XP :

• Cycle trimestriel (versions fréquentes)
• Cycle habdomadaire (itérations).

Une question de choix

Pour certains, cette maturation des exigences est insupportable : "Comment ? On ne sait jamais où on va ?"
Pour d'autres, il est préférable de jouer sur un feedback concret et rapide

• itération
• version

et ainsi d'éviter de développer des choses inutiles car envisagées au départ... par ignorance.

Retrouvez tous les billets "Principes agiles".

Un précédent billet : la complainte de la délocalisation évoquait cette question lancinante, la délocalisation.
Voyons comment l'agilité, non seulement s'accommode (mal) de la délocalisation ou autre mirage off-shore. L'agilité propose aussi des arguments pour rester "local".

Agile délocalisé

L'un des principes agiles est la communication face à face.

Comment faire lorsque l'équipe (Client, Développeurs) est délocalisée ?
Une rencontre entre tous permet de créer cet esprit d'équipe indispensable à l'agilité. Cela permet aussi de prendre conscience du manque du à la délocalisation.
Des solutions

• Outil collaboratif
• Webcam ou vidéo-conf
• Télé-conf

permettent alors de pallier à ce manque de localisation de l'équipe.
Des produits comme Icescrum proposent une fonctionnalité de "chat".
Mais tout cela n'a rien à voir avec la présence effective du Client sur site (pratique XP). On perd en pro-activité, on perd en réactivité.
On perd en feedback concret et rapide.

Pourquoi être localisé

L'agilité pose l'intérêt d'accueillir les changements (le 2ème principe agile). Ce qui a pour corollaire l'émergence des exigences (autre principe agile). Pourquoi ?
Le postulat de l'agilité est que fabriquer un logiciel est trop complexe pour être modélisé par les gros documents du début de projet.

• Le gros plan qualité
• Le gros dossier de spécifications

en particulier. Plus précisément, les activités essentielles : spécifier et concevoir (au sens large) sont trop complexes.
Autrement dit, c'est en utilisant le produit que le Client (le Product Owner dans Scrum) peut mieux comprendre et exprimer les besoins.
D'où la pratique versions fréquentes d'XP que l'on retrouve sous forme de principe agile.

Quel est le rôle du Développeur dans l'expression de besoins ?

Soyons clairs : chacun ses responsabilités.
C'est bien le Client qui spécifie.
Pourtant, le Développeur joue un rôle essentiel.

Dans cette élaboration, cette maturation, des spécifications, le Développeur joue le rôle de miroir. Il sait faire apparaitre des contradictions, des flous, dans ce que raconte le Client.

Le Développeur joue aussi le rôle de poil à gratter.
Il sait poser les questions qui font mal. "Oui... Mais dans ce cas limite, on fait quoi ?".

Le Développeur participe donc à l'expression de besoins, indirectement, en tant que partenaire du Client. Tout comme un expert métier le ferait, dans des registres différents bien entendu.

Et cela ne se fait pas à distance.

Le service Client est prêt à payer (cher...) un "consultant" pour sa ré-ingénierie métier.
Dans le même temps (Ô Ségrégation !) ce même service n'hésite pas à acheter un outil essentiel (informatique) fabriqué par des esclaves à des milliers de kilomètres, se privant ainsi d'une expertise tout aussi pertinente (encore une fois dans un autre registre)... Et certainement moins chère tout en étant correctement rétribuée.

En cas d'avis de tempête : solidarité

Parfois la nouvelle tombe : le service est délocalisé (parfois on l'apprend dans la presse...).
Aïe.

Dans les années 80, alors que la République française devenait mitterandienne, la Pologne commençait à déboulonner les idoles soviétiques.
Solidarność
Si la Liberté ou la Justice en étaient la finalité, la solidarité en était le moyen.

Vous n'êtes pas satisfait des syndicats de votre société ?
Participez, créez un nouveau syndicat.
Vous pensez que le syndicalisme n'est pas la solution ?
Animez un mouvement citoyen.

Créez, animez, participez à des communautés de Développeurs.

Une communauté de Développeurs, ce n'est pas uniquement le partage d'infos techniques que l'on retrouve par l'inévitable gougueul. C'est s'inscrire dans une fraternité professionnelle.

En vous souvenant qu'être Développeur agile,
ce n'est pas uniquement ''pisser du code''.
C'est être à 100% responsable de la fabrication d'un produit logiciel
qui a de la valeur pour ses Utilisateurs.

Il est temps de voir rouge.

Un précédent billet : la complainte de la délocalisation évoquait cette question lancinante, la délocalisation.
Voyons comment l'agilité, non seulement s'accommode (mal) de la délocalisation ou autre mirage off-shore. L'agilité propose aussi des arguments pour rester "local".

Agile délocalisé

L'un des principes agiles est la communication face à face.

Comment faire lorsque l'équipe (Client, Développeurs) est délocalisée ?
Une rencontre entre tous permet de créer cet esprit d'équipe indispensable à l'agilité. Cela permet aussi de prendre conscience du manque du à la délocalisation.
Des solutions

• Outil collaboratif
• Webcam ou vidéo-conf
• Télé-conf

permettent alors de pallier à ce manque de localisation de l'équipe.
Des produits comme Icescrum proposent une fonctionnalité de "chat".
Mais tout cela n'a rien à voir avec la présence effective du Client sur site (pratique XP). On perd en pro-activité, on perd en réactivité.
On perd en feedback concret et rapide.

Pourquoi être localisé

L'agilité pose l'intérêt d'accueillir les changements (le 2ème principe agile). Ce qui a pour corollaire l'émergence des exigences (autre principe agile). Pourquoi ?
Le postulat de l'agilité est que fabriquer un logiciel est trop complexe pour être modélisé par les gros documents du début de projet.

• Le gros plan qualité
• Le gros dossier de spécifications

en particulier. Plus précisément, les activités essentielles : spécifier et concevoir (au sens large) sont trop complexes.
Autrement dit, c'est en utilisant le produit que le Client (le Product Owner dans Scrum) peut mieux comprendre et exprimer les besoins.
D'où la pratique versions fréquentes d'XP que l'on retrouve sous forme de principe agile.

Quel est le rôle du Développeur dans l'expression de besoins ?

Soyons clairs : chacun ses responsabilités.
C'est bien le Client qui spécifie.
Pourtant, le Développeur joue un rôle essentiel.

Dans cette élaboration, cette maturation, des spécifications, le Développeur joue le rôle de miroir. Il sait faire apparaitre des contradictions, des flous, dans ce que raconte le Client.

Le Développeur joue aussi le rôle de poil à gratter.
Il sait poser les questions qui font mal. "Oui... Mais dans ce cas limite, on fait quoi ?".

Le Développeur participe donc à l'expression de besoins, indirectement, en tant que partenaire du Client. Tout comme un expert métier le ferait, dans des registres différents bien entendu.

Et cela ne se fait pas à distance.

Le service Client est prêt à payer (cher...) un "consultant" pour sa ré-ingénierie métier.
Dans le même temps (Ô Ségrégation !) ce même service n'hésite pas à acheter un outil essentiel (informatique) fabriqué par des esclaves à des milliers de kilomètres, se privant ainsi d'une expertise tout aussi pertinente (encore une fois dans un autre registre)... Et certainement moins chère tout en étant correctement rétribuée.

En cas d'avis de tempête : solidarité

Parfois la nouvelle tombe : le service est délocalisé (parfois on l'apprend dans la presse...).
Aïe.

Dans les années 80, alors que la République française devenait mitterandienne, la Pologne commençait à déboulonner les idoles soviétiques.
Solidarność
Si la Liberté ou la Justice en étaient la finalité, la solidarité en était le moyen.

Vous n'êtes pas satisfait des syndicats de votre société ?
Participez, créez un nouveau syndicat.
Vous pensez que le syndicalisme n'est pas la solution ?
Animez un mouvement citoyen.

Créez, animez, participez à des communautés de Développeurs.

Une communauté de Développeurs, ce n'est pas uniquement le partage d'infos techniques que l'on retrouve par l'inévitable gougueul. C'est s'inscrire dans une fraternité professionnelle.

En vous souvenant qu'être Développeur agile,
ce n'est pas uniquement ''pisser du code''.
C'est être à 100% responsable de la fabrication d'un produit logiciel
qui a de la valeur pour ses Utilisateurs.

Il est temps de voir rouge.

L'un des termes à la mode depuis plusieurs années est off-shore. Si le Développeur est une ressource (humaine ?) alors autant l'acheter le moins cher possible ! Pourquoi payer un Développeur Java 320 EUR par jour si ailleurs il ne vaut plus que 30 EUR ?
Ben voyons...
C'est un peu le principe de l'usine logicielle : moins il y a d'Humains (et donc plus de machines) mieux c'est.
Si ce n'est que - tout en respectant les fabricants de boulons - nous fabriquons du logiciel du "soft", pas des boulons.
Et que l'un des postulats de l'agilité est l'émergence des besoins.
Par la collaboration entre Utilisateur et Développeur : cette émergence est consubstancielle à l'auto-organisation de l'équipe (ici équipe au sens agile signifie "y compris le PO").
Et en conversation face à face.

Mais... Nous avons une telle capacité à être fataliste, à accepter que l'on décide à notre place...

La complainte du délocalisé Quand ils ont délocalisé les Développeurs Cobol
Je n'ai rien dit
Je ne suis pas Développeur Cobol

Quand ils ont délocalisé les Développeurs C++
Je n'ai rien dit
Je ne suis pas Développeur C++

Quand ils ont délocalisé les Développeurs Fortran
Je n'ai rien dit
Je ne suis pas Développeur Fortran

Quand ils ont délocalisé les Développeurs C
Je n'ai rien dit
Je ne suis pas Développeur C

Puis ils sont venus me délocaliser
Et il ne restait plus personne
pour dire quelque chose

Librement adapté du poème de Louis Needermeyer