Partager via


Recommandations pour la formalisation des pratiques de gestion du développement de logiciels

S’applique à cette recommandation de la liste de contrôle d’excellence opérationnelle bien conçue : Power Platform

OE:03 Formalisez le processus d’idéation et de planification de logiciels, en vous basant sur les normes industrielles et organisationnelles établies. Utilisez un backlog commun et hiérarchisé et des spécifications suffisamment détaillées. Favorisez les améliorations continues du processus de planification en fonction des résultats.

Ce guide décrit les recommandations pour la gestion des pratiques de développement de la charge de travail conformément aux normes établies. La capacité de votre équipe à produire des logiciels de haute qualité repose sur une approche structurée et collaborative de la planification du développement. Les équipes de charge de travail doivent comprendre et communiquer clairement aux parties prenantes le travail en cours Terminé. Plus précisément, les équipes de charge de travail doivent avoir une vision claire du travail à effectuer dans un cycle de développement et s’assurer que toutes les parties prenantes sont alignées sur le "pourquoi" de ce travail. Les normes établies définissent la manière dont les pratiques de développement doivent être exécutées et permettent à l’équipe de la charge de travail de collaborer efficacement, ce qui réduit le risque de confusion sur les objectifs et les attentes.

Stratégies de conception clés

Formalisez les pratiques de développement de votre charge de travail pour garantir une compréhension commune des objectifs et des attentes.

Ne considérez pas les charges de travail Terminé comme étant de faible complexité. Vous bénéficiez toujours de la formalisation du développement et de la gestion des charges de travail promouvoir. Apprenez des autres équipes de développement de logiciels. Mettez en place une matrice de décision qui dicte le niveau de formalisation requis en fonction de la complexité et de la criticité de la charge de travail.

Normes pour la planification du développement

Les normes suivantes peuvent vous aider à concevoir une stratégie globale de planification du développement.

  • Priorisation : la planification de l’ordre et de la portée du travail implique de comprendre l’impact et la valeur réels des fonctionnalités de charge de travail sur l’entreprise. Cela inclut également d’évaluer ces impacts par rapport à d’autres demandes de travail et à la feuille de route globale de votre produit ou programme. Une façon de prioriser les charges de travail consiste à évaluer la valeur commerciale de l’ensemble de la charge de travail. Vous trouverez peut-être également utile d’évaluer les fonctionnalités individuelles de la charge de travail pour en déterminer la valeur commerciale.

  • Catégorisation : établir des processus qui garantissent que les applications critiques disposent des garde-fous nécessaires pour les prendre en charge. Dans le même temps, veillez à ce que les scénarios de productivité ne soient pas ralentis ou étouffés par trop de processus rigoureux.

  • Collaboration : Le processus de définition des modifications proposées à la charge de travail doit être un effort collaboratif. La plupart des modifications apportées à la charge de travail affectent plusieurs fonctions et composants. Par conséquent, impliquer autant de membres de l’équipe de charge de travail que possible permet de garantir que les considérations importantes ne sont pas oubliées et que chacun est conscient de l’effet sur son domaine particulier. La collaboration permet également de définir clairement la portée d’un changement et de diviser les tâches nécessaires en éléments de travail bien définis. Un groupe plus large, doté d’une expertise dans plusieurs domaines, est en mesure de fournir des estimations fondées sur l’expérience concernant l’effort requis.

  • Outils : utilisez des outils et des processus établis et éprouvés dans le secteur, tels que Agile, Scrum et les tableaux Kanban.

Compromis : la méthodologie Agile peut devenir trop stricte si elle est trop prescriptive. Recherchez un équilibre entre les normes bien définies et l’innovation.

  • Déploiement : prévoyez d’utiliser des déploiements itératifs fréquents et de petite taille plutôt que des déploiements importants et peu fréquents.

  • Conditions : Normalisez votre définition des cycles de développement terminés pour garantir que les fonctions de support, notamment les tests, la documentation et les fonctionnalités d’accessibilité, sont exécutées avec succès.

  • Communication : Définir les protocoles standards pour les propriétaires de produits et les chefs de projet pour les prochaines versions.

  • Histoires d’utilisateurs : Standardiser un modèle pour les histoires d’utilisateurs. Les récits utilisateur bien écrits doivent suivre l’approche INVEST :

    • I – Indépendant : chaque récit utilisateur doit être indépendant des autres, ce qui permet à l’équipe de le délivrer par petites étapes progressives.
    • N – Négociable : les récits utilisateur doivent être négociables et ouvertes à la discussion et au changement.
    • V–Valeur : les user stories doivent apporter de la valeur au client.
    • E – Estimable : les récits utilisateur doivent être estimables et avoir une définition claire du travail effectué.
    • S – Petit : les récits utilisateur doivent être petits et axés sur une seule fonctionnalité.
    • T – Testable : les récits utilisateur doivent être testables et avoir des critères d’acceptation clairs.
  • Critères d’acceptation : Normaliser un modèle pour les critères d’acceptation. Assurez-vous que les critères d’acceptation sont liés spécifiquement au récit utilisateur et peuvent être prouvés sans ambiguïté à l’aide d’un ou de plusieurs tests d’acceptation.

  • Traçage : garantir que le processus de développement est traçable. Vous devez clairement retracer l’état de votre charge de travail de production et le code associé jusqu’aux tests d’assurance qualité, aux critères d’acceptation, aux récits utilisateur et aux fonctionnalités. Un traçage détaillé peut également constituer une exigence réglementaire dans certains cas, comme dans le domaine des soins de santé.

  • Révision : Effectuez régulièrement des audits internes de vos pratiques de développement au moyen de rétrospectives et d’autopsies du cycle de développement. La réflexion sur le processus doit être objective et se concentrer sur l’apprentissage qui peut être appliqué comme améliorations. Assurez-vous que l’équipe réfléchit à l’efficacité du récit utilisateur et des tâches dans la définition des tâches nécessaires et à l’exactitude des estimations de temps.

  • Rapports : normalisez les rapports destinés aux parties prenantes qui fournissent des mesures utiles axées sur le changement. Se concentrer sur le changement vous permet de suivre l’accélération et la décélération du produit. Les mesures utiles peuvent inclure des changements dans :

    • Taux de croissance mensuel de l’adoption
    • Performances
    • Temps de formation
    • Fréquence des incidents

    Les rapports ne doivent pas être utilisés comme un outil pour évaluer le travail des individus ; par conséquent, évitez les mesures telles que les story points ou les lignes de code pour chaque ingénieur.

Facilitation de Power Platform

Bien qu’il n’existe aucun produit facilitant directement cette recommandation, vous pouvez utiliser d’autres outils de la pile. Power Platform Microsoft Azure Boards est un service Web qui permet aux équipes de planifier, de suivre et de discuter du travail tout au long du processus de développement.

GitHub Projects est un outil de gestion de projet personnalisable permettant d’organiser des projets et s’intègre à vos problèmes et demandes d’extraction dans GitHub.

Étapes suivantes