Scrum / Agile: Comment envisagez-vous les améliorations internes? [fermé]

Question

Au cours des deux dernières années, j’ai travaillé au sein de deux équipes différentes utilisant l’approche Agile / Scrum. Les deux équipes étaient impatientes d’améliorer leur approche du développement logiciel. Dans la première équipe, nous pouvions facilement convaincre notre propriétaire de produit d’avoir du temps pour des tâches internes, telles que l’amélioration du système de compilation, la mise en place de tests d’intégration plus performants, la définition d’une meilleure stratégie de publication, etc. il est plus repoussant, ce qui est raisonnable car il doit également faire ses affaires.

Quoi qu'il en soit, ma question est la suivante: comment les autres équipes gèrent-elles cela? Créez-vous une histoire d’amélioration et la mettez-vous sur la table lors de la planification ou gardez-vous un "compartiment"? de temps pour de telles choses? Dans votre expérience, at-il été difficile de convaincre le responsable du produit d’avoir le temps de s’améliorer? Après tout ce genre d’améliorations profitera à l’équipe, mais pas directement ou immédiatement au propriétaire / entreprise de Prodcut.

Answer 1

Excellente question. Je pense qu'il existe plusieurs types d'items d'action. des rétrospectives qui méritent des approches différentes.

1) des tâches techniques pour résoudre des problèmes tels que l’endettement technique ou l’amélioration de l’infrastructure - telles que "Nous devons nous assurer que nous n’avons pas d’appel de base de données dans la couche de visualisation de notre application, ce qui nous a fait perdre du temps lors de la dernière itération ... Quelqu'un devrait faire une recherche dans le code pour s'assurer que nous ne le faisons pas ailleurs. "

2) Améliorations des processus (par exemple, "les gens ne se présentent pas à l'heure prévue ... commençons par verser un don de 1 $ à un organisme caritatif chaque fois que quelqu'un est en retard".)

La première catégorie peut être un travail important ou peut être simple. L’exemple que j’ai montré est assez simple… mais peut générer d’autres tâches à planifier (par exemple, supprimer les appels de base de données dans les 5 emplacements où ils ont été découverts).

La deuxième catégorie doit être gérée / pilotée par le responsable des itérations, le responsable du projet, le responsable Scrum, etc. Je les répertorie généralement sur un wiki de projet et en parle en rétrospective, vérifie-les. éteint quand ils sont adressés, et faire rapport à l'équipe sur le statut. Je garde le feu allumé.

Je pense que l'erreur dans la première catégorie - les tâches techniques - est que nous ne définissons pas de critères d'acceptation. Vos exemples incluaient "l'amélioration du système de compilation, la mise en place de meilleurs tests d'intégration, une meilleure stratégie de publication". Celles-ci ne sont pas déterministes et doivent être énumérées en termes précis (en utilisant des pointes si nécessaire). Donc, l’amélioration du système de compilation peut commencer par une tâche technique ou un pic pour évaluer les options.

