Le plan de gestion de projet, partie 2 : une comparaison complète de Waterfall, DAD, SAFe, LeSS et Scrum@Scale

Aperçu

Dans la partie 1 du Plan directeur de gestion de projet, nous avons couvert les méthodologies de développement de logiciels Lean, Agile, Scrum et Kanban et comment elles remontent toutes à la fabrication au plus juste. Ces méthodologies sont généralement déployées au niveau d'une seule équipe. Cependant, la complexité augmente à mesure que les projets et les équipes de projet deviennent plus grands et que de nouvelles approches sont nécessaires pour être agiles à grande échelle.

Dans la partie 2, nous allons d'abord plonger dans la façon dont les chefs de projet utilisent la méthodologie en cascade, qui est le cadre le plus courant pour le développement de logiciels dans les entreprises traditionnelles. Juxtaposés à cela, nous couvrirons les frameworks les plus populaires qui tentent d'intégrer les principes agiles à grande échelle - Disciplined Agile Delivery (DAD), Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS) et Scrum@Scale.

Cascade

La méthodologie en cascade (également connue sous le nom de modèle de cycle de vie du développement logiciel (SDLC)) est une méthodologie plus traditionnelle dans laquelle le développement logiciel passe d'une phase à l'autre comme une cascade. Les phases ne se chevauchent pas et ont des critères d'entrée et de sortie spécifiques pour passer d'une phase à la suivante.

Les six étapes du cycle de vie du modèle de cascade original sont :

1. Exigences : dans cette phase, les attentes et les objectifs du projet sont définis, et les exigences sont analysées et documentées de manière approfondie, généralement par un analyste métier. Les exigences sont examinées et approuvées avant de quitter cette phase.
2. Conception : Une fois les exigences approuvées, le travail commence sur l'architecture et la conception du produit pour répondre aux exigences approuvées. L'architecture physique, l'architecture des composants, la conception de la base de données, les composants détaillés, la conception des modules et d'autres aspects de la conception sont documentés par un architecte ou un concepteur logiciel. Il est ensuite examiné et approuvé avant de commencer la mise en œuvre.
3. Implémentation : Une fois la conception approuvée, l'implémentation ou le codage du logiciel en fonction des exigences et de la conception est effectué par les développeurs de logiciels.
4. Vérification : une fois la mise en œuvre terminée, le logiciel est testé par l'équipe de test ou d'assurance qualité pour s'assurer que les exigences et la conception sont respectées et que le niveau de qualité souhaité est atteint. Les défauts sont détectés, consignés, triés et, dans de nombreux cas, corrigés.
5. Publication et maintenance : une fois les tests et le débogage terminés, le produit est publié sur le client et installé. Souvent, une série de tests a lieu pour s'assurer que l'installation a réussi. Une fois le produit livré, une maintenance et un support continus ont lieu pour s'assurer que le produit continue de fonctionner comme prévu.

Avantages de la cascade

La cascade présente certains avantages et convient à certains types de projets, mais elle présente également de sérieux inconvénients. Waterfall convient mieux aux projets plus courts où les exigences et la technologie sont bien comprises et ne sont pas susceptibles de changer de manière significative.

S'il est appliqué au bon type de projet, certains des avantages du modèle en cascade :

• Simplicité : Waterfall est simple à mettre en œuvre en raison de l'identification de la portée à l'avance et en raison des phases rigides et d'une transition claire d'une phase à la suivante.
• Visibilité : les progrès sont plus facilement mesurés et perçus par les parties prenantes, car l'étendue complète du travail est connue à l'avance et au fur et à mesure que le projet passe d'une étape à l'autre.
• Documentation : la portée, les exigences et les plans peuvent être soigneusement pensés et bien documentés, ce qui facilite le travail des équipes moins expérimentées sur le projet.
• Travail par phases : en raison des rôles rigides et de la transition entre les phases, il est possible que les ressources du projet travaillent sur d'autres projets lorsque leur phase principale n'est pas en cours.

Inconvénients de la cascade

