Comment gérez-vous les coûts d'un changement trop rapide?

Comme la plupart des développeurs modernes, j'apprécie les principes Agile comme la collaboration client et la réponse au changement, mais que se passe-t-il lorsqu'un propriétaire de produit (ou celui qui détermine les exigences et les priorités) change trop souvent les exigences et les priorités? Comme plusieurs fois par jour?

J'ai récemment hérité d'une petite base de code qui était boguée, incomplète et ne pouvait même pas gérer le scénario le plus simple qu'il était censé faire. Je peux m'occuper des problèmes techniques mais je reçois plusieurs courriels, textos ou appels téléphoniques par jour disant "OMG tu DOIS travailler sur ce droit MAINTENANT! TOP PRIORITY! C'est un MUST !!! oneone" (ce n'est qu'une légère exagération) Ce qui est encore pire, c'est que la plupart des choses sont des détails mineurs qui ne sont même pas pertinents pour ce que le logiciel est réellement censé faire et prendraient des jours de toute façon. J'ai essayé d'expliquer qu'il n'y a que si peu de temps et que nous devons d'abord nous concentrer sur les choses les plus importantes, mais quelque chose semble se perdre dans la traduction car la même chose se produit un jour ou deux plus tard.

Existe-t-il une sorte de rôle de Product-Owner-Handler, d'étude approfondie, de métaphore ou de citation qui peut m'aider à réduire la quantité d'efforts gaspillés ou au moins à expliquer les coûts de ce comportement chaotique?

C'est à cela que sert l'arriéré. Les nouvelles demandes sont placées dans l'arriéré et les priorités ne peuvent changer que sur les limites de l'itération. Un délai moyen d'une semaine (la moitié d'un sprint de deux semaines) est suffisamment agile pour gérer toutes les urgences, sauf les plus graves.

Voici comment j'ai traité un problème similaire. À l'époque où nous étions agiles avant Agile.

Pour toute demande de modification, le client définit la priorité. Le développeur peut uniquement et doit arrêter le travail sur une tâche pour travailler sur une tâche de priorité plus élevée. Les tâches de priorité égale sont des horaires par ordre d'arrivée. (La priorité des tâches ne peut pas être modifiée une fois le travail commencé.)

Cela vous fera mal lorsque vous dites au client que vous ne pouvez pas travailler sur sa tâche car vous travaillez sur une tâche X sans importance qui a la même priorité que sa dernière demande. Vous lui dites ensuite qu'à ce niveau de priorité, il y a 50 tâches triviales et sans importance avant sa dernière demande. Maintenant, le vrai piège - toutes ces tâches sont au niveau de priorité 1 (le plus élevé), défini par ... LUI ... Donc, il ne peut pas vous supplanter de la tâche que vous faites. Maintenant, lorsque vous avez terminé de déplacer le cadre de la fenêtre de 3 pixels vers la gauche pour faire de la place pour le mot plus long dans la traduction islandaise sur l'option de configuration rarement utilisée .....

J'ai également fermé la porte du bureau SD, je l'ai verrouillée et j'ai décroché les téléphones. Les e-mails ont été ignorés jusqu'à 10h00, 12h00 et 14h00. Malgré ce que les gens pensaient et ressentaient, le monde tournait toujours autour du soleil, nous avons fait notre travail et les «clients» ont reçu des logiciels plus rapidement et mieux que par le passé.

