Introduction à l'agilité
•Télécharger en tant que PPTX, PDF•
2 j'aime•1,652 vues
La première conférence de l'année du CARA (Club Agile Rhône Alpes) vous présente un tour à 360° sur les concepts fondamentaux de l'agilité et un exemple de méthode agile avec SCRUM
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (17)
Similaire à Introduction à l'agilité
Similaire à Introduction à l'agilité (20)
Plus de Romain Couturier
Plus de Romain Couturier (20)
Introduction à l'agilité
- 1. Introduction aux méthodes agiles Romain Couturier – Exakis Email : couturier.romain@gmail.com Twitter : @calton13 LinkedIn : http://fr.linkedin.com/in/romaincouturier
- 2. Préambule : le CARA Association loi 1901 à but non lucratif Objectif Evènements Conférences / Ateliers mensuels Agile Grenoble : 23 novembre 2010 (http://www.agile-grenoble.org) Rencontres Coding dojo Petits-déjeuners
- 3. Préambule : le CARA Lyon Newsletter : lyon.cara@gmail.com Conférence 1er mardi du mois 19h Comment vendre l'agilité à mes clients à mon patron ? Tests Agiles : apports et bonnes pratiques http://lyon.clubagile.org/
- 4. Origines : valeurs & principes Les modèles existants : Scrum / XP Les rôles et les outils Facteurs de succès Synthèse Ressources Agenda
- 5. Principes de fonctionnementagile Les clés du succès d’un projet agile Les facteurs d’échec Qui, 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ématique Retard Tout est prioritaire Trop de bugs Victime du changement Manque de compréhension des attentes métier
- 11. Une meilleure voie Approche collaborative Eliminer les risques Visibilité sur la progression Transparence Itératif Incrémental Embrasser le changement Feedbacks
- 13. Scrum
- 14. Scrum (2/2)
- 15. Rôle : Scrum Master Au service de l'équipe Facilitateur Protecteur Elimine les obstacles
- 16. Rôle : Product Owner Représentant des clients et utilisateurs Oriente le produit Définit les priorités Pas de lien hiérarchique Disponible Lead le changement
- 17. Rôle : L’équipe Tout le monde Participe aux décisions Auto-gérée Cross-fonctionnelle Communication
- 18. Itération Courte, bornée dans le temps et le contenu Ciblée sur des objectifs prioritaires Semaine 1 Semaine 2 L M M J V L M M J V Kickoff clarification des objectifs de l’itération avec l’équipe. 1h Démarrage code & test Conception modélisation agile UML 5h Demo Rétrospective 4 h De-scope de l’iteration si trop de travail restant Workshop fonctionnel1j Check-in final and « code-freeze »
- 19. Planning d’itération Pré-requis : user stories & critères d’acceptation Discussion Conception, découpage en tâches Tâches courtes (8-16h)
- 20. Daily meeting 15 minutes max 3 questions La plus importante des pratiques
- 21. Revue de sprint, démonstration Présentation des user stories terminées … … selon la définition de « terminé » Scénario de démonstration Ce n’est pas une séance de tests Tous les utilisateurs sont les bienvenus
- 22. Rétrospective Le bon ? Le mauvais ? Axes de progression ? http://agile-alchemist.com/
- 23. Product backlog – Site voyagiste Exemple de product backlog En tant qu’utilisateur, je veux réserver une chambre d'hôtel En tant qu’utilisateur, je veux annuler une réservation En tant qu’opérateur de réservation, je veux voir les photos des hôtels En 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 voyages Les User Stories lancent la conversation
- 24. Sprint Backlog En tant qu’utilisateur, je veux réserver une chambre d'hôtel Ajouter une table « hotel » à la base de données – 1 h Ecrire le code Ajax pour afficher la réservation – 4 h Ecrire le code pour entrer 1 réservation dans la base de données – 4 h En tant qu’utilisateur, je veux annuler une réservation Afficher la réservation de l'utilisateur courant – 4 h Ajouter un bouton annuler à côté de chaque réservation – 1 h ….
- 25. Scrum Board
- 26. Mesures : BurndownChart de Sprint
- 28. Kanban Lean Software Development Feature Driven Development Agile Unified Process CrystalClear Dynamic Systems Development Method Autres méthodes agiles
- 29. Pratiques d’ingénierie logicielle TDD = Test Design First + Refactoring Intégration continue Pair programming Valeurs Communication Simplicité Courage Feeback Humilité XP (eXtremeProgramming)
- 30. Modèle scalable Equipe 1 Equipe 2 Equipe 3
- 31. Facteur de succès : Communication
- 32. Facteur de succès : Tests Durant tout le cycle de vie Projet sécurisé, haute qualité, taux faible de bugs Indicateurs à jour Fonctionnel Technique Validation à la volée des livraisons Intégration continue Automatisation des tests Facilite la réactivité Identification au plus tôt des incidents Désigner l’équipe ou la personne responsable de l’intégration
- 33. Bénéfices de l’agilité Maîtrise Transparence Décloisonnement des équipes = communication Social engineering Qualité Coûts Délais de livraison Favorise les « earlyadopters » … (liste non exhaustive)
- 34. L'équipeestresponsable du travail fourni et des résultats L'agilité ne résout pas les problèmes, elle les expose L'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. http://www.agilemanifesto.org/ http://blog.mountaingoatsoftware.com/ http://www.qualitystreet.fr/ http://www.aubryconseil.com/pages/Scrum http://www.scrumforteamsystem.com http://groups.yahoo.com/group/scrumdevelopment/ http://etreagile.thierrycros.net
- 36. Quelles sont les bonnes pratiques de votre équipe ? Comment utiliseriez vous les techniques agiles pour développer vos forces ? Questions / Réponses 36 Discussions
- 37. Thèmes Création du productbacklog Estimations agile Planification agile & priorités Le rôle du Product Owner Les pratiques XP AUP : phase, livrables, rôles, activités, use cases … 37 Idées de session
- 38. 38 De l’agilité partout ? Transition agile != Big Bang Changement d’état d’esprit Changement des pratiques de gestion de projet
- 39. Evaluer l’agilité L’agilité oui mais pas partout Projet pilote Requiert Adaptation Confiance Engagement Définition de terminé Challenges Education AMOA Rigueur
Notes de l'éditeur
- 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.
- Objectifs : échanger / partager /
- 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)
- 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.
- 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.
- 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.
- 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
- 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.
- 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
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Transparence, inspection, adaptationForming, storming, norming & performing
- Le plus importantAu cœur de l’agilitéA tous les niveaux de l’organisation