paint-brush
L'avantage d'une page : un modèle pour les projets de génie logicielpar@vlshahane
2,543 lectures
2,543 lectures

L'avantage d'une page : un modèle pour les projets de génie logiciel

par Vishal Shahane3m2024/05/22
Read on Terminal Reader
Read this story w/o Javascript

Trop long; Pour lire

La complexité des systèmes logiciels oblige souvent les ingénieurs logiciels ou les gestionnaires à rédiger des propositions pour aligner l'équipe, l'organisation ou les parties prenantes. Ces propositions aident à communiquer la motivation, les recommandations ou les jalons de manière concise, tout en obtenant des commentaires et en alignant toutes les parties prenantes. Cet article fournit un modèle générique pour écrire des pages uniques, bien que non limité aux systèmes logiciels, il s'est avéré utile lors de la direction d'organisations de génie logiciel.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - L'avantage d'une page : un modèle pour les projets de génie logiciel
Vishal Shahane HackerNoon profile picture

Avertissement : Les points de vue et opinions exprimés dans cet article sont uniquement les miens et ne reflètent pas nécessairement les points de vue d'une institution ou d'une organisation.

Introduction

La complexité des systèmes logiciels oblige souvent les ingénieurs logiciels ou les managers à rédiger des propositions pour aligner les équipes, les organisations ou les parties prenantes (équipes partenaires, services dépendants, etc.) sur les changements. Ces propositions aident à communiquer la motivation, les recommandations ou les jalons de manière concise, tout en obtenant des commentaires et en alignant toutes les parties prenantes.


Ces documents servent également de points de référence passés pour les nouveaux employés qui s'approprient les systèmes logiciels et comprennent le processus de réflexion sur la façon dont les décisions ont été prises dans le passé. Cet article fournit un modèle générique pour écrire des pages uniques ; bien qu'il ne se limite pas aux systèmes logiciels, il s'est avéré utile dans les organisations de génie logiciel.

Modèle

Aperçu

Ce sera le résumé du document, idéal pour capturer la motivation et ce que vous proposez aux lecteurs pour qu'ils s'intéressent à votre document.

Introduction

Fournissez des détails sur le contexte/la motivation du changement. Des métriques/données peuvent être incluses pour expliquer le problème et fournir des informations supplémentaires.

Objectifs

Exigences liées à la portée de ce projet.

Non-objectifs

Signalez toutes les tâches qui ne sont pas des objectifs ou qui sont hors de portée de ce projet. Cela peut vous distraire de la résolution du problème sur lequel vous souhaitez vous concentrer.

Possibilités

Résumez une liste d'options/alternatives que vous avez envisagées pour résoudre le problème, de préférence avec les avantages et les inconvénients de chacune.

Recommandation

Sur la base des alternatives évoquées dans la section précédente, fournissez des recommandations de solutions stratégiques avec des explications ou des arguments à l’appui.


Approche tactique en option – En fonction des défis et du calendrier associés à la réalisation de l'approche recommandée, envisager de proposer une solution tactique ; cela peut potentiellement constituer une étape progressive vers une solution stratégique ou un changement minimal pour résoudre le problème à court terme.

Essai

Décrivez comment vous vérifierez que la fonctionnalité fonctionne comme prévu ; que vas-tu tester ? Comment allez-vous le tester ? Y aura-t-il une période de validation gamma ou de pré-production ? Qu’est-ce que cela impliquera ? Assurez-vous d'inclure des cas de test qui vérifient que la fonctionnalité s'applique uniquement aux événements pour lesquels elle doit s'appliquer

Jalons

Répertoriez les tâches/jalons de haut niveau pour les solutions recommandées avec des estimations en jours de développement. Pour fournir cette liste en dehors des changements fonctionnels, pensez à :

  • Stratégie de tests avant release (tests unitaires, d'intégration, etc.)
  • Besoin/stratégie de remplissage
  • Toute modification apportée aux métriques/scripts/outils de reporting
  • Nouvelles mesures/étapes de validation après la publication (canaris, workflows d'approbation du pipeline)
  • Examen de sécurité
  • Mini revue de préparation opérationnelle

Les références

Les références qui, selon vous, pourraient aider les lecteurs à approfondir l’espace du problème ou les alternatives présentées.

FAQ

Répondez de manière proactive à toutes les questions ou questions anticipées qui auraient pu être soulevées lors de discussions consécutives liées à cette proposition.

annexe

Ajoutez toute information supplémentaire à la proposition, à laquelle les lecteurs pourront se référer si nécessaire.

Réunion # Notes

Conservez le résumé ci-dessous pour les réunions au cours desquelles la proposition est examinée.

Participants

Liste des personnes ayant assisté à la réunion.

MoM (procès-verbal de la réunion)

Résumez le procès-verbal de la réunion pour référence future.