Après plus de deux ans de travail dans une structure de développement très cloisonnée, "loup solitaire", nous adoptons Agile SCRUM. Génial. J'aime Agile; en tant que développeur, il vous permet de rester concentré, occupé et productif sans qu'une myriade d'intervenants ne vous poussent projet après projet dans l'attente qu'ils soient tous effectués hier.
Il y a, cependant, un aspect du passage à SCRUM par rapport à notre "modèle" actuel, que je pense que les gens en dehors du développement n'aimeront pas du tout. C'est leur capacité actuelle à nous faire faire de petits changements "pendant que vous attendez". Une grande partie de notre développement est destinée à la consommation interne uniquement, et nous sommes pour la plupart tous dans le même bâtiment. Ainsi, il est courant depuis des années qu'un chef de service ou un gestionnaire ailleurs vienne voir le "propriétaire de la base de code" d'une application particulière et demande de petites choses (parfois pas si petites, mais nous sommes plutôt bons de ne pas en prendre trois- projets hebdomadaires basés sur ces "drive-bys"). Même notre patron relaie parfois des choses qui lui ont été rapportées de cette façon. Très souvent, si nous travaillons dans la base de code en question à l'époque, nous pouvons simplement afficher le fichier source,
Avec une méthodologie de base Agile SCRUM, ces ajustements seraient soit enregistrés comme des défauts (nous ne répondions pas à une exigence spécifiée dans une histoire précédemment consommée) ou de nouvelles petites histoires (nous répondions à toutes les exigences énoncées, mais ces exigences étaient incomplètes, vagues ou incorrectes , ou ils ont changé après la livraison une fois que les utilisateurs ont vu les nouvelles fonctionnalités). Quoi qu'il en soit, la grande majorité serait au plus un pointeur sinon des zéros et de priorité relativement faible (le système est utilisable dans son état actuel, mais il serait tellement plus cool si ...), ce qui les rend peu susceptibles d'être amené dans un sprint lors de l'utilisation du backlog top-down.
Cette possibilité a été évoquée lors d'une réunion de développement comme étant une source d'opposition active à notre processus Agile par d'autres départements, qui le verraient comme moins "agile" que notre capacité actuelle à faire de petits ajustements sur demande. C'est une préoccupation valable de l'OMI; les parties prenantes derrière l'OP ne sont pas toujours d'accord sur les choses les plus importantes, car elles n'ont pas toutes le même point de vue, mais ce ne sont généralement que les gestionnaires qui prennent la décision finale, et donc leur parti pris est celui qui s'affiche dans le backlog de produit.
Une solution a alors été proposée, qui a été provisoirement appelée le "pot de bonbons" (un autre terme jeté était le "saucière"). Petits ajustements demandés par les "petits gars" dans les différents départements, qui ne sont pas des défauts dans une histoire existante, qui sont estimés par consensus ou acclamation au sein de l'équipe pour prendre moins de la moitié d'une journée développeur, et cela aurait un impact immédiat, significatif et positif sur l'expérience utilisateur de l'avis de l'utilisateur final, sont mis sur une liste en parallèle du backlog principal. Ils seraient identifiés comme des «histoires», mais seraient séparés de l'arriéré principal des «grandes» histoires soumises à un ordre de priorité. Si, à tout moment pendant le déroulement normal d'un sprint, nous travaillons dans une zone du système dans laquelle l'un de ces ajustements peut être effectué, rendant le tweak trivial, nous pouvons apporter le tweak dans le sprint et le coder à côté de l'histoire plus large. Ce faisantne doit pas compromettre l'achèvement de l'histoire plus vaste ou de tout autre travail engagé. Le bon de commande aurait également accès à cette liste, et s'il travaillait sur une prochaine user story touchant la fonctionnalité de base impliquant le tweak, il pourrait la replier dans l'histoire en tant qu'exigence, puis nous répondrions à l'exigence comme nous le ferions autre. On pensait que cela rendrait les ajustements plus susceptibles d'être travaillés plus tôt que tard.
Cela a déclenché la réaction parmi ceux d'entre nous avec une formation ScrumMaster "uh-uh". Il y a un arriéré. Deux backlogs introduisent la question de savoir quel élément # 1 est vraiment le plus important, quels éléments de la liste déterminent la vitesse réelle et dans lequel des deux backlogs une histoire appartient réellement (toute démarcation de taille / complexité va avoir des cas qui tombent relativement arbitrairement d'un côté ou de l'autre). "Que le processus fonctionne", avons-nous dit; si le changement est vraiment important pour les utilisateurs finaux, ils feront assez de bruit pour amener les chefs de département à prendre des décisions temps / argent à bord, et cela se heurtera à la conscience de l'équipe de développement vers le haut de l'arriéré.
Je pensais poser la question au sol: à votre avis, une liste parallèle d'histoires «de la taille d'une bouchée» aurait-elle de la valeur à obtenir plus rapidement des changements petits, utiles mais finalement de faible priorité, ou est-ce globalement une meilleure décision les replier dans l'arriéré principal et laisser le processus de base régir leur inclusion dans un sprint?