Comment gérez-vous l'évolution des exigences? [fermé]

Dans mon travail actuel, j'ai l'impression que nous avons beaucoup de changements d'exigences. Nous sommes une boutique "Agile", donc je comprends que nous sommes censés nous ajuster et quoi, mais parfois le changement est important et rien de trivial.

Ma question est la suivante: comment communiquez-vous efficacement le coût du changement? En raison de son agilité, si un changement est suffisamment important, quelque chose sera supprimé du sprint actuel, mais il sera généralement ajouté la prochaine fois. Comme notre modèle est le SaaS, le client final est effectivement l'entreprise elle-même et il sait qu'il obtiendra la fonctionnalité de coupure n semaines plus tard.

Je suppose que ce que j'essaie de comprendre, c'est que la suppression d'une fonctionnalité n'est vraiment pas quelque chose à utiliser pour la communication car elle n'a été retardée que de n semaines. De quelles autres façons disposez-vous pour que l'entreprise comprenne ce que coûte un changement?

@Joe "Nous sommes une boutique" Agile ", donc je comprends que nous sommes censés nous ajuster et quoi, mais parfois le changement est important et rien de trivial."

Si votre processus ne vous permet pas de contrôler le taux de changement des exigences, votre processus n'est pas agile, mais au hasard. Agile ne signifie pas «prendre tout ce qui vient à ma rencontre».

