Un backlog de tâches «de la taille d'une bouchée» en parallèle du backlog de la fonctionnalité «principale»?

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?

Je vais parler de quelques points qui, espérons-le, vous aideront à trouver votre chemin:

1. " SCRUM ", c'est être agile. Le bon sens est requis. Si le changement est un changement de quelques minutes, je ne pense pas que vous ayez besoin d'un arriéré pour cela. Si c'est plus de 2 heures, je pense que vous devriez y réfléchir. Tout ce qui est «facile à gagner» ne doit pas être fait. Dans SCRUM, vous travaillez par priorité. Je pense que le PO doit obtenir les informations sur ce que vous gagnez de l'ajout et l'effort qu'il faut. Ce n'est qu'alors que le bon de commande peut décider si c'est important ou non. Passer à SCRUM, vient parfois avec beaucoup de questions et les développeurs diront souvent "mais cela ne prendra que quelques heures". Et alors? Quelques heures, c'est du temps, tout ce qui est court n'a pas besoin d'être inclus.
2. J'ai déjà travaillé sur un projet où nous avions un "backlog d'ingénierie" . Ce backlog contenait des éléments suggérés par les développeurs pour améliorer le produit. Ces éléments n'avaient pas de valeur utilisateur explicite (mais avaient une valeur utilisateur implicite). Par exemple: refactoring d'un composant dans le code. Nous avions décrit le changement, l'effort et le gain (dans ce cas, vous ne pouvez rien présenter à l'utilisateur. Mais si un tel refactoring provoque le développement de nouvelles capacités plus rapidement, c'est définitivement un gain pour l'utilisateur). Notre OP a décidé que pendant la version, nous devrions investir 10% de chaque sprint (en moyenne) dans de tels articles. Avant chaque sprint, lorsque l'OP décidait du carnet de commandes du sprint à venir, il s'assurait que 10% des éléments du carnet de commandes étaient en train d'être créés. Donc , le backlog de 2 versions -> 1 backlog de sprint.
3. Tampons - Quand on commence à travailler chez SCRUM, les gens oublient souvent qu'en tant qu'ingénieurs en logiciel, nous partons dans un monde d'incertitude. C'est ok pour compter 1 jour de travail comme 6 heures au lieu de 8. Disons que vous avez un sprint de 15 jours, cela signifie que vous avez 30 heures supplémentaires pour les réunions, les choses qui ont pris trop de temps, et oui - aussi pour ces petits des choses qui sont trop mineures pour être mémorisées mais qui font partie de notre travail quotidien.
4. Restez concentré - Last but not least, dans SCRUM, il est important de rester concentré. Décidez combien de votre effort total, et quelle est la priorité, pour investir dans de telles tâches et n'oubliez pas d'investir ce temps et cet effort. Ne dérivez pas pour travailler sur des "petites choses" juste parce qu'elles sont petites. Vous avez un bon de commande pour vous aider à décider et vous avez votre bon sens.
5. Restez agile - Et, à la fin, n'oubliez pas d'essayer différentes méthodes pour aborder le problème, demandez-vous si c'est bien la meilleure façon. Améliorez en cours de route.

Bonne chance :)

Les cadres de programmation comme Agile et SCRUM sont conçus pour appliquer la discipline et la structure au développement. Cependant, la discipline et la structure semblent être les antonymes du plaisir et de la créativité. En règle générale, vous devez travailler plus dur pour établir et maintenir la discipline. Il est très difficile de trouver un équilibre entre ces concepts opposés. Par conséquent, les cadres ont tendance à éviter le sujet.

Lors de mon dernier projet, nous avons observé que les développeurs avaient besoin d'un peu de temps chaque jour pour se rafraîchir ou se vider la tête, etc. raison (avec la possibilité d'être appliqué à quelque chose au travail). Pour garder les choses disciplinées, on leur a demandé de documenter leurs activités afin de pouvoir obtenir des crédits pour toutes les réalisations, etc.

Btw, nous avons appelé le nôtre "cool projet" et il a fini par être la source de nombreuses bonnes idées et améliorations dans cette entreprise.

Vous devez conserver les petites histoires dans l'arriéré principal.

