je viens de terminer la première partie de ce cours. J ai deux remarques sur celle-ci :
les videos présentent aux parties P1C3, P1C4 et P1C5 sont à 80% identiques. Ce qui les rends pas vraiment agréable à regarder (beaucoup de redite)
La seule et unique question de la partie 1 n accepte pas la transparence comme pilier... mais il est indiqué galement dans le commentaire de la solution qu’il le faut... mon résultats est donc à 0% malgré l’exactitude de ma réponse. 😫
Je vous remercie pour ces remarques et vous présente toutes mes excuses pour l'erreur d'enregistrement du quiz 1.
Nous allons remonter les vidéos de P1C3 et de P1C4 afin d'éviter les redites
Vous pouvez faire une demande de réinitialisation du quiz 1 à l'adresse : hello@openclassrooms.com
Nous sommes ravis de savoir que vous avez tout de même apprécié ce cours et je vous donne rendez-vous en octobre pour Maîtrisez un projet avec plusieurs équipes Scrum ! (ou dès aujourd'hui pour Initiez-vous à la gestion de projet agile).
je suis ce chapître 2 de la trilogie Scrum. Je me demandais si le product owner, pourrait être un utilisateur final. Ce que j'appelais un power-user.
Celui qui sera justement le pilote et "propriétaire" de l'application, une fois le projet terminé et qui porte le projet du coté utilisateur, et qui défend le budget de ce projet auprès du sponsor (le Daf en fait)
Sa disponibilité peut elle être d'une demi journée par semaine, par exemple ?
j'essaie de voir comment mes projet qui n'était pas agile, auraient pu l'être avec les mêmes moyens
Bonne année 2018 et merci pour l'attention portée à mes cours. #trilogie
Votre idée est tentante... mais je préconise de ne pas trop mélanger les différents rôles (effet double casquette) !
Le product owner a déjà des semaines de travail (ou d'itérations) bien remplies et il est préférable de miser sur ses compétences de gestionnaire du product backlog, de représentant du client, etc. Plutôt que de prendre le risque de lui donner une position de juge-arbitre !
L'utilisateur final a surtout la responsabilité de tester le produit/service en cours de conception ou de développement. Avec des moyens limités, vous trouverez toujours la possibilité de créer un groupe de testeurs motivés grâce aux réseaux sociaux (à moins de débuter dans le métier).
Merci et bravo pour vos cours d'un très bon niveau !
Une petite question concernant le point suivant: "Idéalement, votre équipe est agile et tous ses membres sont solidaires. Votre gestion de projet ne sera plus ralentie pas l'absence ou l'indisponibilité imprévue d'un des acteurs."
Je ne comprends pas comment l'agilité permet de suppléer l'absence d'une personne, surtout si elle a des compétences uniques dans l'équipe, ce qui est souvent le cas dans une petite équipe. Est-ce que j'ai mal compris ce que vous vouliez dire ?
Ce n'est pas simple ;-) C'est pourquoi la gestion de projet agile (bien ordonnée) nécessite une expertise importante de la conception jusqu'au développement ! Sans "chasse gardée", l'équipe peut toujours continuer à avancer malgré une absence ponctuelle (reprioriser ou replanifier le sprint, si nécessaire).
je remonte la suggestion d'Éric en début de thread:
les videos présentent aux parties P1C3, P1C4 et P1C5 sont à 80% identiques. Ce qui les rends pas vraiment agréable à regarder (beaucoup de redite)
Visiblement le remontage n'a pas été fait, ou alors ce n'est pas encore complétement suffisant car la dernière vidéo du chapitre est particulièrement ennuyeuse à cause des redites.
En plus d'être d'une légalité douteuse, je trouve ce conseil inadapté: tous les sprints vont souffrir d'innatendus, de jours en moins, de collaborateurs en vacances, etc. C'est justement le rôle du planning d'anticiper ces cas. Alors, certe, cela risque d'abimer le burndown chart mais franchement, est-ce bien agile de se retrouver bloqué par ses indicateurs?
Et puis, avoir des sprints qui termine le vendredi ça n'aurait pas tendance à inciter au deploy le vendredi soir par hasard?
A part ça, cours intéressant, notamment il me permet de consolider ma connaissance empirique de SCRUM en voyant le côté SCRUM master.
Je te remercie pour toutes l'attention portée à mes cours et te souhaite également une bonne année 2019.
"La facilité et la perfection s'obtiennent par la répétition" ;-) c'est pourquoi j'assume ces redites pédagogiques qui répondent bien aux attentes d'apprenant(e)s plus débutant(e)s, tandis que mes textes complètent aussi les connaissances des plus expert(e)s d'entre vous.
"... si possible" ;-) Il s'agit en effet d'un modèle d'origine américaine qui favorise une vélocité sans interruption pendant les sprints et que des entreprises innovantes appliquent plus ou moins légalement partout dans le monde actuellement. L'équipe agile reste seule responsable de ses conditions de travail.
C'est le rituel de sprint retrospective qui termine une itération (le vendredi, par exemple). L'intégration continue d'incréments doit être finalisée avant la sprint review (idéalement) !
Je reste à ta disposition pour tous renseignements supplémentaires.
La répétition... OK mais là j'avais surtout envie de zapper, au risque de perdre la partie intéressante. Le jeu d'acteur étant ce qu'il est de la part des employés de OpenClassRooms
En fait je crois que la bonne solution serait d'avoir chaque partie présentées indépendament et une ultime vidéo qui regroupe tout pour revoir la séquence entièrement pour ceux qui veulent. Cependantm je comprends le problème que cela impose puisue ça ne rentre pas dans votre patron de cours.
Concernant les jours feríés par contre, je vais être intransigeant. Rien ne justifie de les travailler dans un sprint standard. Il faudrait vraiment être dans un rush pour le justifier mais, honnêtement, je trouve que c'est un très mauvais conseil à donner à des chefs de projet / SCRUM master débutants et français (ou européens). Bien au contraire, le vrai conseil à donner c'est de s'organiser pour ne jamais être dans le rush.
A ce sujet, voir les études sur le crush dans le jeu vidéo et l'impact négatif qu'il a sur la qualité et la vélocité passé les 2 premières semaines. Toutes les entreprises de jeu vidéo qui ont supprimé le crush s'en porte beaucoup mieux.
OK pour le sprint review le vendredi avec le dernier déploiement le jeudi soir alors :). Cela dit, j'ai souvent travaillé avec des sprints qui finissent le mardi par exemple. Ca permet de se ressourcer le weekend et d'arriver frais pour terminer le sprint.
Je fais confiance à chaque apprenant(e)s pour adapter le rythme de travail à son propre contexte professionnel ;-) Mon équipe peut travailler les jours fériés, sans être dans le rush, mais simplement pour continuer à battre le fer pendant qu'il est encore chaud, puis prendre le temps de récupérer quand bon lui semble (si besoin, hé hé).
Je partage ton avis sur le cruNCh, notamment parce que les modèles agiles s’intéressent moins aux temps de travail (pointage journalier) qu'au calcul de la vélocité (story points gagnés lors d'une itération).
Du coup ce que je ne comprends pas c'est pourquoi travailler les jours feriés si c'est pour le récupérer plus tard. Sous format de RTT ça ne fait que repousser le problème (en pire car on empute un seul membre de l'équipe au lieu de fermer pour la journée), sous format congé payé, ça peut être une option un peu plus gérable mais le problème reste proche. En plus, cela demande à ce que tous les membres de l'équipe soient d'accord car si on en a que quelqu'uns présents, c'est le même problème qu'au-dessus.
Dans mon entreprise, je l'ai déjà fait plusieurs fois mais c'était souvent pour déplacer les jours et faire des ponts ou de longs weekends. Bref, ça n'amène rien pour Scrum, c'est plus du confort pour l'équipe.
Je verrais un intérêt si on fait une mission courte éventuellement. Genre récuper pendant un inter-contrat par exemple. Moi qui travaille toute l'année en SCRUM ça me laisse dubitatif.
En fait, ce qui me gène c'est vraiment le côté startup nation, flexiblité, forfait-jour, etc... qui sont les méthodes à la mode mais qui:
1 - sont souvent illégales (forfait jour voir le travail les jours fériés)
2 - sont souvent vicieusement négatives pour les employés (impossible de réellement refuser, pression du groupe, période d'essai, etc.).
Appelle moi old school (on se tutoie?) mais j'aime le code du travail et je pense que le premier respect de l'employé, avant de lui offrir des pizzas fridays et un baby-foot, c'est de respecter la loi. Notamment ça permet de passer ses jours de congé avec ses enfants et ses amis au lieu des les récuperer (si besoin????) un jour où tout le monde travaille.
C'est pour ça que je touve ça limite dans un cours d'initiation au SCRUM car, pour moi, ça devrait être exceptionnel et non pas une pratique courante.
Je travaille en effet principalement avec des startups comme facilitateur, et Scrum n'est pas l'unique modèle agile que nous appliquons pour développer ce type d'entreprise/projet. Le format congé payé et la rémunération supplémentaire des jours fériés (ou même la mise en place de vacances illimités, chez OpenClassrooms par exemple) forment tout un "arsenal légal" afin de garantir des sprints les plus homogènes et ininterrompus possible !
J'aime le code du travail autant que les pizzas et le baby-foot (si besoin, HÉ HÉ). Les membres d'une équipe agile peuvent également s'organiser de façon autonome : travailler le lundi, s'occuper des enfants le mercredi... le temps passé sur une tâche ou une user story m’intéresse bien moins que le respect de la qualité du travail à accomplir.
Le contexte des vidéos de mon cours d'initiation (compétences limitées, première collaboration, etc.) ne présente pas non plus une "pratique courante" et rien que pour continuer à faire réagir tous mes lecteurs, je pense conserver durablement cette petite phrase provocatrice.
je crois que c'est là que l'on divergent. Le contexte que tu décris est loin d'être un contexte général d'application de SCRUM (en France). Tous ces avantagent peuvent facilement se transformer en inconvénients et nécessitent un framework RH très avancé pour permettre de le faire en toute légalité.
Ce qui me fait peur, c'est le SCRUM master débutant qui va lire ce conseil au pied de la lettre pour le mettre en place dans une équipe classique chez Carrefour/SNCF/CapGémini où on fait les 35h/semaine sans prime pour les jours feriés. Ou dans une startup à la cool où le respect du code du travail est loin d'être une priorité (et là, gare aux prud'hommes).
Plus concrètement, je trouve que cette petite phrase provocatrice n'a pas trop sa place dans un cours d'introduction en ligne où la discussion avec le professeur est loin d'être la norme. Pour un comme moi qui vient en débatre sur le forum (d'ailleurs merci de me faire la gentillesse de répondre), combien vont croire que c'est une pratique de base de SCRUM sans la remettre en question?
Un scrum master débutant aura très peu de chance de travailler dans ton contexte général d'application de SCRUM (en France). Les "framework RH" ont également tout intérêt à comprendre l'importance d'une estimation collective de la complexité (planning poker) et d'un calcul empirique de la vélocité (burndown chart) en plus du cadre légal à respecter.
En gestion de projet agile, seul le périmètre (qualité) du produit ou du service est véritablement variable. Je laisse donc à la gestion de projet en cascade prédire les deux autres impératifs restants (coût et délais) :
La discussion avec les apprenant(e)s est pour moi une norme et je reste toujours disponible/réactif sur ce forum, Workplace, LinkedIn et par courriel ou téléphone (si besoin, hé hé). Croire sans se poser de questions, ne fera jamais un bon facilitateur agile ;-)
Je te remercie pour toute l'attention portée à mon cours et à mon expertise.
Avant d'importer le modèle Scrum à ton projet universitaire, tu peux également suivre mon cours d'initiation à la gestion empirique de projet informatique (conception centrée sur l'utilisateur comme préalable incontournable avant tout développement agile). La formulation, l'évaluation et l'estimation des récits utilisateurs (user stories) dans le carnet du produit (product backog) sont bien précisées : https://openclassrooms.com/fr/courses/4507926-initiez-vous-a-la-gestion-de-projet-agile
Je n'ai pas bien compris l'élément de correction suivant : "Cela constitue une file d’attente beaucoup trop longue, car il faudra attendre 10 sprints pour embarquer une nouvelle User Story.".
Faudrait il 8 sprints ? 4 sprints ?
J'ai bien lu la notion du "juste à temps". Mais si des User Stories sont connues dès le début, que doit en faire le Product Owner s'il ne les met pas dans le Product Backlog ?
La métaphore du scrum (la « mêlée du rugby ») apparaît pour la première fois en 1986 dans une publication de Hirotaka Takeuchi et Ikujiro Nonaka, intitulée The New New Product Development Game, qui s'appliquait à l'époque au monde industriel.
Ils y décrivent, sous le nom de rugby approach (« méthode du rugby »), une nouvelle méthode holistique qui augmente vitesse et flexibilité dans le développement de nouveaux produits logiciels1.
L'ensemble du développement est réalisé itérativement par une équipe multidisciplinaire en passant par différentes phases 2 et que les phases et itérations peuvent se chevaucher fortement 3.
Ils ont comparé cette nouvelle méthode au rugby à XV, sport où les membres de l'équipe en bloc tentent d'aller jusqu'à la ligne d'en-but, en se passant et repassant le ballon4.
Allez les Bleus !
- Edité par kribonono 24 novembre 2021 à 18:55:08
https://www.linkedin.com/in/arnaudlissajoux
Gérez votre projet avec une équipe Scrum
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
https://www.linkedin.com/in/arnaudlissajoux
https://www.linkedin.com/in/arnaudlissajoux
https://www.linkedin.com/in/arnaudlissajoux
https://www.linkedin.com/in/arnaudlissajoux
https://www.linkedin.com/in/arnaudlissajoux
https://www.linkedin.com/in/arnaudlissajoux
https://www.linkedin.com/in/arnaudlissajoux
https://www.linkedin.com/in/arnaudlissajoux
https://www.linkedin.com/in/arnaudlissajoux
https://www.linkedin.com/in/arnaudlissajoux
https://www.linkedin.com/in/arnaudlissajoux
https://www.linkedin.com/in/arnaudlissajoux
https://www.linkedin.com/in/arnaudlissajoux
https://www.linkedin.com/in/arnaudlissajoux