Pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter, inscrivez-vous gratuitement !

 

Affichage des résultats du sondage: Laquelle des deux méthodologies est-elle la meilleure ?

Votants
18. Vous ne pouvez pas participer à ce sondage.
  • Scrum

    4 22,22%
  • Kanban

    11 61,11%
  • Aucune préférence

    1 5,56%
  • Autre avis (à préciser)

    2 11,11%
  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    juin 2016
    Messages
    174
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2016
    Messages : 174
    Points : 5 833
    Points
    5 833

    Par défaut Agile : entre Scrum et kanban, laquelle des deux méthodologies est-elle la meilleure ?

    Agile : entre Scrum et Kanban, laquelle des deux méthodologies est-elle la meilleure ?
    Le point dans une étude comparative

    Le développement d'applications modernes est rarement un effort solitaire. La conception, le codage, le test et l'empaquetage des applications nécessitent une équipe interfonctionnelle composée de concepteurs, de développeurs, de testeurs et de graphistes travaillant en étroite collaboration. Ceci est rendu plus difficile par le fait que les tâches à faire sont le plus souvent inconnues ou incomplètes. Toutes ces compétences combinées permettent de développer des applications qui répondent aux attentes des utilisateurs. Ces applications sont de plus en plus stables et livrées dans les délais et les contraintes budgétaires du client.

    Depuis le début des années 1970, diverses méthodologies ont été créées pour surmonter ces difficultés et, au fil du temps, la plus populaire a été la méthode en cascade « waterfall model » qui est une approche de conception séquentielle relativement linéaire pour certaines zones de conception technique. Le problème avec ce modèle est que chaque phase doit être complètement achevée avant de passer à la phase suivante. Au fur et à mesure que la taille et la complexité des applications augmentaient vers les années 1980 et 1990, de nombreuses méthodes de développement ont vu le jour pour tenter de surmonter les problèmes rencontrés avec la méthode en cascade parmi lesquelles on peut citer Kanban et Scrum. Ces modèles reflètent à des degrés divers les principes définis par le Manifeste pour le développement agile de logiciels.

    En effet, le Manifeste pour le développement Agile de logiciels est un texte rédigé par 17 experts du développement d'applications informatiques sous la forme de plusieurs méthodes dites agiles. Ces experts estimaient que le traditionnel cycle de développement en cascade ne correspondait plus aux contraintes et aux exigences des organisations en évolution rapide. Les méthodes agiles ne sont pas apparues avec l’Agile manifesto en 2001, mais celui-ci détermine leur commun dénominateur et consacre le terme d'« agile » pour les référencer. Les valeurs et principes du Manifeste agile sont défendus par l'Agile Alliance.

    Nom : Agile-Methodes.jpg
