Confrence Scrum @ EPITECH

1Scrum @

1

2Les produits ne sont pas des personnes.

Vous pouvez les aimer.

Mais ils ne peuvent vous aimer en retour.23

LEANKAIZENPierre NeisPMO / Scrum & Lean Coach34

qui tes-vous? sur une ligne: dfinir le degr de connaissance de Scrum

4

quelles sont vos attentes?5

marquer sur post-itprioriservaloriser

5Objectif de latelier6Vous faire dcouvrir Scrum

Expliquer les principes de base

les tester

6Scrum7

7Introduction par Ken SchwaberScrum n'est pas une mthodologie.Scrum ne fournit pas les rponses la manire de construire des logiciels de qualit plus rapidement.

Scrum est un cadre dans lequel le jeu du dveloppement des produits est jou.

Votre quipe joue et, le bon ou le mauvais deviennent trs visibles.

Votre quipe est dans un processus damlioration continue.

88

Scrum est une approche novatrice pour achever votre travailScrum est un cadre souple pour la ralisation de projets complexes.

A lorigine Scrum a t formalis pour le dveloppement de logiciels. Mais il fonctionne trs bien galement pour les projets complexes et novateurs.

Le cadre de Scrum est trompeusement simple9Projets ?

Complexes ?Process EmpiriqueItratif & Incrmental3 PiliersLa TransparenceL'InspectionL'adaptation

9qu'est-ce qu'un projet?10QualitCadreRessourcesTempsmagic triangleun projet en cascadeun projet itratif

10Complexe?1111ComplexeSimpleCompliquChaotiqueSondeComprendreRpondreComprendreAnalyserRpondreAgirComprendreRpondreComprendreCatgoriserRpondreEmergentBonnes pratiquesOriginalMeilleures pratiques1212Les objectifs de Scrum1313Maximiser la Valeur14

14Livrer, livrer, livrer15

15Rduire le risque16

16

1717Les Rles dans Scrum18

18Les cochons et les poules19Les poules sont engages.Les cochons sont impliques.19 LEquipe20

The Team Teams of developers turn Product Backlog into increments of potentially shippable functionality every Sprint. Teams are also cross-functional; Team members must have all of the skills necessary to create an increment of work. Team members often have specialized skills, such as programming, quality control, business analysis, architecture, user interface design, or data base design. However, the skills that Team member share that is, the skill of addressing a requirement and turning it into a usable product tend to be more important than the ones that they do not. People who refuse to code because they are architects or designers are not good fits for Teams. Everyone chips in, even if that requires learning new skills or remembering old ones. There are no titles on Teams, and there are no exceptions to this rule. Teams do not contain sub-Teams dedicated to particular domains like testing or business analysis, either. Teams are also self-organizing. No one not even the ScrumMaster - tells the Team how to turn Product Backlog into increments of shippable functionality. The Team figures this out on its own. Each Team member applies his or her expertise to all of the problems. The synergy that results improves the entire Teams overall efficiency and effectiveness. The optimal size for a Team is seven people, plus or minus two. When there are fewer than five Team members, there is less interaction and as a result less productivity gain. Whats more, the Team may encounter skill constraints during parts of the Sprint and be unable to deliver a releasable piece of the product. If there are more than nine members, there is simply too much coordination required. Large Teams generate too much complexity for an empirical process to manage. However, we have encountered some successful Teams that have exceeded the upper and lower bounds of this size range. The Product Owner and ScrumMaster roles are not included in this count unless they are also pigs, working on tasks in the Sprint Backlog. 202121Equipes auto-gres vs. Organisation traditionnelle22Equipes autogres Organisation traditionnelle Orientes client Pilote par le management Force de travail multi-comptente Foce de travail constitue de spcialistes isols Peu de description de poste Beaucoup de description de poste Information largement partage Information limite Peu de niveau de management De nombreux niveaux de management Oriente Mtier Oriente fonction/dpartement Objectifs partags Objectifs spars Dapparence chaotique Dapparence organise Emphatique sur lhypothse datteinte du rsultat Emphatique sur la rsolution de problme Trs fort engagement des producteurs Trs fort engagement du Management Amliorations continues Amliorations incrmentales Auto-rgules Contrles par le Management Bases sur des valeurs et des principes Bases sur les politiques et les procdures Source: "Leading self-directed work teams" by Kimball Fisher22Le ScrumMaster23

assure

aide

coache

protge

limine

responsabletravaille avec

Sassure que lquipe suit les valeurs, les principes et les pratiques de Scrum

