Toute discussion sur les processus de développement de logiciels basée sur quelques approches classiques sur la création de logiciels modernes. Nous devons établir une certaine cadence pour livrer des produits avec la fréquence attendue en tenant compte des besoins du marché. Une longueur d'itération devrait refléter la vitesse nécessaire d'adaptation aux changements de backlog du produit. Les équipes devraient se préparer à chaque itération et préparer les éléments de backlog. Il semble que l'approche de gestion des priorités soit absolument intuitive et vous n'avez pas besoin d'avoir une compréhension profonde de la normalisation pour l'utiliser dans votre développement logiciel. Néanmoins, l'établissement de tout processus signifie la déclaration de principes généraux pour chaque membre de l'équipe. Et voici les complications: comment expliquer à tout membre de l'équipe ce que signifie un chiffre ou un mot à côté d'une tâche ou d'un bug de produit? Il est toujours possible d'inventer votre propre système de priorités, mais cela conduit à la nécessité d'expliquer les principes de votre système pour chaque nouveau membre de l'équipe. Si le projet est grand et que vous avez beaucoup de nouveaux collègues, alors c'est un problème. Par conséquent, il est plus facile d'utiliser des normes ou des approches internationales testées par le temps. Dans cet article, je voudrais discuter de l'utilisation de la méthode MoSCoW pour la priorisation dans le développement de produits comme de fait la façon la plus courante de rationaliser le travail pendant les itérations, qui fournissent des résultats rapides et mesurables. Pour illustrer, je vais fournir un exemple de la méthode de priorisation personnalisée et des problèmes que j'ai rencontrés avec cette approche. Un article peut être utile pour les gestionnaires de produits ou toute personne poursuivant le processus de développement de produits qui fonctionne bien. S’amuser avec l’approche personnalisée en ce qui concerne la priorité des éléments Il y a très longtemps, dans une équipe de produits, nous essayions de résoudre un problème avec des priorités d'éléments dans nos cycles de développement. Le processus lui-même était très immature: les délais de mise en œuvre ont souvent été violés, l'équipe a dû travailler des heures supplémentaires et les sorties de produits étaient de qualité insatisfaisante. À ce moment-là, nous avons utilisé des priorités numériques 1-2-3-4 et elles n'ont pas aidé du tout. Ensuite, nous avons décidé de rationaliser la communication entre les membres de l'équipe et introduit une priorité supplémentaire « 5 ». Cette priorité deviendrait la priorité la plus élevée, plus importante que « 1 », et signifierait « showstopper » - le billet ou l'article qui devrait être mis en œuvre Why is “5” more important than “1”? Because historically we had myriad priority “1” items, and “0” was used for the tasks that had to be prioritised later. Changing the meaning of “0” means a thoughtful review of the entire backlog, implementation of some migration, and nobody wanted to do it. How does it happen that we have so many priority “1” tasks in the iteration that we have to introduce an additional priority? And what is the purpose of 2-3-4? These are the most important questions that show the process immaturity, because team members had no idea what the difference was between 2-3-4. All these tasks were just “optional”. How do we explain these illogical rules to new team members? These rules were impossible to explain, and this improvement didn’t help to make things right. Bien sûr, une méthode de priorisation n’était pas le problème général dans ce processus. Il y avait des problèmes fondamentaux dans l’approche de la planification, de la gestion des risques et de la stratégie elle-même. Mais si vous avez beaucoup de défis sur votre table, l’invention de votre propre méthodologie obscure ne semble pas être la meilleure décision. Introduction de l’approche « MoSCoW » Certaines normes sont strictement codifiées dans les RFC de meilleures pratiques internationales d'organismes tels que l'IETF ou l'IEEE, tandis que d'autres sont devenues des normes en leur faveur. La méthodologie MoSCoW n'est pas la seule approche de la priorisation des tâches, mais l'une des méthodes les plus efficaces et universelles pour commencer à faire les choses correctement. L’approche a été proposée par Dai Clegg dans le livre « Le nom "MoSCoW" n'a pas de lien avec la capitale du nord et a été créé comme un acronyme de catégories de priorisation: Vous avez, Il faut avoir, Il y a, Ces catégories peuvent être associées à des priorités numériques 1-2-3-4 et aider à déterminer sans équivoque la séquence des tâches ou des éléments dans l'itération du développement du produit. Le but clair de chaque catégorie fait de cette méthode un tel joyau, et au cours de cet article, je voudrais couvrir chaque priorité avec des exemples dans le développement Agile. Méthode de cas Fast-Track: une approche RAD M S Co W Tout d’abord, il est nécessaire d’établir un scénario d’exemple pour l’utilisation de l’approche. Supposons que nous soyons membres d’une équipe de produits qui développe un produit B2B. Dans ce produit, nos clients peuvent stocker et échanger des fichiers pour leurs projets. Pour le rendre simple, notre équipe ajoutera quelques fonctionnalités de base, telles que « invitation utilisateur » - la fonctionnalité d’ajouter un nouveau participant à un projet. Nous avons promis à nos clients que nous mettrons cette fonctionnalité en œuvre à une certaine date; nous avons un engagement. Dans cet exemple, nous ne segmenterons pas les membres de l’équipe par spécialité (Dev, DevOps, QA), et nous imaginerons notre équipe comme une équipe canonique universelle Scrum. Le scénario d'invitation de l'utilisateur a préparé des exigences techniques, UX/UI. La fonctionnalité a déjà été décomposée en éléments significatifs qui ont du sens, et tous ces éléments ont été estimés. Il est grand temps d’utiliser une approche de priorisation, et sans plus d’inquiétude, nous allons catégoriser ces éléments. Il faut le faire - 1 La priorité « Must Have 1 » est utilisée pour les tâches, les fonctionnalités, les éléments de backlog de produits, les histoires d'utilisateurs ou les bugs qui doivent être inclus dans la prochaine itération de développement. Par exemple, au cours de la planification, nous avons réalisé que certaines tâches devraient être développées par le biais d'accords avec les clients ou qu'elles sont critiques pour une autre raison. L'idée principale est que ces éléments sont cruciaux et non négociables. L'équipe doit les estimer, assumer les risques et les planifier. Si l'estimation est supérieure au temps disponible, les éléments devraient être décomposés jusqu'à ce que le produit de valeur minimale (MVP) puisse être créé au cours de l'itération. Sur la base de l'exemple d'une nouvelle fonctionnalité de produit, supposons que nous souhaitons mettre en œuvre une fonctionnalité "inviter un nouvel utilisateur à un projet".La catégorie "Must Have" reflète les tâches MVP et crée des fonctionnalités de base.Le résultat de l'itération doit fournir un scénario significatif et des tâches appropriées pour la priorité "1": Implement the <Invite user> button in the project users list. Develop basic functions of the “Invite user” pop-up. Send a notification to the new user with authentication instructions. Il faudrait - 2 La seconde catégorie est proche du "Must Have". mais c'est quelque chose que nous pourrions reporter ou livrer plus tard. Si nous avons un accord avec le client sur les invitations d’utilisateurs, les fonctions MVP seront libérées comme options obligatoires dans la priorité « 1 ». Néanmoins, il y a toujours beaucoup d’améliorations qui sont nécessaires à mettre en œuvre, mais elles peuvent être omises dans la portée déclarée. Par exemple, dans la fonctionnalité « Invitation utilisateur », le produit devrait aider à mettre de nouveaux utilisateurs à bord. Dans la priorité « Il faut avoir », l'équipe développera le scénario critique de création et d'invitation. Mais il est également important d'envoyer des commentaires à l'administrateur invitant qu'un nouvel utilisateur s'est connecté avec succès. Il est possible d'utiliser la fonctionnalité sans ce commentaire, mais avec cette notification, le produit est certainement meilleur et l'administrateur saura que tout va bien. C'est ainsi que la deuxième priorité est établie - nous améliorons le processus principal, quelque chose d'important pour l'entreprise, tout en gardant à l'esprit que cette fonctionnalité est supplémentaire. Un bug de produit "doit avoir" est quelque chose qui brise le scénario, mais il y a une solution raisonnable, disponible pour un utilisateur ordinaire et non technique.Il est préférable de toujours corriger ces bugs pendant l'itération, mais ils pourraient être négociés près de la date limite, car il est toujours possible de les libérer. Peut être - 3 Cette catégorie concerne des améliorations ou des défauts visuels mineurs qui font une différence en général et qui pourraient améliorer la sensation globale du produit, mais ils ne sont pas critiques en ce moment ou profondément facultatifs pour le scénario. Il serait agréable de développer ces choses, uniquement si les risques des priorités "Must Have" ou "Should Have" sont atténués. Pendant la planification, l'équipe du produit devrait penser aux éléments "Could Have" comme cela: la première priorité doit être faite. Nous devrions faire le maximum d'efforts pour livrer la seconde priorité. Si tout va bien, nous nous attendons à développer des éléments prioritaires tiers, mais si nous avons échoué, cela ne devrait pas affecter les affaires. Dans le cas de la fonctionnalité "Invitation utilisateur", la troisième priorité est quelques améliorations supplémentaires dans le formulaire d'invitation utilisateur. En tant que troisième fonctionnalité de priorité, l'administrateur pourrait configurer des notifications automatiques si un utilisateur n'est pas connecté au cours des trois prochains jours. L'administrateur du projet pourrait envoyer ce rappel manuellement s'il remarquait l'absence d'une deuxième notification de priorité, mais il serait agréable de mettre en œuvre des rappels automatiques au départ. Sans cette amélioration, le produit fonctionne bien et remplit les conditions du contrat, ce qui le rend "pourrait avoir". Une priorité "peut avoir" en tant que bug produit est quelque chose de caractéristiques rares ou de bugs visuels qui sont reproduits dans certains environnements inhabituels. Ces bugs pourraient être corrigés si nous n'avons pas des fonctionnalités inachevées ou des bugs de produit d'autres catégories. Les bugs de troisième priorité pourraient être déplacés à la prochaine itération sans de longues négociations, car ils ne bloquent pas la sortie du produit. Par exemple, la majorité de notre base de clients utilise des navigateurs Web sur un moteur spécifique et nous avons un défaut insignifiant dans un moteur non populaire. Il serait génial de corriger ce bug, mais si tout le monde est occupé par des tâches plus importantes, il n'y a Il n'y en aura pas - 4 Une catégorie utile qui montre les éléments qui ne seront certainement pas libérés pendant l'itération. Cependant, il est important de les avoir s'il reste une certaine capacité. L'équipe de produit pourrait planifier les tâches d'itération et de segment et les bugs comme première, deuxième et troisième priorité. Et il arrive que les tâches soient plus faciles que prévu. Les développeurs auront du temps supplémentaire qui pourrait être utilisé pour la quatrième priorité. Ces éléments sont toujours développés en branches et ne sont jamais destinés à être fusionnés dans l'itération actuelle, mais cela facilite les choses pour la prochaine itération. Quels types de tâches conviennent à un backlog «ne pas avoir»? Tout d'abord, il y a des tâches de dette technique. Ceux très importants pourraient également être la priorité "Must Have" ou "Should Have", mais les améliorations régulières du code pour la maintenance de la base de codes sont un excellent exemple de la quatrième priorité. Les développeurs ont la possibilité d'améliorer le code après les tâches cruciales pour l'entreprise et d'utiliser ces améliorations dans les prochaines itérations. Si certains changements sont en panne et nécessitent une exécution de QA non typique, les améliorations effectuées avant de nouvelles itérations fournissent également une opportunité d'amélioration en temps opportun. En outre, il est utile d’ajouter comme priorité « Ne pas avoir » certains éléments qui seront la première priorité « Il faut avoir » dans la prochaine itération. Nous savons qu’après l’invitation d’utilisateur de base, nous devrions intégrer des paramètres de permission d’utilisateur détaillés dans ce scénario, pour simplifier le flux d’administrateur. Cette fonctionnalité sera le MVP de la prochaine itération. Si nous avons une certaine capacité, il est excellent de commencer à le développer comme une quatrième priorité; ce qui réduira les risques à l’avenir. Pendant la planification de la prochaine itération, la priorité de cet élément sera mise à jour à « Il faut avoir ». Il est préférable de ne pas avoir de bugs de produit de la quatrième priorité, car cette catégorie montre que le bug ne sera pas corrigé pendant l'itération et qu'il créera simplement un gâchis supplémentaire sur le tableau de bord. Néanmoins, la priorité pourrait être utilisée pour les bugs qui nécessitent des modifications architecturales qui sont dangereuses pour l'itération actuelle et leur test devrait être planifié dans la prochaine. Utilisation de l’approche prioritaire Au début de cet article, j'ai fait un exemple de l'approche de priorité personnalisée avec quatre catégories, que personne ne comprenait et que l'équipe doit introduire la cinquième priorité pour les tâches les plus importantes. Ces règles servent également de référence à l’équipe et aident à montrer les problèmes dans l’approche de planification d’équipe. Par exemple, si l’équipe ne peut pas développer tous les éléments planifiés de la première priorité «Il faut avoir», sans parler d’autres priorités, elle montre des problèmes profonds dans le processus: Les exigences de caractéristiques n'étaient pas aussi bonnes et claires. Il y a eu une erreur dans la décomposition. L’équipe a en quelque sorte sous-estimé la complexité des tâches. Quelqu'un a décidé de changer d'idée pendant l'itération. L'équipe doit fournir une rétrospective et déterminer la source du problème et trouver la solution pour corriger le processus de développement cassé. En même temps, l'achèvement stable des trois et quatrième priorités n'est pas si bon non plus. Cela signifie que nous sommes bons dans l'estimation et la gestion des risques, mais cela montre également que l'équipe est assez détendue ou sous-chargeuse. Peut-être que nous pourrions planifier des éléments supplémentaires des priorités "Must Have" ou "Should Have".Le processus de développement nécessite un équilibre et quelques défis pour garder tous les membres de l'équipe clairs et rechercher les améliorations. Les cons de l’approche Dans l’exemple ci-dessus, les tâches ont été catégorisées par priorité pour une itération particulière, mais cela ne signifie pas une priorité globale en fonction de l’activité de l’entreprise. Les tâches qui sont étiquetées « Peut avoir » dans l’itération actuelle pourraient devenir « Doit avoir » dans la prochaine, et ces changements nécessitent du temps supplémentaire pendant chaque session de planification pour le gestionnaire d’itération. En outre, l’approche a toujours un problème avec la séquence des tâches dans une catégorie. Si l’itération a peu d’éléments « Must Have », lequel d’entre eux devrait être développé en premier? Cette séquence devrait toujours être discutée par la planification de l’itération et coordonnée via un logiciel spécifique. Il n’y a pas de balle d’argent pour l’ensemble du processus de développement, mais l’utilisation d’approches telles que MoSCoW aide à rationaliser les processus de base. Conclusion Il existe de nombreuses méthodes et approches de priorisation. Cependant, je pense que l'approche MoSCoW est l'une des plus faciles à commencer par des améliorations générales au processus de développement de logiciels. Cette approche est plus appropriée pour les produits du marché B2B et le développement de produits avec des tâches et une vision clairement formulées. Il est nécessaire d'avoir un plan pour les itérations ultérieures pour utiliser cette approche correctement. Dans un environnement chaotique et en évolution rapide, cette approche peut mal fonctionner et créer tant de tâches de haute priorité, ce qui affectera la prévisibilité de la sortie. Le même problème peut apparaître sans des processus de planification et d'estimation appropriés.
