Ces slides ont pour objectif de présenter le contexte des méthodes agiles, et de présenter le fonctionnement de la méthode Scrum.
Je donne également un premier retour d'expérience
Introduction à l'Agilité - Cours complet 1 jourRenaud BROSSE
Un cours gratuit en 1 jour sur l'agilité en licence opensource. Servez-vous ! Dans un contexte de transformations tous azimuts des entreprises, l’agilité est devenue un atout indéniable pour faire face aux changements. Son originalité est qu’il mise avant tout sur la souplesse organisationnelle et le désilotage pour assurer efficacité et rapidité au système. Seul problème : faire de belles acrobaties, c’est bien joli (mais pas toujours facile) quand on est une startup de moins de 5 ans d’âge avec une cinquantaine de salariés, mais attention aux courbatures pour le méga-groupe de quelques 100.000 salariés traînant déjà plusieurs décennies d’histoire ! Et pourtant, nous avons une bonne nouvelle, « être agile », ça s’apprend ! Nous vous proposons de vous introduire dans cette démarche au travers de ce document. Il s’agit de notre support de formation à l’agilité dont le contenu a largement été éprouvé, au fil des contextes opérationnels auxquels il a été appelé à servir…
Cette présentation, mise en scène les valeurs et les principes des méthodes agiles , ainsi qu'une présentation détaillée sur la méthode XP et la méthode Scrum.
Support de formation pour la formation Professional Scrum Master I en vue de passer la certification PSM I.
Ce support est basé sur le scrum guide de 2017 (dernière version à jour à juillet 2020)
Pratique pour réviser avant de passer le Scrum PSM I de façon plus agréable et visuelle que le scrum guide.
Attention le support est en CC-BY mais les images utilisées pour Rôles / Artefacts / Events ne sont pas en CC-BY (à voir avec les sites s'ils autorisent l'utilisation, surtout pour une utilisation commerciale)
Le monde de l'informatique est divisé depuis toujours en deux univers : les personnes qui créent (Dev) et celles qui exploitent en production (Ops). Cette séparation peut générer stress et frustration. Les équipes n'ont pas l'impression d'aller dans le même sens et cela nuit à la productivité. Pour les réconcilier, un ensemble de pratiques et d'outils ont été imaginées: elles se cachent derrière le terme DevOps. Qu'est-ce que c'est exactement ? Quels problèmes est-ce que cela résout ? Quelle est la bonne approche pour le mettre en place? Nous vous proposons de découvrir notre vision sur ce sujet lors de cette session d'introduction.
Introduction à SCRUM.
- Qu'est-ce que l'agile ?
- Présentation de quelques idées reçues
- Dans quel cadre on peut mettre en place Scrum
- Scrum et le management
- Les méthodes de gestion de projets classiques : cycle en V, en cascade
- Changement d'organisation en terme de management dit "classique"
- Comment mettre en place Scrum
- Explication des processus Scrum.
- Couplage avec des techniques d'ingénieries logicielles et de qualité.
- Couplage avec lean startup
Agilité et la gestion du changement mboisvert - 15 octobre 2013Pyxis Technologies
Description:
Les méthodes Agiles sont de plus en plus utilisées dans les projets de développement logiciel, en particulier la méthode Scrum. Mais est-ce que cette méthode peut-être utilisée dans d'autres domaines que celui du développement logiciel?
Avec cette présentation, Mathieu Boisvert propose quelques exemples pour réfléchir avec les participants sur les préalables, les avantages et les difficultés d'adopter les méthodes Agiles dans le domaine de la gestion du changement. La présentation se découpe en trois parties :
- Introduction aux approches Agiles et à la méthode Scrum
- Planification et suivi d'un projet de gestion du changement à l'aide de Scrum
- Gestion de changement à planifier lors de l'adoption des approches Agiles
Biographie:
Mathieu Boisvert est coauteur, avec Sylvie Trudel, du livre « Choisir l’agilité: du développement logiciel à la gouvernance ».
Il est également membre actif de la communauté Agile et chargé de cours à la Chaire de gestion de projet de l’UQAM.
Lieu : Université de Sherbrooke - Campus de Longueuil
La gestion de projet agile propose une alternative crédible aux méthodes traditionnelles de gestion de projets.
La méthode SCRUM est à ce jour la plus utilisée des méthodes agiles. Réputée comme la plus simple à mettre en œuvre, elle définit un cadre précis d’organisation du projet qui doit être appliqué avec discipline mais qui se prête parfaitement à une adaptation au contexte métier de chaque entreprise.
Quelques slides génériques d'introduction à l'agilité avec un peu d'historique et de contexte, les bases, des éléments sur deux méthodes particulières : Scrum & Kanban
Un résumé rapide des ateliers et présentations auxquels j'ai pu prendre part et un feedback pour partager le contenu de certains ateliers que j'ai trouvé intéressant mais qui pourraient ne pas être retranscrit en vidéo
Meetup : De l'agilité de la DSI à l'agile MarketingBuy The Way
Retour sur le Meetup organisé par l'agence web BUY THE WAY :
- Comment appliquer la méthode Agile aux projets digitaux ?
- Comment réconcilier les équipes SI et les équipes métiers / marketing ?
Le but de cet événement est de sensibiliser les fonctions marketing / digitales à une méthode issue des départements informatiques.
Sommaire :
- Qu'est-ce que l'Agile ?
- L'Agile côté IT
- L'Agile côté Marketing
- Témoignage client
Introduction de la gestion de projet Agile au sein de l’équipe Réseau de Bell...PMI-Montréal
Bell Mobilité SSE Réseau a introduit la gestion de projet agile au sein de son organisation au cours de l’année 2014. L’objectif de la présentation est de faire le point sur leur progrès ainsi que de partager les défis et opportunités rencontrés.
Jean-François Guay
Jean-François Guay est titulaire d’un baccalauréat en génie électrique (spécialisation en Télécommunications) de l’université Laval de Québec et d’une maîtrise en gestion de l’Ingénierie de l’université Sherbrooke. Il est certifié PMP et détient une certification de "Change Management Practicioner" de PROSCI. Il apporte plus de 25 ans d’expérience en Télécommunications et Systèmes d’Informations. Avant de joindre Bell Mobilité, il a joué des rôles très actifs dans le design et la mise en place de réseau LAN/WAN/WAN en Amérique du Nord et du Sud. Il occupe présentement un poste de gestionnaire principal responsable du Bureau de projets SSE et de la Gouvernance au sein du groupe réseau de Bell Mobilité.
To be Agile or not to be ? Les méthodologies de développement doivent s'adapter aux demandes de plus en plus spécifiques et changeantes tout en respectant les besoins pratiques du client.
Chez TheCodingMachine, on pense que chaque projet mérite un instant de réflexion pour adopter la bonne approche méthodologique ! Pour certains types de projets ou bien certains contextes clients, la methode agile est très bien adaptée. Dans d’autres situations, c’est naturellement moins le cas et il est préférable d'employer les méthodes classiques.
Zoom sur les meilleures méthodologies de développement web et informatique (methode agile et methode classique de développement.)
5. C’est quoi être Agile ?
• Énormément de réponses possibles, suivant
l’angle et le prisme choisi, la plupart
complémentaires
Agilité
Bien être et valeurs
(prévention de risques psycho-sociaux au travail)
…
…
Faire les bonnes choses
(satisfaction client)
…
…
Faire les choses efficacement
(productivité)
5/75
6. Pour moi et aujourd’hui,
c’est de plus en plus
• Évoluer vers une organisation
– plus organique
– en petites structures auto-organisées
– apprenantes
– respectueuses de leur écosystème (gagnant-
gagnant)
• Conséquences
– De meilleur résultats
– Un regain de sens dans le travail
• (Problème générationnel ?)
6/75
7. Et ça demande…
• Une ouverture d’esprit
• Du courage
– Remettre en question nos modes de pensées
– Réapprendre l’entreprise
• Dans notre contexte
• Au bénéfices de toutes les parties prenantes
• Un lâcher prise
– Manager
• mieux atteindre le « quoi » en contrôlant moins le « comment »
– Acteur : avoir plus de pouvoir
• mais avec de grands pouvoirs viennent de grandes responsabilités
7/75
10. Des équipiers en forme de T
10/75
http://newcdn.flamehaus.com/Valve_Handbook_LowRes.pdf
11. Mais avant d’en arriver là…
• On commence souvent par mettre un pied
dans des choses plus terre-à-terre
– Réduire les problèmes techniques
• Intégration continue
• Tests unitaires, TDD, …
– Améliorer la visibilité et la priorisation (pilotage)
• Management visuel
• Incréments
– Etc, etc.
11/75
14. Modèle en cascade (Waterfall)
14/75
http://www.commentcamarche.net/contents/genie-logiciel/cycle-de-vie.php3
15. Cycle en V
15/75
http://www.commentcamarche.net/contents/genie-logiciel/cycle-de-vie.php3
16. Simple à mettre en œuvre
• Contrat simple
– Tout est prévu précisément à l’avance
• Qui / Quoi / Quand
• Approches connues et enseignées partout
16/75
17. Effet « Tunnel »
• X mois sans visibilité
– « Nuit polaire »
17/75
http://www.projectcartoon.com
18. Importance des documents écrits
• Causes
– Délais long entre la création d’une étude et de son
utilisation
– Spécialisation des gens = nombreux intermédiaires
• Sert de référence ultime
– Du besoin
– De la solution
– De la validation
–…
18/75
19. Facteurs de succès
• Le client sait exactement ce qu’il veut dès le
départ
• Les besoins ne changent pas
• L’équipe de réalisation sait parfaitement
– Trouver les bonnes solutions techniques du
premier coup
– Chiffrer la charge de travail en début de projet
• …
19/75
23. Constat
• Les spécifications ne sont pas complètement
comprises tant que le projet n’est pas
commencé
• Les utilisateurs ne savent ce qu’ils veulent
qu’après avoir vu une première version de
l’application
23/75
24. Caractéristiques
• Méthodes réactives et incrémentales
d’organisation du travail
• Focalisées sur le produit et la satisfaction
client
• Construit en adéquation avec les capacités et
limites humaines
24/75
26. Les 4 valeurs
Nous reconnaissons que les éléments à droite ont
de la valeur, mais nous privilégions ceux à gauche
Individus et
Processus et outils
interactions
Un produit Documentation exhaustive
opérationnel
Collaboration Négociation du contrat
avec le client
Adaptation au Suivi d'un plan
changement 26/75
27. 12 principes
1. Satisfaire le client
2. Accueillir le changement
3. Livrer fréquemment
4. Travailler quotidiennement avec les utilisateurs ou leur
représentants
5. Créer un environnement qui soutienne l’équipe
6. Communiquer en face à face
7. Mesurer l’avancement sur un logiciel opérationnel
8. Avoir un rythme de développement soutenable
9. Porter une attention continue à l'excellence technique
10. Minimiser la quantité de travail inutile
11. Avoir une équipe auto-organisée pour faire émerger les solutions
12. Inspecter et s’adapter régulièrement
27/75
28. Marge de manœuvre : 4 axes
• Qualité
– Fixe
• Car la dette technique comporte un fort taux d’intérêt !
• Priorisation suivant les 3 autres axes
Périmètre
Délai Coût
28/75
29. L’agilité en 2 slides (1/2)
Expression des besoins
Conception
Développement
Tests, recette & debugage
À 50% du temps total, le client ne voit statistiquement
que 10% de son application.
Et il ne sait pas dans quel état elle est.
29/75
30. L’agilité en 2 slides (2/2)
Backlog, user stories Expression de besoins
Simplicité, refactoring Conception
TDD, acceptance Développement
Demos, reviews Tests, recette & debuggage
i1 i2 i3 i4 i5 in
À chaque itération, le produit est 100% fonctionnel.
30/75
31. Facteurs de succès
• L’utilisateur est impliqué quotidiennement (ou
son représentant)
• Le middle management soutient l’équipe auto-
organisée
• Les pratiques sont adaptés au mode incrémental
– Automatisation des tests car rejoués souvent
– Code compréhensible car modifié souvent
–…
• …
31/75
32. Bénéfices de l’adoption (sondage)
32/75
http://www.versionone.com/state_of_agile_development_survey
33. Répartition des méthodes (sondage)
33/75
http://www.versionone.com/state_of_agile_development_survey
35. Rôle 1/3 : Product Owner
• Porteur de la vision globale du produit
• Défini les priorités
• Accepte ou rejette les livrables
35/75
36. Rôle 2/3 : Scrum Master
• Enlève les obstacles pour l’équipe
• S’assure du respect de scrum
• Serviteur de l’équipe : facilitateur
• Ce n’est pas un chef de projet
36/75
37. Rôle 3/3 : L’équipe
• Réalise le logiciel
• Auto-organisée
• Stable durant le sprint
• Avec toute les compétences nécessaires pour
le sprint
37/75
39. Product Backlog
• Liste du travail à effectuer
– Chiffré imprécisément
– Valeur ajoutée précisée
– Sous forme de User Stories
Géré par le product owner
39/75
40. User Stories (1/2)
• Nom (Valeur métier)
• En tant que <rôle>
• Je veux <action>
• Afin de <but>
• Critères d'acceptation
40/75
41. User Stories (2/2)
• Ecrites par le Product Owner
• Très simples
• Focalisées sur l'utilisateur final
– valeur métier apportée
• Critères d'acceptations
– testable, définit le « Done »
• Laisse place à la discussion pour les détails
– individus et interactions : une user story est une
promesse d’une rencontre future
41/75
42. Planification de sprint
• Choisir et s’engager, collectivement
– L’objectif du sprint
– Les user stories du Product Backlog embarquées dans le
Sprint Backlog
• Découpées en tâches
• Estimées en point, relativement à une user story de référence
42/75
48. Burndown
• Suivi du reste à faire (pas du consommé)
48/75
http://www.scrumalliance.org/articles/55
49. Mêlée quotidienne – Daily Scrum
• Auto-organisée, pas de micro-management
• ~ 15 minutes
• 3 questions par personnes
– Qu’ai-je fais hier ?
– Qu’est ce que je compte faire aujourd’hui ?
– Quels obstacles je rencontre ?
49/75
50. Sprint Review et démonstration
• Démonstration de l’incrément réalisé
• Toute l’équipe participe
• Tout le monde peut y assister
– Feedback venant alimenter le product backlog
• Informel
• Revue du sprint backlog
50/75
58. Feedback
• Avoir un retour, et l’avoir très vite
– Réunions d’équipe quotidienne
– Démos avec le clients
– Tests unitaires
– Tests d’acceptance automatisés
–…
58/75
59. Courage
• S'attaquer aux problèmes tout de suite
– ne pas les laisser « pourrir »
• Redévelopper si nécessaire
• Appliquer les valeurs XP
59/75
60. Respect
• Une personne n'a pas moins ou plus de valeur
qu’une autre
• Tout le monde a voie au chapitre et toutes les
contributions sont bienvenues
60/75
68. Succinctement
• Un méta-processus non-prescriptif
– Ne décrit pas la méthode de travail à suivre
• Démarre à partir de la méthode de travail préexistante, avec
ces rôles, ces artefacts, …
• Décrit comment l’améliorer
• En flux continu
– Pas d’itérations, mais des cadences
• Contrairement à Scrum, le tableau n’est jamais vide
• Avec travail en cours (W.I.P.) limité
• Avec amélioration continue pas à pas (kaizen)
68/75