Bon, ok l'accroche est nulle, mais au moins j'ai votre attention.
Si vous n'avez aucun test, vous pouvez arrêter de lire.
Vous et votre logiciel n'allez jamais tenir le marathon *
Suivez le guide et oubliez mon accroche débile.
Test-driven, absolument.
Et non, le client ne doit pas "valider le surcoût".
Du reste, BDD et TDD sont géniaux mais insuffisants.
Ces techniques sont orientées qualité et architecture.
Une équipe peut y exceller et construire pourtant le mauvais logiciel.
On peut balancer du TestDriven en CleanArchitecture, avec une super #ContinuousDelivery.
On peut balancer tous les meilleurs buzzwords de l'industrie informatique.
On peut même exceller au point d'éviter systématiquement les N+1 queries.
On peut faire tout cela ...
... et construire des montagnes de fonctionnalités qui n'intéressent personne.
Du coup, en particulier en startup, pensez à d'autres X-driven encore.
Tout en nourissant le produit réel et la vision qui l'accompagne :
1️⃣ PDD - Prospect-Driven Development
Développer un truc qui en jette pour la démo au prochain prospect.
2️⃣ VDD - Video-Driven Development
Dans une stratégie de marketing inbound, développer des choses qui vont cartonner dans les démos vidéos.
3️⃣ RDD - Retention-Driven Development
Dans une stratégie de rétention haute, être absolument à l'écoute des utilisateurs et ne jamais les laisser bloqués trop longtemps.
Tout ça c'est de l'agilité bien comprise, pas uniquement techniquement.
Soyez créatif, inventez les vôtes, mais observez.
Au coeur de PDD, VDD et RDD, il y a un utilisateur.
Au coeur du TDD il y a un Technicien.
#SoftwareEngineering #Agile
- il y a une technique facile chez les développeurs cela dit: s'en aller pépouze et laisser les ennuis au suivant. Vous ai-je déjà dit que le problème de la tech c'est l'infidélité ?