Téléchargé 47 fois
Téléchargé parRomain Couturier
Introduction à l'agilité
Le document présente une introduction aux méthodes agiles, en mettant l'accent sur des pratiques comme Scrum et l'Extreme Programming (XP). Il discute des rôles clés, de la gestion des itérations et des user stories, tout en abordant les facteurs de succès et les défis de l'implémentation de l'agilité. Enfin, il souligne l'importance d'une approche collaborative et itérative pour répondre aux besoins évolutifs des clients.
Contenu connexe
Similaire à Introduction à l'agilité
Introduction à l'agilité
- 1. Introduction aux méthodesagilesRomain Couturier – ExakisEmail : couturier.romain@gmail.comTwitter : @calton13LinkedIn : http://fr.linkedin.com/in/romaincouturier
- 2. Préambule : leCARAAssociation loi 1901 à but non lucratifObjectifEvènementsConférences / Ateliers mensuelsAgile Grenoble : 23 novembre 2010 (http://www.agile-grenoble.org)RencontresCoding dojoPetits-déjeuners
- 3. Préambule : leCARA LyonNewsletter : lyon.cara@gmail.comConférence 1er mardi du mois 19hComment vendre l'agilité à mes clients à mon patron ?Tests Agiles : apports et bonnes pratiqueshttp://lyon.clubagile.org/
- 4. Origines : valeurs& principesLes modèles existants : Scrum / XPLes rôles et les outilsFacteurs de succèsSynthèseRessourcesAgenda
- 5. Principes de fonctionnementagileLesclés du succès d’un projet agileLes facteurs d’échecQui, Quoi, Quand, Comment ?De l’agilité partout ?Objectifs
- 7. Manifeste agile :4 valeurs
- 8. Manifeste agile :12 principes
- 9. Manifeste agile :12 principes
- 10. ProblématiqueRetardTout est prioritaireTropde bugsVictime du changementManque de compréhension des attentes métier
- 11. Une meilleure voieApprochecollaborativeEliminer les risquesVisibilité sur la progressionTransparenceItératifIncrémentalEmbrasser le changementFeedbacks
- 12.
- 13.
- 14.
- 15. Rôle : ScrumMasterAu service de l'équipeFacilitateurProtecteurElimine les obstacles
- 16. Rôle : ProductOwnerReprésentant des clients et utilisateursOriente le produitDéfinit les prioritésPas de lien hiérarchiqueDisponibleLead le changement
- 17. Rôle : L’équipeToutle mondeParticipe aux décisionsAuto-géréeCross-fonctionnelleCommunication
- 18. ItérationCourte, bornée dansle temps et le contenuCiblée sur des objectifs prioritairesSemaine 1Semaine 2LMMJVLMMJVKickoff clarification des objectifs de l’itération avec l’équipe.1hDémarrage code & testConception modélisation agileUML5hDemoRétrospective4 hDe-scope de l’iteration si trop de travail restantWorkshop fonctionnel1jCheck-in final and « code-freeze »
- 19. Planning d’itérationPré-requis :user stories & critères d’acceptationDiscussionConception, découpage en tâchesTâches courtes (8-16h)
- 20. Daily meeting15 minutesmax3 questionsLa plus importante des pratiques
- 21. Revue de sprint,démonstrationPrésentation des user stories terminées …… selon la définition de « terminé »Scénario de démonstrationCe n’est pas une séance de testsTous les utilisateurs sont les bienvenus
- 22. RétrospectiveLe bon ?Lemauvais ?Axes de progression ?http://agile-alchemist.com/
- 23. Product backlog –Site voyagisteExemple de product backlogEn tant qu’utilisateur, je veux réserver une chambre d'hôtelEn tant qu’utilisateur, je veux annuler une réservationEn tant qu’opérateur de réservation, je veux voir les photos des hôtelsEn tant que voyageur régulier, je veux re-réserver un précédent vol, pour gagner du temps lors de la réservation de mes voyagesLes User Stories lancent la conversation
- 24. Sprint BacklogEn tantqu’utilisateur, je veux réserver une chambre d'hôtelAjouter une table « hotel » à la base de données – 1 hEcrire le code Ajax pour afficher la réservation – 4 hEcrire le code pour entrer 1 réservation dans la base de données – 4 hEn tant qu’utilisateur, je veux annuler une réservationAfficher la réservation de l'utilisateur courant – 4 hAjouter un bouton annuler à côté de chaque réservation – 1 h….
- 25.
- 26. Mesures : BurndownChartde Sprint
- 27.
- 28. KanbanLean Software DevelopmentFeatureDriven DevelopmentAgile Unified ProcessCrystalClearDynamic Systems Development MethodAutres méthodes agiles
- 29. Pratiques d’ingénierie logicielleTDD= Test Design First + RefactoringIntégration continuePair programmingValeursCommunicationSimplicitéCourageFeebackHumilitéXP (eXtremeProgramming)
- 30. Modèle scalableEquipe 1Equipe2Equipe 3
- 31. Facteur de succès: Communication
- 32. Facteur de succès: TestsDurant tout le cycle de vieProjet sécurisé, haute qualité, taux faible de bugsIndicateurs à jourFonctionnelTechniqueValidation à la volée des livraisonsIntégration continueAutomatisation des testsFacilite la réactivitéIdentification au plus tôt des incidentsDésigner l’équipe ou la personne responsable de l’intégration
- 33. Bénéfices de l’agilitéMaîtriseTransparenceDécloisonnementdes équipes = communicationSocial engineering QualitéCoûtsDélais de livraisonFavorise les « earlyadopters »… (liste non exhaustive)
- 34. L'équipeestresponsable du travailfourni et des résultatsL'agilité ne résout pas les problèmes, elle les exposeL'agilitédoits'adapter à l'environnementprojet"Uneméthode agile estuneapprocheitérative et incrémentale, qui estmenéedans un esprit collaboratif avec justecequ’ilfaut de formalisme. Elle génère un produit de haute qualité tout en prenant en comptel’évolution des besoins des clients" (QualityStreet.fr)Synthèse
- 35.
- 36. Quelles sont lesbonnes pratiques de votre équipe ?Comment utiliseriez vous les techniques agiles pour développer vos forces ?Questions / Réponses36Discussions
- 37. ThèmesCréation du productbacklogEstimationsagilePlanification agile & prioritésLe rôle du Product OwnerLes pratiques XPAUP : phase, livrables, rôles, activités, use cases…37Idées de session
- 38. 38De l’agilité partout?Transition agile != Big BangChangement d’état d’espritChangement des pratiques de gestion de projet
- 39. Evaluer l’agilitéL’agilité ouimais pas partoutProjet piloteRequiert AdaptationConfianceEngagementDéfinition de terminéChallengesEducation AMOARigueur
Notes de l'éditeur
- #3 Objectifs : échanger / partager / apprendre / s’enrichirle CARA est une association à but on lucratif et que pour avoir un minimum de fonds de roulement, il est proposé d'adhérer au club pour une somme minimaliste de 20 euros.Cette cotisation sera proposée à partir du mois de Janvier.
- #4 Objectifs : échanger / partager /
- #7 1986 : The New New Product Development Game (Takeuchi et Nonaka )1991 : RAD (James Martin)1995 : Grands principes de Scrum (Ken Schwaber et Jeff Sutherland)1996 : Premier article sur Scrum (Ken Schwaber et Jeff Sutherland)1998 : Cône d'incertitude (Steve McConnell)2001 : Manifeste agile (17 représentants)
- #12 So what is a better way?Iterative development – developing in short fixed cycles of one to four weeks, with input from customers and built-in feedback loop.Communications – an ongoing dialog between the customer (or product management) and the team; a constant conversation within the team helping to solve problems and remove barriers.Self Organizing – the team works together to decide how best to solve problems and avoid bottle necks.Scrum – a set of practices to formalize all of this.Scrum is an agile process that allows self organizing teams to focus on delivering the highest business value in the shortest time.
- #14 Like any process Scrum is built out of a series of parts. The people who do the work, the events they use to organise themselves and the artifacts they generate to track the work being done.
- #16 The scrum master is the grease that allows everything on the team to run smoothly. The scrum master exists to remove roadblocks from they way of team. The team doesn’t report to them – the team reports to itself. Instead the job of the scrum master is to act as the facilitator and track the progress of the team.
- #17 The product owner is the person understands the customer needs. They:Choose what order to have the features created in. Maintain and prioritise the product backlog.They’re ultimately responsible for the entire product – hence the Single Wringable neck
- #18 Everyone required to produce the product – not just developers but QA, technical writing – anyone else required to complete the product.Self organising – scrum teams are not told what to do. Instead day by day, task by task they volunteer to work on tasks. Each team member only takes one task at a timeThis helps break down silos and reduce bottlenecks. Story: I’ve been in situations where we only had one person who knew the intricacies of the engine. However this person already had as much work as they could handle. So instead another person stepped in and figured out how work in the specific part of the engine. When the work was done the first person reviewed the work and recommended a number changes. Result – the task got done and the second person learned a bit about the engine. Over time everyone did a bit of work in the engine, so eventually we could all pinch hit there. All Agile methods promote generalising specialists, it helps remove bottlenecks and means that you always have someone else to discuss problems with.
- #19 SprintA sprint is short fixed length development cycle (between 1-4 weeks) whose purpose is to deliver small chunk of useful functionality to the customer. At the end of every sprint the customer demonstrates and tests the product we’ve produced. Once the sprint is planned the team is committed to the tasks and the goal cannot be changed with aborting the sprint. In the face of constantly changing requirements this provides a small island of sanity.At the end of the sprint we’re prepared to demonstrate a small chunk of functionality to the Product Owner
- #20 The team and Scrum Master meets with the product owner to determine what stories it believes it can commit to in the sprint. This usually involves a lot of questions to the product owner to clarify their intention. The team breaks the committed stories down into a batch of small tasks and provides estimates for them. At the longest tasks are 8-16 hours of work, typically tasks are of couple of hours long – anything longer is a sign that tasks have not be broken down into small enough chunks – large pitfalls may remain.Tell a story of the team: Through conversation gaining a deeper understanding of story and coming up with a better set of ideas than they would’ve on their own.
- #21 Perhaps the most important Scrum practice. The daily scrum is chance for the team to synchronize and share progress with each other (note the team is not reporting to the Scrum Master). Held near the beginning of the day.Answer the three questions What did you do yesterdayWhat will you do todayDo you have any roadblocksAnyone may attend, only team members (people with skin in the game) may speakScrum master uses the information from the standup to update burndown chart illustrating progressFifteen minutes maximumTypically held standing up (to encourage brevity and focus)Gets the team focused for the day ahead. It is the heartbeat of the team.The team shares information and isn’t reporting to a manager.Roadblocks are addressed immediatelyPossibly the most important practice because it gives you a chance to discover what your team mates are doing and provide help (offline) to solve problems they encounter. Also it encourages the team to communicate breaking down silos.On my last team over the course of a few months the daily scrum helped break down barriers and caused to talk more openly. We also tended to hold impromptu design discussions immediately afterwards – which went a long way to improving the architecture of the application.
- #22 Product Owner plays the sprint’s work (without guidance) and provides feedbackDevelopers may also demo workAs part of building trust with the customer we acknowledge the problems that still exist instead of waiting until the PO/customer finds them.We only declare work that fits our definition of complete to be done. My definition of complete at a minimum: coded, reviewed and tested (by QA or on a team without QA someone other than self).Tell a story about the team admitting that very little got done – but the product owner was still happy because he knew exactly what the state of the world was.
- #23 Team reviews what went well and what went poorlyUse retrospection techniques to find potential for improvement.Pick one or two areas to focus for improvementBasic technique – go round the team 3 teams answering the following questionsWhat went well?What went poorly?What will work on next time?With teams that don’t know each other well its often a good idea to use anonymous feedback and other methods – these help build trust and ensure that dominant team members don’t drown out the quieter voices.Tell the story about exceptions during the demo – first then – everyone laughs it off. Then a second and third. By the time the demo was done the whole team was hanging its head in shame. During the retrospective every team member raised quality as an important focus. During the next few iterations the team had a greater focus on quality. But most important the team took the issue far more seriously than if I or someone else had raised the concern during the middle of the iteration.
- #24 A prioritized list of everything needed or wanted for the entire productWritten in the form of user storiesHave estimates associated with them (usually just a relative measure such as Story Points)Stories are a small piece of useful functionality that can be defined in one sentence. Stories must represent functionality that is useful to the end user. They often use the format:As a <user role> I can <story> so that <benefit>or<Persona name> can <story> so that <benefit>Stories are an invitation to start a conversation – not a fully defined requirement.
- #25 During the planning meeting the team agrees to the stories that they believe they can complete within the sprint. The sprint backlog is the list of tasks (with estimates) required to complete the stories. The tasks were created during the planning meeting. The sprint backlog is a closed list – once its complete no more tasks can be added to it (unless the team identifies missing tasks). A closed list provides the team with the psychology benefit of seeing a shrinking pile vs. the normal ever growing stack of features and bugs. It provides an achievable short term goal allowing the long term to be left in the background.
- #27 All the task hours for the sprint are added up and that is used as starting point on the left. As the team progresses through the sprint they track the work remaining (not the hours worked). The blips up indicate either the team discovered new tasks or the re-estimated the amount of work involved. The chart is important because it gives everyone from team members to stakeholders a palpable sense of how the sprint is progressing. A similar chart is also made for the release.
- #29 Transparence, inspection, adaptationForming, storming, norming & performing
- #32 Le plus importantAu cœur de l’agilitéA tous les niveaux de l’organisation