Affichages : 8870
Taille : 87,9 Ko

    Les douze principes du Manifeste sont les suivants :
    • satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée ;
    • accueillir positivement les changements de besoins, même tard dans le projet ;
    • livrer fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts ;
    • les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet ;
    • réaliser les projets avec des personnes motivées et leur fournir l’environnement et le soutien dont elles ont besoin et leur faire confiance pour atteindre les objectifs fixés ;
    • privilégier la colocation de toutes les personnes travaillant ensemble et le dialogue en face à face comme méthode de communication ;
    • un logiciel opérationnel est la principale mesure de progression d'un projet ;
    • les processus agiles encouragent un rythme de développement soutenable, ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant ;
    • une attention continue à l'excellence technique et à un bon design ;
    • la simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle ;
    • les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées ;
    • à intervalles réguliers, l'équipe réfléchit aux moyens possibles pour devenir plus efficace puis elle s'adapte et modifie son mode de fonctionnement en conséquence.


    Qu'est-ce que Scrum?

    Scrum est un schéma d’organisation de développement de produits complexes. Il est défini par ses créateurs comme un « cadre de travail holistique itératif qui se concentre sur les buts communs en livrant de manière productive et créative des produits de la plus grande valeur possible ». Il est considéré comme un groupe de pratiques répondant pour la plupart aux préconisations du Manifeste Agile. Son framework s'appuie sur le découpage d'un projet en boîtes de temps, nommées « sprints » qui peuvent durer entre quelques heures et un mois avec une préférence pour deux semaines. Il se base sur l'expérience du terrain et s'appuie sur trois piliers :
    • transparence (même langage commun entre l'équipe et le management pour permettre à tout observateur d'obtenir rapidement une bonne compréhension du projet) ;
    • inspection (à intervalle régulier, Scrum propose de faire le point sur les différents artéfacts produits, afin de détecter toute variation indésirable) ;
    • adaptation (si une dérive est constatée pendant l'inspection, le processus doit alors être adapté. Scrum fournit des évènements durant lesquels cette adaptation est possible) ;

    Le cadre du scrum consiste en la définition des rôles projets, activités ou artefacts, et réunions ou événements. Ceux-ci sont décrits dans le guide rédigé par les créateurs de la méthode.

    La méthodologie scrum présente néanmoins quelques risques à savoir le flaccid scrum, un scrum master directif et la communication constructive laisse la place aux reproches.

    Nom : scrum.gif
Affichages : 8826
Taille : 53,4 Ko

    Qu'est-ce que Kanban?

    Kanban est un terme japonais qui signifie « étiquette ». C'est une méthodologie du Manifeste d'Agile qui a été formalisée en 2010 par David Anderson. Elle est basée sur le principe de la limitation du nombre de travaux à faire (TAF). L’objectif de Kanban est d’éviter le gaspillage en assurant l’amélioration continue du processus. L’équipe définit les limites du TAF pour chaque étape du processus Kanban. Le flux du travail est contrôlé visuellement et permet à l'équipe de suspendre le processus afin de résoudre un problème bloquant.

    Les 4 phases d’une démarche Kanban sont les suivantes :
    • la phase de conception ;
    • la phase de mise en œuvre (l’équipe applique les pratiques de la démarche Kanban et utilise ses outils à l’identification du processus existant et la définition des éléments du travail et la mise en place des règles du système) ;
    • la phase d’étude (ensemble, l’équipe et le concepteur étudient la réaction du système aux règles instaurées lors de la première phase de conception) ;
    • la phase d’amélioration (en fonction des conclusions de la phase d’étude, l’équipe ajuste le système, stabilise le processus, réorganise les éléments et fixe les règles).


    Nom : Scrum-vs-Kanban-Diagram.png
Affichages : 8658
Taille : 219,9 Ko

    Qu'est-ce que Scrum et Kanban ont en commun ?

    Il y a beaucoup de similitudes entre Scrum et Kanban. Scrum et Kanban permettent à la fois de décomposer et d'exécuter efficacement des tâches importantes et complexes. Tous deux accordent une grande importance à l'amélioration continue, à l'optimisation du travail et au processus. Et tous les deux partagent le même accent sur un flux de travail très visible qui tient tous les membres de l'équipe au courant des tâches exécutées et de celles qui suivent.


    Qu'est-ce qui différencie Scrum et Kanban ?

    il existe un certain nombre de différences dans la philosophie de l'application pratique de Scrum et Kanban. Bien que les différences individuelles soient nombreuses, elles peuvent être regroupées dans les trois catégories suivantes :

    • Planification, itération et cadence

      Les processus Scrum mettent fortement l'accent sur le calendrier. L'équipe de Scrum dispose d'une liste hiérarchisée de tâches à faire qui doivent être complétées pour livrer un produit livrable. L'équipe doit décider combien de points, selon elle, peuvent être complétés dans un sprint. Tout ce qui sort de la portée à laquelle ils s'engagent doit attendre le prochain sprint. Idéalement, une équipe Scrum efficace apprendra rapidement ses capacités au cours de plusieurs sprints et ses estimations s'amélioreront et seront optimisées au fil du temps. Ensuite, toutes les deux semaines (ou quelque soit la durée de leur sprint), l'équipe produit un produit livrable, effectue une rétrospective pour discuter de l'optimisation du processus et passe au sprint suivant. Ce processus itératif est conçu pour permettre des estimations précises du flux de travail et une gestion efficace de plusieurs projets.

      Sur une équipe Kanban, il n'y a pas de boîtes de temps ou d'itérations requises. Bien que la méthode Kanban soit de nature itérative, on s'attend à ce que l'amélioration continue se produise de façon évolutive à mesure que le travail est continuellement complété. Les limitations imposées à diverses conditions dans le flux de travail seront réglées au début de l'utilisation de Kanban par une équipe (ou une organisation) jusqu'à ce qu'un ensemble optimal de limites soit atteint pour maintenir le flux régulier et efficace.

    • Rôles et responsabilités

      Sur les équipes Scrum, il existe au moins trois rôles à attribuer pour traiter efficacement le travail: le propriétaire du produit « Product Owner », Scrum Master et les membres de l'équipe. Chaque rôle a son propre ensemble de responsabilités, et ils doivent travailler ensemble pour atteindre un équilibre ordonné et efficace. L'équipe de mêlée doit elle aussi être interfonctionnelle, c'est-à-dire qu'une équipe doit avoir toutes les ressources nécessaires pour compléter le travail du sprint.

      Sous Kanban, aucun ensemble de rôles n'est prescrit. D'un point de vue pratique, il est logique que quelqu'un occupe un poste de chef de projet ou de superviseur, en particulier pour des projets Kanban plus importants et plus complexes, mais les rôles devraient théoriquement évoluer en fonction des besoins du projet et de l'organisation. Une équipe Kanban n'est pas obligée d'être interfonctionnelle puisque le flux de travail Kanban est destiné à être utilisé par toutes les équipes impliquées dans le projet. Par conséquent, une équipe de spécialistes et une équipe distincte de généralistes peuvent travailler sur différents aspects du même projet Kanban à partir du même conseil.

    • Les tableaux

      Bien que très similaires, le tableau Scrum et le tableau Kanban sont très différents. Sur un tableau Scrum, les colonnes sont étiquetées pour refléter les périodes dans le flux de travail commençant avec le backlog de sprint et se terminant par tout ce qui les tâches à faire de l'équipe. Tous les historiques ajoutés au tableau au début de chaque sprint doivent être trouvés dans la dernière colonne à la fin de ce sprint ou le sprint n'a pas réussi. Après la rétrospective du sprint, le tableau est effacé et préparé pour le prochain sprint.

      Sur un tableau Kanban, les colonnes sont également étiquetées pour afficher les états de flux de travail, mais avec une différence essentielle. Elles publient également le nombre maximum d'historiques autorisés dans chaque colonne à la fois. Cela renforce les limites déterminées par l'équipe que Kanban prescrit pour chaque condition. Étant donné que chaque colonne a un nombre limité d'historiques autorisés et qu'il n'y a pas de case horaire requise (comme la longueur du sprint), il n'y a aucune raison de réinitialiser le tableau Kanban au fur et à mesure que le travail progresse. Il continuera à circuler aussi longtemps que le projet se poursuivra, avec de nouveaux historiques ajoutés au fur et à mesure des besoins, et les historiques complétés seront réévalués si nécessaire.


    Sources : Scrum Methodology, scrum guide, Cprime

    Et vous ?

    Entre les méthodologies Scrum et Kanban, laquelle préféreriez-vous et pourquoi ?

    Voir aussi

    Testez vos connaissances sur kanban
    Scrum et les changements pendant un sprint
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Nouveau membre du Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    mars 2015
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : mars 2015
    Messages : 5
    Points : 36
    Points
    36

    Par défaut et l'environnement?

    je mettrais un petit warning sur l'article. Personnellement, je considère qu'il n'y a pas de meilleure méthodologie. Choisir une méthodologie dépend de la culture de l'entreprise et donc du management.

  3. #3
    Membre confirmé
    Profil pro
    Expert technique .NET
    Inscrit en
    août 2007
    Messages
    272
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Expert technique .NET

    Informations forums :
    Inscription : août 2007
    Messages : 272
    Points : 520
    Points
    520

    Par défaut

    Il est dommage de confondre SCRUM et Agile. Il existe en effet d'autres méthodes Agile, moins contraignantes que SCRUM, comme par exemple XP.
    Sinon je suis d'accord avec silicoman, il n'y a pas vraiment de meilleure méthode que d'autre. Le contexte de l'entreprise et du projet y sont pour beaucoup.

  4. #4
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    2 064
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 2 064
    Points : 7 475
    Points
    7 475

    Par défaut

    Citation Envoyé par Bill Fassinou Voir le message
    Entre les méthodologies Scrum et Kanban, laquelle préféreriez-vous et pourquoi ?
    La meilleure méthode est celle où l'ensemble des intervenants du projet est à l'aise.
    Il est indispensable que le CP (ou scrum master pour reprendre le terme de la méthode) maîtrise parfaitement sa méthode et sache la partager avec l'ensembles des intervenants du projets et pas uniquement l'équipe technique comme on le voit souvent car en Agile, la participation des équipes métiers et des utilisateurs est indispensable.
    Du coup, une méthode trop rigide et/ou mal comprise va plus gêner qu'autre chose.

    Personnellement, je n'applique aucune méthode Agile au sens strict mais mélange de tout ce que j'y aie trouvé de bien et qui s'appliquent dans le context de mon projet et de mon équipe.

  5. #5
    Membre éprouvé
    Homme Profil pro
    Inscrit en
    mars 2011
    Messages
    544
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : mars 2011
    Messages : 544
    Points : 1 208
    Points
    1 208

    Par défaut

    Je suis "Scrum Master" depuis quelques année maintenant après avoir été dev et un peu Product Owner et je dois dire que Scrum est plutôt bien appliqué dans ma boite. Cependant, plus ça vas, moins je suis convaincu par cette méthodes. Ce que j'en retiens:

    - L'agilité permet de supprimer le middle management. Donc moins de manager, moins de "gros" salaire à payer et un plafond de verre s'installe entre l'équipe Dev/SM/PO et le management d'en haut.
    - Le PO ne produit rien. Si le projet est en retard, ce n'est pas de sa faute, c'est les dev qui ne respectent pas leurs évals.
    - Le Scrum Master n'a pas vraiment d'objectif défini. Il peu se contenter de glander la journée en lisant des blog sur l'agilité et de poser les réunions de rétro/review toutes les 2 semaines.
    - L'équipe de dev "a le droit de se tromper". Si elle est dans les choux, "Une éval est par essence imprécise", ou alors "la vélocité est faite pour évoluer avec le temps." Bref, tout un tas d'excuse pour ne pas prendre ses responsabilités.
    - Les développeurs sont interchangeable. Il n'y a pas de notion d'expert technique dans Scrum ou dans Kanban, l'expertise n'est pas valorisé et on encourage la polyvalence plutôt que la spécialisation. On se retrouve alors avec des développeurs moyens dans des équipes moyennes qui font du code moyen.
    - Il n'y a pas de "Décideur", ou "Leader" identifié parmi les dev. Si l'équipe n'arrive pas a un consensus sur une solution technique, on s'embourbe dans des discussions interminables car personne n'a la responsabilité de trancher.
    - L'agilité est devenue une véritable pompe à fric. Entre le prix de certains outils, le prix des formations, le prix pour passer les certif SM, PO, etc...

    Je ne connais pas assez bien Kanban pour voir s'il y a les même dérive avec cette méthode. Quelqu'un pratiquant Kanban pourrait-il me donner son avis ?
    La perfection est atteinte, non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à retirer. - Antoine de Saint-Exupéry

  6. #6
    Membre confirmé Avatar de Bayard
    Inscrit en
    juin 2002
    Messages
    690
    Détails du profil
    Informations forums :
    Inscription : juin 2002
    Messages : 690
    Points : 523
    Points
    523

    Par défaut

    J'ai quelques années Agile au compteur et mon point de vue est qu'il n'y a pas une méthode meilleure qu'une autre.
    Néanmoins, si je dois dégager des avantages:
    • Scrum: Déterminisme. Ceci sera apprécié dans l'industrie. Une ligne de production dans une usine ou du logiciel dans des délais de livraison contraints.
    • Kanba: Souplesse. Pour du logiciel où on a un peu plus le droit à l'erreur (l'IHM d'un site Web par exemple). Cette méthodologie suggère une Polyvalence des métiers (ceux qui font et ceux qui testent doivent pouvoir se remplacer afin qu'il n'y ait pas de bottleneck).


    Le déterminisme plaira à la direction. La souplesse au client.
    Le déterminisme a un coût (formation, écriture des User Stories avec leurs estimations...). C'est un investissement.
    Si vous n'avez pas de budget, commencez par un KanBan.
    Si tu ne vis pas ce que tu penses alors tu penses ce que tu vis.

  7. #7
    Expert éminent sénior

    Homme Profil pro
    Directeur des systèmes d'information
    Inscrit en
    avril 2002
    Messages
    1 599
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : Luxembourg

    Informations professionnelles :
    Activité : Directeur des systèmes d'information
    Secteur : Finance

    Informations forums :
    Inscription : avril 2002
    Messages : 1 599
    Points : 10 477
    Points
    10 477

    Par défaut

    Les développeurs préfèrent Kanban mais les employeurs préfèrent Scrum, pourquoi ? qui à raison qui à tord ?

    Une recherche sur https://emploi.developpez.com donne :

    Agile : 1913 résultats
    Scrum : 950 résultats
    Kanban : 69 résultats
    Ne prenez pas la vie au sérieux, vous n'en sortirez pas vivant ...

  8. #8
    Nouveau Candidat au Club
    Homme Profil pro
    Historien
    Inscrit en
    mai 2018
    Messages
    322
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : Algérie

    Informations professionnelles :
    Activité : Historien

    Informations forums :
    Inscription : mai 2018
    Messages : 322
    Points : 0
    Points
    0

    Par défaut

    moi je fais de l'hybride, un mélange de scrum et kanban.
    Les 2 de toute manière sont très proche je pense pas que se soit pertinent d'avoir un débat la dessus

    Dans méthode Agile, il y'a "Agile" et pour moi la regle numéro 1 c'est d’être agile, ne pas suivre a la lettre les process définis dans les manifestes mais de les adapter. Si un truc ne nous conviens pas on jette ou on modifie.

    un exemple tous bete, la petite réunion le matin, on la fais que 2 fois/semaine parchment a estimé que c'étais de la réunionite 1 fois/jours

  9. #9
    Membre averti
    Avatar de UNi[FR]
    Homme Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    juin 2002
    Messages
    339
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information

    Informations forums :
    Inscription : juin 2002
    Messages : 339
    Points : 443
    Points
    443

    Par défaut a côté de la plaque !

    je suis sidéré par cet article. Scrum n'est aucunement une méthode, c'est une abération que de pretendre le contraire. il s'agit d'un cadre de travail (framework). c'est comme si l'on parle d'ustensiles de cusisine en tant que méthode a la place d'une recette. Scrum founit des outils ce n'est pas une recette a suivre a la lettre et qui va faire que le projet/produit sera par magie réussi. c'est malheureusement ce genre d'article qui donne une mauvaise image de l'agilité. on ne parle pas de méthodes Agiles mais plutôt de culture agile. c'est une fassons de penser qui propose tout un éventail d'outils et de méthode adaptés a des situations/organisations différentes
    Gnarf !
    Mon C.V.
    AGILE && (.NET {VS 2017 && WPF} || PHP {(PHPStorm || SublimeText3 || VS Code) && (Docker)})

    Pensez au TAG

  10. #10
    Expert éminent sénior

    Homme Profil pro
    Directeur des systèmes d'information
    Inscrit en
    avril 2002
    Messages
    1 599
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : Luxembourg

    Informations professionnelles :
    Activité : Directeur des systèmes d'information
    Secteur : Finance

    Informations forums :
    Inscription : avril 2002
    Messages : 1 599
    Points : 10 477
    Points
    10 477

    Par défaut

    En fait tu as lu que le titre pas l'article ? Dans l'article on lit :

    Qu'est-ce que Scrum?

    Scrum est un schéma d’organisation de développement de produits complexes. Il est défini par ses créateurs comme un « cadre de travail holistique itératif qui se concentre sur les buts communs en livrant de manière productive et créative des produits de la plus grande valeur possible ». Il est considéré comme un groupe de pratiques répondant pour la plupart aux préconisations du Manifeste Agile
    Ne prenez pas la vie au sérieux, vous n'en sortirez pas vivant ...

  11. #11
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    2 064
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 2 064
    Points : 7 475
    Points
    7 475

    Par défaut

    Citation Envoyé par UNi[FR] Voir le message
    je suis sidéré par cet article. Scrum n'est aucunement une méthode, c'est une abération que de pretendre le contraire.
    Tu confonds le Manifeste Agile (ou Agile Manifesto, écrit en 2001) qui décrit parfaitement bien le concept de l'agilité dans les projets et les différentes implémentations de ce manifeste dont SCRUM et Kanban qui sont bien des méthodes de travail.

    Comme il est stipulé dans ce manifeste, l'agilité implique de s'adapter et donc, de ne pas appliquer bêtement et aveuglement une méthode en dépit du bon sens et du contexte du projet, de l'équipe et de l'entreprise.
    Raison pour laquelle nous sommes invités à prendre du recul par rapport aux différentes implémentations du manifeste et de n'y prendre que ce qui nous intéresse.

    Donc oui, SCRUM et Kanban sont bien des méthodes issues de l'Agile.
    Et non, elles ne sont pas à appliquer strictement.

    J'ai eu l'occasion de rencontrer un "évangéliste de SCRUM" (il se définissait lui-même ainsi) qui n'avait rien compris au sens du manifeste et prônait une application radicale de SCRUM.
    Comme l'indique parfaitement le titre qu'il se donne, il s'agit d'une fanatique écervelé qui n'a rien compris au sens de ce qu'il prétend défendre et enseigner.
    Malheureusement, ce type d’extrémistes sont parfois de très bons orateurs et ils ne savent que trop bien vendre leur soupe à certains décideurs qui n'y connaissent pas grand chose.

  12. #12
    Membre à l'essai
    Développeur (J2EE, Web, ..)
    Inscrit en
    mars 2010
    Messages
    13
    Détails du profil
    Informations professionnelles :
    Activité : Développeur (J2EE, Web, ..)
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2010
    Messages : 13
    Points : 23
    Points
    23

    Par défaut

    Entre les deux je préfere SCRUM. Elle me paraît simple et concret à l'opposé de Kanban qui me paraît un peu complexe. Quand on a une équipe de plus de 8, autant diviser le travail pour faire de petites équipes qui seront dédiées aux différentes taches.

    Bien évidemment, tout dépend de la volonté de l'équipe, mais en informatique on a plutôt tendance à faire de petites équipe pour adopter l'agilité.

  13. #13
    Candidat au Club
    Inscrit en
    janvier 2011
    Messages
    1
    Détails du profil
    Informations forums :
    Inscription : janvier 2011
    Messages : 1
    Points : 2
    Points
    2

    Par défaut Une méthode agile ne régle pas tout

    Un des risques des méthodes agiles (je parle de SCRUM pour ce que je connais), c'est qu'en appliquant à la lettre on entre dans un schéma de "code first" ie le code produit prime sur tout le reste. Cela se traduit par un développement rapide au détriment de l'architecture en créant des données qu'il faudra ensuite gérer en commun. Cela peut induire des dérives fonctionnelles qu'il faudra corriger ensuite voire perturber les autres équipes projets. De mon point de vue, les méthodes agiles sont trés utiles mais il ne faut garder la partie "données" sous controle avec une équipe "centralisée sur le domaine fonctionnel" car les équipes agiles ne discutent pas toujours entre elles (en principe)......

  14. #14
    Candidat au Club
    Homme Profil pro
    Coach Agile Junior
    Inscrit en
    mai 2018
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Coach Agile Junior

    Informations forums :
    Inscription : mai 2018
    Messages : 1
    Points : 4
    Points
    4

    Par défaut

    Citation Envoyé par Saverok Voir le message
    Tu confonds le Manifeste Agile (ou Agile Manifesto, écrit en 2001) qui décrit parfaitement bien le concept de l'agilité dans les projets et les différentes implémentations de ce manifeste dont SCRUM et Kanban qui sont bien des méthodes de travail.
    Exact ! Par contre, Scrum est bien un "framework", ou cadre de travail, et pas vraiment une "méthode" selon la définition française . Il donne un cadre "managérial", mais aucune méthode technique pour arriver à gérer la gestion de produit complexe : car Scrum n'est pas utilisable que dans l'IT, contrairement à XP qui lui donne une vraie méthode technique (enfin, surtout des pratiques) !. Donc ce n'est juste pas une méthode complète (comme le cycle en V, par exemple, malgré ses travers car utile en production compliquée et non complexe), tout au plus un cadre. Cette légèreté en fait sa force, et sa faiblesse.

    Kanban est par contre une méthode de conduite du changement d'un processus : c'est un outil qui s'applique sur un processus pour l'améliorer continuellement, ainsi qu'améliorer l'équipe de manière évolutionnaire, petit à petit.

    Bref les deux sont proches mais n'ont pas la même utilité. C'est d'ailleurs pour ça que Scrumban et Scrum with Kanban sont arrivés, on en voit l'intérêt dans certaines équipes !

    Le vrai soucis, et ça se voit dans les discussions, c'est un problème de vocabulaire / communication (surprise !! ). On dit tous les même choses, mais de manière différente.

  15. #15
    Nouveau Candidat au Club
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2012
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Industrie

    Informations forums :
    Inscription : août 2012
    Messages : 1
    Points : 0
    Points
    0

    Par défaut Manque de creativite

    Voici quelques mois que je suis dans une equipe Scrum.
    Le retour que j en fais rejoint l avis de Pyros
    J'ajouterai un point :
    Cette methode à mon sens tue la creativité.
    Les developpeurs sont concentrés sur l objectif et ne s'accordent plus de temps pour tester ou envisager des nouveaux concepts/technologies.
    D un point vue management, le court terme prevaut sur le long terme.

  16. #16
    Membre confirmé Avatar de Bayard
    Inscrit en
    juin 2002
    Messages
    690
    Détails du profil
    Informations forums :
    Inscription : juin 2002
    Messages : 690
    Points : 523
    Points
    523

    Par défaut

    Cette methode à mon sens tue la creativité.
    Les developpeurs sont concentrés sur l objectif et ne s'accordent plus de temps pour tester ou envisager des nouveaux concepts/technologies.
    La méthode Scrum prévoit des rétrospective de sprints dans lesquelles l'équipe indique ce qui peut être amélioré dans le projet. Cela peut aboutir sur des études (spike)
    sur des nouveaux concepts/technologies.
    Si tu ne vis pas ce que tu penses alors tu penses ce que tu vis.

  17. #17
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    797
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : janvier 2011
    Messages : 797
    Points : 2 895
    Points
    2 895

    Par défaut

    Citation Envoyé par kerauzen Voir le message
    Cette methode à mon sens tue la creativité.
    Les developpeurs sont concentrés sur l objectif et ne s'accordent plus de temps pour tester ou envisager des nouveaux concepts/technologies.
    D un point vue management, le court terme prevaut sur le long terme.
    La natation à mon sens tue la créativité.
    Mon entraineur veut que je me concentre sur les compétitions et je n'ai plus de temps d'envisager d'autres loisirs.
    D'un point de vue coaching sportif, le court terme prévaut sur le long terme.



    Plus sérieusement, rien dans Scrum ne dit qu'on ne peut pas faire de veille techno.

    Il faut arrêter de se mettre des barrières mentales et/ou de mettre les conneries de managers peu scrupuleux sur le compte des méthodos.

Discussions similaires

  1. Etude comparative entre UML et MERISE
    Par deydtapha dans le forum Méthodes
    Réponses: 2
    Dernier message: 28/06/2015, 11h51
  2. Réponses: 1
    Dernier message: 15/04/2015, 13h46
  3. L'etude comparative entre linux et windows?
    Par karimala dans le forum Contribuez
    Réponses: 2
    Dernier message: 13/12/2008, 16h09
  4. Etude comparative entre RTP et TCP/UDP
    Par imadin dans le forum Développement
    Réponses: 6
    Dernier message: 25/05/2008, 15h13
  5. Réponses: 19
    Dernier message: 11/05/2006, 08h49

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo