L’événement débutera à 8 h, pour une durée de 2 heures. Un petit déjeuner sera servi.

Inscrivez-vous maintenant, les places sont limitées.

Au plaisir de vous y voir!

Il s’agit donc ici non seulement d’échanger sur les barrières rencontrées, mais surtout de pratiquer le TDD dans cette couche souvent délaissée. Cette séance se veut interactive : – chaque participant dans la salle est invité à binômer avec son voisin; – toutes les 20 minutes, nous comparerons les différentes stratégies incrémentales empruntées.

1. Merger une branche sur elle-même
2. Rechercher un commit

1. Créer un nouveau répertoire suivi par git.
2. Repérer un commit en particulier. En pratique un code chat, du genre 3a68fd32ca3b16547c5abb2da52fdf7aed290ee3
3. Contredire le commit héros de cette histoire
4. git cherry-pick 3a68fd32ca3b16547c5abb2da52fdf7aed290ee3
5. Et là, « magie »

1. Créer un fichier shell qui teste si mon fichier existe.
2. initialiser git bisect. Je prends l’intervale le plus large : [HEAD premier-commit]
3. lancer le run: git bisect run search.sh

• Nous avons pris le temps d’explorer plusieurs manières d’exprimer nos tests : les  assertions basiques de NUnit, l’écriture d’une contrainte personnalisée.
• Nous avons évoqué le Broken Test Pattern avant la pause. Partir avec un test rouge avant la pause nous aide au retour à savoir où nous en sommes.
• Nous avons utilisé nos moments de refactoring pour introduire au maximum le langage du domaine qui faciliterait une conversation avec un expert du domaine.
• Chemin faisant nous avons créé de la duplication algorithmique et nous avons ressenti le dilemme entre payer cette dette et augmenter les capacités de notre code.

Qu’est-ce que tu vois après Scrum ?

De mon expérience, lorsque quelqu’un me pose cette question, il s’attend à ce que l’on parle de la prochaine méthode, de la prochaine approche, du prochain outil. Il a souvent envie d’avoir un avis comparé sur toutes les méthodes ou techniques du moment. Je me souviens par exemple que c’est de cette manière qu’était posé le thème d’une table pendant un world-café Scrum avec l’intention d’étudier le buzz de l’époque sur le Kanban.

Aujourd’hui, ce n’est pas cet aspet de la question qui m’interpelle. Considérant Scrum comme un outil que l’on utilise pour découvrir ce que l’on a besoin de changer pour devenir meilleurs à développer des logiciels, la question de l’après Scrum m’incite à imaginer le monde lorsqu’effectivement nous serons devenus meilleurs à développer des logiciels.

Est-ce que tu imagines qu’alors nous n’aurons plus besoin de Scrum ?

Non car d’une part on peut toujours progresser, et d’autre part il faudra toujours former la relève.

Cette question de la formation des jeunes m’amène à considérer l’intégration de Scrum à l’enseignement universitaire non pas comme l’outil à apprendre mais comme un outil à utiliser au cours de la formation pour construire des équipes performantes. Ces universités, ou plutôt ces académies du logiciel, ne formeront plus des individus mais des équipes complètes capable de livrer un logiciel utile en un mois.

Le mouvement du software craftmanship qui étudie des modèles autour du compagnonnage nous donne des pistes pour repenser la formation continue autour du parrainage actif de ces nouvelles équipes par des professionnels d’expérience.

De son côté le lean startup explore des modèles de recherche de valeur en se basant sur des cycles d’apprentissage très rapide.

Plusieurs questions se bousculent. Que veux-tu dire par livrer un logiciel utile en un mois ? Pourquoi un mois ? J’ai en tête des systèmes qui ont mis des années à être construits, imagines-tu pouvoir les construire en un seul mois ?

Lol. Allons-y doucement.

Plusieurs pièces du même puzzle s’emboîtent pour moi très naturellement.

Une première pièce concerne la formation que l’on vient d’évoquer. Une autre concerne le mode de financement.

Le passage du Waterfall à Scrum a des impacts importants sur de nombreux aspects. Néanmoins, sur le terrain, le mode de financement est souvent resté le même. Je rencontre de nombreux cas dans lesquels des projets démarrent pour 12 ou 18 mois tout en disant qu’ils vont utiliser Scrum. Plusieurs éléments m’interpellent dans ces situations. Par exemple on parle alors souvent de projets, et non de produits. Ou encore, plus évident, on a déjà un plan et un financement pour plusieurs mois, ce qui me semble contradictoire avec une approche empirique, c’est à dire une approche qui considère que l’humain ne sait pas identifier ce qui sera une bonne idée dans 6 mois.

Imaginons maintenant une rupture plus nette. Un mois, un seul.

Cela nous invite à considerer un mode de financement différent. Dans ce mode, je ne finance que le premier mois et je mets en production l’incrément construit. Cet incrément ensuite génère lui même les bénéfices pour financer un autre incrément.

Cela suppose que l’on sache trouver de la valeur en un seul mois.