Waterfall n'est pas adapté aux projets plus longs où les exigences ne sont pas bien comprises et/ou susceptibles de changer et/ou où il existe un risque technique important. À l'ère d'aujourd'hui où les conditions du marché changent constamment et où le délai de mise sur le marché est critique, cela s'applique à la plupart des projets logiciels.

Les inconvénients du modèle en cascade, qui se concentrent principalement sur son incapacité à s'adapter au changement, incluent :

• Portée monolithique : elle récompense les parties prenantes de penser à TOUT lors de la définition de la portée du projet, conduisant à une portée monolithique.
• Commentaires tardifs des clients : il est difficile pour les parties prenantes et en particulier les clients d'imaginer l'étendue détaillée d'un projet. Étant donné que Waterfall expose les clients aux résultats du projet principalement dans les dernières étapes du projet, il devient inévitablement difficile d'intégrer les commentaires des clients dans le projet.
• Les exigences changent : dans les projets plus longs, les conditions du marché, et donc les objectifs et les exigences du projet, présentent un risque très élevé de changer au cours du projet.
• Valeur créée à la fin : Waterfall nécessite beaucoup de travail en amont, ce qui signifie que la valeur n'est pas produite avant la fin du projet.
• Interdépendance des phases : l'intégration de modifications entraîne souvent des exigences et/ou des remaniements de conception qui peuvent avoir un impact sur d'autres domaines du projet. La dépendance des étapes ultérieures aux étapes antérieures peut rendre les petits changements dans le projet extrêmement difficiles.

Livraison agile disciplinée (DAD)

La livraison agile disciplinée (DAD) a été formalisée par Scott Ambler chez IBM et Mark Lines et étend les cadres agile et scrum, reconnaissant que les parties non agiles d'une organisation sont généralement impliquées dans une certaine mesure dans la livraison d'un projet logiciel. Ce cadre inclut explicitement les activités des opérations informatiques, de l'architecture d'entreprise, de la gestion de portefeuille, des finances et de l'approvisionnement dans le cycle de vie complet de la livraison. DAD vise à accroître l'agilité globale de l'entreprise de manière pragmatique.

Principes et composants principaux

Les rôles

DAD a considérablement plus de rôles que Scrum et est divisé en deux catégories de rôles d'équipe. Les rôles principaux sont remplis par des personnes qui travaillent constamment sur le projet. Les rôles secondaires sont généralement introduits temporairement pour aider l'équipe avec la mise à l'échelle ou d'autres problèmes. DAD a ces rôles supplémentaires parce qu'il couvre l'ensemble du cycle de vie de la livraison de la solution et parce qu'il reconnaît les différents types de rôles temporaires et de soutien nécessaires trouvés dans le monde réel

Rôles principaux :

1. Partie prenante : Quelqu'un qui dépend de votre équipe pour terminer le projet : client, utilisateur final ou collègue interne.
2. Membre de l'équipe : personnes au sein de l'équipe qui effectuent réellement le travail prévu : développeurs, concepteurs, testeurs, etc.
3. Chef d'équipe : Analogue au scrum master, le chef d'équipe agit comme un leader-serviteur pour l'équipe en supprimant les obstacles, en facilitant la cohésion de l'équipe et en diffusant les valeurs agiles.
4. Propriétaire du produit : parfois appelé la « voix du client ». Le propriétaire du produit représente les parties prenantes et tient à jour la liste prioritaire des travaux à effectuer.
5. Propriétaire de l'architecture : responsable de l'atténuation des risques liés à l'architecture à grande échelle. Ce rôle est généralement occupé par un développeur senior au sein de l'équipe, car il nécessite une formation technique approfondie et une solide connaissance du domaine d'activité.

Rôles secondaires :

