Développement agile

« Salut Amigo ! »

"Salut, Bilaabo !"

"Aujourd'hui, je vais vous parler de la façon dont les programmes sont généralement développés."

"Au 20e siècle, lorsque l'informatique moderne en était à ses balbutiements, tout le monde semblait penser que la programmation était comme la construction ou la fabrication."

"Les choses se passaient généralement comme ceci :"

« Le client expliquait le type de programme dont il avait besoin, ce qu'il devait faire et comment il devait le faire.

" Les analystes commerciaux l'écoutaient et dressaient une liste complète des exigences du programme en fonction de ce qu'il disait."

"Ensuite, les chefs de projet diviseraient ces exigences en tâches et détermineraient également quel programmeur ferait quelle tâche et dans quel ordre."

"Ensuite, les programmeurs se mettaient au travail. Parfois, ils travaillaient plusieurs années (!)."

"Quand ils ont été terminés, le programme a été donné aux testeurs."

"Les testeurs passeraient en revue chacune des exigences du programme pour vérifier qu'elles étaient mises en œuvre et que le programme fonctionnait comme il était censé le faire."

"Si quelque chose tournait mal, les testeurs enregistraient les bogues et les envoyaient aux programmeurs."

"Ensuite, les programmeurs corrigeaient les bogues et renvoyaient le programme corrigé aux testeurs. Et le cycle se répétait."

"Lorsque les principaux bugs ont été corrigés, le programme a été remis au client."

« C'est vraiment comme ça que ça s'est passé ?

"Eh bien, bien sûr, j'ai beaucoup simplifié, mais c'est assez proche de la façon dont les choses ont été faites."

"Et un projet peut vraiment prendre un an et demi à deux ans pour être réalisé ?"

"Parfois, si le développement d'un projet était vraiment long, ils le décomposaient en versions distinctes. Tous les 3 à 6 mois, les développeurs devaient créer une partie spécifique de la fonctionnalité du programme, la tester, corriger tous ses bogues et la montrer au client."

"D'abord, pour qu'il puisse partager ses impressions. Et ensuite, et surtout, pour qu'il continue à payer pour le développement du programme."

« Continuer à payer ? »

"À l'époque, le développement prenait souvent 2 à 3 fois plus de temps que prévu. Et comme les programmeurs étaient souvent payés à l'heure, le programme devenait 2 à 3 fois plus cher. De plus, les avantages étaient également réduits. Après tout, ce que le client veut aujourd'hui pour 100 000 $ peut ne pas être nécessaire dans 3 ans - surtout à trois fois le prix."

« Les clients refusaient-ils souvent de payer ? »

"Ouais. Plus tard, ils ont commencé à ajouter des pénalités au contrat, mais cela n'a pas amélioré la situation. Le développement de logiciels a traîné en longueur. Et personne ne pouvait rien y faire, même s'il le voulait."

"Mais pourquoi?"

"Eh bien, tout d'abord, on en sait trop peu pendant la phase de planification. Le plus souvent, au début, personne ne pouvait prédire les problèmes auxquels les programmeurs seraient confrontés."

« Mais des programmeurs expérimentés auraient dû tout prévoir, n'est-ce pas ? »

"Pouvez-vous voir que la programmation est une profession unique."

"Un ouvrier ordinaire exécute souvent le même travail encore et encore. Les horlogers fabriquent des montres, les cuisiniers cuisinent, les enseignants enseignent, les médecins soignent, etc."

"Chacun de ces professionnels fait essentiellement la même chose jour après jour. En conséquence, ils commencent à s'améliorer de plus en plus dans leur travail."

"En programmation, l'approche est différente. Dès qu'un programmeur est confronté à la même tâche tous les jours, il écrit une fonction, un module ou un programme pour l'exécuter, et n'y revient plus jamais."

"Chaque programmeur résout généralement chaque tâche une fois dans sa vie."

"Quelque chose comme des scientifiques ou des ingénieurs concepteurs qui inventent des choses."

« Ah. Eh bien, quel est le rôle le plus important dans un projet ? »

"Hmm, comment dois-je répondre à ça. C'est facile de dire lequel est le plus important, mais identifier le moins important est difficile."

" Le travail principal d'un testeur ( assurance  qualité , QA ) est de surveiller l'état d'un programme et de signaler rapidement les bogues. Plus un testeur trouve des bogues et tôt  , plus ils peuvent être corrigés.  Un bon testeur influence la qualité du produit plus que un bon programmeur le fait ."

