Comment gérez-vous un arriéré de produits volumineux? [fermé]

Question

Nous avons un important arriéré de tâches à effectuer dans notre logiciel, dans de nombreuses catégories différentes, par exemple:

• Nouveaux problèmes à résoudre pour nos produits
• Nouvelle fonctionnalité prenant en charge les problèmes existants
• Nouvelle fonctionnalité demandée par nos utilisateurs existants
• Ergonomie et "look " améliorations
• Mises à niveau architecturales vers le back-end
• Corrections de bugs

La gestion de tous ces éléments de manière judicieuse est un travail qui incombe à la gestion des produits, mais qui est délicat pour de nombreuses raisons. Premièrement, nous avons un certain nombre de systèmes différents qui contiennent des éléments différents (exigences du marché documentées dans des fichiers, bogues dans une base de données de bogues, exigences du client dans notre système de support technique, liste de souhaits des ingénieurs sur notre intranet, etc.). Et deuxièmement, la plupart des éléments sont de taille, d’envergure, de complexité et bien sûr de valeur différente, ce qui signifie que choisir n’est pas aussi simple que de simplement ordonner une liste par priorité.

Étant donné que nous sommes maintenant assez grands, que nous avons un produit complexe et de nombreux clients, les solutions de base (un tableur, un document Google, une liste de tâches à effectuer dans un camp de base) ne suffisent tout simplement pas. Nous avons besoin d’un moyen de regrouper les éléments de différentes manières, de les hiérarchiser en permanence, de préciser ce que nous faisons et ce qui nous attend, sans que cela prenne tout le temps de quelqu'un pour gérer un outil.

Comment gérez-vous cela de manière à permettre à l'entreprise de toujours faire ce qui a le plus de valeur pour les clients existants, d'aider à en obtenir de nouveaux et de maintenir les règles logicielles en bon état?

Notez que cela diffère du développement, que nous avons assez bien, je pense. Nous développons tout de manière itérative et agile, et une fois que quelque chose a été choisi pour la conception et la mise en œuvre, nous pouvons le faire. C'est la partie où nous devons déterminer ce qu'il faut faire ensuite, c'est le plus difficile!

Avez-vous trouvé une méthode ou un outil qui fonctionne? Si oui, s'il vous plaît partager! (Et si vous souhaitez également connaître la réponse, évaluez la question pour qu'elle reste visible:)

Addendum: Bien sûr, il est agréable de corriger tous les bogues en premier, mais dans un système réel installé sur les ordinateurs des clients, ce n'est pas toujours pratique. Par exemple, il se peut que nous ayons un bogue qui ne se produit que très rarement et qu'il faudrait beaucoup de temps et de bouleversements architecturaux pour le réparer - nous pourrions en rester là un moment. Ou nous pourrions avoir un bug où quelqu'un pense que quelque chose est difficile à utiliser, et nous pensons que le résoudre devrait attendre une plus grande refonte de cette zone. Donc, il y a beaucoup de raisons pour lesquelles nous ne les réparons pas tous immédiatement, mais les gardons ouverts pour ne pas les oublier. De plus, c'est la priorisation des non-bogues qui est la plus difficile; Imaginez que nous n’en avons pas:)

Answer 1

La gestion agressive d’un arriéré important est presque toujours une perte de temps. Au moment où vous arrivez au milieu d'une pile prioritaire, les choses ont très souvent changé. Je recommanderais d'adopter quelque chose comme ce que Corey Ladas appelle un filtre de priorité:

http://leansoftwareengineering.com/2008/08/19/priority-filter /

En gros, vous avez quelques compartiments de taille croissante et de priorité décroissante. Vous autorisez les parties prenantes à les remplir, mais les obligez à ignorer le reste des histoires jusqu'à ce qu'il y ait des ouvertures dans les compartiments. Très simple mais très efficace.

Modifier: Allan a demandé quoi faire si les tâches sont de tailles différentes. Pour faire ce travail, il est essentiel de bien dimensionner vos tâches. Nous appliquons cette hiérarchisation uniquement aux user stories. Les histoires d'utilisateurs sont généralement beaucoup plus petites que "créer un site communautaire". Je considérerais le site communautaire peu comme une épopée ou même un projet. Il faudrait le décomposer en bits beaucoup plus petits pour pouvoir être hiérarchisé.

Cela dit, il peut toujours être difficile de faire des histoires de la même taille. Parfois, vous ne pouvez tout simplement pas, alors vous le communiquez lors de vos décisions de planification.

En ce qui concerne le déplacement des pixels de deux pixels, bon nombre de ces tâches faciles peuvent être effectuées "gratuitement". Vous devez juste faire attention à les équilibrer et à ne les faire que s’ils sont vraiment proches de la liberté et qu’ils sont en fait assez importants.