1. Spécialiste : personnes qui se joignent temporairement à l'équipe pour aider dans un rôle spécialisé. Par exemple, un analyste de données peut se joindre pour fournir des capacités de recherche dans les premières étapes d'un projet.
2. Expert du domaine : consultants fiscaux, conseillers juridiques et autres personnes qui ont une expertise dans le domaine et aident l'équipe sur les défis connexes.
3. Expert technique : administrateur de base de données, maître de construction expert en sécurité, etc. Ces personnes aident les membres de l'équipe les plus généralistes à des moments clés du cycle de vie.
4. Testeur indépendant : Alors que les testeurs font généralement partie de l'équipe principale, dans certains cas, les exigences réglementaires de la vie ou des systèmes très complexes, les testeurs indépendants travaillent en parallèle pour valider le travail fourni.
5. Intégrateur : à grande échelle, différentes équipes travaillent sur différentes parties de l'ensemble du système. Un intégrateur aide l'équipe à intégrer sa partie à l'ensemble du système et gère les dépendances.

Prise en charge du cycle de vie

DAD favorise un cycle de vie de livraison complet, non seulement la partie programmation et release couverte par agile/scrum, mais aussi la phase de démarrage où la vision du projet est définie et approuvée et les phases de support et de retrait après la release. Actuellement, DAD prend en charge 6 cycles de vie différents :

• Le cycle de vie agile : un cycle de vie de projet basé sur Scrum
• Le cycle de vie Lean : un cycle de vie de projet basé sur Kanban
• La livraison continue : cycle de vie agile
• La livraison continue : cycle de vie Lean
• Le cycle de vie exploratoire (Lean Startup)
• Le cycle de vie du programme pour une équipe d'équipes

Ces cycles de vie tiennent compte des différents styles de travail, des niveaux d'agilité de l'entreprise et d'autres situations dans lesquelles les équipes peuvent se trouver. Le point principal est que ces cycles de vie agissent comme des suggestions. DAD favorise le pragmatisme plutôt que le purisme, car chaque situation est unique et les praticiens agiles disciplinés doivent adopter le processus agile en fonction de leurs besoins.

Objectifs du processus

DAD utilise une approche axée sur les objectifs pour créer et adapter des processus agiles. Les auteurs de cette méthodologie décrivent 21 processus les plus importants et les plus courants auxquels la plupart des équipes seront confrontées au cours de leur cycle de vie.

Tous ces processus ont des points de décision documentés qui obligeront l'équipe à décider comment elle structurera ce processus. Chaque point de décision fournit des techniques ou des pratiques suggérées qui peuvent être utilisées pour mettre en œuvre la décision. Vous pouvez en voir un exemple dans l'image ci-dessous. Un processus « Développer une vision commune » comporte 6 décisions qui doivent être prises. Chacune de ces décisions a 2 à 5 pratiques suggérées. Les flèches indiquent que les auteurs DAD ont ordonné la liste avec l'élément du haut représentant la meilleure pratique et l'élément du bas étant la pire pratique de cette liste. Le texte en _ gras italique _ signifie de bons points de départ pour les nouvelles équipes, qui débutent avec DAD.

Mise à l'échelle de DAD

Disciplined Agile Delivery aborde la mise à l'échelle sous deux angles différents :

• Agilité tactique à grande échelle

• Agilité stratégique à grande échelle

L'agilité tactique tente d'aborder les facteurs de mise à l'échelle de l'équipe individuelle tels que la taille, la répartition géographique, la complexité du projet, etc., grâce à l'application situationnelle des objectifs du processus et de leurs pratiques suggérées.

L'agilité stratégique tente d'aborder la mise à l'échelle par l'application de stratégies agiles et allégées dans l'ensemble de l'organisation en élargissant le cadre pour aborder différents domaines de l'organisation :

• DevOps discipliné : couvre l'utilisation de DevOps pour fournir des résultats plus efficaces à une organisation.

• Disciplined Agile IT (DAIT) : explique comment appliquer des stratégies agiles et allégées à tous les aspects de l'informatique.

• Entreprise agile disciplinée :. explique comment appliquer le lean et l'agilité dans l'ensemble d'une entreprise.

Sûr

Scaled Agile Framework (SAFe) est actuellement le framework Agile à l'échelle le plus populaire, le plus complexe et le plus complet. 29 % des personnes interrogées dans le rapport annuel sur l'état de l'agilité affirment utiliser ce cadre dans leur organisation. À leur tour, il existe de nombreux chefs de projet SAFe sur le marché.

