Merci pour cette video intéressante et consistante. Juste un point, le client peut envisager une méthode AGILE pour avoir un rendu régulier, plutôt qu'un cycle en V qui favorise l'effet tunnel amenant potentiellement à un décalage avec les attendus en fin de projet. Mais attention aux clients ambigus (il y en a ) qui n'auront pas compris (voulu comprendre) que le backlog pourrait ne pas être entièrement exécuté par manque de moyen (d'où la priorisation et l'évaluation des tâches en fonction aussi des capacités de l'équipe Réa) ou de temps, l'enveloppe financière étant mal ficelée car orientée forfaitaire (cycle en V) sur un ensemble de fonctionnalités (backlog complet) et non par sprint. Le client (product owner) doit avoir digéré la méthode AGILE avant de se lancer dans la démarche en pensant qu"elle nécessite moins de rigueur et d'implication de sa part dans la définition du besoin. Au niveau du management de projet et de la vente, il faut un IC qui tienne la route et qui sache éduquer son client.
Donc avec SCRUM en début de projet on ne saurait dire au client combien va lui coûter le produit finale approximativement comme cela se fait avec la démarche classique ?
Bonjour, merci pour votre réponse, mais ce que je comprend pas si j ai besoin dans un projet de créer une base de données, donc si je modélise dans chaque sprint une partie cela peut contribuer à la redondance des donnes n 'est ce pas?
Je voudrais savoir est ce que la phase de conception du projet :modélisation est absente? parce que souvent on parle que de la planification et réalisation, si oui comment concevoir ?avec merise ou uml?, et la conception de tous le projet ou bien juste partie d' itérations?
Lors d'une phase de conception dans un projet Classique, vous pouvez tout à fait simuler des écrans, des maquettes, qui permettront d'avoir des retours immédiats de votre client ; et cela, sans engager un centime de développement. J'ai l'impression que les méthodes "agiles" viennent palier un défaut de compétence "en rédaction/conception du besoin". L'équipe ne possède pas "l'architecte qui sait dessiner le besoin du client". Ils sont obligés de "faire en réel" pour que le client puisse VOIR ce qu'il va avoir ; autant dire que ce n'est pas du tout optimisé. Cela est facilement le cas lorsque l'équipe n'est composée que de développeur (désolé pour le préjugé du développeur renfermé sur lui-même) et qu'il n'y a pas de profils MOA qui disposent d'un minimum de relationnel pour vraiment comprendre le monde du client ET rester en contact avec lui au cours du projet. Comme par hasard, l'équipe SCRUM classique est composé de développeurs, "d'un chef de projet", d'un client... et pas de MOA. Plus drôle : l'un des principes majeur de l'agilité est : "Un logiciel qui fonctionne plus qu’une documentation exhaustive.", autant dire que ces gens là ont des vrais problèmes avec la rédaction ; et je ne souhaite à personne de maintenir un logiciel sans documentation, cela créé à terme des logiciels où chaque bug/évolution coûte une fortune (car personne ne sait exactement comment ça fonctionne, car le développeur et le client initial ont déjà changé de poste...)
10 minutes de très grande clarté ! Merci pour cette vidéo et cette synthèse parfaite 👍
Avec grand plaisir!
Merci beaucoup pour cette présentation si précise et utile.
Très pédagogique
Merci beaucoup! Très instructif.
Je ne connaissais pas cette méthode, contenu et rythme intéressant, donne envie d'en savoir plus. merci.
Merci Mr votre Schéma m’aide bcp
Schéma qui paraît complexe à première vue, mais l'explication est parfait pour bien comprendre. Merci.
merci pour cette vidéo elle est très utile et l'explication est très claire
Excellente démonstration de SCRUM
Merci bien expliqué de façon terre à terre
Merci pour cet exposé, très bien détaillé.
Ce franglais de qualité !
Merci pour cette video intéressante et consistante. Juste un point, le client peut envisager une méthode AGILE pour avoir un rendu régulier, plutôt qu'un cycle en V qui favorise l'effet tunnel amenant potentiellement à un décalage avec les attendus en fin de projet. Mais attention aux clients ambigus (il y en a ) qui n'auront pas compris (voulu comprendre) que le backlog pourrait ne pas être entièrement exécuté par manque de moyen (d'où la priorisation et l'évaluation des tâches en fonction aussi des capacités de l'équipe Réa) ou de temps, l'enveloppe financière étant mal ficelée car orientée forfaitaire (cycle en V) sur un ensemble de fonctionnalités (backlog complet) et non par sprint. Le client (product owner) doit avoir digéré la méthode AGILE avant de se lancer dans la démarche en pensant qu"elle nécessite moins de rigueur et d'implication de sa part dans la définition du besoin. Au niveau du management de projet et de la vente, il faut un IC qui tienne la route et qui sache éduquer son client.
Très bien expliqué
Merci pour cette présentation très détaillée.
merci, bien expliqué
Clairement et bien expliqué, Merci Monsieur.
Merci pour cette instructive vidéo.
Merci pour cette belle présentation
Donc avec SCRUM en début de projet on ne saurait dire au client combien va lui coûter le produit finale approximativement comme cela se fait avec la démarche classique ?
شرح رائع 😍
concis et clair , merci pour votre explication
excellente présentation merci!
Très bonne introduction.
très bien expliqué
Merci
Bonjour, merci pour votre réponse, mais ce que je comprend pas si j ai besoin dans un projet de créer une base de données, donc si je modélise dans chaque sprint une partie cela peut contribuer à la redondance des donnes n 'est ce pas?
Je voudrais savoir est ce que la phase de conception du projet :modélisation est absente? parce que souvent on parle que de la planification et réalisation, si oui comment concevoir ?avec merise ou uml?, et la conception de tous le projet ou bien juste partie d' itérations?
C'est très utile, merci!
Merci beaucoup
Merci beaucoup !
Lors d'une phase de conception dans un projet Classique, vous pouvez tout à fait simuler des écrans, des maquettes, qui permettront d'avoir des retours immédiats de votre client ; et cela, sans engager un centime de développement.
J'ai l'impression que les méthodes "agiles" viennent palier un défaut de compétence "en rédaction/conception du besoin". L'équipe ne possède pas "l'architecte qui sait dessiner le besoin du client". Ils sont obligés de "faire en réel" pour que le client puisse VOIR ce qu'il va avoir ; autant dire que ce n'est pas du tout optimisé.
Cela est facilement le cas lorsque l'équipe n'est composée que de développeur (désolé pour le préjugé du développeur renfermé sur lui-même) et qu'il n'y a pas de profils MOA qui disposent d'un minimum de relationnel pour vraiment comprendre le monde du client ET rester en contact avec lui au cours du projet.
Comme par hasard, l'équipe SCRUM classique est composé de développeurs, "d'un chef de projet", d'un client... et pas de MOA. Plus drôle : l'un des principes majeur de l'agilité est : "Un logiciel qui fonctionne plus qu’une documentation exhaustive.", autant dire que ces gens là ont des vrais problèmes avec la rédaction ; et je ne souhaite à personne de maintenir un logiciel sans documentation, cela créé à terme des logiciels où chaque bug/évolution coûte une fortune (car personne ne sait exactement comment ça fonctionne, car le développeur et le client initial ont déjà changé de poste...)
super merci
Merci bien !
Bonne didactique Marc-Noël, agilement vôtre !
Ils doivent être contents 3M😝
Bref, comment organiser le bordel et l'indécision :p
pardon, j'oubliais : "in short, how to manage mess and wavering!" c'est plus understandable ?
bien vue
Merci