Yassine ZAKARIA SÉMINAIRE : MÉTHODES AGILES

Transcription

1 Yassine ZAKARIA SÉMINAIRE : MÉTHODES AGILES

2 Quelques constats Etude du Standish Group Seul 1/3 des projets informatiques sont qualifiés de succès 50 % sont livrés et opérationnels, mais sont sortis du contrat initial QCD : moins de fonctions que prévues dépassement des budgets et/ou du planning 20 % sont abandonnés en cours de route ou les résultats livrés ne sont jamais utilisés... 2

3 Pourquoi? 3

4 Cycle classique Vision de l avancement dans un projet traditionnel Fini à 50% Utilisable à 0% Analyse Design Dev Test Avancement 4

5 Cycle Agile Vision de l avancement dans un projet Agile Analyse Design Dev Test Fct 1 Fct n Fini à 50% Utilisable à 100% Avancement Fct m 5

6 2001, le Manifeste Agile En 2001, 17 spécialistes du développement logiciel se réunissent pour définir les valeurs et les principes de l Agile Les quatre valeurs fondamentales Agiles sont de valoriser : Les individus et leurs interactions plus que les processus et les outils. Des logiciels opérationnels plus qu une documentation exhaustive. La collaboration avec les clients plus que la négociation contractuelle. L adaptation au changement plus que le suivi d un plan. Le manifeste agile avec ses 4 valeurs et ses 12 principes 6

7 Pourquoi l Agile marche? Priorité à ce qui a le plus de valeur, à ce qui est le plus important Démarche itérative, incrémentale et adaptative Des interactions et de la communication (Feedback) Un outillage compact et rapidement assimilable De la visibilité De la motivation et de la satisfaction dans les équipes Un produit opérationnel très tôt Une réactivité face au changement 7

8 Vue d ensemble Lean Agile Optimisation globale Respect des individus Traque de la perte de valeur Scrum Cycles itératifs courts Décloisonnement métiers Rituels & visuels Responsabilisation Auto-organisation XP Pratiques d excellence technique 8

9 Quels bénéfices avec l Agile? 9

10 Cycle Agile Scrum 10

11 Backlog et Sprint planning La liste de tous les besoins exprimés Une rencontre entre les besoins métiers et le point de vue technique Exprimé de façon à mettre en évidence la valeur apportée par chaque composant (User Stories) Priorisé par le Product Owner, repriorisé en début de chaque sprint A la fin du sprint planning : Les US sont découpées en tâches et estimées L équipe s engage sur le contenu du sprint Le Backlog peut être découpé en sprints pour planifier les versions (release planning) 11

12 Le release planning 12

13 Le Daily Scrum 15 min A tour de rôle, chacun présente : S il a respecté les engagements qu il a pris la veille Les obstacles qu il rencontre dans le respect de ses engagements Les engagements qu il prend pour la prochaine journée Quelles sont tes tâches aujourd'hui? Qu'est ce que tu as réalisé hier? Est-ce que quelque chose te gène dans la réalisation de tes tâches? 13

14 Le Scrum Board C est un tableau qui reflète le contenu du Sprint Backlog Les user stories et les tâches sont représentées Les user stories sont hiérarchisées selon leur priorité 14

15 Rituels de fin de sprint Revue de sprint La notion «done» est très importante. Elle est définie au début du projet ou du sprint. Quand le sprint est terminé, on propose aux parties prenantes (stakeholders) le résultat du travail qui a été effectué et dont le statut est «done» au travers d'une démo, il s'agit de la revue de sprint La rétrospective Etat des lieux du sprint qui vient de s'achever. Elle est là pour améliorer les processus (identifier les axes d'amélioration, capitaliser sur les bonnes pratiques) : Qu'est ce qui a bien fonctionné? Qu'est ce qui a mal fonctionné? Comment améliorer les choses? Comment résoudre les problèmes que nous voyons apparaître? 15

16 L Agile dans le monde Source : 7th Annual State of Agile Development Survey 16

17 L Agile L adoption Source : 7th Annual State of Agile Development Survey 17

18 L Agile Les techniques employées Source : 7th Annual State of Agile Development Survey 18

19 L Agile Les bénéfices Source : 7th Annual State of Agile Development Survey 19

20 L Agile Quid des équipes Source : 7th Annual State of Agile Development Survey 20

21 L Agile Méthodes et pratiques Source : 7th Annual State of Agile Development Survey 21

22 L Agile Les freins à l adoption Source : 7th Annual State of Agile Development Survey 22

23 L Agile Bonnes pratiques Stabilité de l'équipe Protection de l'équipe vis à vis des parties prenantes Responsabilisation du Product Owner et de l'équipe de développement Plus de chef de projet mais un Scrum Master Attention à la contractualisation L'agile est simple à appréhender mais il n'est pas simple à déployer 23

24 Cursus Agile Module 1 Cursus 1 : Méthodes agiles, comprendre la démarche En trois journées permettre aux participants d'appréhender les principales méthodes agiles (Scrum, Extreme Programming, Kanban, Lean). Les sensibiliser aux défis d'une transformation agile. 24

25 Cursus Agile Module 2 Cursus 2 : Travail en équipes agiles En deux journées permettre aux participants d'appréhender les notions d'intelligence collective, d'auto-organisation, de travail d'équipe. 25

26 Cursus Agile Module 3 Cursus 3 : Ingénierie logicielle agile En deux journées : permettre aux participants de d'appréhender le développement agile basé sur des techniques modernes : TDD, intégration continue, automatisation des tests, etc. 26

27 Cursus Agile Module 4 Cursus 4 : De Chef de projet à Manager Agile Ces deux jours permettent d'appréhender le changement de paradigme - du chef de projet au scrummaster, facilitateur ; - du manager au leader, - du "command & control" au "servant leadership". 27

28 Cursus Agile Module 5 Cursus 5 : Le Responsable produit : son rôle dans le projet Agile Deux journées pour approfondir le rôle de product owner et product manager. Son positionnement, ses responsabilités, les compétences et outils nécessaires. 28

29 QUESTIONS / REPONSES 29