Recommandations pour formaliser le développement et la gestion des logiciels
S’applique à cette recommandation de liste de contrôle Azure Well-Architected Framework Operational Excellence :
| OE :03 | Formalisez l’idéation et la planification logicielles. Inspirez-vous des normes établies de l’organisation et du secteur d’activité. Utilisez un backlog commun, hiérarchisé et des spécifications suffisamment détaillées. En fonction des résultats, apportez des améliorations continues dans votre processus de planification. |
|---|
Ce guide décrit les recommandations relatives à la gestion des pratiques de développement de logiciels 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 propriétaires et les gestionnaires de produits doivent être en mesure de comprendre les parties prenantes et de leur expliquer clairement 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 par le biais de 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 effectuées et permettent à l’équipe de charge de travail de collaborer efficacement, ce qui réduit le risque de confusion sur les objectifs et les attentes.
Stratégies de conception
Formalisez vos pratiques de développement de logiciels pour vous assurer que les propriétaires de produits, les responsables de projets et les développeurs comprennent les objectifs de chaque sprint et fournissent une qualité cohérente aux parties prenantes. Pour consulter des conseils sur les pratiques de développement, consultez le guide d’intégration continue.
Établir des normes de collaboration et de communication
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 auront un impact sur plusieurs fonctions et/ou composants, ce qui permettra d’impliquer autant de membres de l’équipe de charge de travail que possible de s’assurer que les considérations importantes ne sont pas manquées et que tout le monde est conscient de l’impact sur son 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 le changement en éléments de travail bien définis, car un groupe plus vaste disposant d’une expertise dans différents domaines sera en mesure de fournir des estimations soutenues par l’expérience pour l’effort requis.
Communication : Définissez les protocoles standard pour les propriétaires de produits et les responsables de projets 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 au sujet des 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.
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 postmortems. La réflexion sur les processus doit être sans blâme et doit se concentrer sur l’apprentissage qui peut être appliqué en tant qu’améliorations. Assurez-vous que l’équipe reflète l’efficacité du récit utilisateur et des tâches dans la définition des tâches nécessaires et sur la précision des estimations de temps.
Rapports : normaliser les rapports pour les parties prenantes qui fournissent des métriques utiles qui se concentrent sur les changements. Le fait de vous concentrer sur les changements 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 de formation.
Fréquence des incidents.
La création de rapports ne doit pas être utilisée comme outil pour évaluer le travail des individus. Évitez donc les métriques telles que les points d’histoire ou les lignes de code pour chaque ingénieur.
Choisir des outils standard
Utilisez des outils et des processus établis et éprouvés par le secteur, tels que Agile, Scrum et kanban. Le développement de vos propres outils et processus est une entreprise importante, prenant du temps et des cycles de développement qui pourraient autrement être dépensés sur votre charge de travail. La plupart des ingénieurs DevOps expérimentés et des propriétaires de produits connaissent ces types d’outils et de processus, de sorte que la courbe d’apprentissage en les adoptant doit être minimale. De même, le processus d’intégration pour les nouveaux employés profitera également de l’utilisation d’outils et de processus standard, car ils sont susceptibles d’avoir un degré d’exposition aux mêmes outils et processus déjà.
Compromis : La méthodologie agile peut devenir trop stricte si elle est trop prescriptive. S’efforcez d’obtenir un équilibre entre les normes bien définies et l’innovation.
Adopter une norme pour capturer des scénarios d’utilisateur final
Récits utilisateur : normaliser 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 article utilisateur doit être entièrement indépendant les uns des autres. Maintenir les récits utilisateur indépendants les uns des autres évite toute confusion avec le travail qui se chevauche et aide l’équipe à comprendre si le travail sur un récit utilisateur donné s’appuie sur le travail sur d’autres personnes, ce qui permet de planifier et de hiérarchiser.
Chaque histoire utilisateur est négociée. Les perspectives des membres de l’équipe de charge de travail et des utilisateurs finaux sont essentielles pour capturer des récits utilisateur réalistes qui peuvent être réalisés sur un court laps de temps.
Les récits 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’ils souhaitent voir et qui ajouteront de la valeur à leur expérience. Le fait de garder ce focus lorsque l’article utilisateur est divisé en éléments de travail permet de s’assurer que chaque déploiement offre une expérience améliorée.
L’effort nécessaire pour un récit utilisateur estimable avec un degré élevé de confiance. Sans être en mesure d’avoir une approximation étroite des heures requises pour un récit utilisateur donné, la planification sera difficile et le risque d’absence de délais augmente, ce qui peut entraîner des effets en cascade sur d’autres travaux planifiés.
Les histoires utilisateur bien écrites sont petites, afin qu’elles puissent être terminées dans quelques semaines. Les histoires limitées plus petites aident à les maintenir utilisables et gérables et à maintenir les éléments de travail réalisables.
Les récits utilisateur doivent être testables. Sans pouvoir tester qu’une fonctionnalité a été fournie, l’utilisateur final ne peut pas avoir confiance que l’objectif a été atteint. Même si un test n’a pas déjà é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 : 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 plusieurs tests d’acceptation.
Normaliser les pratiques de déploiement
Déploiement : prévoyez d’utiliser des déploiements fréquemment petits et itératifs au lieu de 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 lorsque les déploiements échouent.
Termes : normaliser votre définition des cycles de développement terminés pour vous assurer que les fonctions de prise en charge, notamment les tests, la documentation et les fonctionnalités d’accessibilité, sont correctement terminées.
Suivi : vérifiez que le processus de développement est traceable. Vous devez clairement tracer l’état de votre charge de travail de production et le code associé vers les tests d’assurance qualité, les critères d’acceptation, les récits utilisateur et les fonctionnalités. Le suivi détaillé peut également être une exigence réglementaire dans certains cas, comme la santé, par exemple.
Facilitation Azure
Azure Boards est un service web qui permet aux équipes de planifier, de suivre et de discuter du travail dans l’ensemble du processus de développement. Il convient parfaitement 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ègre à l’aide de problèmes et de demandes de tirage dans GitHub.
Liens connexes
Liens de la communauté
Liste de contrôle d’excellence opérationnelle
Reportez-vous à l’ensemble complet de recommandations.