Oui. Et que l’on sache livrer un incrément terminé en un mois. C’est une invitation à aller au delà du potentially shippable, c’est une invitation à shipper.

Scrum est un outil pour être meilleur. Un outil pour s’entraîner à livrer un logiciel utile en un mois. S’entraîner à trouver la fonctionnalité utile. S’entraîner à construire un incrément terminé. Les deux.

Shipper plutôt que potentially shippable me semble puissant car dans sa recherche de ROI, le Product Owner doit mettre en production pour effectivement avoir accès au ROI. Sinon, ce ROI n’est que potentiel.

N’as-tu pas peur de perdre les avantages de l’empirisme dans cette idée de faire des itérations d’un mois ?

Je n’ai pas dit ça.

Vous vous rappelez sans doute que dans la première description de Scrum, Ken et Jeff parlaient de sprints d’un mois, plus exactement de 30 jours. On a tous interprété cela comme des itérations d’un mois. Et on continue d’ailleurs à traduire sprint par itérations et de parler de sprints ayant des tailles comprises entre 1 et 4 semaines. Il faut dire que cela a des côtés pratiques dans nos calendriers.

Si on cantonne la notion de sprint au container de 30 jours dans lequel l’équipe se dote d’un objectif de sprint, le sprint goal, et s’impose un niveau de qualité production, rien n’empêche l’équipe de faire des itérations à l’intérieur de ce sprint, par exemple d’une semaine.

Cela ouvre l’idée de livrer un logiciel en un mois, puis de s’arrêter pour attendre d’avoir de nouvelles idées. Ne penses-tu pas que les clients continueront à avoir envie d’ajouter immédiatement d’autres fonctionnalités ?

On parle de clients dans un futur avec des équipes capables de leur livrer en un mois un logiciel pour les aider à tirer profit de leur idée. Ce ne sont pas les clients que l’on connait aujourd’hui. Leurs états d’esprit n’est plus le même. Ils valorisent le feedback d’utilisateurs qui ont utilisé le logiciel en situation réelle. Parfois plusieurs semaines, plusieurs mois peut être seront nécessaires pour un feedback pertinent. Pour ceux qui sont dans ce cas, s’ils ont envie d’ajouter une fonctionnalité, ils ne voudront certainement pas l’ajouter immédiatement, ce serait trop risqué.

Reprendre un développement plus tard représente un risque, comment être sûr que l’on trouvera une équipe capable d’ajouter une fonctionnalité ?

Aujourd’hui on est déjà dans cette situation. Il n’y a pas de raison de penser que le monde va devenir plus simple. Il y aura toujours des incertitudes, elles ne feront que changer et probablement que nous ne pouvons pas aujourd’hui anticiper de quelles natures elles seraient dans ce futur.

On peut néanmoins anticiper que les équipes continueront à avoir des spécialités. Certaines choisiront par exemple les énormes systèmes à modifier en un mois pour ajouter une fonctionnalité clef. D’autres se spécialiseront sur les nouveaux logiciels sans héritage à inspecter et un nouveau domaine à explorer.

L’industrie continuera à progresser. Les techniques et les outils continueront à s’améliorer et les prochaines promotions feront en une semaine ce qui prenait un mois aux précédentes. Le parrainage permettra d’enrichir mutuellement les mondes universitaires et professionnels.

Le point clef est d’apprendre à livrer un logiciel utile en un mois. Les équipes ont l’embarras du choix pour s’entraîner. Le monde regorge d’associations caritatives qui pourraient bénéficier de leur travail. Un seul critère d’évaluation : que le logiciel soit utilisé.

Tu parles d’académies, de mettre au placard les développements de plus d’un mois, mais tu vois ça pour quand ?

Les progrès accomplis dans les 10 dernières années tels que je les comprends me font penser que cela mettra plus de 10 ans. J’aimerais que cela prenne moins de 20 ans pour pouvoir en profiter.

Cela semble ambitieux. Par où commencer ?

C’est la troisième pièce de mon puzzle : le chemin pour nous y rendre. Pour l’instant je n’en connais que le début bien sûr. Et encore, un début qui fait du sens pour moi.

Evidemment il faut continuer à s’entraîner car nous sommes loin de ce monde. Cela veut dire enseigner tout ce qui peut aider une équipe à livrer un logiciel utile en un mois. Je contribue à cette effort en donnant des formations sur les pratiques agiles.

S’entraîner cela veut dire aussi aider les équipes à mettre en place ce qui fonctionne pour nous et que nous enseignons. Je me concentre aujourd’hui sur deux activités clefs qui maximisent selon moi cette transmission. D’une part l’animation de dojos dans les équipes. D’autre part l’immersion dans ces équipes : un mois avec une équipe avec l’objectif de lui transmettre le plus de savoir-faire et savoir-être possible.

S’entraîner enfin c’est livrer des logiciels utiles en un mois. De nombreuses personnes ont des idées et voudraient trouver une équipe pour leur livrer un logiciel rapidement pour tirer profit de leur idée.

Donc si je comprend bien, ils n’ont qu’à te contacter.

Exactement .