Un point d'étape révèle qu'un tiers seulement du projet est fait à…

Reprenons le morpion, dont le noyau est « deux humains, terminal, annonce du résultat », et supposons que le groupe visait en outre l'adversaire automatique, la grille $n\times n$ et l'enregistrement des scores. À mi-parcours, seuls grille et une partie de regles tournent.

Trois réductions, de la moins douloureuse à la plus radicale.

• Abandonner les trois extensions, et les seules. Le noyau est intact, il reste à finir gagnant, affichage et partie. C'est la réduction à tenter d'abord, et elle suffit souvent : les extensions représentaient l'essentiel du travail restant.
• Simplifier l'affichage : afficher la grille avec un simple print de trois lignes, au lieu du tracé encadré prévu. On gagne une séance, on ne perd rien de démontrable.
• Réduire les entrées : au lieu de lire deux entiers et de gérer toutes les saisies fautives, lire un seul numéro de case de $0$ à $8$. Une seule vérification au lieu de deux, et le jeu reste jouable devant un public.

Ce qu'il ne faut surtout pas réduire. Ni les tests, ni la fin de partie. Supprimer les tests fait gagner une séance et en coûte deux à la suivante. Supprimer la détection du gagnant laisse un programme qui ne se termine pas — donc rien à montrer, ce qui est exactement le résultat qu'on cherchait à éviter.

Le critère qui décide, à chaque candidat à la coupe : cette suppression laisse-t-elle une démonstration complète de bout en bout ? Si oui, on coupe. Si non, on cherche ailleurs.

Ce que dit le programme, et qu'il faut lire deux fois : un point d'étape sert à « adapter ses objectifs, voire le redéfinir partiellement ». Réduire à mi-parcours n'est pas un constat d'échec — c'est le mécanisme prévu, et le seul échec possible ici serait de continuer comme si de rien n'était jusqu'à la veille de la présentation.