#mes2sous

« Car pour coder des tests automatisés il faut prévoir du temps. Environ 20 à 30% de temps de dev en plus. »

Ce que j'avais appris c'est que pour être propre, le test « visible » ça représente 50% du temps de dév. Et si on inclue le test « invisible » (débug, tests unitaire, lecture de console, revue de code, …), en réalité tester prend autant de temps que coder.

« Le client veut les features 1 à 14, donc vous devez faire les features 1 à 14. Point.
On préfère donner au client une version instable et pleine de bugs avec des bugs qui contient ces 14 features, qu'une version ultra stable et testée qui contient que 10 features. Car contrat, engagement, tout ça. »

Et c'est de ce constat que l'on est passé d'une conception « cycle en V » au « développement Agile ».

« En plus, quand, en tant que dev, on doit estimer un sujet, ben on oublie tout ça. On estime "ok une journée pour ça, une journée pour ça, et une journée pour ça, donc 3 jours".
Sauf que t'as pas calculé qu'un logiciel plantera. Qu'un autre sera incompatible avec un prérequis. Que le besoin client sur un point précis changera pendant ces 3 jours. Que le serveur aura pas la bonne mise à jour pour un des plugins. Etc. »

Ou alors : « Fonction 1 = 1 jour ; Fonction 2 = 1 jour ; Intégration de fonction 1 avec fonction 2 = 1 jour. Total pour 2 fonctions = 3 jours. »
Après il faut faire attention car 3 fonctions = 6 jours, 4f = 10j, 5f = 15j, …

« Perso j'ai une règle ultra simple dans l'informatique. Tu dois estimer un truc ? Tu estimes honnêtement combien de temps il te faut pour le faire.
Ensuite tu fais x2 pour une estimation réaliste et réalisable.
Et si tu veux faire du code propre, tu fais x3. »

#tafdak
— Permalien