« Pourquoi les programmeurs ne peuvent-ils pas tester leurs propres programmes ? Après tout, ne savent-ils pas mieux que les testeurs ce qui fonctionne et ce qui ne fonctionne pas ? »

"Un bon programmeur est tout simplement incapable d'être un bon testeur. Un programmeur sait très bien comment le programme fonctionne, donc il l'utilise toujours d'une certaine manière. Contrairement aux utilisateurs ordinaires qui utilisent le programme comme ils le souhaitent. "

"De plus, les testeurs ne testent pas ce qui ne fonctionne pas encore. Le testeur teste les fonctionnalités ou les parties du programme qui, selon le programmeur, fonctionnent déjà presque parfaitement."

"Et lorsque le testeur trouve des tonnes de bogues dans cette fonctionnalité et que le programmeur les corrige, le produit se rapproche en fait de la perfection."

" La tâche principale d'un programmeur ( S oftware  D eveloper  Engineer ,  D eveloper ,  SDE ) est de mettre en œuvre de nouvelles fonctionnalités. Ou, plus simplement, d'effectuer les tâches qui lui sont assignées. Quand les programmeurs se voient attribuer des tâches avec de nouvelles fonctionnalités , ils les exécutent. Quand on leur assigne des bogues, ils corrigent des bogues.

"Mais parfois, il y a des tâches plus difficiles, par exemple, proposer l'architecture du programme ou des parties de celui-ci. Plus l'architecture proposée est bonne, plus il sera facile de faire avancer les choses à l'avenir."

"Le problème est que l'architecture doit être choisie au tout début, mais ce n'est que lorsque vous êtes au milieu du développement qu'il est clair si vous avez choisi la bonne architecture."

"De plus, si l'architecture est réussie et que le programme s'avère excellent, le client voudra probablement l'utiliser comme base pour de nouvelles versions du programme."

"Voici où je veux en venir."

"Quelle que soit l'architecture que vous choisissez, il y aura toujours un tas de changements, d'ajouts et de nouvelles fonctionnalités dont l'architecture ne tient pas compte."

"Voilà un bon exemple."

"Un client vous demande de construire un immeuble de 5 étages, alors vous concevez une architecture et construisez la maison."

"Ensuite, le client demande d'ajouter une autre histoire, puis une autre, et ainsi de suite."

"Mais les murs du premier étage n'étaient pas conçus pour autant de poids, et les fondations non plus. Donc tout est à refaire."

"Mais une fois le bâtiment de 5 étages terminé, que se passe-t-il si le client décide immédiatement qu'il veut un bâtiment de 50 étages ?"

"Il serait plus facile de démolir la structure existante et de tout reconstruire à partir de rien…"

"Mais j'ai un conseil pour vous concernant l'architecture."

"L'architecture d'une application doit avant tout être flexible, ce qui signifie que vous n'aurez pas à repartir de zéro si vous décidez de refaire la moitié de l'application. Ce type d'architecture est généralement qualifié de flexible et modulaire . "

" Le travail principal du chef de projet est de prendre des décisions. Le chef de projet est celui qui voit la situation dans son ensemble et prend des décisions en fonction de cette perspective."

"Supposons qu'au cours du développement, il devienne clair qu'une certaine tâche ne sera pas terminée comme prévu. Le chef de projet peut alors :"

" a)  essayer de négocier avec le client pour modifier la tâche"

" b)  allouer plus de temps à la tâche"

" c)  faire venir des programmeurs plus expérimentés d'autres projets."

"Et il y a beaucoup d'autres possibilités."

"Chaque option vous oblige à sacrifier quelque chose, et le travail du manager est de minimiser les pertes totales de ces sacrifices. "

"Par exemple, supposons que des concurrents volent le programmeur principal en lui offrant deux fois plus d'argent."

"Le chef de projet peut :"

" a)  ne rien faire. Le programmeur partira, et le projet prendra probablement du retard et encourra des pénalités."

" b)  doubler son salaire. Ensuite, tous les autres membres de l'équipe voudront également des augmentations. Si vous leur donnez plus d'argent à tous, les coûts du projet augmenteront et il pourrait devenir non rentable. "

" c)  une autre option que vous imaginez."

"Je vois."

"Avec un mauvais chef de projet, une bonne équipe allonge généralement un projet, mais pas toujours."

"Un bon manager avec une équipe de programmeurs moyens terminera presque toujours un projet plus rapidement qu'un mauvais manager avec une équipe d'excellents programmeurs."

"Je vois."

"D'accord, faisons une courte pause, puis nous continuerons."