Je fais face à des problèmes similaires à ce que vous décrivez, bien que je n'utilise pas Scrum. Je vois que vous faites face à des défis de priorisation et d' efficacité .

Il semble que sous votre "ancienne façon", n'importe qui était implicitement autorisé à faire de sa tâche la "priorité absolue" actuelle s'il visitait le bureau d'un développeur. Cela présente certains avantages. Le demandeur a l'impression qu'on lui répond, et le demandeur et le développeur obtiennent un «gain rapide».

L'inconvénient est que l'insertion fréquente de ces tâches a tendance à ralentir ou à faire dérailler les tâches prioritaires qui ont été convenues avec le propriétaire du produit. (Remarque: souvent, tout le monde sous-estime le temps nécessaire à ces corrections «rapides».)

D'après mon expérience, essayer de se faufiler dans une tâche de faible priorité mine les avantages de la priorisation. En tant que développeur, la priorisation me confirme que je travaille sur ce que le propriétaire du produit veut que je travaille. La propriétaire du produit doit décider si elle souhaite assumer le travail supplémentaire et le risque (même léger) de plier une demande "agréable à avoir".

Souvent, lorsque je demande aux parties prenantes d'établir des priorités, on me demande "Pouvez-vous simplement insérer cela?". Le souhait implicite est pour moi de terminer comme par magie la nouvelle tâche sans affecter la priorité la plus élevée actuelle.