Il aide lquipe et lorganisation dans ladoption de Scrum

Il coache et soutien lquipe pour amliorer la productivit et dlivrer de la qualit

Il protge lquipe

Il limine les obstacles

Il est le responsable du bon fonctionnement du projet

Il nexiste quun ScrumMaster par quipe

Le ScrumMaster travaille avec lquipe (idalement dans la mme pice)

23Le Product Owner24

responsable du Product Backlog

assure la valeur cree

Accepte

rejte

entretient

travaille avecIl est le seul et unique responsable de la gestion du Product Backlog

Il sassure de la valeur cree par lquipe: il accepte ou rejte les items en fonction de la Definition of Done.

Il entretient le Product Backlog et sassure quil est visible par tous

Il nexiste quun Product Owner par quipe

Le Product Owner travaille avec lquipe (idalement dans la mme pice)

2425

Le cycle des crmonies25Les crmonies sont time-boxes26Sprint PlanningRevue de SprintRtrospectiveSprint PlanningSPRINTDaily Meetings26Principe de Pull27

Push vs Pull

Pull:Le cahier des charges est prdfini par la MOA.La MOA dfinit la feuille de route.Elle pousse (push) le cahier des charges vers lquipe projet.Objectif: excution du cahier des charges conformment un cadre fixe et fig.Pull:Le cahier des charges est estim par la MOA.La MOA dfinit la feuille de route prvisionnelle.Elle prsente le cahier des charges vers lquipe projet.Lquipe projet tire (pull) les lments du cahier des charges quelle peut dvelopper.Objectif: co-production en fonction de la capacit rlle de production. Co-production orinete rsultat.

27 Sprint Planning Meeting28Organisateur: Product Owner

Participants: lquipe (actif), le ScrumMaster (passif)

Dure: 8 heures pour un Sprint de 4 semaines

2 parties:Le QUOI?Le COMMENT?

Dune manire gnrale, le Sprint Planning Meeting (SPM) est dcoup en deux parties:

Le SPM 1:Dure: 4 heuresOrganisateur: le Product OwnerObjectif: dfinition du QUOIFocus: valuation du Product Backlog, Dcoupage des Sprints, Evaluation du Product Backlog. Attention: rsonnenement uniquement bas sur les fonctionnalits et sur lingnirie.

Le SPM 2:Dure: 4 heuresOrganisateur: lEquipeObjectif: dfinition du COMMENTFocus: Design, valuation du Sprint Backlog, Dcoupage des tches, Evaluation du Sprint Backlog, objectif de Sprint28 Sprint Planning Meeting29Organisateur: Product Owner

Participants: lquipe (actif), le ScrumMaster (passif)

Dure: 8 heures pour un Sprint de 4 semaines

Le Product Owner:Prsente le Product Backlog prioris par le client et/ou les utilisateursPrsente le Release Plan InitialPrsentation de la Vision

Lquipe:Estime le Product Backlog en fonction de sa faisabilit (estimation fonctionelle)Dcoupe le Product Backlog en Sprint Backlogs avec le Product OwnerDcoupe le Sprint Backlog en tchesEstime le Sprint Backlog

Le Product Owner et lEquipe:

Dfinissent lobjectif du Sprint

Valident la Definition of Done

Dune manire gnrale, le Sprint Planning Meeting (SPM) est dcoup en deux parties:

Le SPM 1:Dure: 4 heuresOrganisateur: le Product OwnerObjectif: dfinition du QUOIFocus: valuation du Product Backlog, Dcoupage des Sprints, Evaluation du Product Backlog. Attention: rsonnenement uniquement bas sur les fonctionnalits et sur lingnirie.

Le SPM 2:Dure: 4 heuresOrganisateur: lEquipeObjectif: dfinition du COMMENTFocus: Design, valuation du Sprint Backlog, Dcoupage des tches, Evaluation du Sprint Backlog, objectif de Sprint29Sprint30Organisateur: lquipe

Participants: lquipe, le ScrumMaster, le Product Owner

Dure: 2-4 semaines

Dveloppement des applications du Sprint Backlog sur lesquelles lquipe sest engage

Maintenance du Level of Done:DevelopementTests unitairesAcceptanceTests dintgrationTests SystmePerformance

co-gestion des empchements avec le ScrumMaster

Co-entretien du Sprint Backlog avec le Product Owner

30 Daily Scrum31Organisateur: lquipe

Participants: lquipe (actif), le ScrumMaster (passif), Product Owner (passif)

Dure: 15 min

Cest linspect-and-adapt de lquipe: synchronisation et engagement

