Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’applique à cette recommandation de liste de contrôle Azure Well-Architected Framework Operational Excellence :
| OE :03 | Formaliser les processus dans le cycle de vie complet du développement de logiciels, de l’idée à la livraison et de les rendre transparents à l’équipe et aux parties prenantes. |
|---|
Le développement de logiciels implique plus que de produire du code. Les développeurs doivent comprendre clairement ce qu’il faut créer et pourquoi. Les propriétaires de produits et les responsables maintiennent une visibilité sur le travail en cours et sur la progression. En établissant des pratiques cohérentes, les équipes peuvent fournir des logiciels de qualité, présenter des risques précoces et gérer les attentes et suivre les progrès.
Ce guide fournit des recommandations sur la façon d’exécuter le développement de logiciels de manière structurée, prévisible et collaborative.
Établir des normes pour la gestion des modifications
Dans le développement logiciel, chaque unité de travail est un changement. Même les nouvelles fonctionnalités représentent un passage d’un état inexistant à un état implémenté.
Lors du lancement du travail pour une modification demandée, gardez à l’esprit les considérations suivantes :
Collaborer. Les équipes doivent travailler ensemble plutôt que dans l’isolement. La plupart des modifications affectent plusieurs composants ou rôles. Impliquez les développeurs, les testeurs, les opérations et les parties prenantes du produit tôt pour s’assurer que les détails importants ne sont pas manqués et que tout le monde comprend l’impact sur leur domaine. Travailler ensemble conduit également à des estimations d’efforts plus précises, car les personnes ayant une expérience pertinente peuvent contribuer à leur perspective.
Gardez les objectifs de collaboration simples. Acceptez l’étendue d’une modification, identifiez les dépendances et divisez le travail en tâches claires, gérables et documentez-les dans un backlog.
Communiquer. Normaliser la façon dont l’équipe communique les versions, à la fois en interne et en externe. Définissez les informations à partager avec des audiences externes (telles que les clients), le niveau de détail approprié, la documentation d’intégration ou de support requise et la chronologie de communication. Par exemple, informez les parties prenantes deux semaines avant une mise en production et envoyez un rappel 24 heures avant le déploiement.
Retrospect. Examinez régulièrement chaque cycle de développement pour identifier ce qui a fonctionné, ce qui n’a pas été fait et ce qui peut être amélioré. Gardez ces avis sans blâme et axés sur l’apprentissage.
Utilisez cette occasion pour vérifier si les pratiques standard sont efficaces. Par exemple, vérifiez si les tâches du développeur ont été clairement définies, les estimations de temps étaient précises et les processus fonctionnent comme prévu.
Rapports. Normaliser les rapports sur la façon dont le produit change. Gardez les rapports axés sur la croissance des produits plutôt que sur la productivité individuelle des développeurs. Par exemple, il est judicieux pour les parties prenantes de suivre :
- Croissance de l’adoption
- Améliorations des performances
- Temps d’intégration
- Fréquence des incidents
Choisir des outils éprouvés par l’industrie
Au lieu d’inventer vos propres processus, utilisez des processus éprouvés comme Agile, Scrum et kanban.
L’utilisation d’approches éprouvées permet de gagner du temps, de réduire les efforts et de faciliter l’utilisation des membres de l’équipe, car la plupart d’entre eux doivent déjà être familiarisés avec ces outils. Les outils standard simplifient également l’intégration de nouveaux employés et améliorent la collaboration entre les équipes.
Compromis: La méthodologie agile peut devenir trop rigide si elle est trop prescriptive. S’efforcez d’obtenir un équilibre entre les normes bien définies et l’innovation.
Normaliser la façon dont le travail de développement est enregistré
Normaliser un modèle pour capturer des unités discrètes de travail. Elle doit être écrite du point de vue de l’utilisateur et respecter ces principes :
Indépendant. Pour éviter le chevauchement du travail, une histoire ne doit pas dépendre d’une autre.
Négociable. Le travail devrait être ouvert à la discussion et à l’affinement, car le travail doit être réaliste du point de vue du développement et aligné sur les objectifs de l’entreprise.
Précieux. Le travail doit clairement bénéficier à l’utilisateur.
Peut être estimé. L’équipe doit être en mesure d’estimer en toute confiance les efforts afin qu’il soit possible de fournir la fonctionnalité à temps. Préférez les petits articles qui peuvent être terminés en quelques semaines ou moins.
Vérifiable Il doit y avoir un moyen clair de vérifier la fonctionnalité et le déploiement de la fonctionnalité.
Note
Toutes les ressources de développement en production doivent être retracables vers le code, les tests, les critères d’acceptation et les éléments de backlog. Le suivi prend en charge le contrôle de la qualité, simplifie le débogage et aide les équipes à répondre aux exigences de conformité dans les environnements réglementés.
En outre, standardisez un modèle pour les critères d’acceptation afin que l’équipe et les parties prenantes sachent que le travail est terminé. Chaque unité de travail doit être un critère d’acceptation qui n’est pas ambigu et peut être vérifié par des tests.
Assurez-vous que tout le monde est d’accord sur ce que signifie « fait » pour un cycle de développement. Les exigences doivent inclure le code terminé, les tests terminés, la documentation mise à jour et l’accessibilité traitée. Les définitions claires empêchent l’accumulation de travaux non terminés.
Possibilité offerte par l’IA : Vous pouvez standardiser sous forme de modèles les descriptions des tâches et les critères d’acceptation en fonction des politiques organisationnelles. Utilisez Copilot pour générer des brouillons initiaux à partir des modèles. L’IA peut également appliquer des normes en validant des documents sur des modèles. Pour les scénarios avancés, utilisez des agents IA qui sont ancrés dans vos modèles standard pour consommer des sorties des révisions de code et des analyses de cause racine, puis créez automatiquement des éléments de travail conformes pour les défauts et améliorations identifiés.
Normaliser les pratiques de codage
Les pratiques de codage définissent les conventions et instructions que les développeurs suivent lors de l’écriture et de la collaboration sur le code. Ces pratiques établissent la façon dont le code est structuré, documenté et examiné au sein et dans les équipes. Ils accélèrent également l’intégration des développeurs et réduisent les défauts causés par les variations d’implémentation.
Environnement de développement et outils. Normaliser les configurations IDE, les outils de développement et les outils de génération de code approuvés dans les équipes. Appliquez l’utilisation de bibliothèques courantes, de frameworks et de normes de gestion des packages pour promouvoir la réutilisation, garantir la cohérence et respecter les exigences de sécurité de l’organisation.
Conventions de codage. Définissez et documentez les normes de codage qui couvrent les conventions d’affectation de noms, la structure du code et la mise en forme. Nous vous recommandons d’appliquer des normes dans des blocs de code qui gèrent les exceptions et implémentent l’instrumentation. Les conventions claires facilitent la lecture, la compréhension et la maintenance du code et aident les équipes à travailler de manière cohérente entre les fonctionnalités et les composants. Assurez-vous que ces instructions sont accessibles par tous les développeurs et sont régulièrement mises à jour à mesure que le codebase évolue. Par exemple, vous pouvez utiliser EditorConfig dans Visual Studio pour appliquer des styles de codage.
Référentiel de code. Établissez et appliquez des stratégies de branche standardisées, telles que Gitflow, GitHub Flow ou le développement basé sur des jonctions, dans tous les référentiels pour garantir une intégration et des pratiques de mise en production cohérentes du code.
Évaluations par les pairs. Définissez les normes de demande de tirage (PR) qui spécifient une taille de demande de tirage acceptable, les formats de titre et de description requis et les exigences de révision obligatoires. Imposer des revues de code par les pairs pour toute modification de code afin de garantir le respect des normes. Définissez un modèle de collaboration pour les révisions de demandes de fusion qui précise les attentes en matière de responsabilités, de feedback et d'approbations.
Modèles pour les artefacts courants. Les descriptions, les messages de validation et les tests unitaires sont des exemples classiques d’artefacts qui peuvent être templatés. Assurez-vous que la documentation inclut des étapes d’objectif, de contexte et de test.
Couverture des tests. Exiger des tests unitaires pour tous les nouveaux codes et des modifications significatives apportées au code existant. Les tests doivent suivre des modèles convenus et inclure des assertions significatives pour vérifier les fonctionnalités.
Les outils tels que SonarQube et Copilot Labs peuvent identifier automatiquement les écarts des normes de codage, la couverture des tests manquants et les anti-modèles courants. Décharger ces tâches de validation répétitives à l’INTELLIGENCE permet aux équipes de se concentrer sur le travail à valeur élevée. Toutefois, l’examen humain reste essentiel, car les pratiques de développement sont essentielles à l’implémentation correcte de la logique métier et à la qualité globale de la charge de travail.
Normaliser les pratiques d’intégration
L’intégration fait référence aux processus et conventions automatisés utilisés pour valider, sécuriser et empaqueter le code au fur et à mesure qu’il passe au cycle de vie du développement. Il inclut la façon dont les modifications de code sont générées, testées, analysées et préparées pour le déploiement dans le cadre de pipelines d’intégration continue.
Les pratiques d’intégration standardisées sont nécessaires pour valider le code par rapport aux exigences de qualité et de sécurité définies et permettre également des boucles de rétroaction plus rapides pour les développeurs.
Générer l’automatisation et les tests intégrés : Normaliser les builds automatisées qui s’exécutent sur chaque push de code et appliquent des tests automatisés d’unité et d’intégration avec des seuils de couverture définis, le cas échéant.
Analyse de la qualité du code : Appliquez des portes statiques d’analyse du code et de qualité à l’aide d’outils approuvés pour garantir que le code répond aux normes de qualité définies avant la promotion.
Gestion des dépendances : Analysez en permanence les dépendances des composants obsolètes ou vulnérables et intégrez l’analyse de sécurité, notamment les tests de sécurité d’application statiques (SAST), les tests de sécurité des applications dynamiques (DAST) et la détection des secrets.
Gestion des artefacts : Normaliser les stratégies de contrôle de version, de stockage et de rétention des packages et des artefacts pour garantir la traçabilité et la reproductibilité.
Surveillance et création de rapports : Collectez et surveillez les métriques de build et de pipeline pour suivre la qualité, les performances et la conformité.
Soutien 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 en utilisant des issues et des pull requests dans GitHub.
Liens connexes
Liens de la communauté
Liste de contrôle d’excellence opérationnelle
Reportez-vous à l’ensemble complet de recommandations.