Pour contrôler le changement / fluage d'exigence, vous pouvez adopter - dans votre processus - la notion qu'une exigence ne change pas (une notion qu'elle est au cœur de Scrum.) Traitez un changement d'exigence comme remplaçant une ancienne exigence par une nouvelle. Vous devez avoir un arriéré d'exigences et vous devez demander à l'utilisateur de choisir celles qu'il souhaite mettre en œuvre.

Vous vouliez X et Y dans deux semaines, mais tout à coup, vous voulez Z. Eh bien, je peux vous livrer les trois en 4 semaines. Ou je peux donner une paire (X et Z) ou (X et Y) ou (Y et Z) dans deux semaines et livrer le reste plus tard. Choisir.

C'est ainsi que vous négociez avec les clients. C'est ainsi que vous communiquez le coût du changement d'exigence. Si votre groupe n'a pas ce pouvoir, vous n'êtes pas dans une boutique agile et vous ne pouvez rien y faire. Ça craint, mais c'est vrai.

Dans le cas où vous pouvez négocier, vous devez suivre (avec précision) le temps nécessaire à la mise en œuvre des exigences et des modifications des exigences. Autrement dit, vous devez collecter ces données des projets passés et présents.

Vous collectez l'estimation de temps d'origine et le temps de réalisation réel (en plus des ressources comme le nombre de développeurs) par demande (ou module affecté par N demandes). Mieux encore, estimez la taille de la demande / modification de la demande (en termes de lignes de code ou de points de fonction dans les projets et demandes antérieurs.)

Supposons que vous ayez une mesure avec laquelle vous pouvez parler à l'utilisateur. Vous savez qu'une nouvelle demande prendra, disons, 1 000 lignes de code ou 10 pages Web avec en moyenne 5 champs de saisie chacun (50 points de fonction).

Ensuite, en regardant les données historiques spécifiques à vos projets passés (certaines par lignes de codes, certaines par pages Web, d'autres par points de fonction réels), vous pouvez estimer le coût de chacune de ces dernières en termes de temps de réalisation absolu. Pour ceux qui ont suffisamment de données, vous pouvez également identifier les exigences qui suivent le nombre réel de développeurs.

Ensuite, vous l'utilisez et vous dites à votre client que sur la base de données historiques; vous soutenez que les échecs de projets ont tendance à suivre une distribution exponentielle; puis vous êtes armé de l'argument suivant pour votre client:

Sur la base des données de nos projets passés et présents et des ressources disponibles, l'exigence que vous posez prendra

1. X quantité de temps pour terminer avec une probabilité d'échec de 25% (ou 75% de succès)

2. 1,5 * X quantité de temps pour terminer avec 5% d'échec (ou 95% de succès)

3. 0,5 * X quantité de temps pour terminer avec 95% d'échec (ou 5% de succès)

La probabilité d'échec en fonction de la quantité de temps passe généralement à 95%, 25% et 5% (ce qui ressemble à une distribution exponentielle). ). 1,5 de cela pourrait donner presque une certaine chance de succès avec un risque minimal, mais beaucoup moins que cela (0,5 de l'original garantit un échec presque certain.)

Vous les laissez digérer là-dessus. S'ils optent toujours pour la proposition risquée ( faite hier! ), Vous avez au moins par écrit que vous leur avez dit. S'il y a de l'espoir pour votre groupe d'être non seulement agile, mais semblable à l'ingénierie, alors, le client pourrait accorder une attention sérieuse à vos chiffres et planifier cette demande et les futures en conséquence.

C'est votre travail en tant qu'ingénieur d'expliquer en termes d'ingénieur, des termes vérifiables et clairs que les changements de demande ne sont pas un repas gratuit.

D'après ce que vous avez décrit, vous n'avez pas de problème. Ils demandent un changement et sont prêts à attendre jusqu'à ce que vous disiez que cela peut être fait ou à reporter une autre fonctionnalité. On dirait un équilibre entre: temps, ressources et exigences.

Vous pouvez essayer de définir un âge minimum pour un nouvel ajout / modification (non applicable aux corrections de bogues). Par exemple, aucune nouvelle modification ne peut être effectuée avant l'âge de 3 semaines.

Avoir un âge minimum pour une tâche est bien car au début, chaque tâche semble être extrêmement importante, mais si vous attendez un peu, son importance diminuera souvent de manière significative. En fonction de votre intervalle de temps, cela vous donnera au moins ce temps de stabilité dans les tâches sur lesquelles vous travaillez.

Pour suivre l'âge, vous autoriseriez les tâches à être ajoutées à une liste, mais elles ne seraient pas considérées comme des tâches sur lesquelles travailler avant l'expiration de cette période.

C'est un problème très courant, quelle que soit la vitesse à laquelle un projet avance sur le plan technique, le client le perçoit comme allant beaucoup plus lentement et se sent libre de modifier les exigences car il aime penser que les développeurs ne doivent pas faire grand-chose de toute façon.

Cette perception erronée provient de trois tâches de développement majeures qui prennent du temps et ne seront jamais correctement prises en compte par les clients:

1. Revues de code / nettoyage: l'ancien code est gonflé et foiré et nécessite des révisions et des nettoyages réguliers, cela prend beaucoup de temps et le client ne le croira jamais.
2. Audit de sécurité et correctifs: Surtout si vous avez des membres d'équipe juniors, vous aurez beaucoup de problèmes de sécurité liés au code et vous voudrez parcourir régulièrement tout ce nouveau code qui a été écrit et réécrire des choses qui ne semblent pas bonnes à partir d'une sécurité perspective, le client ne saura jamais ou ne tiendra pas compte de ce temps.
3. Modifications liées à l'architecture: une base de code croissante peut (et très probablement) nécessitera à plusieurs reprises une révision structurelle et une refactorisation, ce qui peut impliquer: A - Modifications / optimisations liées aux performances (modifications d'algorithmes, remplacements de bibliothèques, moteurs de cache, ... etc.) ou: B - Changements / optimisations liés à la productivité (lisibilité, réutilisabilité du code, facilité de compréhension, nouvelles conventions de codage, nouveau framework, ... etc).

Rien de ce qui précède ne sera jamais compris et correctement pris en compte par les clients finaux.

Fondamentalement, tout ce qui n'a pas de "vues" (éléments GUI) n'a pas été fait.

Appelons cela le théorème du projenix, haha ​​non, je plaisante: D