Nous devons également ventiler et hiérarchiser les tâches techniques (par exemple, "de meilleurs tests d'intégration" pourrait commencer par une tâche technique consistant à définir la couverture d'intégration actuelle ou à évaluer le pourcentage de bogues pouvant être imputés aux échecs d'intégration. construire le cas pour l'investissement là-bas.

Une fois que vous avez défini vos priorités, vous pouvez alors transmettre la valeur des éléments hautement prioritaires et négocier avec le propriétaire du produit le temps à consacrer à ces éléments. Je ne suis pas un grand fan des compartiments prédéfinis à dépenser pour quoi que ce soit ... mais avoir la conversation avec le propriétaire du produit avec des exigences précises, un retour sur investissement et des critères d'acceptation est la clé.

Answer 2

Les améliorations doivent faire partie du sprint de la même manière que les nouvelles fonctionnalités. Il appartient à l'équipe de démontrer au Product Owner que ces améliorations sont nécessaires pour le prochain sprint. Cela peut ralentir la vitesse à laquelle de nouvelles fonctionnalités sont produites, mais cela est finalement utile pour le produit.

D'autre part, j'ai des problèmes avec les sprints qui ne contiennent que des améliorations. Chaque sprint doit produire une sortie pouvant être démontrée au Product Owner.

Answer 3

Méthodes Crystal utilise le concept de l'atelier de réflexion pour: Ajustez votre processus de développement. Les équipes se rencontrent périodiquement (peut-être moins souvent que votre cycle de développement) pour discuter des améliorations et de l'état du processus. Trouve 0-3 choses que nous avons essayées cette fois qui ont fonctionné et que nous allons garder, 1-3 choses qui ne fonctionnent pas et 1-3 choses à essayer la prochaine fois. L’idée est d’améliorer progressivement le processus et le produit.

Answer 4

L'année dernière, j'ai travaillé pour l'un des tout premiers adeptes / consultants / formateurs Agile (xp). Je pense qu'il avait une bonne approche.

Nous nous sommes rencontrés chaque vendredi et nous avons juste discuté de ce qui fonctionnait et de ce qui ne fonctionnait pas. Nous les écrivions sur deux grandes feuilles de papier (il était vraiment dans le papier au lieu du tableau blanc car il était plus permanent et pouvait être repositionné plus facilement).

Les choses qui ont fonctionné pourraient être très simples: nous avons bien dialogué en équipe, les paires se sont déroulées sans accroc, etc.

Les choses qui ne fonctionnaient pas étaient aussi simples et aléatoires. Certaines personnes pourraient résister à l’égalité des chances ou même "Le patron ne nous a pas emmenés sur son bateau comme promis".

Chaque semaine, nous reviendrions également sur le passé "Nous n’avons pas travaillé". et voyons si nous les avons corrigés - Dans l’affirmative, ils figureraient toujours dans cette semaine " travaillait " colonne.

Même si nous discuterions de solutions spécifiques, le simple fait de résoudre les problèmes au grand jour avait généralement un effet très positif. S'ils sont restés sur le lien "N'a pas fonctionné" liste pendant 3 ou 4 semaines, nous discuterions de solutions différentes / meilleures et ferions davantage une tentative délibérée de les mettre en œuvre.

Après qu'un élément a passé une semaine ou deux dans le champ "Travaillé bien" colonne, nous la laisserions tomber car elle était plus ou moins attendue (à moins que cela ne continue à s’améliorer).

Cela a également rendu les vendredis après-midi un peu plus intéressants dans la mesure où la réunion a été très amusante et à laquelle tout le monde pouvait participer.

Answer 5

Je voudrais utiliser un «pic» pour de telles choses. Une amélioration interne / des processus ne peut pas être une histoire d’utilisateur, mais une pointe parfaite.

Answer 6

Je n’ai pas grand chose à ajouter ici, mais j’estime qu’une ressource devrait être affectée à ces questions liées à l’amélioration de l’environnement et que les tâches ne devraient pas figurer sur les tableaux de répartition. S'il s'agit d'un matériel supplémentaire requis pour ce projet, il aurait dû être ajouté et budgété à l'avance. Donc, en fin de compte, ils ne devraient pas avoir d'incidence sur le nombre d'heures allouées, mais tout travail affecté à la suite de ces problèmes devrait faire l'objet d'une justification.

Answer 7

Non, il ne faut pas créer des user stories techniques: en théorie, et comme elles n'apportent généralement aucune valeur directe au client, elles ont très peu de chances d'être sélectionnées dans une itération. Convaincre le responsable de produit est une option pour y remédier, mais il existe un autre outil qui peut être utilisé ici: le relâchement.

Slack est une petite partie de votre temps d’itération réservée à ces tâches d’amélioration. Si tout s'est bien passé pendant l'itération, vous pourrez utiliser ce temps pour ces améliorations. D'autre part, vous aurez une autre chance de respecter vos engagements au cas où l'équipe serait trop engagée pour l'itération (ou si une tâche était sous-estimée, plus difficile que prévu ...)

Un autre avantage de l'utilisation de mou est que cela réduira la variation de la vitesse car vous respecterez probablement vos engagements plus souvent, sans recourir à des heures supplémentaires.

Consultez Tom DeMarco Slack: dépasser le surmenage, le travail intense et le mythe du total Efficacité (lien Amazon) - ISBN 0767907698.