Wondershare EdrawMind
EdrawMindRevue PMP-agile
Galerie de cartes mentales Revue PMP-agile
- 2
Revue PMP-agile
Les connaissances et les points de test liés au développement agile sont compilés avant l'examen PMP. Le contenu comprend la sélection du cycle de vie du projet, le Manifeste Agile, les douze principes, le cadre Scrum, d'autres concepts agiles et l'examen de l'agilité selon 10 domaines de connaissances majeurs.
Modifié à 2023-05-18 23:36:51- Breve storia del tempo
Questa è una mappa mentale su una breve storia del tempo. "Una breve storia del tempo" è un'opera scientifica popolare con un'influenza di vasta portata. Non solo introduce i concetti di base della cosmologia e della relatività, ma discute anche dei buchi neri e dell'espansione dell'universo. questioni scientifiche all’avanguardia come l’inflazione e la teoria delle stringhe.
- Il coraggio di essere odiato
Dopo aver letto "Il coraggio di essere antipatico", "Il coraggio di essere antipatico" è un libro filosofico che vale la pena leggere. Può aiutare le persone a comprendere meglio se stesse, a comprendere gli altri e a trovare modi per ottenere la vera felicità.
- Appunti di lettura di Il coraggio di non piacere.
"Il coraggio di essere antipatico" non solo analizza le cause profonde di vari problemi nella vita, ma fornisce anche contromisure corrispondenti per aiutare i lettori a comprendere meglio se stessi e le relazioni interpersonali e come applicare la teoria psicologica di Adler nella vita quotidiana.
Revue PMP-agile
- Breve storia del tempo
Questa è una mappa mentale su una breve storia del tempo. "Una breve storia del tempo" è un'opera scientifica popolare con un'influenza di vasta portata. Non solo introduce i concetti di base della cosmologia e della relatività, ma discute anche dei buchi neri e dell'espansione dell'universo. questioni scientifiche all’avanguardia come l’inflazione e la teoria delle stringhe.
- Il coraggio di essere odiato
Dopo aver letto "Il coraggio di essere antipatico", "Il coraggio di essere antipatico" è un libro filosofico che vale la pena leggere. Può aiutare le persone a comprendere meglio se stesse, a comprendere gli altri e a trovare modi per ottenere la vera felicità.
- Appunti di lettura di Il coraggio di non piacere.
"Il coraggio di essere antipatico" non solo analizza le cause profonde di vari problemi nella vita, ma fornisce anche contromisure corrispondenti per aiutare i lettori a comprendere meglio se stessi e le relazioni interpersonali e come applicare la teoria psicologica di Adler nella vita quotidiana.
- Recommandé pour vous
- Contour
Révision agile PMP
Options du cycle de vie du projet
Prédictif
Projets traditionnels, secteurs matures : tels que la construction, l'industrie manufacturière, l'industrie informatique
Agile
Répéter
Incrément
Hybride
L’entreprise passe du prédictif à l’agile
Les prévisions vers les projets agiles sont en partie prévisionnelles et en partie agiles
Prédiction ou agilité, utiliser la réponse à la question comme direction de choix
Utilisez des mots-clés comme questions pour faire la distinction entre agile et prédictif
Changement organisationnel : du prédictif à l'agile
Analyser et évaluer d’abord la culture de l’entreprise et l’impact de la transformation sur l’entreprise
Apporter des changements de haut en bas, en impliquant des personnes à tous les niveaux de l'entreprise pour comprendre les avantages et les impératifs du changement
Vous pouvez choisir un projet moins complexe comme projet pilote pour obtenir un succès rapide et apporter de la confiance aux autres projets.
Manifeste Agile
personnel
Les interactions individuelles l’emportent sur les processus et les outils
La collaboration client l'emporte sur la négociation contractuelle
livraison de valeur
Les logiciels utilisables l'emportent sur les archives complètes
Mieux vaut faire face au changement que suivre un plan
douze principes
livraison de valeur
Notre objectif le plus important est de satisfaire nos clients grâce à une livraison rapide et cohérente de logiciels de valeur.
Soyez prêt à faire face à des changements d’exigences, même tard dans le développement. Les processus agiles contrôlent le changement pour l’avantage concurrentiel des clients
Livrer des logiciels fonctionnels fréquemment, à quelques semaines ou à un mois ou deux d'intervalle, en privilégiant des cycles plus courts
Un logiciel fonctionnel est la principale mesure du progrès
personnel
Les hommes d'affaires et les développeurs doivent collaborer les uns avec les autres, chaque jour du projet
Stimuler la combativité des individus et construire des projets autour d’eux. Fournir l’environnement et le soutien nécessaires, soutenus par la confiance, pour atteindre les objectifs
Que ce soit à l’intérieur ou à l’extérieur de l’équipe, le moyen le meilleur et le plus efficace de transmettre des informations passe par les conversations en face à face.
Les processus agiles favorisent le développement durable. Propriétaires, développeurs et utilisateurs doivent pouvoir travailler ensemble pour maintenir un rythme constant et continu.
Les meilleures architectures, exigences et conceptions proviennent de l'équipe organisationnelle
L'équipe réfléchit régulièrement à la manière dont elle peut améliorer ses performances et ajuste son comportement en conséquence.
processus
Les capacités agiles sont renforcées par une recherche incessante de l’excellence technique et d’une bonne conception
Dette technique et refactoring
Basé sur la simplicité, c'est l'art de minimiser la charge de travail inutile
Cadre Scrum
cadre global
cadre global
Vision produit et feuille de route produit
Combien de versions sont nécessaires pour obtenir le produit final ?
plan de sortie
1 version détermine le nombre d'itérations ou de sprints pour une version
planification des sprints
Points principaux
Charte de projet agile
Pourquoi faisons-nous ce projet ?
Vision du projet
qui en bénéficiera
Cela peut faire partie de la vision et/ou des objectifs du projet.
Pour ce projet, quelles conditions sont réunies pour que le projet soit réalisé ?
Normes de publication du projet
comment nous allons coopérer
Flux de travail attendu
Charte d'équipe (Contrat social d'équipe)
valeurs de l'équipe
Tels que la vitesse du développement durable et les horaires de travail de base
accord de travail
Par exemple, comment est définie la « préparation », qui est la condition préalable pour que l'équipe accepte le travail ;
Par exemple, comment définir « terminé » afin que l'équipe puisse systématiquement juger de l'exhaustivité ;
Pensez au timeboxing
Utiliser des restrictions de processus de travail
règles de base
Par exemple, les règles concernant une personne qui prend la parole lors d'une réunion
normes de l'équipe
Par exemple, comment les équipes gèrent le temps de réunion
3355
3 personnages
propriétaire du produit
équipe de développement
Maître Scrum
3 artefacts
Carnet de produit
Carnet de sprints
incrément de produit
5 événements
Sprint
Réunion de planification de sprint
Réunion debout quotidienne
Réunion de revue de sprint
Réunion rétrospective Sprint
5 valeurs
promesse
se concentrer
ouvrir
respect
courage
3 personnages
PO du propriétaire du produit (Représentant client, expert métier)
Maintenir et mettre à jour le backlog produit
Le Product Owner est la seule personne responsable de la gestion du Product Backlog
Maintenir le backlog produit et prioriser
Clairement décrit et exprimé afin que l'équipe puisse pleinement comprendre le Product Backlog
Déterminer et approuver si l'incrément de produit est terminé
Déterminer si l'incrément de produit est terminé et répond à la définition d'achèvement du DOD
Centres de test fréquemment visités
Le PO doit être à temps plein et indépendant et ne peut être occupé simultanément par l'équipe de développement ou SM.
Que dois-je faire si de nouvelles exigences changent pendant le conflit ?
De manière générale, les nouvelles exigences sont désormais sur la table du PB et sont priorisées par le PO. Cette exigence n'est généralement pas réalisée dans ce sprint.
La question met l'accent sur les exigences légales et réglementaires et les exigences extrêmement prioritaires. Si elle n'est pas complétée immédiatement, cela entraînera l'échec du projet. Dans ce cas, le PO doit généralement communiquer avec l'équipe et réajuster les objectifs de ce sprint pour que l'achèvement soit rapide. le plus tôt possible est lié aux besoins de vie ou de mort du projet.
équipe de développement
équipe auto-organisée
Une spécialité, des compétences multiples, une équipe interfonctionnelle
Les membres de l'équipe de développement ne sont pas reconnus par leurs titres, ils restent des développeurs quel que soit le type de travail qu'ils effectuent.
Il est préférable d’être engagé à 100 %, de former une équipe à temps plein et de surmonter les silos organisationnels.
suivre le soleil
Points de test communs
S'il y a des exigences, des ordres ou obliger l'équipe à faire des choses dans la question, ils seront directement éliminés.
L'équipe de développement décide et est responsable de l'estimation des user stories, de l'attribution du travail, etc.
Maître Scrum Aussi connu comme coach agile, facilitateur d'équipe, Scrum Master, Chef de projet
Veiller à ce que toute l'équipe agile et les parties concernées suivent les théories, les pratiques et les règles de Scrum.
Pour le bon de commande
Assurez-vous qu'il comprend les responsabilités professionnelles du PO, y compris comment maintenir et mettre à jour le tableau PB.
Pour l'équipe de développement
S'assurer qu'il peut suivre les événements agiles quotidiens, comme les stand-up meetings quotidiens, et utiliser des outils transparents, etc.
Pour l'extérieur du projet
Assurez-vous de comprendre les pratiques agiles. Par exemple, si vous avez besoin de comprendre les progrès, vous pouvez consulter la source d'émission d'informations. Si vous avez besoin de comprendre la priorité des user stories, vous pouvez communiquer avec le PO, etc.
Leadership serviteur, leadership serviteur, se concentrant sur la croissance de l'équipe et aidant l'équipe à éliminer les obstacles
barrières internes
Lorsque l’équipe de développement rencontre des problèmes techniques, de processus ou autres, elle aide à les résoudre plutôt que de les résoudre elle-même.
obstacles extérieurs
SM négocie et communique avec des parties externes
Points de test communs
Dans un environnement agile, SM n'est pas responsable de l'attribution spécifique du travail, des modalités de travail, etc.
Généralement, SM est chargé d’éliminer certains facteurs externes et obstacles qui interfèrent avec l’équipe.
3 artefacts
Carnet de produit Carnet de produit
Histoires d'utilisateurs
concept
En tant que <rôle>, je veux une <fonctionnalité> pour que <valeur> puisse être atteinte
Principe INVESTIR
Indépendant
Négociable
Précieux
Estimable (évaluable)
Petit
Testable
point d'histoire
Comme standard de référence interne, utilisé au sein de l’équipe. Comparer le nombre de story points entre différentes équipes n'a aucun sens
Estimer les points de la user story
Planification Poker (Broadband Delphi)
Avantages de l'utilisation du poker d'estimation agile
Promouvoir la communication entre les membres de l’équipe pour partager et apprendre plus d’informations
La discussion et l'évaluation par l'équipe des résultats de l'estimation rendront les résultats de l'estimation plus réels et objectifs et éviteront de nombreuses décisions trop arbitraires.
S'applique à une user story spécifique ou à toutes les user stories utilisées dans une itération
Estimation d'affinité
S'applique à l'ensemble du tableau PB, estimation globale approximative
Contient du contenu
Répertoriez toutes les fonctionnalités, fonctions, exigences, améliorations et correctifs qui modifieront le produit pour les versions futures
Selon une séquence de priorités allant de élevée à faible, valeur élevée et risque élevé > valeur élevée et risque faible > valeur faible et risque faible
Les éléments du Product Backlog les mieux classés sont plus clairs, plus spécifiques, conformes au DOR et nécessitent un développement immédiat.
Mises à jour dynamiques continues, détails progressifs
Le propriétaire du produit est responsable de
Carnet de sprint Carnet de sprint
Déplacez les user stories hautement prioritaires de la liste PB vers le Sprint Backlog Dans ce sprint, l'équipe décide du nombre de user stories à réaliser et l'équipe affine les user stories.
sondage/sondage
Principalement pour obtenir des connaissances de base afin de savoir si une certaine exigence est techniquement réalisable ou non. Cette méthode est généralement utilisée lorsque les user stories ne peuvent pas être estimées efficacement.
Inclure au moins une amélioration de processus hautement prioritaire identifiée lors d'une réunion rétrospective précédente
L'équipe de développement est responsable et le PO est chargé de répondre aux questions.
Incrément de produit Incrément de produit
Atteindre la définition du DOD standard « terminé »
Le propriétaire du produit décide s'il est terminé ou non. Qu'il soit publié ou non, l'incrément doit être disponible et intégré en permanence.
5 événements
Sprint
Traduit par « sprint » ou « itération »
Durée 2-4 semaines (box horaire fixe), 5-9 personnes
Précautions
Impossible d'apporter des modifications préjudiciables à l'objectif de sprint
Des objectifs qui ne peuvent pas compromettre la qualité
Seul le propriétaire du produit a le pouvoir d'annuler les sprints. Comme les sprints sont très courts, l'annulation n'a que peu d'importance.
Réunion de planification de sprint
faire un plan
Que devrait être inclus dans l’incrément délivré lors du prochain Sprint ?
Comment effectuer le travail requis pour livrer l'incrément
Précautions
C'est à l'équipe de développement de décider combien d'éléments du backlog de produit choisir.
Le Product Owner peut aider à expliquer les user stories sélectionnées et à faire des compromis
Participants
Généralement, SM, l'équipe de développement et PO participent conjointement, et des parties prenantes importantes peuvent également être invitées à participer.
Réunion debout quotidienne
Contenu de la conférence
hier
Ce que j'ai fait pour aider l'équipe de développement à atteindre l'objectif de sprint
aujourd'hui
Que vais-je faire pour aider l'équipe de développement à atteindre son objectif de sprint ?
Y a-t-il des obstacles qui m'empêchent, moi ou l'équipe de développement, d'atteindre l'objectif de sprint ?
Après la réunion, mettre à jour les informations sur les sources d'émission (tableaux, burndown charts, gaz, etc.) et les tableaux de problèmes
Précautions
Enregistrez uniquement les problèmes au lieu d'en discuter. Après la réunion, un personnel dédié peut organiser une réunion de résolution de problèmes.
Le SM doit avoir lieu au même moment et au même endroit. Il est généralement recommandé que les membres de l'équipe l'hébergent. La durée est généralement de 15 minutes.
Points de test communs
Les réunions debout quotidiennes peuvent suivre immédiatement les progrès et apporter des corrections
Les réunions debout quotidiennes peuvent empêcher que le même travail soit répété par différents membres
Capacité à détecter les problèmes et les risques en temps opportun et à apporter des améliorations en temps opportun après la réunion pour minimiser l'impact des risques sur le projet
Participants
Équipe de développement (SM, PO, parties prenantes importantes, le cas échéant)
Réunion SOS (Scrum of Scrums)
Réunion de revue de sprint
Examinez les incréments de produits et obtenez des commentaires
L'équipe de développement démontre l'incrément de produit, le bon de commande invite les parties prenantes à participer et le bon de commande détermine si l'incrément de produit est terminé.
Ajuster le backlog produit
Articuler les éléments du backlog produit susceptibles de figurer dans le prochain sprint
Le résultat de la réunion de revue de sprint est un backlog produit révisé.
Participants
client
fêtes importantes
PO
SM
équipe de développement
Réunion rétrospective Sprint Réunion rétrospective
Revoir ce qui a été bien fait, ce qui doit être amélioré et faire un suivi lors du prochain Sprint (amélioration continue)
Participants
SM
équipe de développement
Bon de commande (sous réserve de disponibilité)
5 valeurs
promesse
Volonté de s'engager sur des objectifs
se concentrer
Mettez votre esprit et vos capacités dans le travail pour lequel vous vous êtes engagé
ouvrir
Scrum rend tout le projet ouvert à tous
respect
Chacun a son parcours et son expérience uniques
courage
Avoir le courage de faire des promesses, de les tenir et d'accepter le respect des autres
Autres concepts agiles
Gestion Kanban
Flux de travail visuel
Un tableau blanc et quelques cartes peuvent créer
Éliminer les goulots d'étranglement
Restrictions WIP (Work In Progress) sur les travaux en cours
Points de test communs
La question mentionnait que le flux de travail du projet était chaotique, ce qui entraînait le blocage de certains processus. La gestion Kanban pouvait résoudre efficacement ce problème.
La question mentionne que d'autres processus ou procédures se déroulent très bien, mais qu'un seul processus rencontre un goulot d'étranglement, entraînant un retard dans la progression de l'ensemble du processus. Vous pouvez envisager d'affecter des membres de l'équipe interfonctionnelle d'autres processus à l'ensemble du processus de goulot d'étranglement.
MVP (produit minimum viable)
Créez rapidement un ensemble minimal de fonctionnalités qui répondent aux fonctionnalités attendues du produit, contiennent suffisamment de fonctionnalités pour répondre aux exigences de déploiement du produit et valident les hypothèses clés concernant l'interaction du client avec le produit.
Expérimentez avec le moins de ressources et le moins de temps possible pour obtenir les commentaires des premiers utilisateurs
Points de test communs
Si les clients ne peuvent pas déterminer clairement leurs besoins, ils peuvent créer un prototype de produit préliminaire et finalement répondre à leurs besoins grâce à des commentaires et des corrections ultérieurs.
Lorsque le marché est incertain ou que les risques sont élevés, utilisez des expériences de conception MVP pour tester rapidement si votre produit ou votre orientation est réalisable.
Regard sur l'agile selon les 10 grands domaines de connaissances
Intégrer
Déléguer le contrôle de la planification et de la livraison de produits spécifiques à l’équipe. Les membres de l’équipe décident comment planifier et intégrer
L'objectif du chef de projet est de créer un environnement de prise de décision collaborative et de garantir la capacité de l'équipe à répondre aux changements.
Il n'y a pas de processus de contrôle du changement en Agile. Agile consiste à accepter le changement.
portée
Les méthodes agiles créent et examinent délibérément des prototypes et clarifient les exigences à travers plusieurs versions. Ainsi, le périmètre est défini et redéfini tout au long du projet
Définir le périmètre avant chaque sprint
Réunion de planification de sprint et backlog de sprint
Confirmer la portée avant la fin de chaque sprint
Examen de la réunion de revue de sprint et approbation de l'incrément de produit
calendrier
La relation entre la vision du produit, la planification des versions et la planification des itérations
Calendrier itératif avec des éléments inachevés
Il s’agit d’une planification glissante basée sur le cycle de vie adaptatif. Cette approche nécessite que les exigences soient documentées dans les user stories, puis que les user stories soient hiérarchisées et affinées avant d'être construites, et enfin que les fonctionnalités du produit soient développées dans un délai défini. Cette approche est généralement utilisée pour apporter une valeur incrémentielle aux interactions avec les clients, ou pour que plusieurs équipes développent en parallèle un grand nombre de fonctionnalités moins interconnectées.
horaire à la demande
Généralement utilisé dans les systèmes Kanban, basé sur la théorie des contraintes et le concept de pull scheduling issu de la production Lean, pour limiter le travail effectué par l'équipe en fonction de sa capacité à livrer. L'approche de planification à la demande ne s'appuie pas sur des calendriers préalablement spécifiés pour le développement ou les incréments de produits, mais s'appuie plutôt sur les éléments du backlog et les séquences de travail à mesure que les ressources deviennent disponibles.
Contrôler les outils de progression
Source d'émission d'informations
Tableau de combustion
Tableau d'allumage
coût
Utiliser des méthodes d'estimation légères
Les estimations détaillées conviennent à la planification à court terme en utilisant le juste à temps
qualité
Planifier la gestion de la qualité
Définition de DOD
Gérer et contrôler la qualité
Revue du cycle, vérifier régulièrement l'efficacité du processus qualité, trouver les causes profondes des problèmes et mettre en œuvre de nouvelles méthodes d'amélioration de la qualité
Concentrez-vous sur les petits lots et pouvez livrer fréquemment
Développement piloté par les tests (TDD), intégration continue
Ressource
Bénéficiez de structures d'équipe qui maximisent la concentration et la collaboration, telles que des équipes auto-organisées avec des généralistes
communiquer
Essayez de simplifier les canaux permettant aux membres de l'équipe d'obtenir des informations, d'effectuer des contrôles fréquents de l'équipe et de permettre aux membres de l'équipe de travailler ensemble.
Bureau centralisé
Travail quotidien : stand-up meeting quotidien
Les artefacts du projet doivent être publiés de manière transparente et les parties prenantes doivent être régulièrement invitées à examiner les artefacts du projet.
Travail quotidien : sources d'émissions d'informations
Reporting et communication : réunion de revue de sprint
équipe virtuelle
fenêtre d'aquarium
Établir un lien de vidéoconférence à long terme
appairage à distance
Partagez votre écran en utilisant des outils de réunion virtuelle, notamment des liens vocaux et vidéo
risque
Les risques doivent être pris en compte lors de la planification des itérations
Les risques doivent être identifiés, analysés et gérés au cours des itérations
Les documents d'exigences doivent être mis à jour régulièrement sur la base d'une meilleure compréhension des expositions aux risques actuelles et les travaux doivent être redéfinis à mesure que le projet progresse.
achat
Peut nécessiter une collaboration avec des vendeurs spécifiques pour élargir l’équipe. Cette relation de collaboration crée un modèle d'approvisionnement à risques partagés dans lequel les acheteurs et les vendeurs partagent les risques et les récompenses du projet.
accord flexible
structure multicouche
accord-cadre
Accord complémentaire
parties intéressées
Promouvoir un haut degré de transparence
Par exemple, inviter toutes les parties concernées à participer aux réunions et aux examens du projet, ou publier des artefacts du projet dans un espace public, dans le but de faire apparaître le plus rapidement possible les incohérences et les dépendances entre les parties, ou d'autres problèmes liés à un projet en constante évolution. .
Les projets très changeants nécessitent une interaction et une participation efficaces de la part des parties prenantes du projet. Pour permettre des discussions et des décisions opportunes et hilarantes, les équipes adaptatives interagissent directement avec les parties prenantes plutôt que de passer par plusieurs niveaux de gestion.