-la-gestion-de-projet-agile

La gestion de projet agile $1,000.00

Du 02/09/2020 au 20/10/2020

Plus de la moitié des projets de développement sont désormais réalisés avec une méthode et des bonnes pratiques qui se réclament du mouvement agile. A condition qu'ils s'y prêtent et que les équipes oublient un peu leurs habitudes.

Votre package
  • Abonnement au site LeMarson pendant un an
  • 8 sessions en direct
  • Des documents à télécharger en relation avec les thèmes traités
  • Des QCM pour vous évaluer à chaque session
Tarif du séminaire
  • Remise $0.00
  • Montant total à régler $1,000.00
Inscrivez-vous
8 sessions au programme
Session 1 : Introduction , recommandations applicables aux méthodes agiles
Séminaire

Session 1 : Introduction , recommandations applicables aux méthodes agiles

Les méthodes agiles sont un sujet permanent de polémiques, entre les chefs de projets traditionnalistes et ceux qui sont ouverts à d’autres méthodes, dès lors qu’elles apportent un plus mesurable. Elles ne sont cependant pas en contradiction avec le cycle en V, souvent pratiqué dans les équipes traditionnelles. Dans les deux cas, on cherche à anticiper sur le déroulé des projets, plus précisément à mieux appréhender les tests unitaires, d’intégration et fonctionnels. Nous insisterons particulièrement sur la conception des tests fonctionnels, qui ne peut être assurée que par les « gens » du métier, les utilisateurs. L’agilité, ce n’est pas un cadre rigide de mise en œuvre d’un projet. C’est aussi un ensemble de recommandations, qui chacune à son niveau, va contribuer au succès des entreprises : homogénéité de l’équipe projet, unicité et respect de la boîte à outils, gestion des risques, gestion des compétences, modélisation. Elles ne sont pas obligatoires, mais ne sauraient nuire à la bonne marche des travaux. Elles contribuent pour une part non négligeable dans la réussite des projets agiles.
Session 2 : Les faiblesses de la gestion traditionnelle, état d’esprit agile et forum
Séminaire

Session 2 : Les faiblesses de la gestion traditionnelle, état d’esprit agile et forum

Les méthodes traditionnelles peuvent souffrir de quelques inconvénients et manques : difficultés pour élaborer un cahier des charges, estimation des charges de développement, effet tunnel, etc. Les méthodes agiles permettent de limiter ces inconvénients. On se focalisera surtout sur les cahiers des charges et sur quelques recommandations pour bien les élaborer. L’agilité ce sont à la fois des méthodes et des bonnes pratiques, « posées » sur un état d’esprit commun, ludique et parfois très orienté papier. C’est aussi le fait que les techniciens du TI comprennent que les véritables « patrons » des projets, ce n’est plus eux, mais leurs utilisateurs, pour qui ils travaillent. Un juste retour des choses. L’aventure agile a commencé en février 2001 avec un forum qui a réuni 17 chefs de projets, blanchis sous le harnais. Même si on peut faire remonter les origines du mouvement plus loin, avec les méthodes RAD, c’est février 2001 qui sert de référence. Qui a abouti à la publication d’un manifeste en douze principes, que nous présentons ici en détails. Pourquoi passer à une gestion agile ? Eternelle question de motivation des chefs de projets. Nous vous proposons les meilleurs arguments, qui vous seront d’autant plus utiles, si vous avez à vous justifier pour vouloir modifier l’ordre établi.
Session 3 : Les piliers des méthodes agiles et les principales méthodes hors Scrum
Séminaire

Session 3 : Les piliers des méthodes agiles et les principales méthodes hors Scrum

Qu’il s’agisse de méthodes ou de bonnes pratiques, l’agilité exploite un certain nombre d’artefacts et d’outils, qui reviennent toujours. Nous les passons en revue de manière systématique en insistant sur ceux qui suscitent le plus de polémiques : le regroupement des équipes en un même lieu et l’autogestion des équipes, entre autres. Le sujet du TDD est approfondi, la programmation pilotée par les tests, de même que la programmation en binôme et le suivi des performances des développeurs, de leur tendance naturelle (parfois) à produire du code complexe, qui nuit au cycle de vie des applications (maintenance). Dans un cadre agile, on ne refuse pas le recours aux revues de codes et personne n’est accusé. Après la présentation rapide des méthodes et bonnes pratiques qui se réclament du mouvement agile, nous insistons sur les recommandations de XP, qu’il faut plus considérer comme un ensemble de techniques d’ingénierie dédiées au codage d’applications, qu’une véritable gestion de projet. Bien que XP « stricto sensu » est relativement peu utilisé, certaines de ses pratiques sont très répandues et contribuent aux méthodes dites hybrides. Un zoom est appliqué sur le « Lean Management » et ses bonnes pratiques (ce n’est pas une méthode), issues des techniques de fabrication de Toyota, parmi lesquelles la course au gaspillage, le pilier majeur de ses 7 recommandations.
Session 4 : La méthode Scrum (I) : présentation, Backlog et « user stories »
Séminaire

