"Alors, je veux vous parler d' Agile et de Scrum ."
"Au début du 21e siècle, la façon dont les gens pensaient à la programmation a été bouleversée."
"Tout le monde était convaincu que la planification à long terme ne fonctionnait pas, alors ils ont décidé de l'abandonner complètement."
« Comment ont-ils fait ça ?
"Voici comment."
"Ils ont inventé l'approche de gestion de projet la plus flexible possible."
Voici les principales idées derrière le développement agile :"
- les personnes et la communication sont plus importantes que les processus et les outils ;
- un produit fonctionnel est plus important qu'une documentation exhaustive;
- la collaboration avec le client est plus importante que le respect des termes d'un contrat ;
- la volonté de changer est plus importante que de s'en tenir au plan initial.
Voici les principes du développement rapide :
- satisfaire le client en fournissant un logiciel de valeur de manière précoce et continue ;
- accueillir les changements d'exigences même à la fin du développement (cela peut augmenter la compétitivité du produit final) ;
- fournir fréquemment des logiciels fonctionnels (tous les mois ou toutes les semaines ou plus souvent) ;
- une communication quotidienne étroite entre le client et les développeurs tout au long du projet ;
- le projet est travaillé par des personnes motivées qui bénéficient des conditions de travail, du soutien et de la confiance nécessaires ;
- la méthode préférée pour communiquer des informations est une conversation personnelle (face à face) ;
- un logiciel fonctionnel est la meilleure mesure de progrès;
- les sponsors, développeurs et utilisateurs doivent pouvoir maintenir un rythme constant pendant une durée indéterminée ;
- souci constant d'améliorer l'excellence technique et la conception conviviale ;
- la simplicité est l'art de ne pas faire de travail superflu ;
- les meilleures exigences techniques, la conception et l'architecture proviennent d'une équipe auto-organisée ;
- adaptation constante aux circonstances changeantes.
"Le principal problème avec le développement de logiciels était qu'à aucun stade, aucun des participants n'avait d'informations complètes sur ce qu'il fallait faire."
"Le client peut vous dire comment il envisage le programme, mais il laissera quelque chose de côté ou prendra quelque chose pour acquis."
"Le responsable doit généralement traduire les exigences du jargon de programmation dans la langue du client et inversement."
« Il y a trop d'incertitudes.
"Souvent, les exigences du client sont comme ça : faites-le d'une manière ou d'une autre, puis montrez-moi - si je n'aime pas ça, alors vous pouvez le refaire."
"Euh... c'est affreux."
"Selon le nouveau paradigme, les programmeurs ne développent plus un produit ou un programme. Au lieu de cela, ils implémentent la fonctionnalité dont le client a besoin."
"Quelle est la différence?"
"Eh bien, supposons que le développement du programme prenne un an. Et six mois devaient s'écouler avant qu'il n'y ait quoi que ce soit à voir. C'est comme construire une grande maison : d'abord, vous creusez une fosse pour la fondation, puis coulez la fondation, le construire les murs, le toit, les boiseries, etc."
"Mais maintenant, les programmeurs essaient de libérer les fonctionnalités nécessaires dès que possible. Ce serait comme construire d'abord une hutte, puis une maison mobile, puis une petite maison, et seulement ensuite une grande maison, par tranches."
"Étant donné que le client ne sait probablement pas exactement ce qu'il veut, il s'agit d'une approche très raisonnable."
"Supposons que le client veuille un grand pavillon de chasse."
"Les promoteurs lui en construisent une petite. Il y vit un hiver. Puis il décide qu'il n'aime pas les maisons en bois. Faisons-en une en brique."
"Il vit près du lac pendant un été, mais les moustiques le mangent vivant. Il avait entendu dire quelque part que les lacs sont frais, alors il s'est imaginé en avoir un. Mais maintenant, il ne veut pas de lac. Et ce sera plus facile à construire la maison de cette façon : pas de lac, pas de risque d'inondation, et vous pouvez construire la maison sur le sol plutôt que sur des pilotis, ce qui sera 25 % plus rapide."
« Une analogie intéressante. Les clients changent-ils vraiment souvent leurs exigences ? »
"Oui, mais le problème n'est pas le client."
"D'abord, il est très difficile d'imaginer comment les choses vont se passer à l'avenir. Les managers, les testeurs et les programmeurs font tous cela aussi. Ils changent également d'avis en fonction de la façon dont les choses se déroulent."
"Deuxièmement, les exigences du client ne sont-elles pas ce qui compte le plus ? Après tout , le but de tout ce travail est de créer ce dont le client a besoin , et non ce qu'il a initialement dit de créer ."
"En effet, cela fonctionnait comme ceci : les analystes commerciaux dressaient une liste de toutes les exigences. Ils incluaient cette liste dans un contrat, le signaient et ne travaillaient qu'en fonction de la liste."
"S'il manquait à la liste quelque chose dont le client avait vraiment besoin mais qu'il avait oublié, personne ne ferait rien pour y remédier."
"Je vois. C'est plus facile de suivre un plan, mais tout ne peut pas être fait selon un plan !"
"Exactement."
"C'est pourquoi les méthodes de développement agiles ont été inventées."
"Et aujourd'hui, je vais vous parler de Scrum , le plus populaire d'entre eux.
"La principale caractéristique de Scrum est la division du développement de projet en petites itérations - généralement de 2 à 4 semaines. Chaque itération s'appelle un sprint."
"Au début d'un sprint, une réunion de planification de sprint a lieu. Elle dure 3-4 heures."
"A la fin, il y a une démonstration de toutes les tâches entièrement terminées."
"Voici comment tout fonctionne habituellement :"
"Avant le tout premier sprint, le client (ou un représentant du client) forme une liste d'exigences, c'est-à-dire l'ensemble des choses que le programme doit être capable de faire. Ces exigences sont généralement appelées user stories, et le client est généralement appelé le propriétaire du produit ."
"Il s'appelle le propriétaire du produit , car le produit est écrit pour lui. Lui, et lui seul, définit la liste des exigences - quoi, quand et dans quel ordre."
"De plus, le propriétaire du produit attribue généralement des priorités aux tâches. Les tâches les plus prioritaires seront implémentées en premier. La liste complète des exigences est également appelée backlog du produit ."
"Lorsqu'un sprint commence, tout le monde se réunit pour une réunion. Le scrum master , généralement un membre de l'équipe, dirige généralement la réunion. L'objectif de la réunion est de sélectionner les tâches ( user story ) pour le sprint en cours (itération de développement). "
"Tout d'abord, l'équipe attribue à chaque tâche une estimation approximative en jours-homme abstraits, également appelés points d'histoire. Ensuite, l'équipe décide du nombre de tâches qu'elle aura le temps d'accomplir pendant le sprint."
"Encore une fois, c'est l'équipe elle-même qui décide du nombre de tâches qu'elle aura le temps d'accomplir pendant le sprint."
"Disons que le Product Owner s'attendait à ce que l'équipe sélectionne les 7 premières tâches mais qu'elle n'en a sélectionné que 5, puis les tâches 6 et 7 sont reportées au sprint suivant. Si cela ne convient pas au Product Owner , il peut augmenter la priorité des tâches 6 et 7 pour s'assurer qu'elles sont sélectionnées, mais alors certaines des autres tâches seront abandonnées du sprint."
"Le scrum master peut également proposer de diviser certaines des tâches en tâches plus petites et de leur fixer des priorités différentes pour rendre le propriétaire du produit aussi heureux que possible."
"C'est le but de la réunion : les tâches peuvent être modifiées et fractionnées, les priorités peuvent être modifiées, etc. C'est le travail qui n'était pas visible au départ, mais qui apporte beaucoup de valeur."
"Compris. C'est comme conduire une voiture. Même si vous pensez au départ que vous devez juste aller tout droit, la réalité est que vous devez constamment éviter les nids-de-poule, tourner à droite et à gauche et dépasser les autres ou les laisser vous dépasser."
"Oui quelque chose comme ça."
"La liste des tâches choisies pour le sprint s'appelle le backlog de sprint ."
« Les programmeurs décident qui fera quoi, et ce n'est qu'alors qu'ils se mettent au travail. » Pour améliorer l'efficacité, Scrum suggère qu'une réunion de 5 à 15 minutes ait lieu chaque jour où chacun peut se dire ce qu'il a fait hier et ce qu'il est. va faire aujourd'hui."
"Le travail d'équipe. Je peux respecter ça !"
"Pour rendre les choses plus faciles à visualiser, il est généralement recommandé d'afficher l'état actuel du sprint sur un tableau spécial :"
"Notez les trois colonnes sur la gauche."
"Les noms abrégés des tâches sont écrits sur des notes autocollantes. Et les notes autocollantes sont placées dans différentes colonnes en fonction de leur statut (prévu, en cours, terminé)."
"Sur la droite, vous pouvez voir un burndown chart . Pour chaque jour, ce graphique répertorie les tâches qui restent à accomplir. Idéalement, le nombre de tâches inachevées tombe à zéro pendant le sprint."
"Quand le sprint est terminé, le scrum-master donne une démo pour montrer la liste de tout ce qui a été complètement terminé."
"Ensuite, il organise une réunion rétrospective de sprint, qui dure également quelques heures. Au cours de cette réunion, les participants essaient généralement de comprendre ce qui s'est bien passé et ce (et comment) les choses auraient pu être mieux faites."
"Généralement, après 2-3 sprints, vous pouvez identifier et éliminer les principaux problèmes qui empêchent l'équipe de travailler plus efficacement. Cela conduit à une plus grande productivité sans augmenter la charge de travail de l'équipe. Ce n'était pas possible avant l'ère des méthodologies agiles. "
"Parfois, une réunion de préparation est également organisée pendant le sprint. Son but est de planifier le prochain sprint. Les participants clarifient généralement les priorités des tâches lors de cette réunion. Ils peuvent également diviser certaines tâches en parties et/ou ajouter de nouvelles tâches au backlog du produit . "
"Eh bien, c'est à peu près tout ce que j'ai. Ce n'est qu'un aperçu. Il est impossible de tout expliquer en quelques mots, mais vous pouvez lire un bon article sur le sujet ici :"
GO TO FULL VERSION