Le livre de Dean Leffingwell "Scaling Software Agility: Best Practices for Large Enterprises", publié en 2007, a été à l'origine de SAFe. Leffingwell est maintenant le méthodologiste en chef de SAFe, mais de nombreuses autres personnes contribuent également à ce cadre. Actuellement, dans la version 4.6, ce framework ressemble à un produit logiciel avec gestion des versions, rétrocompatibilité et divers composants.

Principes et composants principaux

L'objectif principal de SAFe est de faciliter la création et la croissance d'une entreprise Lean car il reconnaît que de nombreux types d'entreprises sont, en partie, des éditeurs de logiciels qui doivent continuellement fournir de la valeur dans les délais les plus courts et les plus durables.

SAFe for Lean Enterprises tente de créer une entreprise Lean en fournissant une base de connaissances de principes, de compétences et de meilleures pratiques éprouvés.

SAFe 4.6 définit cinq compétences de base de l'entreprise Lean. Chaque compétence est un ensemble de connaissances, d'aptitudes et de comportements connexes qui, ensemble, permettent aux organisations d'exceller :

1. Leadership Lean-Agile : Décrit comment les dirigeants conduisent et soutiennent le changement organisationnel par l'apprentissage, l'enseignement et la mise en œuvre de l'état d'esprit Lean-Agile de SAFe.

2. Agilité d'équipe et technique : Décrit les compétences, les principes et les pratiques nécessaires pour créer des équipes agiles performantes.

3. DevOps et publication à la demande : décrit comment la mise en œuvre de DevOps et d'un pipeline de livraison continue permet aux organisations de publier des incréments de produit à tout moment pour répondre à la demande.

4. Solutions d'entreprise et ingénierie des systèmes allégés : Décrit comment appliquer les principes et pratiques lean-agiles à la spécification, au développement, au déploiement et à l'évolution d'applications logicielles volumineuses et complexes

5. Gestion de portefeuille Lean : aligne la stratégie et l'exécution en appliquant des approches de pensée lean et systémique à la stratégie et au financement des investissements, aux opérations de portefeuille agiles et à la gouvernance.

Chacune des compétences de base correspond directement à son niveau respectif dans le diagramme de processus SAFe, à l'exception du leadership Lean-Agile qui englobe l'ensemble du processus.

Compétence de leadership Lean-Agile

L'objectif principal de la compétence de leadership Lean-Agile est d'aider à transformer l'organisation en une entreprise Lean-Agile. Cela se fait en apprenant, en pratiquant et en enseignant l'état d'esprit, les valeurs, les principes et les pratiques Lean-Agile de SAFe.

Les valeurs fondamentales de SAFe guident la transformation vers l'entreprise lean. À chaque occasion, le comportement d'un leader joue un rôle essentiel dans sa promotion. Les valeurs fondamentales sont :

1. Alignement : Communiquer la mission, la stratégie du portefeuille et la vision de la solution. Organiser des séances d'information pertinentes et participer à la planification de l'incrémentation du programme (IP) et à la maintenance de l'arriéré.

2. Transparence : Visualisez tous les travaux pertinents.

3. Qualité intégrée : engagez- vous dans des pratiques visant à assurer la qualité tout au long du cycle de vie. Refuser d'accepter un travail de mauvaise qualité. Soutenir les investissements dans la maintenance et la réduction de la dette technique.

4. Exécution du programme : Participez en tant que propriétaires d'entreprise à l'exécution de PI et établissez la valeur commerciale. Assurez-vous que la portée est alignée sur la demande et la capacité. Supprimez agressivement les obstacles et les démotivateurs.

Les valeurs fondamentales de SAFe sont soutenues par l'adoption de l'état d'esprit Lean-Agile et l'application des principes SAFe :

1. Adopter une vision économique

2. Appliquer la pensée systémique

3. Supposer la variabilité ; conserver les options

4. Construire progressivement avec des cycles d'apprentissage rapides et intégrés

5. Basez les jalons sur une évaluation objective des systèmes de travail

