Dans un environnement de développement itératif, tel qu'un agile, comment dessinez-vous la ligne entre une itération régulière et les débuts du fluage de la portée? À quel moment dit-tu au client que "Non, nous ne pouvons pas faire ce changement, à cause de?"
9 Réponses :
Ceci est assez simple dans une approche Scrum. Dans Scrum, vous définissez votre temps de sprint, par exemple. 2 semaines, puis adapter les articles dans cette situation. Lorsqu'un client veut que quelque chose ajouté, il est mis dans l'arriéré et sera fait dans une future itération. S'ils le veulent maintenant, vous devrez leur expliquer que quelque chose sera supprimé pour cela pour s'intégrer à l'itération.
Je comprends que, mais si elles continuent à vouloir des choses ajoutées à l'arriéré. L'étendue Creep n'est pas juste au niveau du sprint, c'est au niveau du projet. Ils continuent de demander des changements à ajouter à l'arriéré, alors à quel moment dites-vous non?
Je ne dirais pas "non", mais gardez un affichage constant de l'état de l'arriéré afin qu'ils comprennent les implications. Les utilisateurs ne sont pas déraisonnables à vouloir plus - je discuterais même que tous les grands logiciels déclenchent plus de demande!
Eh bien c'est quelque chose de subjectif. Ont-ils un fonds d'argent sans fin peut-on se permettre la portée du fluage? Avez-vous assez de gens pour faire le travail pour que vous n'ayez pas annulé d'autres emplois qui pourraient être plus rentables. L'article est-il déjà là mais sous un nom différent? Et quelques autres questions comme ça. Répondez à ces questions et vous saurez quand dire non
"Mais si s'ils continuent à vouloir des choses ajoutées à l'arriéré?" Qu'est-ce qui ne va pas avec ça? C'est la façon dont un bon projet fonctionne. Ils veulent toujours plus.
L'ajout à l'arriéré est bien ... La partie importante est que l'itération actuelle a une portée fixe. Seules les choses qui sont dans une itération seront complétées - et c'est le rouleau de la maîtrise PM / Scrum pour gérer les attentes autour de l'arriéré.
La principale faiblesse de l'agile est que la plupart des gens qui font "agile" volent vraiment par le siège de leur pantalon. Les choses ne devraient pas changer dans une seule itération, mais vous devriez permettre de changer en dehors de cela.
Et la plupart des gens font la cascade ne volent pas par le siège de leur pantalon? Honnêtement, le fait que les gens le font au fur et à mesure qu'ils partent n'ont rien à voir avec leur méthodologie, mais que la plupart des gens ne sont tout simplement pas disciplinés.
+1 pour contrer l'influence des évangélistes agiles. Et +1 au commentaire de Lee aussi.
+1 pour avoir le courage de signaler le manque de pantalon de l'empereur ..
Pour moi, le fluage de portée se produit lorsque la nouvelle fonction est ajoutée sans que le calendrier soit explicitement ajusté.
Avec des méthodes agiles, l'utilisateur est profondément impliqué dans la décision dont les histoires ont une priorité pour la mise en œuvre. D'où la fonction de commerce d'une seule pièce contre un autre est beaucoup plus claire.
Je n'appellerais pas que les utilisateurs ont pour objectif d'obtenir la fonction qu'ils choisissent dans l'ordre qu'ils influencent.
+1: Ce n'est que "Scope Creep" lorsque vous l'étiquetez comme mode de défaillance. Si les gens veulent plus, il ne s'agit pas de fluage de portée, il ne veut que plus.
Les itérations agiles ont une portée fixe; Le client accepte de ne pas modifier la portée pendant l'itération (bien qu'ils puissent annuler l'itération actuelle et le démarrer). Entre les itérations, la portée peut changer - spectaculaire.
Compte tenu de ce qui précède, la portée de la portée par définition ne peut pas se produire dans un projet agile. La notion de fluage d'étendue est un concept de cascade héritée qui suppose que toute la portée est connue à l'avant et ne changera pas la durée du projet. Ce concept ne s'applique pas aux méthodes agiles tant que chaque itération a une cible fixe .
+1 "Scope Creep est un concept de cascade héritée qui suppose que toute la portée est connue à l'avance" et un mauvais concept à cela.
Si le client est prêt à payer, pourquoi devriez-vous dire non? S'il n'y a qu'un seul client en train de payer pour tout cela, il est à peu près au pouvoir de ce qui développe («si vous ne le faites pas, je prendrai mon argent et dites à quelqu'un d'autre de le faire»). Mais bien sûr, si le produit a un grand public, vous devez disposer d'un objectif bien défini de ce que le produit devrait faire, car l'ajout de fonctionnalités inutiles peut réduire sa convivialité.
Certaines situations sont dans mon esprit, lorsque l'équipe de développement peut recommander au client de ne pas mettre en œuvre certaines fonctionnalités. Après cela, c'est la responsabilité du client, s'il veut quand même la mettre en œuvre. Si la fonction est conflit avec d'autres caractéristiques plus importantes, il serait sage de ne pas l'ajouter. Si la fonctionnalité ne donne pas beaucoup de valeur au client, par rapport au coût de la mise en œuvre, il pourrait ne pas être intelligent de brûler beaucoup d'argent dessus. Également dans certains cas, il pourrait également avoir plus de sens à mettre en œuvre certaines caractéristiques en tant que programme distinct, si leur objectif est très différent du programme d'origine - il est préférable d'avoir de nombreuses petites applications que chacun fait une chose et le fait bien, d'une humustion application qui fait tout sauf est spécialisée sur rien.
Pourquoi devriez-vous dire non? Je ne sais pas quelle saveur de développement agile que vous utilisez. Scrum est la plus prescriptive / a des règles définies pour répondre à ce scénario.
Scope Creep ne devrait plus se produire - à moins que vous ne pliez les règles. Vous avez un camion qui transportera 500 cases (plan de publication) pour ajouter 100 cases (nouvelles fonctionnalités) au plan, le PO devrait d'abord supprimer (Descope) 100 boîtes les moins recherchées de son ensemble d'origine.
Je pense qu'il y a deux types de griffe de portée:
1.) L'extension de la portée d'un projet sans augmenter le paiement / budget / temps disponible les développeurs. Cela peut arriver dans un processus agile, juste avec n'importe quel autre processus lorsque le maître PM / Scrum ou tout ce qui ne vous convient pas aux figures et serre une autre fonctionnalité dans le projet / itération / sprint.
2.) L'extension de la portée d'un logiciel, au-delà de ce qu'elle est utile. Je pense que les processus agiles pourraient réellement aider à ce type de problème, car le coût d'une fonctionnalité est très directement communiqué au propriétaire du projet, les coûts devraient donc être très transparents. Mais l'outil principal contre ce type de champ d'application est la même chose partout: avec chaque fonctionnalité que vous devez vérifier: En avons-nous vraiment besoin? En avons-nous besoin de cela dans ce logiciel? Ou appartient-il ailleurs? Ou en gestion parle: qu'est-ce que cela coûte de construire, que coûte-t-il de maintenir (souvent oublié), combien cela augmente-t-il les revenus?
La réponse à à quel moment dit-on au client que "Non, nous ne pouvons pas faire ce changement, à cause de" dépend de la valeur de ? .
Il n'y a généralement pas une bonne raison de dire "nous ne pouvons pas faire ce changement." Certaines choses que vous pourriez dire:
(1) - (5) fait bouillir jusqu'à "le code d'écriture prend du temps" - avec des niveaux de détail variables. Le (2) / (3) combo est probablement le plus proche de l'idée traditionnelle de "étendue fluage". (Dans la théorie des logiciels développés par une équipe agile est toujours dans un état libérable, mais peu d'équipes sont aussi bonnes.) Mais l'étendue Creep n'est qu'un problème si cela signifie que les propriétaires de produits font des demandes irréalistes sur l'équipe de développement. Tant que l'équipe de développement fournit des estimations réalistes et que les propriétaires de produits les acceptent, DEV ne devrait pas se soucier de la mesure où la portée parvient à se glisser.
Si l'équipe de développement a une relation malsaine avec le propriétaire du produit, et ce que vous voulez vraiment dire, c'est que «Boy Howdy est que Dumb et je ne veux pas y travailler», la réponse habituelle est de faire l'objet de la fonctionnalité vraiment, vraiment cher.
Étant donné que l'un des principaux avantages d'Agile est l'échange d'estimations réalistes pour les dates de livraison réaliste, cependant, ce n'est pas un bon endroit pour être ..
Voici une simple heuristique, que vous travailliez sur une itération de 1 à 2 semaines de mois, ou même un environnement de type Kanban, où des fonctionnalités sont ajoutées dans un flux continu:
+1 Pour le rappel que la protection de la valeur ajoutée est également une responsabilité du développement.
Honnêtement, je ne pense pas qu'il y a une ligne entre eux. IMHO, "Développement Agile", les méthodologies sont toutes sur la création et l'exploitation de la fluage de la portée. (au niveau du PM et plus élevé, pas au niveau du développeur).
Lorsque vous êtes payé à l'heure, vous n'arrêtez pas l'étendue Creep ... Vous l'encouragez - avec la mise en garde habituelle de vous assurer que le client comprendra les délais et les coûts seront affectés.
Le développement agile n'encourage certainement pas le fluage de la portée, la portée actuelle est toujours corrigée.
Je vote pour fermer cette question en tant que hors-sujet car les questions de gestion de projet sont hors tension et doivent être posées à https: //pm.stackexchange. com /