Comment gérez-vous un arriéré de produits important?

Question

Nous avons un important arriéré de choses que nous devons faire dans notre logiciel, dans beaucoup de catégories différentes, par exemple:

• nouveaux problèmes pour nos produits pour résoudre
• Les nouvelles fonctionnalités de soutien les problèmes existants
• nouvelles fonctionnalités demandées par nos utilisateurs existants
• utilisabilité et améliorations « look »
• Mises à niveau d'architecture à l'arrière-plan
• Bug f ixes

La gestion de tous ces éléments de manière rationnelle est un travail qui relève de la gestion des produits, mais c'est difficile pour de nombreuses raisons. Tout d'abord, nous avons différents systèmes qui contiennent des choses différentes (documents sur les exigences du marché dans les fichiers, bogues dans une base de données de bogues, besoins des clients dans notre système d'assistance, liste de souhaits d'enginering sur notre intranet, etc.). Et deuxièmement, beaucoup d'éléments sont de taille, d'envergure, de complexité et bien sûr de valeur très différents, ce qui signifie que le choix n'est pas aussi simple que de simplement classer une liste par priorité. Parce que nous sommes maintenant assez grands, que nous avons un produit complexe et beaucoup de clients, les solutions de base (une feuille de calcul, un google doc, une liste de choses à faire) ne suffisent pas. Nous avons besoin d'un moyen de regrouper les choses de diverses façons, de les hiérarchiser de façon continue, de préciser ce que nous faisons et ce qui s'en vient - sans que cela demande à tout le monde de gérer un outil.

Comment gérez-vous cela d'une manière qui permette à l'entreprise de toujours faire ce qui est le plus précieux pour les clients existants, d'en obtenir de nouveaux et de maintenir le bon fonctionnement du logiciel? Notez que cela est différent du développement, ce que je pense que nous avons assez bien. 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 dur!

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

Addendum: Bien sûr, il est bien d'abord de corriger tous les bogues, mais dans un vrai système qui est réellement installé sur les machines des clients, ce n'est pas toujours pratique. Par exemple, nous pouvons avoir un bug qui ne se produit que très rarement et qu'il faudrait beaucoup de temps et de bouleversements architecturaux à résoudre - nous pourrions laisser cela pour un moment. Ou nous pourrions avoir un bug où quelqu'un pense que quelque chose est difficile à utiliser, et nous pensons que le corriger devrait attendre une plus grande refonte de cette zone. Donc, il y a beaucoup de raisons pour lesquelles nous ne les réparons pas tout de suite, mais nous les gardons ouverts pour que nous n'oublions pas. De plus, c'est la priorisation des non-bogues qui est la plus difficile; Imaginez que nous n'en avons pas :)

Answer 1

Gérer un important carnet de commandes de manière agressive est presque toujours un gaspillage. Au moment où vous arrivez au milieu d'une pile prioritaire les choses ont le plus souvent changé. Je vous recommande d'adopter quelque chose comme ce que Corey Ladas appelle un filtre prioritaire:

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

Essentiellement, vous avez quelques seaux de taille croissante et priorité décroissante. Vous permettez aux parties prenantes de les remplir, mais les forcez à ignorer le reste des histoires jusqu'à ce qu'il y ait des ouvertures dans les seaux. Très simple mais très efficace.

Editer: Allan a demandé ce qu'il faut faire si les tâches sont de tailles différentes. Fondamentalement, une grande partie de faire ce travail est juste de dimensionner vos tâches. Nous appliquons uniquement cette hiérarchisation aux user stories. Les histoires d'utilisateur sont généralement beaucoup plus petites que «créer un site communautaire». Je considérerais le site de la communauté comme une épopée ou même un projet. Il devrait être divisé en morceaux significativement plus petits afin d'être priorisé.

Cela dit, il peut toujours être difficile de créer des histoires de taille similaire. Parfois, vous ne pouvez pas, alors vous communiquez cela lors de vos décisions de planification.

En ce qui concerne déplacer des morceaux de deux pixels, beaucoup de ces choses qui sont faciles peuvent être faites pour "libre". Vous devez juste faire attention à équilibrer ces derniers et ne les faire que s'ils sont vraiment proches de la liberté et ils sont en fait assez important.