Il a fallu quelques semaines pour que les priorités se règlent sur quelque chose de plus réaliste, nous avons pu déverrouiller la porte etc ... Mais le système est resté assez longtemps. Vous n'aurez peut-être pas besoin d'être aussi extrême (nous l'avons fait) et aurez besoin du soutien de la haute direction. Mais cela fonctionnera ....

AMADOUER. Procédure d'exploitation standard (ou au moins un protocole souple approuvé par votre équipe de gestion). Votre service doit en développer un ou travailler avec votre équipe de direction pour en développer un. Les personnes à qui vous devez parler sont au-dessus du propriétaire du produit / gestionnaire de compte.

Quelques exemples de ce que votre SOP devrait définir.

• Quelles procédures doivent être suivies lorsqu'un client ou une entité interne demande un changement
• Quelles sont les implications et / ou l'impact sur le contrôle qualité ou la vérification de ce produit?
• Quelle est la méthode pour déterminer raisonnablement un délai de livraison? Cette itération? Prochaine version?

Sans de telles procédures en place, tout le monde va vous courir dessus comme s'il était poursuivi par des zombies et s'attendre à tout MAINTENANT MAINTENANT. Les gens comme ça ne respecteront pas votre «non» poli ou «veuillez patienter. Avec une politique ferme en place, ces mutants qui ont soif de code comprendront qu'ils ont tort lorsqu'ils demandent des choses sur une base aussi lâche.

Le résultat final est mécontent de vous, et ce n'est pas dans le meilleur intérêt de votre entreprise.

D'un autre côté, vous avez peut-être hérité du désordre de quelqu'un causé par un tel manque de respect flagrant pour sa position et son devoir. Les gens dans cette situation ont du mal à produire des produits de qualité. Est-il étonnant? Génie logiciel 101.

Il est très difficile de travailler dans ces conditions "prêt, tirer, viser". Il me semble que vous recevez des exigences d'une personne très précaire, dont l'opinion change chaque fois qu'une personne de niveau supérieur suggère une idée conceptuelle.

Dans ce genre de situations, j'ai trouvé utile d'attendre AU MOINS une heure avant de répondre aux e-mails. (J'ignorerais les textes, à moins que les SMS aient largement remplacé les courriers électroniques par votre organisation dans son ensemble.) Lisez-les, peut-être, mais ne répondez pas. De cette façon, vous pouvez passer votre temps à vous concentrer sur le travail réel que vous devez faire, pas sur la discussion des urgences aléatoires qui peuvent devenir inutiles demain, ou même deux ou trois courriels plus tard. Dans mon dernier emploi, si quelque chose était VRAIMENT urgent, quelqu'un viendrait me parler en personne, en supposant que je n'avais pas encore vu les courriels (si vous travaillez à distance, un appel téléphonique avec une conversation bidirectionnelle réelle peut être le équivalent).

Lorsque vous avez un face à face ou une conversation téléphonique, il est utile de répéter ce que la personne demande dans vos propres mots, puis de poser vos questions sur les nouvelles exigences et la priorité. "Si je comprends bien, vous dites que nous devrions cesser de travailler sur la priorité actuelle supérieure X et maintenant nous concentrer sur la priorité de la minute Y. C'est un grand changement. Pouvez-vous expliquer le changement dans l'entreprise? Je devrais peut-être faire plus de contexte travail que simplement changer l'interface utilisateur. Y aura-t-il des changements dans d'autres processus commerciaux, comme la facturation ou l'inventaire (par exemple)? Allez-vous vous attendre à ce que ces nouveaux éléments de données apparaissent sur tous les rapports mensuels? " Il est également utile de dire quelque chose dans le sens de "Vous comprenez que si nous poursuivons ce nouvel effort, cela retardera la libération de la priorité X actuelle d'au moins un (semaine, mois,

S'il s'agit d'une véritable urgence, le demandeur devrait être en mesure de répondre à ce genre de questions ou de vous référer immédiatement à quelqu'un qui le pourrait. S'il ne s'agit pas d'une véritable urgence, ce type de conversation obligera le demandeur à ralentir et à déterminer l'importance réelle du changement, étant donné qu'il a besoin de vous obtenir plus d'informations. Souvent, ils verront que ce qui est déjà dans le tuyau est plus important, ou du moins ne vaut pas la peine d'être arrêté, et la nouvelle demande peut être inscrite sur la liste.

Si les modifications sont jugées nécessaires, j'ai trouvé utile d'écrire ce qui était demandé et votre compréhension des modifications dans un e-mail, et de l'envoyer au demandeur d'origine, lui demandant s'il était d'accord sur la portée de la modification, encore une fois, à titre de clarification. De cette façon, vous avez une documentation écrite de ce qui doit être fait, et pourquoi cela a été demandé, au cas où il y aurait un retour en arrière sur les raisons pour lesquelles vous ne travaillez plus sur Current Top Priority X, ou devez expliquer pourquoi les délais d'origine ne vont pas à respecter.

Nous espérons que cela améliorera votre relation avec le demandeur, car vous démontrez vos connaissances et vous assurez que vous travaillez sur ce qu'ils veulent, mais vous êtes honnête sur ce qu'il faut pour apporter des changements. En posant des questions sur la demande en détail, ils voient que vous pensez à l'avance et envisagez des choses qu'ils pourraient ne pas avoir à l'origine.

Il semble que personne ne l'ait encore mentionné, Sprint et ses histoires d'utilisateurs ideally should be locked till the next sprint(le sprint typique prend de 2 à 4 semaines). Par verrouillage - je veux dire qu'aucune tâche supplémentaire ne doit être ajoutée dans Sprint déjà démarré.

Si la user story est suffisamment grande pour ne pas s'adapter au sprint, limitez-la à des tâches plus petites et réalisables pendant le sprint. De plus, comme mentionné, même les tâches prioritaires doivent être conservées dans le carnet de commandes , et lors du prochain sprint, la planification de haute priorité une fois le drapeau levé :)

Edit: seuls des changements mineurs peuvent être introduits au printemps. s'ils portent l'état d'urgence. Cependant, s'il y a toujours quelques urgences pendant le sprint, alors quelque chose doit être changé dans la planification du sprint lui-même.

Scrum a le rôle Scrum Master, qui serait la personne qui devrait résoudre les problèmes que vous avez mentionnés.

S'il y a quelqu'un comme un chef d'équipe, un chef de projet, un maître de mêlée, etc. qui est responsable, je parlerais à cette personne.

J'ai essayé d'expliquer qu'il n'y a que si peu de temps et que nous devons d'abord nous concentrer sur les choses les plus importantes, mais quelque chose semble se perdre dans la traduction car la même chose se produit un jour ou deux plus tard.

Je pense que vous devrez continuer à l'expliquer encore et encore et encore. On dirait que vous devrez peut-être accepter que certaines personnes avec lesquelles vous travaillez ont des habitudes inutiles. Si vous avez de la chance, vous verrez éventuellement un changement.

Le Manifeste Agile dit que l'un des principes les plus fondamentaux est:

Bienvenue aux exigences changeantes, même en retard de développement Les processus agiles exploitent le changement pour l'avantage concurrentiel du client.

Cependant, je ne pense pas que cela signifiait un changement au quotidien. Vous devrez peut-être modifier le prix de base d'un produit plusieurs fois par jour, mais pas changer la façon dont ce produit peut être vendu plusieurs fois par jour. Le flux de travail des ventes d'un produit peut plutôt changer sur une base hebdomadaire (dans les entreprises très réactives et dynamiques).

Encore une fois, bien que le flux de travail des ventes d'un produit puisse changer chaque semaine, je pense que le produit global ne sera pas changé chaque semaine. Je ne peux pas imaginer un Microsoft qui nous donne aujourd'hui Office, mais demain nous donnera Offooose, et une semaine plus tard Offasooooooooooos.

Non, ce n'est pas ce que signifie le changement par agilité. Je crois que cela vient de mauvaises visions et d'un grand malentendu profond sur le concept de changement.

Sans parler de mentionner que le changement n'est pas le bienvenu dans un sprint, où les développeurs se rendent dans leurs grottes et doivent se concentrer sur ce qu'ils font. Au lieu de cela, les changements doivent être ajoutés au Product Backlog, et être analysés et hiérarchisés avant d'être remis aux mains de l'équipe Scrum. En d'autres termes, un Sprint Backlog n'est pas immuable. Plus d'agilité doit être recherchée en utilisant des sprints plus courts, et non en injectant directement dans les salles de développement, plusieurs fois par jour.