Waterfall

Durée: 4m27s

Date de sortie: 21/02/2018

La plus grosse arnaque de notre industrie!

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

Est-ce que vous croyez que la capacité à livrer dans les temps,
les coûts, il y a avec la qualité requise et fonction de la méthodologie de conduite de projet ?
Telle est la question qu'on me pose sur LinkedIn ?
Non mais vous êtes sérieux ?
Évidemment que la réponse est oui, bien évidemment que le processus conditionne le résultat.
Maintenant la vraie bonne question c'est de demander est-ce qu'il y a une méthode meilleure que l'autre ?
Mais les gars en 2018 il y a encore un doute ?
Il y a vraiment encore un doute sur le fait que faire du logiciel en Waterfall
est beaucoup moins efficace que de le faire avec une méthode agile ?
Non mais vous êtes sérieux ?
Alors attention je vais ne parler que de ce que je connais bien,
c'est-à-dire le logiciel, le software.
Je ne fais pas partie de ceux qui veulent diffuser partout les méthodes agile, partout, partout, partout.
Moi je suis tombé dans l'extrême programming et l'extrême programming c'est ma famille d'adoption.
J'ai démarré par là et dans l'extrême programming il y a de fortes règles à respecter
sur la manière de faire sur les pratiques d'ingénierie.
Donc ça c'est pas forcément transposable partout.
Mais pour faire du logiciel on est d'accord ?
Il y a aucun doute ?
Attention je ne dis pas que les méthodes agile sont la recette miracle.
Si c'était le cas ça saurait, si c'était le cas on n'en parlerait même plus.
Évidemment qu'avec les méthodes agile on peut se planter.
Évidemment qu'on peut avoir des retard, des surcoûts, faire de la merde.
On peut toujours ces choses-là.
On est d'accord ?
Ça dépend pas de la méthode, ça dépend des gens qui sont dans l'équipe.
Mais sur le fait qu'il y ait une approche plus efficace que l'autre, il y a aucun doute ?
Ne serait-ce que pour une raison c'est que nous travaillons sur des méthodes qui sont empiriques,
empiriques par opposition ou prédictifs.
J'ai fait une vidéo sur YouTube qui parle de ça, sur la chaîne Agile-idée.
Je vous recommande d'y aller pour comprendre pourquoi, dans le cas du logiciel,
cela ne fait aucun doute sur le fait que les approches empiriques soient meilleures.
Mais là où ça me fait le plus marrer c'est quand on parle de Waterfall.
Waterfall quand vous lisez le papier de Winston Royce de 1970, où il parle de ça,
assez rapidement, il dit, ne faites pas ça, ça ne fonctionne pas.
Ne faites pas ça pour du logiciel, ça ne fonctionne pas.
Pourquoi est-ce que ça ne fonctionne pas ?
Il arrive bien trop tard dans le processus.
Et qu'est-ce qui se passe à ce moment-là ?
Il se la va demander au moment du test, en face des utilisateurs,
où en face d'intégration, cela va demander de tellement gros changements
qu'il va falloir prévoir potentiellement des délais et des surcoups
de l'ordre qui peuvent aller jusqu'à 100%.
Le gars écrit ça en 1970, les gars, on se réveille !
Il y a 50 ans, on savait déjà que le Waterfall ne fonctionnait pas.
Mais les gens ont retenu le Waterfall.
Alors ça c'est une bonne question.
Pourquoi est-ce que les gens ont retenu le Waterfall comme la solution idéale ?
A moi j'ai un début de réponse à vous proposer et je suis curé d'échanger.
C'est que c'est vachement rassurant.
On a l'impression d'être comme dans l'agence touriste,
un plan qui va se dérouler sans accro.
Oui mais les gars ça ne marche pas.
D'ailleurs lui-même, il donne un début de solution.
A la fin il dit, il faudrait faire en fait
un espèce de mini projet en amont pour évaluer
ce qu'on appellerait nous un carotage aujourd'hui.
Ce qu'on appellerait potentiellement
une première itération ou la fameuse itération 0.
Donc les gars arrêtez de me faire marrer avec Waterfall
le Waterfall pour faire du logiciel
est significativement moins efficace que les méthodes agile.
Et si vous voulez que les méthodes agile marchent vraiment
intéressez-vous à la technique.
Intéressez-vous au savoir-faire.
Accélérer les rythmes.
C'est intéressant sauf que si vous n'êtes pas capable de tenir la cadence
parce que vous ne faites pas ce qu'il faut sur le plan technique
vous allez dans le mur.
C'est pour ça que j'aime l'extrême programming
parce que l'extrême programming guide
sur les choses à faire sur le plan technique.
Et en plus on a des bases qui sont...
J'allais dire solides
mais je n'ai pas envie de dire solides
j'ai envie de dire qu'ils sont profondément ancrés.
Comme un arbre plus éracine
ils vont être profondément ancrés
et mieux ils vont tenir au vent.
Bah là c'est pareil.
Je suis curieux qu'est-ce que vous en pensez ?
Envoyez moins un email à benoîtarobaseartisandeveloper.com
ou laissez un commentaire.
A demain !

Episode suivant:


Les infos glanées

Je suis une fonctionnalité encore en dévelopement

Signaler une erreur

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

Lien du podcast

[{'term': 'Technology', 'label': None, 'scheme': None}, {'term': 'Technology', 'label': None, 'scheme': 'http://www.itunes.com/'}]

Go somewhere