Introduction à l'agilité

1 045 vues

Publié le

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

Publié dans : Technologie
0 commentaire
1 j’aime
  • Soyez le premier à commenter

Aucun téléchargement
Nombre de vues
1 045
Sur SlideShare
Issues des intégrations
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • 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
  • ×