Je viens d'ajouter un nouvel article qui décrit l'organisation d'un projet Agile utilisant la méthodologie Scrum dans un contexte classique à la française (séparation MOA/MOE).

Il est temps de donner un peu de nouvelles.

Quelques citations au passage :

« Les espèces qui survivent ne sont pas les espèces les plus fortes, ni les plus intelligentes, mais celles qui s'adaptent le mieux aux changements. »

Darwin

«  Un bon plan exécuté immédiatement vaut mieux qu’un plan parfait exécuté la semaine suivante. »

«  Si vous dites aux gens où aller, mais pas comment ils doivent y aller, vous serez impressionné par les résultats. »

«  Ne dites jamais aux gens comment faire les choses. Dites leur ce qu’ils doivent faire et vous serez surpris de leur ingéniosité. »

George Smith Patton

Voilà c'est fait, la vidéo vient s'ajouter au retour d'expérience.

Bonjour,

Je n'étais pas là pour en témoigner mais il paraît qu'il y a longtemps, les projets informatiques se faisaient en régie.
Par la suite, le client s'est vite méfié du prestataire : "Et si mon prestataire se la coulait douce ? Après tout il est sûr d'être payé et de ne jamais être inquiété en cas de problème"
Donc on en serait venu au forfait inversant les risques. Dorénavant, c'est le prestataire qui est sous pression "Et si mon client, ne s'implique pas assez, ne prends pas les bonnes décisions à temps, revient sans arrêt sur son besoin, ne valide pas les spécifications,...".

J'ai fait quelques recherches et voici une proposition de contrat équilibrant les risques entre client et prestataire nous venant de Bob Martin patron de Object Mentor et auteur de pas mal de bouquins primés portant sur le développement Agile et la conception orientée objet.

Pour l'expliquer, je prends un exemple simple pour ensuite expliquer le calcul.


Explication du calcul :

Au démarrage des travaux, l'entrepreneur évalue le nombre d'heures de boulot et multiplie le montant par son taux horaire : 8h x 100€ soit 800€.
Ensuite il divise la somme en 2 : 400€ son fixes (payés quoiqu'il arrive) et le reste de la somme correspond au nombre d'heure de boulot estimé facturées moitié moins cher (50€ l'heure).

Ce qui donne selon le scénario :

• Négatif : les travaux prennent plus de temps que prévu (2 heures de plus). Ce qui donne 400 € (fixe) + (10 heures x 50€) = 900 €
• Positif : les travaux prennent moins de temps que prévu (2 heures de moins). Ce qui donne 400 €(fixe) + (6 heures x 50€) = 700 €

Ainsi tout le monde y gagne, ou plutôt les risques sont partagés, les deux parties ont intérêt à collaborer.
Voilà un contrat qui permet de partir sur de bonnes bases il me semble.

Bien que je sois originaire du sud ouest, je n'avais jamais pris conscience de la richesse du Rugby, de ses valeurs.
Je le redécouvre donc avec plaisir grâce à la méthode Agile "Scrum" bien inspirée par ce sport.

Voici une petite vidéo qui illustre l'organisation d'une équipe, les rôles de chacun, on devine notamment en la regardant l'importance de la coordination.
Chaque joueur à un rôle précis, l'individualisme n'a pas sa place.

Voilà ce que j'ai pu trouver sur les valeurs du Rugby :

• L’AMITIÉ : « C’est le plus pur des sentiments humains »
• LE COURAGE : « C’est faire ce qui est juste »
• LA SINCÉRITÉ : « C’est s’exprimer sans déguiser sa pensée »
• L’HONNEUR : « C’est être fidèle à la parole donnée »
• LA MODESTIE : « C’est parler de soi-même sans orgueil »
• LE RESPECT : « Sans respect aucune confiance ne peut naître »
• LE CONTRÔLE DE SOI : « C’est savoir se taire lorsque monte la colère »
• LA POLITESSE : « C’est le respect d’autrui »

Dans mon équipe, une question m'a été posé quand j'ai proposé d'adopter à l'essai une pratique Agile de plus : "Ok mais comment on s'y prend, je ne trouve pas de véritable tutorial sur TDR (Test Driven Requirements) à part les principes de base et 3 exemples dans un contexte qui n'est pas le notre ?"

Ce qu’il faut bien comprendre avec certaines pratiques Agile (la majorité je pense), c’est que leur apprentissage et leur application sont par nature empirique.
C’est un peu comme en cuisine. On part d’une recette qui indique les ingrédients, les étapes, le temps de cuisson. La première fois on a tendance à appliquer scrupuleusement cette recette.
Mais, généralement les fois suivantes, on prend naturellement certaines libertés compte tenu de nos goûts (trop gras, pas assez salé, trop cuit,…) et du contexte (puissance du four, taille du plat,…).
Sur certaines pratiques Agiles comme TDD ou TDR, c’est un peu la même chose, les principes de base sont là, généralement rapides à assimiler, ensuite chaque projet fait sa cuisine en fonction de son contexte. Parfois ça ne fonctionne pas, dans ce cas là, on écoute les feedbacks, on adapte la pratique en fonction et on recommence. Le véritable apprentissage se fait par la pratique et l'empirisme. Nous avons tous appri à marcher de cette façon.

De nombreux projets de développement conservent une approche traditionnelle sur bien des aspects. Même si beaucoup d'entre nous admettent les travers d'une telle approche : pression forte, gestion des changements douloureuse, délais et budget souvent dépassés, relation client parfois difficile, journées de travail longues...

J'appelle « approche traditionnelle », une approche essentiellement basée sur le prédictif souvent illustrée par une phase de conception énergivore et coûteuse censée accoucher de spécifications fonctionnelles détaillées millimétrées. Ces spécifications deviennent ensuite le nerf de la guerre entre le commanditaire et le réalisateur lors de l'apparition des premiers changements (inévitables évidemment). Le tout dans le cadre d'un forfait.

Dans cet article, je propose de donner un peu plus de souplesse à cette approche sans basculer complètement dans l'agilité qui fait peur à beaucoup de monde (par ignorance, la plupart du temps).

Or trouver un outil qui couvre la plupart de ces besoins ou même l'ensemble n'est pas évident. Surtout quand le budget est serré.

Voici un article qui vous propose un ensemble d'outils pour différents budgets et différentes utilisations. Je me suis concentré sur des outils exclusivement client léger car l'aspect collaboratif est plutôt indispensable.

Bonne lecture