Share via

Recommandations pour formaliser le développement et la gestion de logiciels

  • Article

S’applique à cette recommandation de liste de contrôle d’excellence opérationnelle Azure Well-Architected Framework :

OE :03 Formaliser les processus d’idéation et de planification des logiciels. Tirez parti des normes établies de l’industrie et de l’organisation. Utilisez un backlog commun et hiérarchisé et des spécifications suffisamment détaillées. En fonction des résultats, améliorez continuellement votre processus de planification.

Ce guide décrit les recommandations relatives à la gestion des pratiques de développement logiciel conformément aux normes établies. La capacité de votre équipe à produire des logiciels de haute qualité s’appuie sur une approche structurée et collaborative de la planification du développement. Les propriétaires et les gestionnaires de produits doivent être en mesure de comprendre clairement et d’articuler avec les parties prenantes le travail que les développeurs effectuent à tout moment dans un cycle de développement. À l’inverse, les développeurs doivent comprendre les objectifs du cycle de développement via des fonctionnalités bien écrites, des récits utilisateur et des critères d’acceptation. Les normes établies définissent la façon dont les pratiques de développement doivent être exécutées et permettent à l’équipe de charge de travail de collaborer efficacement, ce qui réduit le risque de confusion par rapport aux objectifs et aux attentes.

Stratégies de conception

Formalisez vos pratiques de développement logiciel pour vous assurer que les propriétaires de produits, les responsables de projet et les développeurs comprennent les objectifs de chaque sprint et fournissent une qualité cohérente aux parties prenantes. Pour passer en revue les conseils sur les pratiques de développement, consultez le guide d’intégration continue.