Nous traitons les insectes de la même manière. Les insectes sont classés dans l'une des trois catégories suivantes: maintenant, bientôt ou éventuellement. Nous corrigeons les bugs Now et Soon aussi rapidement que possible, la seule différence étant que nous publions les correctifs. Finalement, les bugs ne sont pas réparés à moins que les développeurs ne s’ennuient et n’aient rien à faire ou qu’ils deviennent plus prioritaires.

Answer 2

La clé est la catégorisation agressive et la priorisation.

Résolvez les problèmes qui éloignent rapidement les clients et ajoutez des fonctionnalités supplémentaires pour les fidéliser. Résolvez les problèmes qui ne concernent qu'un petit nombre de personnes, à moins qu'ils ne soient très faciles à résoudre.

Answer 3

Une technique simple consiste à utiliser une matrice de priorisation.

Exemples:

• http://erc.msh.org/quality/pstools/ psprior2.cfm

• http: // it. toolbox.com/blogs/enterprise-solutions/sample-project-prioritization-matrix-23381

Covey propose également les quadrants de priorité (deux dimensions: Importance, Urgence): http : //www.dkeener.com/keenstuff/priority.html . Concentrez-vous sur les points importants et urgents, puis sur les points importants et non urgents. Les trucs non-importants… bien… si quelqu'un veut le faire pendant ses heures creuses :-). Une variante des quadrants de Covey que j'ai utilisée concerne les dimensions Importance et Facilité. La facilité est un bon moyen de hiérarchiser les tâches dans un quadrant Covey.

Answer 4

Je pense que vous devez tous les réunir au même endroit pour pouvoir les hiérarchiser. Devoir rassembler plusieurs sources différentes rend cela pratiquement impossible. Une fois que vous avez cela, quelqu'un / un groupe doit classer chaque bogue, chaque fonctionnalité demandée et chaque développement souhaité.

Les éléments que vous pouvez prioriser sont les suivants:

• Valeur ajoutée au produit
• Importance pour les clients, existants et potentiels
• Echelle de la tâche

Answer 5

Vous devez corriger tous les bogues en premier, puis penser à y ajouter de nouvelles fonctions.

Answer 6

Tout cela pourrait être suivi par un bon système de suivi des bogues doté des fonctionnalités suivantes:

• Possibilité de marquer des éléments de travail en tant que bogues ou demandes d'amélioration
• Champ de catégorie pour la région de responsabilité dans laquelle l'élément de travail est situé (interface utilisateur, serveur principal, etc.)
• Champ n ° de version pour le moment où le correctif ou la fonctionnalité doit être exécuté
• Champ d'état (en cours, terminé, vérifié, etc.)
• Champ de priorité

Answer 7

Puisque vous travaillez déjà de manière agile, vous pouvez emprunter quelques idées à XP:

• mettez toutes toutes vos histoires dans un gros tas de fiches (ou un outil similaire)
• les développeurs doivent maintenant estimer la taille de ces histoires (ici les développeurs ont le dernier mot)
• et laissez le client (ou son mandataire - comme le chef de produit) classer ces récits en fonction de leur valeur commerciale (le client a le dernier mot)
• et si les développeurs pensent que quelque chose de technique est plus important (comme la correction de ces bugs embêtants), ils doivent le communiquer au client (personne d’affaires) et le faire passer à la priorité (le client a toujours le dernier mot)
• sélectionnez autant d'histoires pour la prochaine itération que la vitesse de votre équipe le permet

De cette façon:

• il existe une seule file d'attente de tâches, classée par besoins de l'entreprise
• les clients obtiennent le meilleur retour sur leur investissement
• la valeur commerciale est le moteur du développement, pas la technologie ou les geeks
• Les développeurs ont la possibilité de dire combien il est difficile de mettre en œuvre
• s'il n'y a pas de ROI , la tâche reste au bas de la pile

Pour plus d'informations, voir Planification de la programmation extrême de Kent Bech et Martin Fowler . Ils le disent bien mieux que je ne pourrais jamais le faire.

Answer 8

Je ne suis pas sûr que l'outil soit aussi critique que le processus. J'ai vu des équipes réussir avec quelque chose d'aussi simple que des fiches et des tableaux blancs pour gérer des projets assez volumineux. Une chose que je recommanderais dans la hiérarchisation est de vous assurer que vous avez une liste complète de ces éléments ensemble. De cette façon, vous pouvez peser la priorité de la résolution d'un problème par rapport à une nouvelle fonctionnalité, etc.

Answer 9

Au-delà de tout outil et processus, il devrait y avoir ... certaines personnes;)

Dans notre boutique, il est appelé responsable de la publication et il détermine le prochain périmètre fonctionnel d'expédition de la production.
Il existe ensuite un gestionnaire Freeze qui connaît le code, les fichiers et les bogues (il est généralement l'un des programmeurs), qui imposera les choix du gestionnaire des versions et surveillera les fusions nécessaires afin de: avoir quelque chose à tester et ensuite relâcher.

Entre eux deux, une hiérarchisation peut être établie, tant au niveau haut (demandes fonctionnelles) qu'au niveau bas (bugs et problèmes techniques)