Les 3 questions:Quest-ce que tu as fait hier?Quels sont les problmes que tu as rencontrs?Quest-ce que tu as prvu aujourdhui?

31La Revue de Sprint32Organisateur: Product Owner

Participants: lquipe (actif), le ScrumMaster (passif), le Management (actif), le client (actif), les utilisateurs (actifs)

Dure: 4 heures pour un Sprint de 4 semaines

Cest linspect-and-adapt des utilisateurs, du client et du management

Lquipe prsente les rsultats du Sprint

Utilisateurs/Client/ Management expriment leurs remarques et trouvent un compromis avec lquipe

Le Product Owner valide ou rejte les items du Sprint Backlog en fonction de la Definition of Done

Cest le Product Owner qui a toujours le dernier mot...

32La Rtrospective33Organisateur: ScrumMaster

Participants: lquipe (actif), le ScrumMaster (actif), le Product Owner (actif en sa qualit de membre de lquipe)

Dure: 3 heures pour un Sprint de 4 semaines

Analyse du Process Scrum:Comment cela cest pass pendant le SprintComment samliorer

Points principaux de vrification:La communication dans lquipeLes relations entre les membres de lquipeLes process et les outilsLes besoins en formation

33Les Artifacts3434Le Product Backlog35

Le Product Backlog rpond aux questions suivantes:Quoi? Quand? Pour Qui?35Le Release Burndown36

Le Release Burndown = la somme du carnet de commandes du produit restant estim l'effort travers le temps.L'effort est estim n'importe quelle unit de travail de l'quipe Scrum et l'organisation ont dcid.Les units de temps sont gnralement Sprints.36Sprint Backlog37

37

Sprint Burndown38The Sprint Burn-down chart shows how much effort has been expended by working on the task contained in the Sprint Backlog and compares this to an ideal expenditure

The chart provides a trend that shows if the Team is likely to meet its commitment (leading indicator)

38Definition of Done39

39Level of Done40Le Code est conforme aux normes

Le Code est PropreRefactorTest unitairementValid (checked in)Intgr (Built)Dispose d'une suite de test unitaire qui lui est applique.

Pour arriver cela, lenvironnement de dveloppement est constitu :Dune bibliothque de code source De codes standards, Build automatis, Dun environnement pour les tests unitaires.Pour lEQUIPE40Definition of Done41Une Story/Item est done lorsque lquipe atteind son Level of Done

Le Sprint/Iteration est done lorsque tous les items sont done et que le Sprint atteint son objectif et que les critres dacceptation sont adresss.

La Release est donedone pour lintgrationdone pour la productionPour SCRUM41

Done?42Half done is not done4243Exercice: Alien Game43Exercice44Crer une couverture dart, une marque et/ou un logo Dfinir des thmes majeurs pour le tourisme martien Dfinir un circuit Intrts artistiques en Europe Dfinir un circuit bas sur la photosynthse Esquisser une expdition sur les 7 merveilles du monde Fixer les prix pour ces expditions Rsumer des alertes (gravit, oxygne, champignons, etc.) Proposer des options dhabillement Expliquer les options de voyage de et depuis Mars. Dcrire un circuit sur les sports humains Donner un aperu sur la politique de remboursement Suggrer des services annexes Dfinir les annonceurs laborer une campagne de 12 mois Planifier le process pour lobtention dinformations supplmentairesDlivrer une brochure pour lOffice terrien du Tourisme sur MARS4544Au fait sa marche comment?45

45Dabord une Ide46

46Ensuite une Vision47

47La Vision48

48Ensuite un Product Backlog49

49 Le Product Backlog50SprintReleaseFuture ReleasesPriorit moyennePriorit haute50Product Backlog - Exemples51

Product Backlog Building: answer these questions:What? When? For Who?

Product Backlog ManagementClean the Backlog bottom from unused features (they can be added later if necessary)

Ever keep in mind: is that really necessary?

For Backlog Meeting: transcribe it on cards and stick up

51Constitution de lEquipe52The TeamDveloppeurAnalysteArchitecteTesteurDBAScrum MasterTout le monde. Pas une autorit.Pas ncessairement un dveloppeur.Product OwnerChef de ProduitAnalyste MtierChef de Projet fonctionnelMOA52Le Cycle de Scrum53

5354Revue du Backlog5455Rtrospective55Scrum Resources56

56

Companies using SCRUM57

5758Questions?

5859Merci

59

60Pierre E. NEIS - Tel +352 / 661 727 867

elpedromajor

60