5 scrum-export bis

  • 898 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
898
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
45
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Les méthodes agiles représentent un mouvement qui vise à apporter plus de valeur aux clients et auxutilisateurs, ainsi qu’une plus grande satisfaction dans leur travail aux membres de l’équipe.Le but affiché d’une méthode agile est de maximiser la valeur ajoutée : le développement s’effectuant paritérations successives, il est possible, à la fin de chaque itération, de changer les priorités en faisant ensorte que les éléments apportant le plus de valeur soient réalisés en premier.Un meilleur accomplissement des personnes impliquées dans un développement est rendu possible par lanotion d’équipe auto-organisée.Une tentative de définition, adaptée de Scott Ambler, pourrait-être :« Une méthode agile est une approche itérative et incrémentale pour le développement de logiciel, réaliséde manière très collaborative par des équipes responsabilisées, appliquant un cérémonial minimal, quiproduisent un logiciel de grande qualité dans un délai contraint, répondant aux besoins changeants desutilisateurs. »Le cérémonial c’est ce qui définit les règles sociales et conventionnelles régissant la vue d’une équipe ; s’ilest vrai que, pour une méthode agile, il est minimal pour la documentation, il existe bien pour le côtésocial, mais avec des règles nouvelles.Avec ses valeurs et ses principes, on peut considérer l‘agilité comme une nouvelle culture dudéveloppement.Celles-ci ont été précisées dés 2001 avec le Manifeste agile, avant même l’apparition des premièresméthodes agiles :  Livrer fréquemment et régulièrement le logiciel  Faire des cycles de développement courts et limités dans le temps  Constituer une équipe complète pour un développement  Gérer les membres de l’équipe en les responsabilisant  Avoir le représentant des utilisateurs sur le même site que le reste de l’équipe  Produire des plans à plusieurs niveaux : détaillés uniquement pour le court terme, et plus généraux pour le moyen terme  Développer en intégrant le code de façon continue  Faire des bilans de projet dans le but d’améliorer la façon de travailler.Prises individuellement, ces pratiques sont déjà efficaces. Insérées dans le cadre cohérent d’uneapproche agile, elles se renforcent mutuellement, et contribuent à la qualité du produit et à son utilité.
  • 2. Les méthodes agiles existaient avant le Manifeste : Scrum et Extreme Programming datent des années1990. Il y a eu de nombreuses autres méthodes qualifiées d’agiles, le Manifeste en énonçant les valeurset les principes communs a contribué à les fédérer toutes derrière la même bannière de l’agilité.Plus récemment, l’engouement pour Scrum a mis fin à une hypothétique rivalité entre les méthodes agiles.Les études d’opinion et les tendances des recherches sur le Web tendent à montrer que Scrum est de loinla plus populaire des méthodes de gestion de projet agiles.Scrum signifie mêlée au rugby. Scrum utilise le valeurs et l’esprit du rugby et les adapte aux projets dedéveloppement. Comme le pack lors d’un ballon porté au rugby, l’équipe chargée du développementtravaille de façon collective, soudée vers un objectif précis. Comme un demi de mêlée, le ScrumMasteraiguillonne les membres de l’équipe, les repositionne dans la bonne direction et donne le tempo pourassurer la réussite du projet.On est naturellement tenté de parler de méthode agile ou de processus agile pour parler de Scrum. Enfait, la définition officielle, celle donnée par la Scrum Alliance et son fondateur Ken Schawaber estlégèrement différente.Le plus souvent, K. Schawaber décrit Scrum comme un cadre (framework) ; à d’autres occasions il enparle comme d’une voie à suivre (path). De manière concrète, Scrum définit des éléments qui ferontpartie du processus appliqué pour développer un produit. Ces éléments sont en petit nombre, le cadreimposé par Scrum étant très léger : guère plus que des itérations, des réunions en début et à la fin dechacune, un « inventaire des tâches » (backlog) et trois rôles. Ce côté minimaliste est sans conteste unedes forces de Scrum, facilitant énormément son implémentation en entreprise.
  • 3. Si la vraie nature de Scrum est difficile à définir, il est beaucoup plus simple d’expliquer la mécanique demise en œuvre :  Scrum sert à développer des produits, généralement en quelques mois. Les fonctionnalités souhaitées sont collectées dans le backlog de produit et classées par priorité. C’est le product Owner qui est responsable de la gestion de ce backlog.  Une version (release) est produite par une série d’itérations appelées des sprints. Le contenu d’un sprint est défini par l’équipe, avec le Product Owner, en tenant compte des priorités et de la capacité de l’équipe. A partir de ce contenu, l’équipe identifie les tâches nécessaires et s’engage pour réaliser fonctionnalités sélectionnées pour le sprint.  Pendant un sprint, des points de contrôle sur le déroulement des tâches sont effectuées lors des mêlées quotidiennes (Scrum Meeting). Cela permet au ScrumMaster, l’animateur chargé de faire appliquer Scrum, de déterminer l’avancement par rapport aux engagements et d’appliquer, avec l’équipe, des ajustements pour assurer le succès du sprint.  A la fin de chaque sprint, l’équipe obtient un produit partiel (un incrément) qui fonctionne. Cet incrément du produit est potentiellement livrable et son évaluation permet d’ajuster le backlog pour le sprint suivant.Les 3 piliers de la théorie sont la transparence, l’inspection et l’adaptation du processus dont Scrum fournitle cadre :Transparence : Elle garantit que tous les indicateurs relatifs à l’état du développement sont visibles partous ceux qui sont intéressés par le résultat du produit.Inspection : Les différentes facettes du développement doivent être inspectées suffisamment souventpour que des variations excessives dans les indicateurs puissent être détectées à temps.Adaptation : Si l’inspection met en évidence que certains indicateurs sont en dehors des limitesacceptables, il est probable que le produit résultat sera également inacceptable si on ne réagit pas. Leprocessus doit donc être ajusté rapidement pour minimiser les futures déviations.Scrum fait partie des approches itératives et incrémentales, dont le modèle de cycle de développement estbasé sur une phase qui se répète plusieurs fois successivement. C’est la notion d’itération, appelée sprintavec Scrum. Tous les sprints se déroulent selon le même schéma et on y fait à chaque fois les mêmetypes de travaux.Dans les approches classiques de la gestion de projet, un cycle dit en ‘V’ est couramment utilisé. Ilpermet, en cas danomalie, de limiter un retour aux étapes précédentes. Les phases de la partie montantedoivent renvoyer de linformation sur les phases en vis-à-vis lorsque des défauts sont détectés, afindaméliorer le logiciel.
  • 4. Scrum va à l’encontre de cette pratique en offrant une approche itérative et incrémentale pour ledéveloppement d’un produit.Incrémental :Est utilisé pour mettre en évidence l’accroissement du produit obtenu à la fin de chaque sprint. Unprocessus incrémental permet de construire un produit morceau par morceau, chaque nouvelle partievenant s’ajouter à l’existant.C’est une pratique rependue dans les développement de logiciel ; on parle souvent de lots pour lesincréments.Itératif :Itérer est l’action de répéter. Le terme itération est utilisée pour désigner une période de temps danslaquelle sont effectuées des activités, qui seront répétées dans les prochaines itérations.Un processus itératif permet de revenir sur ce qui a été fait, dans le but de l’émaliorer ou de le compléter.Cela part de l’idée qu’il est difficile, voire impossible, de bien faire la première fois. Le feedback collectésur le résultat d’une itération permet de faire des améliorations dans la suivante. On cesse d’itérer dans laqualité obtenue est jugée satisfaisante.Itératif et IncrémentalScrum combine les deux approches avec la notion de sprint :  A l’issu du sprint, il y a un incrément de produit qui est réalisé  Le feedback sollicité sur cet incrément permet de le perfectionner dans un prochain sprint.
  • 5. Dans chaque processus de développement, il existe des jalons majeurs et des jalons mineurs. AvecScrum, le jalon mineur et la fin d’un sprint, et le jalon majeur est la production de la release.Une release est une série de sprints qui se termine quand les incréments successifs constituent un produitqui présente suffisamment de valeurs à ses utilisateurs. Release Sprint 1 Sprint 2 Sprint 3Un sprint dure habituellement entre 2 et 4 semaines. Sur le projet AVEA, la durée du sprint a été fixé à 2semaines, et les sprints s’enchainent sans délai : le nouveau démarre immédiatement après le précédent.Le cycle de développement se présente come un enchaînement de phases dans lesquelles on effectuedes activités, qui dans le développement de logiciels suivent le schéma suivant :  Spécifications fonctionnelles  Architecture ( conception )  Codage et tests unitaires  Tests ( d’intégration et de recette )Chaque sprint se compose donc de ses 4 activités, et met en évidence la différence avec un cycleséquentiel traditionnel : Sprint 1 Sprint 2 Sprint 3 Sprint 4 • Spécifications • Spécifications • Spécifications • Spécifications Scrum • Architecture • Architecture • Architecture • Architecture • Codage • Codage • Codage • Codage Test • Test • Test • Test ArchiteSéquentiel Spécif. cture Codage TestAvec une méthode agile comme Scrum, les activités de spécifications et de conception sont continues. Onpart du principe que l’architecture va évoluer, dans une certaine limite, pendant la vie du projet.L’approche est plus réaliste et pragmatique. L’autre principe important est que les tests sont pratiqués désle premier sprint.
  • 6. La hiérarchie classique chef de projet / développeurs est remise en cause dans la méthode Scrum. Celle-ci préconise en effet la suppression de toute forme d’autorité au sein d’une équipe, mais prévoit en lieu etplace des rôles complémentaires et indépendants.Les 3 rôles définis sont celui de ScrumMaster (Animateur ou Facilitateur), de Product Owner (Directeur deproduit) ainsi que l’équipe. Les propositions de traduction françaises de ces rôles étant source de conflitdans la communauté, les termes originaux seront préférés.Lorsqu’on évoque un projet développé par un groupe de personnes, une pensée très rependue est deconsidérer qu’une personne identifier doit être responsable de l’équipe. Traditionnellement, ce rôle estappelé chef de projet. Dans Scrum, ce rôle est tout simplement éliminé.Le travail et les responsabilités d’un chef de projet ne disparaissent pas pour autant. Une grande partie estdévolue au Product Owner, une autre est laissée à l’équipe elle-même. Un des principes de Scrum estl’auto-organisation : il signifie que les membres de l’équipe s’organisent eux-mêmes, et n’ont pas besoind’un chef qui leur assigne le travail à faire.Le ScrumMaster n’est donc pas le nouveau nom donné au chef de projet, il est tel le demi de mêlé d’uneéquipe de rugby, un guide qui sache faire avancer son équipe vers la victoire.Il a pour responsabilité essentielle d’aider l’équipe à appliquer Scrum et à l’adapter au contexte. A ce titre,il doit :  veiller en l’application de Scrum, par exemple en faisant en sorte que les différentes réunions aient lieu et qu’elles se fassent dans le respect des règles.  Encourage l’équipe à apprendre, et à progression  Faire en sorte d’éliminer les obstacles qui pourraient freiner l’avancement, par exemple en protégeant l’équipe des « interférences » extérieures pendant le déroulement d’un sprint  Inciter l’équipe à devenir autonome.Il influence l’équipe et c’est un meneur d’homme qui sait motiver une équipe, pour qu’elle arrive aurésultat. Mais il doit arriver à ses fins par la persuasion, sans imposer ses décisions : un ScrumMaster nedispose d’aucune autorité hiérarchique sur l’équipe.Son travail le plus important est d’éliminer les obstacles, qui peuvent être d’origine technique,environnementaux, personnels, etc. Il joue le rôle de médiateur entre les membres de l’équipe, maissurtout avec le client lorsque cela s’avère nécessaire. Un client mécontent aura toujours affaire auScrumMaster qui s’efforcera de trouver un compromis pour les deux parties, pendant que lesdéveloppeurs resteront dans un environnement optimal pour avancer leur travail.Le Product Owner est responsable de définir l’objectif du produit et de le partager avec l’équipe qui ledéveloppe. Il doit absolument avoir une bonne vision du produit, qui se construit au début dudéveloppement d’un nouveau produit et se consolide ensuite.
  • 7. Il va a se titre rédiger en collaboration avec le client un document permettant de décrire le contenu duproduit. Pour cela, il identifie les fonctionnalités requises et les collecte dans une liste appelée le backlogde produit.Par la suite, il va définir l’ordre dans lequel les parties du produit seront développées. Il doit alimenterl’équipe avec les fonctionnalités à développer, selon ses priorités définies, en fonction de la valeur qu’ellesapportent, ou de l’urgence de leur intégration. En résumé, le Product Owner défini l’objectif d’une releaseet prend les décisions sur son contenu et sa date de mise à disposition.Une bonne connaissance du domaine métier est fondamentale pour le Product Owner, puisqu’il est lereprésentant dans l’équipe de toutes les personnes qui utilisent le produit. Cela s’acquière notamment pardes échanges continues avec le client et ses utilisateurs finaux.Avec une approche agile, la spécification des exigences n’est pas détaillée dès le début dudéveloppement. Il doit donc savoir, en fonction de l’avancement, à quel moment détailler des éléments dubacklog de produit. Cela se fait généralement dans un autre document nommé « tests d’acceptations »qui définit pour chaque user story, cest-à-dire pour chaque tâche élémentaire, comment la vérifier unefois finie.L’équipe est donc composée des « techniciens » qui vont travailler sur le projet, guidés par leScrumMaster et aidé par le Product Owner. Elle a le rôle essentiel, c’est elle qui va réaliser le produit, endéveloppant un incrément à chaque sprint. Elle est investie avec le pouvoir et l’autorité pour le faire defaçon la plus efficace.Pour cela, elle s’organise elle-même et doit avoir toutes les compétences nécessaires au développementdu produit. Chaque membre de l’équipe apportant son expertise, la synergie améliore l’efficacité globale,et chaque développeur se trouve individuellement responsable du produit qu’il crée.Les réunions représentent pour bon nombre de développeurs une perte de temps en raison de leurinefficacité ou de leur fréquence trop importante.En réponse à se sentiment général, la méthodologie Scrum ne définit qu’un nombre limité de cérémoniauxqui ont tous un objectif clairement définis et une méthodologie d’application, permettant ainsi d’optimiser letemps de tous les collaborateurs tout en gagnant en efficacité.Sur l’ensemble du cycle de vie d’un projet, ils sont au nombre de 5.
  • 8. Release Sprint 1 … Sprint N Rétrospective de sprint Revue de sprint Scrum meeting (quotidient) Planification de sprint Planification de releaseDans tous les projets, on fait des plans, pour essayer de prévoir ce que va contenir un produit ou à quelledate il sortira sur le marché. Avec Scrum, la planification de release a les mêmes objectifs : fournir àl’équipe et aux parties intéressées des informations sur le contenu des sprints constituant la release.A cette étape, le Product Owner a en sa possession le backlog de produit contenant les différentes tâchesà réaliser en priorité, ainsi que la capacité de l’équipe ( cest-à-dire le nombre de jours homme disponibledans le sprint ). La planification de release consiste alors à définir quels sont les User Story qui serontincluses dans cette release.Une grande partie de l’effort nécessaire pour produire le plan de release est consacrée à l’estimation.Avec Scrum et les méthodes agiles, celle-ci est collective, elle s’élabore lors de réunions où toute l’équipeparticipe. C’est un point fondamental que l’équipe s’occupe des estimations, car c’est elle qui va par lasuite exécuter les tâches de réalisation , et s’est donc elle qui est la mieux placée pour en connaître lesdifficultés.Ma méthode de planification préconisée par Scrum est à elle seule significatrice de l’esprit de cetteméthode. Il n’est ici pas question d’estimer le temps nécessaire au développement de chaque tâche, maisbien l’effort à fournir pour y arriver.Bien que la technique ne soit pas imposée par Scrum, la plus fréquente est de faire une estimationcollective au cours d’une séance appelée planning poker et d’estimer plutôt la taille que la durée.
  • 9. Le planning PokerIl s’agit d’une séance d’estimation en groupe, avec des cartes, qui combine la jugement d’expert etl’estimation par analogie.Pour commencer la séance, il faut définir un étalon, c’est simplement une user story connue par tous, pourlaquelle l’équipe décide en commun d’une valeur arbitraire.Comme il est plus facile de faire des estimations sur une échelle prédéfinie plutôt que d’avoir à sa disposition tousles entiers, la suite de Fibonacci est généralement utilisée :Pour chaque autre tâche, les membre de l’équipe posent des questions au Product Owner pour bien lacomprendre et débattent brièvement. Tous les participants présentent en même temps la carte choisiepour l’estimation et la valeur moyenne est prise en compte.Une des caractéristiques importante des méthodes agiles est leur capacité à prendre en compte leschangements. Cela implique que les plans sont remis à jour régulièrement. C’est particulièrement vraipour le plan de release, qui est actualisé à chaque sprint, dont les priorité et la liste des tâches peuventvarier.Cette réunion met en évidence le rôle essentiel de l’équipe dans l’élaboration des plans. Le travail dusprint appartient à l’équipe : ce n’est pas un chef qui définit ce qu’il y a à faire, c’est l’équipe qui s’organiseelle-même. Au-delà de sa fonction première de planification, la réunion est un rituel qui prépare l’équipe àtravailler de façon collective pendant le sprint, comme les préparatifs dans les vestiaires qui amènent uneéquipe de rugby à rentrer dans son match.A ce niveau, l’équipe a déjà définie les user story qui seront à effectuer dans le sprint. Après que leProduct Owner ai présenté à l’équipe de façon détaillée une storie, l’équipe va l’étudier pour parvenir àidentifier les tâches atomiques nécessaires à sa réalisation. Le but étant de parvenir à séparer les tâchesde manière optimale, en pensant parallélisassions notamment. Celles-ci sont alors estimés en terme detemps de développement.
  • 10. Des tâches annexes sont souvent rajoutés tel que : écriture des plans de tests (PT), écriture de testsunitaires, prendre contact avec X pour demander plus d’informations, etc.Chaque jour, et à heure fixe, l’équipe complète se réunit durant un quart d’heure pour effectuer la réuniond’avancement.Chaque participant doit alors répondre à 3 questions :  Qu’as-tu fait depuis la dernière réunion ?  Que prévois-tu de faire jusqu’à la prochaine réunion ?  Quels sont les obstacles qui te freinent dans ton travail.C’est l’occasion pour les développeurs de prévoir la meilleur façon de paralléliser leur travaux ou dedemander de l’aide si une tâche s’avère plus délicate que prévue ( le travail en binôme est conseillé dansles méthodes agiles ).Pour les équipes qui utilisent un tableau des tâches mural, comme c’est le cas chez IOcean, c’est aussil’occasion de déplacer physiquement la carte correspondante dans la ligne : en cours ( je prend encharge cette tâche ), à tester ( un autre collaborateur doit tester cette user story ) ou fini.
  • 11. La revue de sprint est une démonstration de l’incrément en présence de toutes les parties prenante (hiérarchie pour un produit interne, client … ). Elle a pour objectif de montrer le résultat du travail del’équipe durant le sprint.Dans un premier temps le Product Owner va rappeler le but du sprint défini dans la réunion deplanification, puis l’équipe présente le produit partiel, résultat de ses travaux, en faisant une démonstrationdes stories réalisées.Les participants à la réunion sont invités à poser des questions à l’équipe et à donner leur impression surle produit montré. Leur feedback se concrétise en propositions et demandes de changement, qui serontprisent en compte dans le backlog de produit.La difficulté de cette réunion est d’éviter qu’elle ne tourne en « chasse au bug » avec un client difficile, lerôle de modérateur du ScrumMaster est alors indispensable pour rappeler la chaîne de remontée desbugs, et ne pas retarder la revue de sprint.En reprenant l’analogie d’un match de rugby, on peut comparer la rétrospective de sprint à la discussion« d’après match ». A partir des expériences tirées du développement du sprint courant, l’équipe identifiece qui marche bien pour elle, ce qui marche moins bien, et trouve collectivement ce qu’il faut modifier auprocessus qu’elle utilise.C’est une pratique d’amélioration continue amenant à l’adaptation des processus, à la capitalisation desconnaissances et à l’change de points de vues. Elle prend généralement la forme d’un brainstorming entretous les acteurs de l’équipe.Une fois tous les points évoqués, l’équipe décide de trois choses à faire pour améliorer l’itération suivante(par exemple : travailler en binôme une heure par jour, réaliser les tests d’acceptations plus tôt dans lecycle, impliquer d’avantage le client).