6. Visualisez et limitez les en-cours, réduisez la taille des lots et gérez la longueur des files d'attente

   

7. Appliquer la cadence, synchroniser avec la planification inter-domaines

8. Libérez la motivation intrinsèque des travailleurs du savoir

9. Décentraliser la prise de décision

Ces principes sont similaires aux principes Lean et Agile. Enfin, la transformation de l'organisation est accomplie en suivant la feuille de route de mise en œuvre de SAFe.

Compétence d'équipe et d'agilité technique/Niveau d'équipe

La compétence Team and Technical Agility décrit les compétences, les principes et les pratiques nécessaires pour créer des équipes agiles hautement performantes qui créent des solutions de haute qualité. Deux caractéristiques clés sont essentielles :

• Agilité d'équipe : les équipes adoptent des pratiques et des principes Agiles, qui leur permettent de travailler, d'apprendre et de s'adapter à une cadence fiable

• Agilité technique : les équipes appliquent des pratiques techniques Agiles qui garantissent la qualité du code et des composants, et la maintenabilité du code qu'ils produisent\ La qualité est un axe majeur de la compétence équipe et agilité technique. Pour y parvenir, des techniques d'ingénierie agiles telles que le développement piloté par le comportement (BDD) et le développement piloté par les tests (TDD) sont appliquées pour augmenter la qualité et le flux. Un débit rapide dépend de la qualité du bâtiment dans tout le système, car les erreurs peuvent avoir un impact important sur le débit et retarder les versions.

Le niveau d'équipe du diagramme SAFe décrit le fonctionnement des équipes Agile individuelles. Toutes les équipes font partie de l'Agile Release Train qui travaille à la livraison d'un incrément de produit. La plupart des flux Agile/Scrum traditionnels s'appliquent, où les équipes travaillent par itérations pour fournir des systèmes fonctionnels. Les rôles de Scrum Master, de Product Owner et de membre d'équipe sont utilisés dans SAFe, tout comme la plupart des activités et artefacts Scrum. Les équipes sont également soutenues par des rôles au niveau du programme tels que la gestion des produits, l'architecte système et d'autres services partagés. Kanban est utilisé pour aider à visualiser le flux des fonctionnalités tout au long du cycle de vie de la livraison, ainsi que les interactions et les transferts entre les équipes.

DevOps et Release on Demand Compétence/Niveau de programme

Les compétences DevOps et Release on Demand décrivent comment "la mise en œuvre de DevOps et d'un pipeline de livraison continue offre à l'entreprise la capacité de libérer de la valeur, en tout ou en partie, à tout moment nécessaire pour répondre à la demande du marché et des clients".

DevOps s'efforce d'aligner le développement, les opérations, l'entreprise et d'autres domaines pour travailler ensemble afin d'obtenir des résultats commerciaux. Bien que toutes les organisations n'aient pas besoin de publier aussi souvent que certains des leaders de l'industrie du mouvement DevOps (Amazon publie toutes les quelques secondes), toutes les organisations doivent être en mesure de publier à la demande.

• DevOps fournit l'approche de la culture, de l'automatisation, du lean-flow, de la mesure et de la récupération (CALMR) qui permet une livraison continue et une publication à la demande

• Les trains de versions agiles (ART) sont des équipes d'équipes agiles qui sont organisées pour fournir de la valeur à la demande via un pipeline de livraison continue

Le niveau de programme du diagramme décrit les rôles et les activités nécessaires pour livrer en continu via un Agile Release Train (ART) . Ce niveau fonctionne de manière itérative similaire au niveau de l'équipe mais intègre plusieurs équipes agiles et comprend plus de cycles. L'ART est une équipe agile d'équipes composée de 5 à 12 équipes (50 à 125 personnes) comprenant les rôles agiles traditionnels ainsi que les rôles de programme critiques tels que Release Train Engineer (RTE) et Product Management. L'ART fournit des incréments de programme (PI) de 8 à 12 semaines qui sont planifiés via PI Planning et dirigés par un chef de produit .

