Jai utilisé SCRUM dans trois projets différents au cours des quatre dernières années. Lun des avantages de SCRUM semble être sa flexibilité et son adaptabilité, par exemple face à lévolution des besoins des clients. Un autre avantage est que la direction peut facilement suivre lavancement dun projet.
La flexibilité de SCRUM peut être un avantage par exemple lors de la mise en œuvre dune application Web, où les exigences changent très rapidement et les clients comprennent vraiment ce quils veulent après avoir vu un prototype.
Dautre part, il existe dautres types de projets logiciels (par exemple dans laérospatiale industrie) où les exigences sont assez fixes: vous obtenez un document de spécification des exigences et vous devez revenir six mois plus tard avec un logiciel fonctionnel et une documentation complète. Pour ce type de projets, je doute que la flexibilité offerte par SCRUM soit nécessaire (dans le sens que vous navez pas besoin de construire des prototypes et de les montrer au client pour obtenir des commentaires sur les exigences): vous avez plutôt besoin dune approche très structurée et systématique, qui se répète probablement encore et encore pour chaque projet avec peu de marge de surprise.
SCRUM est-il donc considéré par ses promoteurs comme une méthodologie de développement logiciel à usage général ou est-il considéré comme particulièrement adapté à certaines catégories de projets ou domaines dapplication?
Pour Par exemple, jai récemment regardé le site Web dune entreprise produisant des logiciels pour lindustrie aérospatiale et jai remarqué quelle utilise le modèle en V. Un promoteur de SCRUM dirait-il que SCRUM est moins adapté à ce type de projets ou suggérerait-il plutôt que cette entreprise essaie de passer à SCRUM?
Remarque que je ne demande pas lavis des lecteurs de ce forum, mais je veux savoir quelle est lopinion établie parmi les proposants de SCRUM: est-ce que SCRUM est considéré comme polyvalent ou plutôt adapté à certaines classes des projets seulement? Dans ces derniers cas, pour quels types de projets?
Commentaires
- Voir stackoverflow.com / questions / 596916 / when-should-you-not-scrum et eweek.com/c/a/IT-Management/…
- Pour » obtenir un document de spécification des exigences et vous devez revenir six mois plus tard avec un logiciel opérationnel » est un mythe. Même lorsque vous construisez quelque chose comme un compilateur pour un langage formellement défini (où les exigences fonctionnelles semblent vraiment claires et fixes), vous devez décider et prioriser les choses à implémenter, il y a des exigences non fonctionnelles à discuter avec lutilisateur , et vous avez plusieurs degrés de liberté car il faut décider comment résoudre les choses. Donc, une approche agile a même du sens pour ce type de projets.
- » Une approche agile a donc même du sens pour ce type de projets. « : Bien que lagilité soit plus flexible, dautres méthodes le sont également. Il se peut que dautres méthodes soient suffisamment flexibles et que lagilité soit trop flexible pour certains projets. Juste un brainstorming ici.
- » Que » obtienne un document de spécification des exigences et vous devez revenir six mois plus tard avec un logiciel en état de marche » la chose est un mythe. « : Je ne ‘ je pense pas . Bien que vous puissiez changer rapidement létiquette dun bouton sur une page Web parce que les clients ont changé davis après lavoir regardée, vous ne pouvez pas aussi facilement changer une partie critique dun logiciel avionique qui contrôle une partie mobile dun avion. Peut-être que des modifications tardives seront nécessaires, mais je me demande si une méthode agile est la bonne façon de les gérer, ou si vous avez besoin dune itération plus complexe dune autre méthode (par exemple le modèle en V).
Réponse
SCRUM est une méthodologie à usage général qui peut bien fonctionner pour la plupart des projets et des tailles déquipes, mais est moins utile pour les grandes équipes qui travaillent très projets. Le grand nombre de personnes impliquées dans certains projets rend toute méthodologie agile extrêmement difficile, voire presque impossible, car une structure plus rigide est nécessaire pour maintenir lordre. Lindustrie aérospatiale est un bon exemple dune industrie qui a tendance à avoir dénormes projets où les approches agiles ne sont pas toujours réalisables.
Commentaires
- Y at-il des informations sur le moment où un projet est considéré comme trop grand pour être réalisé avec SCRUM? Considérez par exemple un projet de 18 mois pour une équipe de 15 personnes: une telle équipe bénéficierait-elle de SCRUM ou un autre modèle comme le V-model serait-il également adapté La raison pour laquelle je pose la question est que sur 18 mois, les exigences et la mise en œuvre ont suffisamment de temps pour mûrir et se stabiliser et peut-être que la flexibilité fournie par SCRUM nest pas vraiment nécessaire.Au contraire, une approche plus à moyen et long terme convient ici. Existe-t-il de la littérature à ce sujet?
- @Giorgio lheure du projet na ‘ pas vraiment dimportance, mais 15 personnes suffisent pour que vous puissiez bénéficier de plusieurs mêlées groupes, mais cest toujours dans la plage gérable pour SCRUM. lorsque la gestion de la communication commence à devenir un travail à plein temps pour votre équipe, il est temps de commencer à regarder un modèle en V
- Êtes-vous sérieux? Nous utilisions un modèle en V avant et sommes passés à SCRUM. En fait, nous avons le sentiment que nous ‘ avons ralenti exactement pour cette raison: trop de comptabilité.
- @Giorgio ce serait vrai pour nimporte quel commutateur, vous êtes va se sentir plus lent au début parce que cest nouveau, comme Pierre 303 a dit que vous avez une meilleure idée après quelques sprints.
- @Giorgio – que ‘ est vrai, beaucoup de méthodologies » agiles » sont plus lourdes que les processus lourds quelles ‘ supposés remplacer! Évidemment, cela signifie quils ‘ ont tort – lagilité est censée être légère et libre, et paraître chaotique aux yeux des étrangers. Cela signifie que votre équipe doit être très organisée et disciplinée, mais que ‘ est généralement un avantage. Essayez plutôt Crystal dAlistair Cockburn (lun des fondateurs dAgile).
Réponse
Tout type de projet ! Cela fonctionne bien pour les grands et les petits projets.
Les gens lont utilisé pour planifier des mariages, des déménagements, etc. Donc, pas même uniquement des projets logiciels.
Je crois fermement que il existe de nombreuses opérations commerciales qui pourraient bénéficier d’une approche de type Scrum.
Commentaires
- Votre opinion est-elle partagée par des proposants de SCRUM, cest-à-dire par des auteurs qui ont codifié et promu SCRUM?
- Oui – cela a été récemment dit par Cheryl Hammond ( blog.bsktcase.com ), une consultante ALM avec Northwest Cadence sur une conférence quelle a donnée intitulée » A Scrum Masters Day In The Life: The New Visual Studio « . Vous pouvez le visionner ici: msevents.microsoft.com/CUI/…
Réponse
Veuillez noter que Scrum nest pas une méthodologie, mais un cadre.
Scrum fonctionnera mieux dans un c ross-Functional équipe de 5 à 9 développeurs travaillant sur un projet de taille moyenne à grande (de 4 mois à plusieurs années). Si votre projet est plus grand, vous pouvez évoluer avec Scrum of Scrums .
Je ne parlerai pas de la question transversale ici, mais ici sont ce que le Guide Scrum officiel indique pour la taille de léquipe:
Développement optimal La taille de léquipe est suffisamment petite pour rester agile et suffisamment grande pour effectuer un travail important. Moins de trois membres de léquipe de développement réduisent linteraction et se traduisent par de plus petits gains de productivité. Les équipes de développement plus petites peuvent rencontrer des contraintes de compétences pendant le sprint, ce qui empêche léquipe de développement de fournir un incrément potentiellement libérable. Avoir plus de neuf membres demande trop de coordination. Les grandes équipes de développement génèrent trop de complexité pour un processus empirique à gérer. Les rôles Product Owner et Scrum Master ne sont pas inclus dans ce décompte à moins quils nexécutent également le travail du Sprint Backlog
Un sprint dure environ un mois.
Les sprints sont limités à un mois civil. Lorsquun horizon de Sprint est trop long, la définition de ce qui est construit peut changer, la complexité peut augmenter et le risque peut augmenter. Les sprints permettent la prévisibilité en assurant linspection et ladaptation des progrès vers un objectif au moins tous les mois civils. Les sprints limitent également le risque à un mois calendaire de coût.
Je pense que cela na pas de sens dutiliser un cadre basé sur un processus itératif avec des projets plus petits plus de 4 mois. 4 mois = 4 sprints. Vous devez également considérer que vous obtenez une vitesse plus précise après 3 sprints.
Cela dit , Jutilise personnellement une version limitée de Scrum pour les petits projets. Mais vous ne pouvez pas vraiment lappeler Scrum alors. Dans ce cas particulier, vous utilisez certains principes de base de Scrum dans votre propre implémentation du framework.
Answer
pour commencer , considérez SCRUM comme un ensemble de lignes directrices pour la mise en œuvre de pratiques agiles. Ne le considérez jamais comme un «livre sacré» expliquant comment réaliser des projets. Pour de nombreux projets où un flux constant de tâches est requis, Kanbam est plus approprié, par exemple.
Les projets Agile ont tendance à tomber là où vous faites des projets qui nécessitent une date de fin fixe ou un coût fixe. Bien que vous puissiez toujours réaliser ces projets en utilisant des méthodes Agile, la nécessité de tout planifier à lavance déterminer si vous êtes susceptible datteindre la cible nest pas la manière agile habituelle – en agile, vous avez tendance à continuer à travailler jusquà ce que vous manquiez de choses à faire ou que vous manquiez de temps pour le faire. Pour la plupart des projets, cest correct car les exigences changent de toute façon pendant le projet.
Commentaires
- La façon dont nous agissons dans notre équipe est de laisser le client définir une priorité sur les histoires (du plus important au moins important), nous estimons les user stories à laide de cartes de poker et planifions autant dhistoires que nous pouvons mettre en œuvre jusquà la date limite. Si nous nous révélons plus rapides, nous planifions plus darticles, en fonction de ce qui suit dans la liste des priorités.
- Jai relu votre réponse après quelques mois et elle est en fait très enrichissante. +1