Scrum Workshop

@ Scrum Workshop

1

workshop @ Fujitsu22workshop @ Fujitsu3

LEANKAIZENPierre NeisPMO / Scrum & Lean Coach3objectifworkshop @ Fujitsu4Vous faire dcouvrir Scrum

Expliquer les principes de base

les tester

4

workshop @ Fujitsu55

workshop @ Fujitsu66workshop @ Fujitsu7 Lapproche course de relai du dveloppement de produit peut entrer en conflit avec les objectifs de vitesse maximale et de flexibilit. A contrario, une dmarche holistique ou rugby o une quipe essaie daller au loin comme une unit, passant la balle en arrire, peut mieux servir aujourdhui les exigences de la comptivit.Hirotaka Takeuchi and Ikujiro Nonaka, The New New Product Development Game,Harvard Business Review, January 1986

Nous perdons la course de relai7

workshop @ Fujitsu88

workshop @ Fujitsu99

workshop @ Fujitsu1010

workshop @ Fujitsu1111

workshop @ Fujitsu1212Introduction par Ken Schwaberworkshop @ Fujitsu13Scrum 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.

13Manifeste pour le dveloppement Agile de logicielsworkshop @ Fujitsu14

Manifeste pour le dveloppement Agile de logiciels

Nous dcouvrons comment mieux dvelopper des logicielspar la pratique et en aidant les autres le faire.Ces expriences nous ont amens valoriser :

Les individus et leurs interactionsplus que les processus et les outilsDes logiciels oprationnelsplus quune documentation exhaustiveLa collaboration avec les clientsplus que la ngociation contractuelleLadaptation au changementplus que le suivi dun plan

Nous reconnaissons la valeur des seconds lmentsmais privilgions les premiers.

14Scrum est une approche novatrice pour achever votre travailworkshop @ Fujitsu15Scrum 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 simple

Process EmpiriqueItratif & Incrmental3 PiliersLa TransparenceL'InspectionL'adaptation

15Thorie & Vocabulaireworkshop @ Fujitsu16

16Le Cadre de SCRUMworkshop @ Fujitsu17Le Product Owner cre une liste de fonctionnalits appelle Product Backlog

Pendant le Sprint Planning, lquipe tire un petit morceau du haut de cette liste: le Sprint Backlog; et dcide comment implmenter ces lments.

Lquipe dispose dun temps donn pour y arriver: le Sprint

17Le Cadre de SCRUMworkshop @ Fujitsu18Chaque jour, lquipe mesure sa progression pendant 15: le Daily Scrum

Durant tout le projet, le ScrumMaster fait en sorte que lquipe reste concentre sur sa mission.

A la fin du Sprint, les travaux doivent tre potentiellement livrables. Ces travaux sont considrs comme finis.

18Le Cadre de SCRUMworkshop @ Fujitsu19Le Sprint se termine avec la Revue de Sprint et la Rtrospective.

Lorsque le prochain Sprint dmarre, lquipe choisit un nouveau morceau dans le Product Backlog et recommence le processus.

Le processus sarrte lorsque lon a dlivr suffisamment de fonctionnalits, ou que le budget est atteint, ou que la date butoir est atteinte.

19Objectif recherchworkshop @ Fujitsu20Maximiser la valeur

20Les Rles dans Scrumworkshop @ Fujitsu21

21Les cochons et les poulesworkshop @ Fujitsu22

Les poules sont engages.Les cochons sont impliques.22 LEquipeworkshop @ Fujitsu23

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. 23workshop @ Fujitsu24

24Equipes auto-gres vs. Organisation traditionnelleworkshop @ Fujitsu25

Equipes 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 Fisher25Le ScrumMasterworkshop @ Fujitsu26

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)

26Le Product Ownerworkshop @ Fujitsu27

responsable du Product Backlog

assure la valeur cree

Accepte

rejte

entretient

travaille avec

Il 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)

27workshop @ Fujitsu28

Le cycle des crmonies28Les crmonies sont time-boxesworkshop @ Fujitsu29Sprint PlanningRevue de SprintRtrospectiveSprint PlanningSPRINTDaily Meetings

29 Sprint Planning Meetingworkshop @ Fujitsu30

30Principe de Pullworkshop @ Fujitsu31

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.

31 Sprint Planning Meetingworkshop @ Fujitsu32Organisateur: Product Owner

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

Dure: 8 heures pour un Sprint de 4 semaines

2 parties:Le QUOI?Le COMMENT?

Le Product Owner:Prsente le Product Backlog prioris par le client et/ou les utilisateurs

Prsente le Release Plan Initial

Prsentation 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 Owner

Dcoupe le Sprint Backlog en tches

Estime 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 Sprint32Sprintworkshop @ Fujitsu33

33Sprintworkshop @ Fujitsu34Organisateur: 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

34

Daily Scrumworkshop @ Fujitsu35

35 Daily Scrumworkshop @ Fujitsu36Organisateur: 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?

36La Revue de Sprintworkshop @ Fujitsu37Organisateur: 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...

37La Rtrospectiveworkshop @ Fujitsu38Organisateur: 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

38Les Artifactsworkshop @ Fujitsu39

39Le Product Backlogworkshop @ Fujitsu40

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

40Le Release Burndownworkshop @ Fujitsu41

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.41Sprint Backlogworkshop @ Fujitsu42

42

Sprint Burndownworkshop @ Fujitsu43

The 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)

43Definition of Doneworkshop @ Fujitsu44

44Level of Doneworkshop @ Fujitsu45Le 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 lEQUIPE

45Definition of Doneworkshop @ Fujitsu46Une 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 SCRUM

46

Done?workshop @ Fujitsu47Half done is not done

47Exerciceworkshop @ Fujitsu48Crer 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 MARS4548Les valeurs dans Scrum

49La Transparenceworkshop @ Fujitsu50Transparence

Inspection

Adaptation

50

LInspectionworkshop @ Fujitsu51

51L Adaptationworkshop @ Fujitsu52

52Au fait sa marche comment?workshop @ Fujitsu53

53Dabord une Ideworkshop @ Fujitsu54

54Ensuite une Visionworkshop @ Fujitsu55

55La Visionworkshop @ Fujitsu56

56Ensuite un Product Backlogworkshop @ Fujitsu57

57 Le Product Backlogworkshop @ Fujitsu58SprintReleaseFuture ReleasesPriorit moyennePriorit haute

58Product Backlog - Exemplesworkshop @ Fujitsu59

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

59Constitution de lEquipeworkshop @ Fujitsu60The TeamDveloppeurAnalysteArchitecteTesteurDBAScrum MasterTout le monde. Pas une autorit.Pas ncessairement un dveloppeur.Product OwnerChef de ProduitAnalyste MtierChef de Projet fonctionnelMOA

60Le Cycle de Scrumworkshop @ Fujitsu61

61Les formations Scrumworkshop @ Fujitsu62Scrum AllianceCertified ScrumMasterCertified Product OwnerCertified Scrum DeveloperCertified Scrum ProfessionalCertified Scrum TrainerCertified Scrum Coach

Scrum.org http://www.scrum.org/Professional Scrum MasterProfessional Scrum Master 1Professional Scrum Master 2Professional Scrum DeveloperPSD .NetPSD Java

http://www.scrumalliance.org/

62Mes formations workshop @ Fujitsu63Les formations de base:Introduction Scrumtre ScrumMastertre Product OwnerCoaching ScrumScrum in Depth: formation Scrum avanc

Les formations certifiantes Scrum Alliance & Scrum.org sont toutes la demande.

63Scrum Resourcesworkshop @ Fujitsu64

64

Companies using SCRUMworkshop @ Fujitsu65

65workshop @ Fujitsu66Voici mon introduction la Gestion de Projet avec Scrum

66workshop @ Fujitsu67Questions?

67workshop @ Fujitsu68Merci

68

workshop @ Fujitsu69Pierre E. NEIS - Tel +352 / 661 727 867

elpedromajor69