La progression des fonctionnalités PI, des épopées, etc. est suivie et gérée via un tableau Program Kanban. Le RTE agit en tant que Scrum Master sur l'ART. Les réunions de synchronisation quotidiennes incluent les Daily Standups d'équipe, Scrum-of-Scrums (RTE & Scrum Masters), PO Sync (Product Management & Product Owners) et ART Sync (Scrum-of-Scrums et PO Sync ensemble). Chaque PI a une démo système et une rétrospective.

Compétence en solutions d'affaires et en ingénierie des systèmes allégés/niveau de grande solution

La compétence Business Solutions and Lean Systems Engineering décrit "comment appliquer les principes et pratiques Lean-Agile à la spécification, au développement, au déploiement et à l'évolution d'applications logicielles et de systèmes cyber-physiques complexes et de grande taille".

En plus des principes SAFe, l'application des 8 principes suivants lorsque vous travaillez sur de grandes solutions est essentielle à cette compétence :

Le niveau de solution large contient les rôles, les artefacts et les processus nécessaires pour créer des solutions volumineuses et complexes. Plusieurs ART travaillent ensemble sur des trains de solutions pour fournir des solutions . Les principaux objectifs sont de :

• Gérer l'intégration fréquente

• Répondre en permanence aux problèmes de conformité

• Architecte pour l'échelle, la modularité, la libérabilité et la facilité d'entretien

La gestion de la solution contrôle le contenu d'une solution et le Solution Train Engineer (STE) guide le travail. L'architecte de solution est responsable du maintien d'une bonne architecture pour tous les ART de la solution. La planification pré et post PI est utilisée pour planifier les solutions fournies via plusieurs incréments de programme. Un backlog de solution contient des capacités et des épopées de solution et est suivi via un tableau Solution Kanban

Compétence en gestion de portefeuille au niveau du portefeuille/lean

La compétence Lean Portfolio Management « aligne la stratégie et l'exécution en appliquant des approches Lean et de pensée systémique à la stratégie et au financement des investissements, aux opérations de portefeuille agiles et à la gouvernance ».

Le Lean Portfolio Management se concentre sur les domaines suivants :

1. Financement de la stratégie et des investissements : relie le portefeuille à la stratégie de l'entreprise, finance les flux de valeur et établit le flux du portefeuille

2. Opérations de portefeuille agiles : coordonne les flux de valeur, soutient l'exécution du programme et l'excellence opérationnelle

3. Gouvernance allégée : prévoit les budgets, mesure la performance du portefeuille et applique la conformité

Le niveau du portefeuille contient les principes, les pratiques et les rôles nécessaires pour initier et gouverner un ensemble de flux de valeur de développement. Un Portfolio Backlog contient des Business Epics et des Enabler Epics et est suivi via un tableau Portfolio Kanban*. **Lean Portfolio Management (LPM) décide des flux de valeur d'un portefeuille et inclut les plus hauts décideurs d'une entreprise. Un architecte d'entreprise guide le travail et coordonne les flux de valeur.

Moins

Le framework Scrum à grande échelle (LeSS) a été créé par Craig Larman et Bas Vodde, qui l'ont basé sur leur expérience dans les secteurs de la finance et des télécommunications. Comme son nom l'indique, LeSS encourage le moins de processus et de procédures possible pour que de nombreuses équipes Scrum travaillent ensemble. La mise à l'échelle est difficile parce que les gens la rendent complexe, donc l'objectif ici est de la rendre aussi simple que possible.

Principes et composants principaux

"LeSS est Scrum, appliqué à de nombreuses équipes, travaillant ensemble, sur un seul produit". LeSS est basé sur dix principes qui sembleront familiers à quiconque connaît les principes Lean-Agile :

1. Scrum à grande échelle est Scrum

2. Contrôle de processus empirique

3. Transparence

4. Plus avec moins

5. Focus sur l'ensemble du produit

6. Centrée sur le client

7. Amélioration continue vers la perfection

8. Pensée systémique

9. Pensée Lean

10. Théorie des files d'attente

LeSS n'a que deux rôles principaux, tous deux empruntés à Scrum :

1. Product owner : Travaille avec 2 à 8 équipes.
2. Scrum master : Travaille avec 1 à 3 équipes.