Nous traitons les bugs de la même manière. Bugs obtiennent l'une des trois catégories, maintenant, bientôt ou éventuellement. Nous corrigeons les bogues aussi vite que possible avec la seule différence étant que nous publions les correctifs. Finalement, les bugs ne sont pas résolus à moins que les développeurs ne s'ennuient et n'aient rien à faire ou qu'ils deviennent plus prioritaires.

Answer 2

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

Answer 3

Je pense que vous devez les mettre tous en un seul endroit afin que la priorité soit donnée. Devoir rassembler plusieurs sources différentes rend cela pratiquement impossible.Une fois que vous avez cela, alors quelqu'un/un groupe doit classer chaque bug, fonction demandée et développement souhaité.

Les choses que vous pouvez donner la priorité par sont:

• valeur ajoutée au produit
• importance aux clients, existants et potentiels
• échelle de la tâche

Answer 4

Vous devez résoudre tous les bogues d'abord et seulement ensuite penser à ajouter de nouvelles fonctions.

Answer 5

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

est également utile les quarts de cercle de priorisation (deux dimensions: l'importance, l'urgence) que Covey propose: http://www.dkeener.com/keenstuff/priority.html. Concentrez-vous sur l'important et urgent, puis l'important et pas urgent. Les choses non importantes ... eh bien ... si quelqu'un veut faire ça dans ses heures de repos :-). Une variante des quadrants Covey que j'ai utilisés est avec les dimensions de Importance et Facilité. Facilité est un bon moyen de hiérarchiser les tâches dans un quadrant Covey.

Answer 6

Au-delà de tout outil et le processus, il devrait y avoir ... des gens;)

Dans notre boutique, il est appelé Manager version et il détermine le prochain périmètre fonctionnel pour l'expédition en production.
Ensuite, il y a un Freeze Manager qui connaît réellement le code et les fichiers et les bogues (il est généralement l'un des programmeurs), et applique les choix du gestionnaire de versions, et surveille les fusions nécessaires pour avoir quelque chose à tester puis relâcher.

Entre les deux, un ordre de priorité peut être établie, tant au niveau élevé (demandes fonctionnelles) et à faible niveau (bugs et problèmes techniques)

Answer 7

Toutes ces choses pourraient être suivis par un système de suivi de bug qui présente les caractéristiques suivantes:

• Possibilité de marquer les éléments de travail comme des bugs ou des demandes d'améliorations
• champ Catégorie pour la région de la responsabilité que l'élément de travail relève (IU, back-end, etc.)
• version # Fi domaine lorsque le correctif ou la fonctionnalité est prévue à faire
• champ Etat (en cours, achevé, vérifié, etc.)
• domaine prioritaire

Answer 8

La clé est la catégorisation et la hiérarchisation agressive.

Résolvez les problèmes qui éloignent les clients rapidement et ajoutez plus de fonctionnalités pour que les clients continuent de venir.Repousser les problèmes qui affectent seulement un petit nombre de personnes à moins qu'ils ne soient très faciles à résoudre.

Answer 9

Puisque vous faites des choses déjà en mode agile, vous pouvez emprunter quelques idées de XP:

• mis tous vos histoires en gros tas de cartes d'index (ou un tel outil)
• maintenant Les développeurs doivent estimer la taille de ces histoires (les développeurs ont le dernier mot)
• et laisser le client (ou son chef de produit similaire) commander ces histoires par leur valeur commerciale (ici le client a le dernier mot)
• et si les développeurs pensent qu'il y a quelque chose de technique qui est plus important (comme réparer ces bugs), ils doivent le communiquer au client et faire en sorte que le client atteigne cette priorité (le client a encore le dernier mot). autant d'histoires pour l'itération suivante en tant que votre vitesse équipes permet

de cette façon:

• il y a une seule file d'attente de la tâche, commandée par entreprise a besoin
• clients obtiennent le meilleur rendement de leur investissement
• développement valeur commerciale est la clé, pas la technologie ou les geeks
• développeurs faire dire comment les choses difficiles sont à mettre en œuvre
• s'il n'y a pas ROI, la tâche reste près du fond de cette pile

Pour en savoir plus informations, voir Planification de programmation extrême par Kent Bech et Martin Fowler. Ils le disent beaucoup mieux que je ne peux jamais faire.