QRP FRANCE : 03. Devenir Développeur Agile - Certification Scrum Developer/Team Member

Les points forts de la formation Scrum Developer (scrum.org) avec QRP France

• Les participants sont mis au défi de penser en termes de principes Scrum, tout au long de la formation, pour mieux comprendre leur application lors de leur retour en milieu professionnel.
• Certification Professional Scrum Developer (PSD) de la Scrum.org.
• 40% théorie / 50% pratique / 10% échanges.
• Pédagogie progressive.
• Ateliers de simulation et de mise en situation.
• Retour d'expérience terrain.
• Intervenant certifié et expert en management agile.
• Avis client : 4.3/5 (source Truspilot)

OBJECTIFS

• Être capable de développer en mode agile en mobilisant les bonnes pratiques d’ingénierie logicielle et l’automatisation des tests Agiles, tout en favorisant un fonctionnement en auto-organisation de l’équipe
• Éclairer les bonnes pratiques de développement logiciel
• Maîtriser les bonnes pratiques de développement agile
• Connaître les techniques de tests agiles
• Planifier son action dans un projet agile en tant que membre de l'équipe de développement
• Sensibiliser les stagiaires au rôle de membre d’une équipe agile
• Favoriser l’émergence de l’auto-organisation et de la responsabilisation de l’équipe
• Présenter les outils et techniques les plus représentatifs dans les environnements Java ou .NET 

PROGRAMME DE FORMATION

JOUR 1

Le framework scrum vu du product owner (implication, limites d’intervention, trucs et astuces,…)

• Relation avec le scrum master, le PO et les parties prenantes au projet,…
• Mise en place du projet
• Préparation pour l’action (sprint 0)
• Release et sprint planning meeting
• Sprint et stand-up meeting quotidien
• Sprint review et sprint retrospective

Le framework XP vu du développeur Agile (implication, limites d’intervention, trucs et astuces,…)

• Pratiques XP en termes de gestion de projet
• Pratiques XP en termes d’ingénierie du logiciel

L’approche OBJET & SOLID

• Historique et objectifs
• Concepts d’objet, relations (héritages,…) et échanges (messages, protocoles,…) entre objets
• Single responsability, open/close principes
• Principes de substitution de Liskov, de ségrégations d’interface et de dépendance inversée

Les patterns du développement Agile

• Qu’est-ce qu’un pattern ? et bref rappel historique
• Cartographie des principaux patterns GRASPatterns

JOUR 2

Le testing activité majeur en agile

• Tests et/ou spécifications
• Impact de l’Agilité sur les tests
• Politique, stratégie et activité de testing
• Les différents niveaux de test (acceptation, unitaire, non-régression,…)
• Les différentes approches de testing (BDD, ATDD, TDD,…)
• Automatisation des tests

Les pratiques de développement collectif

• Appropriation collective du code
• Conception à « quatre mains » (Dual Story Telling)
• Développement en binôme
• Testing en binôme
• Mise en pratique (coding dojo)

Développer dans le cadre d’une usine logicielle (concepts, cas d’usage, solutions envisageables)

• Définitions, historique et usage
• Objectifs et composition d’une « software factory »
• Ateliers de modélisation et de développement
• Gestion de configuration
• Automatisation des tests et Intégration continue
• Mise en pratique (coding dojo)

Au-delà de l’ingénierie du logiciel Agile

• Garantir le respect des valeurs et des principes agiles
• Promouvoir l’art du travail bien fait
• Le mouvement DevOps

EXERCICES PRATIQUES

Pour ce module des Coding Dojo sont mis en place pour permettre l’application concrète de la plupart des techniques d’ingénierie logicielle vues cidessus. Selon les cas, les exercices se dérouleront soit :

• en kata : L'un des participants propose un sujet. En commençant de zéro, il code pas à pas une solution devant les autres participants. Les autres participants peuvent intervenir dès qu'une ligne de code leur pose problème (questions, commentaires,…).
• en randori : Pour trouver le meilleur code à un sujet donné, des équipes de participants (par paire : un pilote et un co-pilote) codent à tour de rôle en temps limité devant l'assistance. L'assistance ne peut intervenir que lorsque les tests sont "verts".