66 lines
3.2 KiB
Markdown
66 lines
3.2 KiB
Markdown
<!-- file: docs/objectives/001-PROJECT_OBJECTIVES.md -->
|
|
<!-- version: 1 -->
|
|
|
|
# Objectifs de Project Governance Rules
|
|
|
|
## Mission
|
|
|
|
PGR fournit une gouvernance réutilisable permettant de démarrer, développer, valider, reprendre et publier des projets logiciels plus rapidement, avec des responsabilités explicites et une qualité proportionnée aux risques réels.
|
|
|
|
## Objectifs
|
|
|
|
PGR doit permettre de :
|
|
|
|
- normaliser les pratiques récurrentes qui bénéficient réellement d'une convention commune ;
|
|
- réduire le temps de bootstrap d'un nouveau projet ;
|
|
- rendre explicites les responsabilités des fichiers, composants, couches et outils ;
|
|
- standardiser SemVer, lifecycle de release, deltas, validations, historiques et handoffs ;
|
|
- favoriser des validations ciblées pendant le développement et des gates plus larges aux jalons appropriés ;
|
|
- automatiser les contrôles déterministes et fiables sans automatiser artificiellement les décisions nécessitant du jugement ;
|
|
- fournir des templates techniques éprouvés sans créer de dépendance vers PGR après instanciation ;
|
|
- décrire des skeletons de projets sous forme de recettes Markdown composables plutôt que de générateurs rigides ;
|
|
- supporter plusieurs langages, plateformes et frameworks sans chercher une uniformité artificielle ;
|
|
- conserver une traçabilité historique utile tout en gardant les documents vivants lisibles ;
|
|
- permettre des règles project-specific et des exceptions explicites sans contaminer les règles générales ;
|
|
- privilégier la sécurité, l'explicité, la maintenabilité et la proportionnalité.
|
|
|
|
## Principe de proportionnalité
|
|
|
|
PGR doit servir les objectifs du projet et réduire son coût total de développement, compréhension, validation, diagnostic et maintenance.
|
|
|
|
Une pratique qui ajoute principalement de la bureaucratie, de la duplication, des tests sans gain de preuve, des validations répétitives ou une complexité artificielle doit être simplifiée, rendue optionnelle ou supprimée.
|
|
|
|
La rigueur porte sur ce qui est important ; elle ne consiste pas à rendre chaque opération lourde.
|
|
|
|
## Non-objectifs
|
|
|
|
PGR n'a pas pour objectif de :
|
|
|
|
- devenir un build system ou remplacer Cargo, Gradle, Maven, CMake, npm, Composer ou les outils natifs des écosystèmes ;
|
|
- fournir un générateur universel de projets ;
|
|
- imposer toutes les technologies à tous les dépôts ;
|
|
- figer une architecture une fois un projet démarré ;
|
|
- maximiser le nombre de règles, documents, tests ou audits ;
|
|
- imposer un pourcentage arbitraire de code coverage ;
|
|
- créer des audits regex pour remplacer le jugement architectural ;
|
|
- réimplémenter les fonctionnalités des toolchains officielles sans bénéfice réel ;
|
|
- maintenir automatiquement les projets créés à partir de PGR ;
|
|
- imposer une stratégie Git complexe ou une topologie universelle de branches.
|
|
|
|
## Critères de succès à terme
|
|
|
|
PGR est utile si un nouveau projet peut rapidement identifier :
|
|
|
|
```text
|
|
quoi créer
|
|
pourquoi
|
|
où le placer
|
|
quelles règles s'appliquent
|
|
quelles décisions restent ouvertes
|
|
comment valider les changements
|
|
comment reprendre le travail plus tard
|
|
comment publier proprement
|
|
```
|
|
|
|
sans importer des règles ou technologies sans rapport avec son besoin.
|