Ce qui m'arrive souvent, c'est que les parties prenantes demandent LargeImportantProject et SmallLessImportantTask. Le dilemme est le suivant: SmallLessImportantTask doit-il attendre la fin de LargeImportantProject (ou avoir un barrage routier)? Il y a des compromis, et mon expérience a été que le propriétaire du produit doit décider. (Si le propriétaire du produit ne décide pas, l'équipe de développement doit deviner.)

L'un des objectifs de Scrum (et de la gestion de projet en général) est d'éviter les barrages routiers pour les tâches les plus prioritaires. Au fur et à mesure que vous devenez plus efficace, il y a moins de place pour intégrer un travail supplémentaire "agréable à avoir".

L'efficacité peut être effrayante, mais j'ai vu les avantages l'emporter sur le coût de deux manières importantes.

1. Au fur et à mesure que vous devenez plus efficace, vous augmentez la capacité de votre équipe à effectuer un travail précieux, qui comprend des demandes «agréables à avoir».
2. Si une demande est vraiment "agréable à avoir", il est probablement parfaitement légitime d'attendre que des priorités commerciales plus importantes soient traitées.

À mon avis; votre problème est la façon dont les tâches sont hiérarchisées dans le backlog. Par exemple, la «priorité» pourrait tenir compte à la fois de l'importance et de la rapidité avec laquelle elle peut être réalisée. Quelque chose qui n'est pas aussi important mais qui peut être achevé en 10 minutes peut avoir une priorité plus élevée que quelque chose de plus important qui prendra plusieurs semaines à mettre en œuvre.

Je travaille en agile depuis un moment maintenant. Tout ce que je peux dire, c'est ceci: il y a des situations où insister sur une méthodologie et tout ce qu'elle incorpore est absolument faux. Vous devez être AGILE, et modifier une méthodologie pour des situations spécifiques est, l'OMI, un must.

Comme Avi l'a dit ci-dessus - "SCRUM", c'est être agile. Le bon sens est requis. Si le changement est un changement de quelques minutes, je ne pense pas que vous ayez besoin d'un arriéré pour cela.

Si le changement prend du temps, cela signifie qu'il n'est pas du tout "inoffensif" et qu'il devrait être bien documenté.

Sur la base de votre question initiale et des clarifications ultérieures, voici ce que j'ai perçu que vos points douloureux sont

• Des exigences en constante évolution
• Incapacité des développeurs à se concentrer sur d'autres domaines de l'application, par exemple. nous sommes des héros sur une partie de l'application mais nous ne voulons pas en toucher une autre.
• Différentes approches de l'architecture, des solutions et des cadres adoptés
• Le processus de collecte des exigences ne semble pas fonctionner

Scrum, s'il est initialement respecté correctement, devrait résoudre un grand nombre de ces problèmes et, plus important encore, mettre en évidence d'autres problèmes qui devraient être résolus.

- Des exigences en constante évolution

Avoir un seul carnet de commandes dans lequel tout est alimenté et hiérarchisé correctement devrait signifier que l'équipe ne devrait pas supporter le poids des exigences changeantes au milieu du développement. S'il s'agit d'un environnement très dynamique, des sprints plus petits de 1 ou 2 semaines devraient garantir que les priorités changeantes peuvent toujours être facilitées dans un laps de temps relativement court.

- Incapacité des développeurs à se concentrer sur d'autres domaines de l'application, par exemple. nous sommes des héros sur une partie de l'application mais nous ne voulons pas en toucher une autre.

Une équipe Scrum travaillant bien ensemble et se soutenant mutuellement, avec une volonté spécifique de partager les connaissances au sein de l'équipe et à la recherche du défi de travailler sur d'autres parties de l'application, cherchera à garantir que les connaissances de l'application soient partagées. Certaines pratiques comme la programmation en binôme peuvent aider les gens à surmonter leur peur de travailler sur du code qu'ils ne connaissent pas tout en apprenant et en partageant ces connaissances. Cela peut prendre quelques sprints avant que la connaissance de l'application soit répartie entre les équipes et que les gens soient à l'aise de travailler sur n'importe quel domaine de l'application. En outre, permettre aux gens de retirer les tâches d'un tableau, c'est-à-dire de faire leur propre choix sur ce qu'ils aimeraient travailler, peut encourager cela.

- Différentes approches de l'architecture, des solutions, des cadres adoptés

Scrum facilite une meilleure communication, il facilite le travail d'équipe et une meilleure prise de décision ainsi qu'une plus grande visibilité sur ce qui se passe. C'est à son tour devrait faciliter les décisions organisationnelles autour de l'utilisation des cadres, des solutions architecturales, etc. et l'utilisation d'un mécanisme Scrum of Scrums peut aider à inculquer cela dans toute l'organisation.

- Processus de collecte des exigences

Encore une fois, si vous respectez strictement les règles, si une exigence n'est pas spécifiée et prête pour que l'équipe soit en mesure de comprendre et d'estimer ce qui est nécessaire pour remplir l'exigence, elle ne doit pas être introduite dans le sprint. Prenez une autre exigence qui est une priorité élevée et qui a été bien définie ... car alors vous savez que vous serez en mesure de répondre à cela! Bien qu'il ne puisse pas résoudre le processus de collecte des exigences immédiatement, il forcera la modification requise pour obtenir ce processus fixe.

Pour répondre à votre première question, non, il ne devrait pas y avoir deux arriérés distincts. À tout moment, il est dans l'intérêt de tous que les développeurs et l'organisation travaillent d'abord sur les éléments les plus prioritaires. Les priorités devraient être principalement basées sur la valeur commerciale, et il est tout à fait possible que de nombreux petits ajustements et demandes ajoutent une valeur commerciale. Laissez le propriétaire du produit décider de cela.

Je suis Scrum Master depuis plus de 7 ans et j'ai aidé à l'introduction de Scrum dans de nombreuses équipes et entreprises différentes. À mon humble avis et d'après mes observations, je pense que si Scrum est introduit dans votre organisation pour la toute première fois, suivez-le par le livre. Ne déviez pas. Scrum requiert de la discipline pour pouvoir s'en tenir aux pratiques et aux processus. Il est trop facile de faire des exceptions pour s'adapter à certaines circonstances, et si cela est fait trop tôt, cela entraînera l'érosion des avantages et des valeurs qu'il entraîne. Faites les bases, faites-les vraiment bien. Devenez un expert pour faire les bases et comprendre pourquoi elles sont là, puis changer le processus pour mieux l'adapter et conduire à l'amélioration continue au sein de votre organisation.

Il y a des cas très valables pour dire que c'est "Agile", donc nous devons être prêts à changer le processus, mais il y a une différence significative entre une équipe autogérée et auto-organisée comprenant le processus et discutant des changements qui pourraient être apportés à le processus, par opposition à une équipe qui commence seulement à suivre le chemin de l'Agile ou du Scrum. C'est comme essayer de courir avant de savoir ramper ...