
Pilier #2 Un Logiciel Opérationnel
Durée: 5m33s
Date de sortie: 14/03/2018
Un logiciel qui marche, c'est un peu la base, non?
Pas pour tout le monde...
Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.
Bienvenue sur le podcast Hortison développeur, l'émission pour les
développeurs passionnés qui combinent technique, agilité et développement
personnel dans le but de nourrir l'excellence.
Nos expériences nous ont amené à valoriser des logiciels opérationnels plus
qu'une documentation exhaustive.
Bienvenue dans ce podcast c'est le troisième épisode d'une série de cinq
sur la lecture du manifeste agile. Le premier épisode je parlais de pourquoi
étudier encore en 2018 le manifeste. Dans le deuxième épisode on parlait du
premier pilier et dans cet épisode on va parler du second pilier.
Alors des logiciels opérationnels plus qu'une documentation exhaustive.
Ça lâche l'ambiance, ça lâche à vous. Ça peut paraître un peu un truisme, un
peu une évidence mais pas tant que ça.
Dans le cycle en V, la place de la documentation est énorme.
Avant même le cycle en V dans le Waterfall, la documentation est ce qui
pilote réellement le développement. Ça peut paraître surprenant mais si tu
lis le papier de Winston Royce tu comprendras ça.
Donc la place de la documentation en 2001 est encore extrêmement forte et
prépendait rentre dans beaucoup de processus. Elle l'est toujours tu me
diras mais ce qui avait de particulier à ce moment là c'est que ça pouvait
prendre le dessus sur le reste. Moi j'ai connu une équipe, je te racontais
l'histoire d'une équipe, c'était un peu dingue. J'étais embarqué là-dedans et
on voyait bien les devs que ça allait pas le faire. On voyait bien que ça allait
pas passer. Mais c'était compliqué à dire et puis le
management ne voulait pas vraiment l'entendre. Et puis comme je suis quand
même un petit peu rebelle, j'avais osé timidement quand même du bout
d'élève demander mais euh... mais là ça va pas marcher. Et là on m'a
répondu c'est pas grave l'important c'est de livrer dans les temps avec la
doc. C'est à dire qu'à ce moment là dans cette organisation il était plus
important de livrer quelque chose qui ne marchait pas mais de pouvoir dire on l'a
livré que de réellement se préoccuper de savoir c'est ce qu'on livrait
fonctionné. C'est du vécu. Donc oui ça existe ces endroits.
Évidemment je m'oppose à ça. La seule chose qui compte réellement c'est que
le logiciel fonctionne. Je dis la seule chose non c'est pas vrai. C'est plus
important que le logiciel fonctionne. La documentation reste importante bien
sûr. Là aussi là aussi je préfère dire et par contre ce que je questionne c'est
la forme de la documentation. Et puis l'intérêt de la documentation
fondamentalement on a besoin d'une documentation pour quoi ? Pour faire
plaisir au management ? Pour faire plaisir à la qualité ? Non moi je pense que la
documentation on la recherche avant tout pour pouvoir transmettre, pour pouvoir
maintenir, pour pouvoir faire évoluer. C'est ça la fonction première d'une
documentation. Permettre à d'autres développeurs de prendre la suite,
permettre à d'autres développeurs de s'impliquer dans l'équipe. Et pour moi
il n'y a pas de meilleure documentation que le code lui-même. Si vous avez des
tests qui fonctionnent des tests automatiques qui décrivent le
fonctionnement attendu de l'application, vous avez votre documentation. Si votre
code est suffisamment explicite parce qu'il est bien codé et que l'intention
du développeur est clairement transcrise dans le code, vous avez la
documentation. C'est d'ailleurs une des raisons pour lesquelles j'aime tant que ça le
TDD, c'est que le TDD donne les tests qui forment la documentation. Puis j'aimerais
revenir sur la notion de logiciel opérationnel. Pour moi c'est très
simple, c'est quand même la mesure de progression essentielle d'un projet.
Est-ce que mon logiciel fonctionne ? Est-ce qu'il fonctionne bien ?
Et encore une fois c'est ça que j'aime avec le TDD, c'est qu'il me donne une
indication et il me permet de mesurer l'avancement de mon logiciel. Si j'ai
100 tests à faire passer pour que pour couvrir tous les besoins du logiciel,
je sais que si j'en ai fait passer 57, je peux considérer que je suis à 57%
d'avancement. C'est la mesure la plus objective que je connaisse de progression
d'un projet. Alors s'il fallait faire une synthèse encore une fois,
le côté révolutionnaire de 2001 et du manifeste à ce moment là, je pense
aujourd'hui que c'est un petit peu passé. Et moi aujourd'hui je préfère dire
« et » je veux « dé » logiciel opérationnel et une documentation exhaustive.
Je t'ai remercie d'avoir écouté ce podcast jusqu'au bout. Si tu as apprécié, j'ai un
service à te demander. Va sur le store iTunes et s'il te plaît, mets moi un
petit commentaire et une bonne note si possible cinq étoiles.
Si tu n'as pas le courage d'aller jusqu'au commentaire, au moins une bonne note.
Au-delà de flatter mon égo, c'est surtout que ça me permettra d'abord de me donner
de la motivation pour continuer ce podcast. Et puis ça sera un vrai levier pour
faire découvrir le podcast et le faire monter dans les classements et permettre
de diffuser ça à un maximum de monde. Je t'ai remercie et je te dis à demain,
je donne rendez-vous demain, on parle demain de la collaboration avec les clients.
Bonne journée.
Episode suivant:
Les infos glanées
ArtisanDéveloppeur
Artisan Développeur est un podcast destiné aux développeurs qui veulent bâtir une carrière épanouissante. Hébergé par Ausha. Visitez ausha.co/fr/politique-de-confidentialite pour plus d'informations.
Tags
Card title
[{'term': 'Technology', 'label': None, 'scheme': None}, {'term': 'Technology', 'label': None, 'scheme': 'http://www.itunes.com/'}]
Go somewhere
Pilier #3 La Collaboration Avec Le Client