Normes pour la planification du développement

  • 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 ont un impact sur plusieurs fonctions et/ou composants. Ainsi, l’implication du plus grand nombre possible de membres de l’équipe de charge de travail permet de s’assurer que les considérations importantes ne sont pas manquées et que tout le monde est conscient de l’impact sur leur domaine particulier. La collaboration permet également de définir clairement l’étendue d’un changement et de diviser les tâches nécessaires pour accomplir la modification en éléments de travail bien définis, car un groupe plus important disposant d’une expertise dans différents domaines sera en mesure de fournir des estimations soutenues par l’expérience pour l’effort requis.

  • Outils : Utilisez des outils et des processus établis et éprouvés dans le secteur, comme les tableauxAgile, Scrum et Kanban. Le développement de vos propres outils et processus est une entreprise importante, qui prend du temps et des cycles de développement qui pourraient autrement être consacrés à votre charge de travail. La plupart des ingénieurs DevOps et des propriétaires de produits sont familiarisés avec ces types d’outils et de processus, de sorte que la courbe d’apprentissage lors de leur adoption doit être minimale. De même, le processus d’intégration pour les nouveaux employés tirera également parti de l’utilisation d’outils et de processus standard, car ils sont susceptibles d’avoir déjà un degré d’exposition aux mêmes outils et processus.

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

  • Déploiement : prévoyez d’utiliser de petits déploiements itératifs fréquents au lieu de grands déploiements peu fréquents. L’utilisation de cette approche permet de maintenir les récits utilisateur et les éléments de travail gérables du point de vue de la gestion de projet et de réduire le risque de problèmes à grande échelle en cas d’échec des déploiements.

  • Termes : Standardisez votre définition des cycles de développement terminés pour vous assurer que les fonctions de prise en charge, y compris les fonctionnalités de test, de documentation et d’accessibilité, sont terminées avec succès.

  • Communication : Définissez les protocoles standard pour les propriétaires de produits et les chefs de projet afin de promouvoir les prochaines versions en interne et en externe. Par exemple, vous pouvez établir une norme pour les communications avec des parties externes sur les prochaines versions. La norme peut dicter que la communication doit être envoyée deux semaines avant la publication et qu’un rappel doit être envoyé 24 heures avant la publication.

  • Témoignages utilisateur : standardisez un modèle pour les récits utilisateur. Assurez-vous que chaque récit utilisateur est une unité de travail discrète, écrite du point de vue de l’utilisateur final. Les récits utilisateur bien écrits doivent avoir les caractéristiques suivantes :

    • Chaque histoire utilisateur doit être totalement indépendante l’une de l’autre. Le fait de garder les récits utilisateur indépendants les uns des autres évite toute confusion avec le chevauchement du travail et aide l’équipe à comprendre si le travail sur un récit utilisateur donné repose sur le travail sur d’autres, ce qui aide à la planification et à la hiérarchisation.

    • Chaque histoire utilisateur est négociable. Les perspectives des utilisateurs finaux et des membres de l’équipe de charge de travail sont essentielles pour capturer des témoignages d’utilisateurs réalistes qui peuvent être réalisés sur une courte période de temps.

    • Les témoignages utilisateur sont précieux pour l’utilisateur final. Lorsque vous écrivez des récits utilisateur du point de vue de l’utilisateur final, vous capturez les modifications qu’il souhaite voir et qui ajouteront de la valeur à son expérience. Le fait de garder ce focus à mesure que l’histoire utilisateur est divisée en éléments de travail permet de garantir que chaque déploiement offre une expérience améliorée.

    • L’effort requis pour une histoire utilisateur est possible avec un degré élevé de confiance. Sans être en mesure d’avoir une approximation étroite des heures requises pour un récit d’utilisateur donné, la planification sera difficile et le risque d’échéances manquantes augmente, ce qui pourrait avoir des effets en cascade sur d’autres travaux planifiés.

    • Les récits utilisateur bien écrits sont petits, de sorte qu’ils peuvent être terminés en quelques semaines. Les histoires de portée plus petite aident à les garder estimables et gérables et aident à garder les éléments de travail réalisables.

    • Les témoignages utilisateur doivent être testables. Sans pouvoir tester qu’une fonctionnalité a été fournie, l’utilisateur final ne peut pas être sûr que l’objectif a été atteint. Même si un test n’a pas encore été écrit pour une histoire utilisateur donnée, il doit y avoir une compréhension claire de la façon dont un test peut être développé pour prouver la livraison de la fonctionnalité.

  • Critères d’acceptation : standardisez un modèle pour les critères d’acceptation. Assurez-vous que les critères d’acceptation concernent spécifiquement le récit utilisateur et qu’ils peuvent être prouvés sans ambiguïté à l’aide d’un ou de plusieurs tests d’acceptation.

  • Suivi : vérifiez que le processus de développement est traçable. Vous devez suivre clairement l’état de votre charge de travail de production et le code associé pour les tests d’assurance qualité, les critères d’acceptation, les témoignages utilisateur et les fonctionnalités. Le suivi détaillé peut également être une exigence réglementaire dans certains cas, comme les soins de santé, par exemple.

  • Révision : effectuez régulièrement des audits internes de vos pratiques de développement via des rétrospectives de cycle de développement et des post-mortems. La réflexion sur les processus doit être irréprochable et doit se concentrer sur l’apprentissage qui peut être appliqué en tant qu’améliorations. Veillez à ce que l’équipe réfléchisse à l’efficacité de l’histoire utilisateur et des tâches dans la définition des tâches nécessaires et à l’exactitude des estimations de temps.

  • Rapports : standardisez les rapports pour les parties prenantes qui fournissent des métriques utiles axées sur le changement. Vous concentrer sur le changement vous permet de suivre l’accélération et la décélération des produits. Les métriques utiles peuvent inclure des modifications dans :

    • Taux de croissance mensuel de l’adoption.

    • Les performances.

    • Temps d’entraînement.

    • Fréquence des incidents.

    La création de rapports ne doit pas être utilisée comme un outil pour évaluer le travail des individus. Par conséquent, évitez les métriques telles que des points d’histoire ou des lignes de code pour chaque ingénieur.

Facilitation Azure

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. Il est bien adapté aux pratiques de développement basées sur Agile.

GitHub Projects est un outil de gestion de projet personnalisable qui peut organiser des projets et s’intégrer à l’aide de problèmes et de demandes de tirage dans GitHub.

Liste de contrôle de l’excellence opérationnelle

Reportez-vous à l’ensemble complet de recommandations.

Liste de contrôle de l’excellence opérationnelle