human
Développement logiciel agile Si possible :D tout avantage ou inconvénient Merci Expliquez comme si j'avais cinq ans.
gpt
À l'époque de l'âge de pierre, l'homme faisait du feu avec des bâtons, et les logiciels étaient livrés sur CD-ROM et avant cela sur disques. À cette époque, le développement de logiciels commençait par une liste de souhaits et une date de livraison. La date d'expédition correspondait au jour où le logiciel devait être prêt à être expédié. Car c'était le jour où la copie Golden Master du logiciel serait envoyée aux duplicateurs de disque, et cela devait être fait et parfait. Pas de bugs, toutes les fonctionnalités sont terminées. La date d'expédition a obligé les éditeurs de logiciels à établir des calendriers à long terme axés sur la date d'expédition. Il y avait un délai. Ce qui s'est passé entre les dates de livraison était un pur chaos. Les fonctionnalités ont été débattues, les bogues ont été corrigés, de nouveaux bogues ont été ajoutés, les fonctionnalités ont été tuées à la 11e heure. Désordre pur. C'est ce qu'on appelle le mode chute d'eau : le chaos se précipite vers une falaise. Enfin, à 17 heures le jour de l'expédition, quelqu'un faisait courir le disque Golden Master au terminal FedEx de l'aéroport et manquer cet avion signifiait faire chier de nombreux grands distributeurs importants qui s'attendaient à avoir votre boîte sur leurs étagères le jeudi suivant. Le chaos . Après que le Golden Disk soit en sécurité au terminal FedEx, vous vous rendez compte que vous avez oublié de désactiver les drapeaux DEBUG dans le logiciel. Plus de chaos. Puis Internet est devenu populaire. Internet a supprimé l'apocalypse de la date de livraison pour la plupart des logiciels. Désormais, les utilisateurs peuvent télécharger le logiciel directement auprès des développeurs à tout moment. Cela a complètement changé les calendriers de développement logiciel pour qu'ils soient plus continus : itératifs au lieu de cascades. Agile embrasse l'idée qu'il n'y a pas de date de livraison finale, il n'y a pas de "terminé", mais plutôt le développement est un flux continu d'améliorations. Mais pour planifier un développement continu, vous ne planifiez que ce qui sera développé pendant les 2 ou 3 prochaines semaines (un « sprint »). Vous avez également une feuille de route produit qui vous indique les objectifs globaux à long terme pour un produit mais pas de dates de livraison spécifiques pour ces objectifs (parce que la date de livraison de la version = cascade = chaos) Alors, qu'est-ce qui est développé pour les 3 prochaines semaines ? Cela passe par priorité. Il y a un backlog : la liste des bugs à corriger et des fonctionnalités à ajouter. Le backlog est tenu par ordre de priorité par un Product Owner : quelqu'un qui peut décider des priorités. Combien de fonctionnalités sont développées en 3 semaines ? L'équipe de développement estime la taille de chaque problème dans le backlog, chaque problème est noté en "points d'histoire" et l'équipe de développement sait combien de "points d'histoire" ils peuvent gérer en 3 semaines. Que se passe-t-il au bout de 3 semaines ? Un autre sprint démarre et vous recommencez. Quand sortira la prochaine version ? Pour adopter Agile, vous devez également adopter le déploiement continu : la dernière version est continuellement testée et mise en distribution dès qu'elle passe les tests. Cela peut se produire à tout moment, idéalement plusieurs fois au cours d'un sprint. Pourquoi les développeurs adopteraient-ils ce genre de bureaucratie ? Le gros avantage que la planification Agile peut offrir est que la direction est censée convenir qu'une fois qu'un sprint a été planifié, il n'y a pas de changement une fois que le sprint a commencé. Cela isole les développeurs de la tyrannie des managers qui veulent que leurs idées fantaisistes du jour soient mises en œuvre maintenant et que tout autre travail soit arrêté. Les managers qui adoptent Agile respectent le processus et permettent aux développeurs de se concentrer sur ce qui a déjà été convenu.