Toutes les équipes travaillent avec le même carnet de produit dans des sprints de 1 à 4 semaines. Les équipes travaillent en parallèle, c'est-à-dire qu'elles démarrent et terminent les sprints en même temps. A la fin du sprint, les équipes livrent collectivement un incrément produit . Il peut sembler presque impossible pour un propriétaire de produit de travailler avec 8 équipes. LeSS encourage le transfert de la responsabilité de la clarification des éléments du backlog produit vers les équipes. À leur tour, les équipes doivent être interfonctionnelles et contenir non seulement des compétences en matière de codage, de conception et de test, mais également des connaissances dans le domaine de l'entreprise. Plus important encore, les équipes doivent être habilitées à pouvoir atteindre les clients.

Planification des sprints

La planification est divisée en deux parties :

1. Planification de sprint 1 : où les représentants des équipes rencontrent le propriétaire du produit et décident des éléments du backlog qu'ils prendront en charge et discutent de toute coopération potentielle qui pourrait être nécessaire entre les équipes pendant le sprint.
2. Planification de sprint 2 : Comme dans Scrum traditionnel, chaque équipe se réunit séparément pour créer un plan sur la façon dont les éléments du backlog seront traités.

Raffinement du carnet de produit

Le raffinement du backlog produit (PBR) est effectué pendant le sprint pour préparer les éléments du backlog produit pour la planification du sprint. LeSS n'offre pas de règles sur la façon de faire le PBR et laisse aux entreprises le soin de déterminer elles-mêmes leur processus le plus efficace. Le PBR implique trois activités clés :

1. Fractionnement de gros articles.
2. Détailler les articles jusqu'à ce qu'ils soient prêts.
3. Estimation.

Fin de sprint

A la fin de chaque sprint, trois choses se produisent :

1. Revue de Sprint : Une démo de Sprint partagée, où les équipes et les clients explorent ce qui a été fait pendant le Sprint et ce qui doit être fait ensuite.
2. Rétrospective : Chaque équipe organise sa propre rétrospective pour améliorer son processus.
3. Rétrospective globale : les équipes, les propriétaires de produits et les scrum masters se réunissent pour inspecter et adapter les pratiques organisationnelles afin d'être plus efficaces.

Scrum@Scale

Scrum à l'échelle et Scrum@Scale sont utilisés de manière interchangeable. Cette méthodologie a été introduite par Jeff Sutherland en 2014, qui a créé la méthodologie Scrum et a été l'un des signataires du Manifeste Agile.

Scrum@Scale prend Scrum comme point de départ et offre un cadre simple et léger pour faire évoluer Scrum avec une « bureaucratie minimale viable ». Elle est moins prescriptive que les autres méthodologies agiles à l'échelle et peut être considérée comme un méta-framework. Il met en évidence les problèmes et les domaines de mise à l'échelle et offre un cadre mental sur la manière dont ils pourraient être résolus.

Principes et composants principaux

Scrum@Scale est un framework qui simplifie radicalement la mise à l'échelle en utilisant Scrum pour faire évoluer Scrum. Dans Scrum, le « quoi » (product owner) est clairement séparé du « comment » (scrum master). La même stratégie est utilisée dans Scrum@Scale afin que la juridiction et la responsabilité soient bien comprises, éliminant le gaspillage et les conflits.

Scrum@Scale contient deux cycles pour séparer clairement les juridictions : le cycle Scrum Master et le cycle Product Owner avec deux points de contact : Team Level Process et Product Release Feedback.

Cycle Scrum Master

Le cycle scrum master est responsable de la façon dont les choses identifiées par le cycle du propriétaire du produit seront construites. Dans Scrum@Scale, les équipes Scrum individuelles ont les mêmes rôles, artefacts, activités et cérémonies que Scrum traditionnel.