Session 4 : La méthode Scrum (I) : présentation, Backlog et « user stories »

Phasage de la méthode, depuis la conception du backlog, jusqu’aux cérémoniaux de revue et de rétrospective, en passant par la planification et les « standup » meetings quotidiennes. Les principaux acteurs sont présentés, le « product owner », le « scrum master », qui n’est pas une nouvelle forme de chef de projet et les équipiers (développeurs). Conception du Backlog, la liste des histoires à développer, le « cabinet noir » constitué par le PO et les utilisateurs, établissement des BV (« Business Value »), évaluation des histoires en points d’effort par les équipiers, taille des histoires et dimensionnement de l’équipe de développement, affectée à un sprint.
Session 5 : La méthode Scrum (II) : priorisation du Backlog, découpage en sprints, histoires et tâches
Séminaire

Session 5 : La méthode Scrum (II) : priorisation du Backlog, découpage en sprints, histoires et tâches

Une fois l’évaluation des histoires en BV effectuée de même que leurs points d’efforts, il faut les prioriser. Différentes techniques sont proposées, certaines très simples comme la méthode des sondages ou celle du « scoring », d’autres plus complexes et mieux adaptées, telles que la méthode des « poids relatifs ». Le cas concret d’une usine de lubrifiants est proposé pour illustrer le propos. Il convient ensuite de traduire la liste des histoires priorisées en une succession d’itérations, dont le PO conservera la maîtrise tout au long du projet, avec possibilité de les modifier en fonction des aléas du développement. Chacune des histoires est découpée en tâches élémentaires d’une ou deux journées, l’ensemble sprints, histoires et tâches étant reporté sur un grand tableau, volontairement « papier », devant lequel les équipiers, le PO et le « scrum master » vont se réunir lors, de la « standup meeting ». Le problème des histoires techniques et des bugs est analysé, qui doit être traité, comme une dette technique, en toute priorité.
Session 6 : La méthode Scrum (III) : Les cérémoniaux, indicateurs de pilotage et évaluation des performances
Séminaire

Session 6 : La méthode Scrum (III) : Les cérémoniaux, indicateurs de pilotage et évaluation des performances

Les cinq cérémoniaux de Scrum sont présentés : la réunion des utilisateurs dans le « cabinet noir » pour la définition des histoires à développer, la réunion d’évaluation des histoires par les équipiers, la planification par le PO et son équipe, la « sprint review » et la réunion de rétrospective. Pour éviter les déperditions, le contrôle du temps passé est une institution (l’un des douze principes de base). Pour éviter l’effet tunnel Scrum exploite un ensemble d’indicateurs de suivi, parmi lesquels les « Burn down » et « burn up », qui donnent une vue instantanée précise de l’état d’avancement de chacun des sprints. La connaissance de la vélocité de l’équipe est un critère clé, mesuré sur la base de sprints déjà réalisés.
Session 7 : Approche bimodale, qui utilise Scrum,  le « scaling agile », pièges et causes de dysfonctionnements, l’apport de DevOps
Séminaire

Session 7 : Approche bimodale, qui utilise Scrum, le « scaling agile », pièges et causes de dysfonctionnements, l’apport de DevOps

Scrum n’est pas réservé aux seuls projets à connotation métier. On peut l’exploiter dans des contextes plus techniques, voire même au-delà du développement logiciel, dans les infrastructures. Il faut considérer l’agilité comme un ensemble de suggestions, dont on prendra tout ou partie selon les cas d’usages, ce qui ouvre la voie à de nombreux autres domaines. Les entreprises ont aussi le besoin de lancer plusieurs projets en même temps, sur les mêmes principes. Dès lors se pose le problème de leur gestion parallèle, un PO, un « scrum master » et un équipier, n’étant affectés qu’à un seul projet à la fois. C’est à ce besoin que répond l’agilité « au carré », avec Safe ou Spotify, les solutions les plus répandues. Quels sont les pièges à éviter : le manque de vision dû au foisonnement des sprints, la dette technique qu’il convient « à tout prix » de régler, une mauvaise interprétation du principe Kiss, le manque de discipline lié à la liberté de comportement, les itérations trop courtes. Quelles sont les causes de dysfonctionnement : le manque de pouvoir de décision du PO, les communications insuffisantes, les tests mal conçus et incorrectement menés, les équipes mal structurées et hétérogènes, etc. Apport de DevOps et le lien entre le développement et la production.
Session 8 : L’opposition, la réalité statistique de l’agilité, les outils, conclusion et récapitulatif QCM
Séminaire

Session 8 : L’opposition, la réalité statistique de l’agilité, les outils, conclusion et récapitulatif QCM

La parole à l’opposition et le paysage statistique entre les méthodes traditionnelles et l’agilité. Même si les outils n’occupent pas une place centrale dans un processus agile, ils n’en rendent pas moins de nombreux services et l’offre est pléthorique. Un récapitulatif des QCM est effectué et un rappel des 10 points clés dont il faudra se souvenir, est effectué, qui permettra aux participants de se lancer dans leurs projets agiles, à charge pour eux d’adapter les recommandations à leur contexte particulier.