Les équipes Scrum sont regroupées dans un Scrum of Scrums (SoS) qui est conjointement responsable de la production d'un incrément de produit commun. Ils participent à la préparation et à la priorisation conjointes des arriérés, organisent des rétrospectives, maintiennent les arriérés d'obstacles et organisent une mêlée quotidienne à l'échelle (SDS) (format similaire à la mêlée quotidienne) pour coordonner les équipes et supprimer les obstacles. Le SDS est suivi par au moins un représentant (généralement le scrum master de l'équipe) de chacune des équipes participantes et est dirigé par le Scrum of Scrums master (SoSM) qui est responsable de la coordination avec les équipes scrum et les propriétaires de produit.

Si une mise à l'échelle supplémentaire est nécessaire, il existe une mêlée de mêlée de mêlées (SoSoS) créée à partir de plusieurs SoS qui se réuniraient également quotidiennement, et ainsi de suite. Le leader général est l' équipe d'action exécutive (EAT) qui est chargée de promouvoir Agile dans l'organisation, de coordonner les équipes Scrum selon les besoins et d'être le dernier arrêt pour éliminer les obstacles.

Cycle du propriétaire du produit

Le cycle Product Owner est responsable du produit ou du service qui sera créé et de toutes les activités nécessaires pour le soutenir. Les Product Owners sont affectés aux équipes Scrum et réalisent toutes les activités de leur rôle tel que défini dans Scrum. Les propriétaires de produits sont regroupés en équipes de propriétaires de produits qui correspondent aux équipes SoS. Les équipes de propriétaires de produits se réunissent quotidiennement lors d'un Meta Scrum pour discuter d'une stratégie de haut niveau pour les équipes et se coordonnent au besoin avec le SoSM correspondant et d'autres propriétaires de produits et parties prenantes. Les Meta Scrums sont dirigés par un Chief Product Owner (CPO) .

Les Product Owners évoluent de la même manière que le cycle Scrum Master, en fonction de la taille de l'organisation et se terminent par un Executive Meta Scrum (EMT) , qui est responsable de la définition des priorités à l'échelle de l'entreprise.

Implémenter Scrum@Scale

La mise en œuvre de Scrum@Scale commence par la création d'un modèle de référence évolutif, c'est-à-dire un petit ensemble d'équipes utilisant Scrum à petite échelle. Ceci est fait pour résoudre toutes les politiques organisationnelles et les pratiques de développement qui entravent l'agilité. Scrum@Scale suggère de les résoudre tôt car toutes les équipes sont susceptibles de faire face à ces problèmes à l'échelle de l'organisation et les frustrations qui en résultent pourraient entraver l'adoption de l'agilité. Le modèle de référence est ensuite utilisé comme modèle pour adapter Scrum à d'autres équipes et départements.

Une équipe d'action exécutive (EAT) doit être créée initialement pour mettre en œuvre le modèle de référence. EAT est composé d'individus qui sont politiquement et financièrement habilités au sein de l'organisation, car ils seront en mesure de mettre en œuvre les changements de politique organisationnelle.

Conclusion

Dans cette deuxième partie du plan de gestion de projet, nous avons couvert certains des frameworks les plus populaires utilisés sur des projets ou des programmes plus importants. La cascade est encore largement utilisée dans de nombreuses organisations, et bien qu'elle présente de nombreux inconvénients en raison de ses processus rigides, il est parfois judicieux d'utiliser ce cadre lorsque les projets sont petits et que la portée est bien définie et peu susceptible de changer.

Alors que les entreprises sont confrontées à des projets plus vastes et plus complexes avec des exigences ou des objectifs en constante évolution, elles se tournent vers des approches plus agiles. Comme Agile était à l'origine destiné à de petites équipes de 5 à 9 personnes, divers praticiens Agile ont proposé de multiples façons de faire évoluer Agile d'équipes uniques, à plusieurs équipes, à l'ensemble de l'entreprise. Dans cet article, nous avons couvert Disciplined Agile Delivery (DAD), Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS) et Scrum@Scale.

Dans la dernière partie du plan de gestion de projet, nous aborderons quelques cadres spécifiques à la gestion de projet tels que PMP (PMBOK) et PRINCE2. Nous passerons également en revue certains processus et cadres d'innovation tels que "jobs to be done" (JTBD) et "design thinking".