Vitam - Contributions [fr]

DEVOPS

2026-01-18T22:56:03Z

Vitam :

== Présentation de l'équipe ==

-Achoubie Mohamed

-Amrani Saad

-Bouayad Abderahmane

-Babacar

-Georges Julien

== Upload snapshot spécial odfvalidator sur nexus ==
A défaut d'avoir mieux (upgrade réel & MAJ code), pour injecter la lib dans le nexus :

Récupérer la version odfvalidator depuis un précédent build (dans un RPM ou DEB)<syntaxhighlight lang="bash">
mvn deploy:deploy-file -DgroupId=org.apache.odftoolkit \
-DartifactId=odfvalidator \
-Dversion=1.2.0-incubating-SNAPSHOT \
-Dclassifier=jar-with-dependencies \
-Dpackaging=jar \
-Dfile=/path/to/odfvalidator-jar-with-dependencies.jar \
-DrepositoryId=vitam \
-Durl=https://nexus.dev.programmevitam.fr/repository/maven-snapshots/
</syntaxhighlight>

= Pipelines CI/CD VITAM =
Ce document decrit les pipelines Jenkins du depot Vitam .

== Sources ==

* `Jenkinsfile` : pipeline principal (build, tests, packaging, publication).
* `Jenkinsfile.containers` : pipeline de construction et de scan des images Docker.
* `containers/vitam-external/sources.containers` : liste des images externes traitees.
* `vitam-conf-dev/tests/initdb.d/` : scripts d'init MongoDB utilises par les tests.

== Definition des branches importantes ==
Dans `Jenkinsfile`, la variable `IMPORTANT_BRANCH_OR_TAG` est vraie si :

* la branche est `develop` ou `master_*`, ou
* un tag Git est present.

Cette condition commande l'execution des etapes lourdes (packaging, publication, etc.).

== Pipeline principal (Jenkinsfile) ==

=== Agent, outils, environnement ===

* Agent Jenkins : label `build`.
* Outils :
** JDK : `java11` (par defaut), `java17` pour l'analyse Sonar.
** Maven : `maven-3.8`.

Variables d'environnement principales :
{| class="wikitable"
!Variable
!Description
|-
|`MVN_COMMAND`
|Commande Maven standard (mode batch, erreurs detaillees, build en fin de module).
|-
|`M2_REPO`
|Depot Maven local (`$HOME/.m2`).
|-
|`CI`
|Credentials Jenkins `app-jenkins`.
|-
|`SERVICE_SONAR_URL`
|URL SonarQube.
|-
|`SERVICE_NEXUS_URL`
|URL Nexus.
|-
|`SERVICE_REPO_SSHURL`
|URL SSH du depot de publication.
|-
|`SERVICE_GIT_URL`
|URL Git (scripts de publication).
|-
|`SERVICE_DOCKER_PULL_URL`
|Registry Docker pour les images de test.
|-
|`SERVICE_REPOSITORY_URL`
|URL du repository applicatif.
|-
|`GITHUB_ACCOUNT_TOKEN`
|Token GitHub (usage CI).
|-
|`ES_VERSION` / `MONGO_VERSION` / `MINIO_VERSION` / `OPENIO_VERSION`
|Versions des services Docker de test.
|}

=== Etapes ===

==== Show configuration ====

* Lit `sources/pom.xml` pour extraire la version.
* Affiche des informations de contexte (workspace, branche, version).

==== Detecting changes for build ====

* Compare le commit courant avec le precedent build reussi.
* Ecrit la liste des repertoires modifies dans `.changed_roots.txt`.
* Met a jour `CHANGED_VITAM` et `CHANGED_VITAM_PRODUCT` pour information.

==== Reinit host & containers ====

* Supprime les conteneurs Docker utilises pour les tests.
* Nettoie les volumes Docker.
* Purge le cache Maven `fr/gouv/vitam`.
* Prepare un volume local pour MinIO SSL.

==== Prepare Docker containers for testing ====
Demarre les services necessaires aux tests d'integration :

* Swift (Keystone + Swift),
* MinIO SSL et non-SSL,
* Elasticsearch,
* MongoDB (replica set),
* OpenIO.

Puis configure Elasticsearch et Swift via appels HTTP.

==== Execute unit and integration tests on merge requests ====
Condition : `!IMPORTANT_BRANCH_OR_TAG`.

* `spotless:check`.
* `clean verify` + `dependency-check` OWASP.
* NVM Node.js `v18.20.3`.
* Nettoyage Docker en fin d'etape.

Post-actions :

* Publication des rapports JUnit.
* Archivage du rapport OWASP si present.
* Statuts GitLab `mergerequest` mis a jour.

==== Sonar analysis on merge requests ====
Condition : `!IMPORTANT_BRANCH_OR_TAG`.

* JDK `java17`.
* Execution `sonar:sonar` avec un projectKey derive du nom de branche.
* Commentaire automatique dans la MR GitLab.

==== Execute unit and integration tests on master branches ====
Condition : `IMPORTANT_BRANCH_OR_TAG`.

* Meme sequence que pour les MR (sans statuts GitLab).

==== Sonar analysis on master branches ====
Condition : `IMPORTANT_BRANCH_OR_TAG`.

* Meme analyse Sonar que pour les MR.

==== Build packages ====
Condition : `IMPORTANT_BRANCH_OR_TAG`. Execution parallele :

* Packaging des sources Java (build local + javadoc + deploy + rpm + jdeb).
* Checkout des scripts de publication (branche `scaleway_j11`) dans `vitam-build.git/`.

==== Build doc package ====
Condition : `IMPORTANT_BRANCH_OR_TAG`.

* Build de la documentation (`doc/pom.xml`) avec `jdeb` et `rpm`.
* Publication des rapports JUnit.

==== Prepare packages building ====
Condition : `IMPORTANT_BRANCH_OR_TAG`.

* Nettoie les repertoires `target` des packages `deb` et `rpm`.

==== Build vitam-product & vitam-external packages ====
Condition : `IMPORTANT_BRANCH_OR_TAG`. Execution parallele :

* `rpm/vitam-product/build-all-docker.sh`
* `deb/vitam-product/build-all.sh`
* `rpm/vitam-external/build_repo.sh`
* `deb/vitam-external/build_repo.sh`

==== Publish packages ====
Condition : `IMPORTANT_BRANCH_OR_TAG`. Execution parallele via `sshagent` :

* Publication des packages `vitam-product`.
* Publication des packages `vitam-external`.
* Publication de la documentation.
* Publication des sources.
* Publication du contenu `deployment`.

Post-actions :

* Notification Slack selon le statut du build.

==== Update symlink ====
Condition : `IMPORTANT_BRANCH_OR_TAG`.

* Met a jour les symlinks via `push_symlink_repo.sh`.

==== Information ====

* Affiche le commit courant.
* Execute `.ci/git_commands.sh`.

=== Post-actions globales ===

* Nettoyage des volumes Docker.
* Nettoyage du cache Maven `fr/gouv/vitam`.
* Nettoyage du workspace Jenkins.

== Pipeline conteneurs (Jenkinsfile.containers) ==

=== Agent, environnement ===

* Agent Jenkins : label `java11`.
* Variables similaires au pipeline principal, avec en plus :
** `SERVICE_DOCKER_PUSH_URL` pour la publication d'images.
** `JAVA_HOME` defini explicitement.

=== Etapes ===

==== Build and create vitam docker images ====

* Recupere `CONTAINER_VERSION` depuis `sources/pom.xml`.
* Execute un build Maven avec Jib pour construire et pousser les images.
* Retague et publie `metadata` et `workspace` en variantes `*-collect`.

==== build cots ====

* Login aux registries Docker.
* Lit `containers/vitam-external/sources.containers`.
* Pour chaque ligne : pull depuis le registry source, tag et push vers `vitam-external/`.

==== Set scanner prerequisites ====

* Installe Trivy (`v0.47.0`) et un template HTML.

==== Scan containers ====

* Scanne une liste d'images Vitam avec Trivy.
* Genere des rapports HTML par image et les publie via Jenkins HTML Publisher.

=== Post-actions globales ===

* `docker system prune -a -f`.
* Nettoyage du workspace Jenkins.

== Prerequis d'execution ==

* Agent Jenkins avec Docker (privileges suffisants pour lancer des conteneurs).
* Acces aux registries Docker (pull/push).
* Acces a SonarQube, Nexus, GitLab et au depot de publication.
* Credentials Jenkins requis : `app-jenkins`, `service-sonar-java11-url`, `service-nexus-url`,

`repository-connection-string`, `service-gitlab-url`, `SERVICE_DOCKER_PULL_URL`,
`SERVICE_DOCKER_PUSH_URL`, `service-repository-url`, `vitam-prg-token`,
`jenkins_sftp_to_repository`.

= Pipelines CI/CD VITAMUI =
Ce document decrit les pipelines Jenkins du depot Vitamui. Il couvre les jobs "build/deploy" et "containers/scan".

== Vue d'ensemble ==

* Deux fichiers de pipeline: `Jenkinsfile` et `Jenkinsfile.containers`.
* Agent Jenkins: label `build`.
* Outillage commun: JDK 11 et Maven 3.9 (selon le pipeline).
* Nettoyage systematique en fin de job.

== Pipeline build et publication (Jenkinsfile) ==

=== Objectif ===
Construire, tester, publier les artefacts Maven (deb/rpm), et mettre a jour le depot de publication.

=== Variables d'environnement ===

* `MVN_BASE` et `MVN_COMMAND`: base Maven avec settings `.ci/settings.xml` et options CI.
* `M2_REPO`: `${HOME}/.m2`.
* Identifiants Jenkins requis (noms de credentials):
** `app-jenkins`
** `service-gitlab-url`
** `service-nexus-url`
** `repository-connection-string`
** `service-repository-url`

=== Options ===

* Timeout global: 4 heures.
* Pas de builds concurrents.
* Conservation des builds: 100.

=== Parametrage execution ===

* Stage "Set variables for automatic run": fixe les flags par defaut.
* Stage "Ask for build execution": pour toutes les branches hors `develop*`, `master_*` et tags de version, un input permet d'activer/retirer:
** `DO_BUILD_AND_TEST`
** `DO_DEPLOY`
** `DO_DEPLOY_PASTIS_STANDALONE`
** `DO_PUBLISH`

=== Stages ===

==== Upgrade build context ====

* Installe les prerequis systeme (build-essential, make, ruby, jq).
* Force le timezone a `Europe/Paris`.
* Installe `fpm` via rubygems.
* Installe Node `v14.15.1` via `nvm` et injecte le chemin dans `PATH`.

==== Build and test ====
Condition: `DO_BUILD_AND_TEST=true`.

* Parallele:
** Check icomoon: `./tools/check_icomoon.sh`.
** Build Frontend: Maven `clean verify` sur `ui/ui-frontend` et `ui/ui-frontend-common`.
** Build Backend: Maven `clean verify` en excluant les modules front/cots.
* Post: collecte des rapports JUnit (`**/target/surefire-reports/*.xml`, `**/target/junit/*.xml`).

==== Deploy to Nexus ====
Condition: `DO_DEPLOY=true`.

* Maven `deploy` avec profils `vitam,deb,rpm`, tests et license skips.

==== Deploy PASTIS standalone ====
Condition: `DO_DEPLOY_PASTIS_STANDALONE=true`.

* Maven `install` en excluant plusieurs modules UI.
* Maven `deploy` du module `api/api-pastis/pastis-standalone` avec profil `standalone`.

==== Build COTS ====
Condition: `DO_DEPLOY=true`.

* Maven `deploy` dans `cots/`.

==== Get publishing scripts ====
Condition: `DO_PUBLISH=true` et `DO_DEPLOY=true`.

* Checkout d'un depot de scripts (branche `scaleway_j11`) dans `vitam-build.git`.

==== Publish rpm and deb ====
Condition: `DO_PUBLISH=true` et `DO_DEPLOY=true`.

* Execution des scripts `push_vitamui_repo.sh` pour rpm et deb via `sshagent`.

==== Update symlink ====
Condition: branche `develop` ou `master_*` ou tag de version, et `DO_PUBLISH=true` et `DO_DEPLOY=true`.

* Execution de `push_symlink_repo.sh` via `sshagent`.

=== Post actions ===

* `docker volume prune -f`.
* Suppression de `~/.m2/repository/fr/gouv/vitamui/`.
* `cleanWs()`.

== Pipeline containers et scan (Jenkinsfile.containers) ==

=== Objectif ===
Construire les images Docker, scanner les vulnerabilites avec Trivy, publier les rapports HTML.

=== Variables d'environnement ===

* `MVN_BASE` et `MVN_COMMAND`.
* `M2_REPO`.
* Identifiants Jenkins requis:
** `app-jenkins`
** `service-sonar-java11-url`
** `service-nexus-url`
** `repository-connection-string`
** `SERVICE_DOCKER_PULL_URL`
** `SERVICE_DOCKER_PUSH_URL`
** `service-repository-url`
** `vitam-prg-token`

=== Stages ===

==== Build and create docker images ====

* Outils: JDK 11, Maven 3.9.
* Maven `install/package` avec `jib` active, tests sautes, profil `vitam`.
* Authentification Jib via credentials Jenkins `app-jenkins`.

==== Set scanner prerequisites ====

* Installe Trivy `v0.47.0` et le template HTML.
* Login Docker registry (push URL) via `app-jenkins`.

==== Scan containers ====

* Liste d'images Docker (security-internal, iam-*, referential-*, ingest-*, archive-search-*, pastis-*, collect-*, api-gateway, cas-server, ui-*).
* Pour chaque image:
** `docker pull`.
** Scan Trivy avec rapport HTML (ignore-unfixed, os+library).
** Publication du rapport HTML via `publishHTML`.

=== Post actions ===

* `docker system prune -a -f`.
* `cleanWs()`.

== Notes pour MediaWiki ==

* Mettre a jour la liste des images Docker si de nouveaux services sont ajoutes.
* Les noms de credentials sont references a titre indicatif; ils doivent exister dans Jenkins.

DEVOPS

2026-01-18T22:53:54Z

Vitam : /* Pipelines CI/CD VITAM */

DEVOPS

2026-01-18T22:51:11Z

Vitam :

AGILITÉ

2025-03-18T15:12:02Z

Vitam : /* Le PI Planning VITAM */

= L’Agilité chez Vitam =
L'agilité est une approche de gestion de projet et de développement logiciel qui met l'accent sur l'adaptabilité, la collaboration et l'amélioration continue. Chez '''Vitam''', l'agilité est mise en œuvre à différents niveaux, à travers des cérémonies et des outils spécifiques.

== Vidéo d’introduction ==
Une vidéo introductive sur l'agilité chez Vitam est disponible ici :
[https://exemple.com/video Lien vers la vidéo d'introduction]

== Le cadre ==
L’agilité chez Vitam repose sur différentes cérémonies permettant une coordination efficace et une amélioration continue. La méthodologie centrale est SCRUM avec des ajout spécifique emprunté à méthodologie d'agilité à l'échelle.

=== Au niveau des équipes ===
Les équipes agiles suivent plusieurs rituels pour organiser leur travail et garantir une bonne communication :

==== Le Sprint ====

Un sprint dure trois semaines et commence le jeudi.

==== Les daily ====
Les '''daily meetings''' (ou '''stand-up meetings''') sont des réunions quotidiennes permettant de synchroniser l'équipe et d'identifier les obstacles.

{| class="wikitable"
|+ Tableau des horaires
!
! Admin
! Multiteam
! Devops
|-
! Horaires
| 9h30
| 10h
| 10h30
|}

==== Le sprint planning ====
Le '''sprint planning''' est une réunion où l’équipe définit le contenu du prochain sprint en sélectionnant les tâches prioritaires du backlog. Elle a lieu le premier jour du sprint le jeudi.

{| class="wikitable"
|+ A quels moments
!
! Multiteam
! Devops
|-
! Moments
| Toute la journée
| Toute la matinée
|}

==== Le raffinage du backlog ====
Le '''raffinage du backlog''' est un processus continu où l’équipe ajuste, détaille et priorise les user stories et les tâches.
C'est tous les jeudis de 10h30 à 12h30 hors journées de sprint planning

==== Le Tech Design ====
Le '''Tech Design''' est une session où les développeurs discutent des choix techniques avant d’implémenter une fonctionnalité. Ces moments sont réservés garantissent la présence de la direction technique si besoin.

Tous les mardi de 14h à 15h et tous les vendredi de 10h30 à 11h30.

==== Rétro d'équipe ====
Une rétrospective de l'équipe visant à améliorer les processus et les interactions entre ses membres.

Une fois par mois pour l'équipe Admin
Tous les mercredi après-midi du dernier jour du sprint
** De 14h à 15h pour l'équipe DevOps
** De 15h à 17h pour l'équipe Multiteam

=== Au niveau du programme ===
À un niveau plus large, des cérémonies de coordination ont lieu :

==== Les Tres Amigos ====
Réunion réunissant les trois rôles clé (PO, Développeurs, Testeurs) pour aligner la compréhension des user stories. Elles rentrent dans l'activité de raffinage du backlog mais peut être lancés à tout moments pour les besoins du programme.
Il faut veiller à bien identifier le sujet de discussion et fixer un temps limite pour l'échange. Ne pas toujours y convier les même personnes.

==== Le Weekly ====
Une réunion hebdomadaire permettant d’échanger sur l’avancement global du programme.

Elle a lieu tous les lundi de 11h30 à 12h30.

==== SOS Mid-week ====
Un point intermédiaire pour identifier les blocages critiques et ajuster les priorités.

Elle a lieu tous les mercredis de 12h00 à 12h30

==== Rétro générale ====
Une rétrospective collective visant à améliorer les processus et les interactions entre équipes. Tout le programme y est convié.

Le dernier mercredi du dernier sprint de la release

==== Post Mortem ====
Une analyse après un incident majeur pour comprendre les causes et éviter qu'il ne se reproduise.

==== PI Planning ====
Le '''PI Planning''' (Program Increment Planning) est une réunion de planification à l’échelle du programme, servant à synchroniser les équipes sur les objectifs des prochains sprints.

La première semaine du premier sprint de la release y est consacré.

== L’utilisation de Tuleap ==
Tuleap est la plateforme utilisée par Vitam pour suivre le travail agile et gérer les artefacts du projet.

=== Les outils de suivi (trackers) ===
Tuleap propose des '''trackers''' permettant de suivre les différentes tâches et artefacts du projet.

=== Les Continuous Improvements ===
Les '''Continuous Improvements''' sont des actions d'amélioration continue identifiées lors des rétrospectives.

=== Les Tâches ===
Les tâches sont les unités de travail de base assignées aux membres de l'équipe.

=== Les User Stories ===
Les '''user stories''' décrivent les besoins fonctionnels du projet sous forme d’histoires utilisateur.

=== Les Epic ===
Les '''Epic''' regroupent plusieurs user stories liées à une même fonctionnalité de haut niveau.

=== Les DOMAINES ===
Les '''DOMAINES''' correspondent aux grandes catégories de travail organisées dans Tuleap.

=== Les Activités PIC ===
Les '''Activités PIC''' concernent la planification et la coordination des activités du projet.

=== Les Activités PROD ===
Les '''Activités PROD''' suivent les actions et interventions réalisées en environnement de production.

=== Les Bugs ===
Les '''Bugs''' sont les anomalies détectées et suivies dans Tuleap pour correction.

=== Les Demandes de support ===
Les '''demandes de support''' permettent de signaler des problèmes nécessitant une intervention ou une assistance.

= Le PI Planning VITAM =

Depuis la release 9.0 la vision est travaillée dans le cadre d'un PI Planning méthodologie issus de SAFE.

Une infographie ici vous permet de visualiser toutes les étapes. [https://go.klaxoon.com/NZZGTFD Lien vers l'infographie]

== Les actions préalables ==

Les grandes lignes de la stratégie sont définies en amont par la direction du programme. Elles sont partagés avec les personnes clés du projet ( PO, tech lead etc ... ) pour qu'elles commencent à travailler sur leur backlog.

== La semaine de pré-planning ==

== Le PI Planning ==

=== Le Jour 1 ===

=== Le Jour 2 ===

----

''Cette page est un guide sur l'agilité appliquée chez Vitam. Pour toute mise à jour ou question, veuillez contacter l’équipe de gestion agile.''

AGILITÉ

2025-03-18T14:50:08Z

Vitam :

= L’Agilité chez Vitam =
L'agilité est une approche de gestion de projet et de développement logiciel qui met l'accent sur l'adaptabilité, la collaboration et l'amélioration continue. Chez '''Vitam''', l'agilité est mise en œuvre à différents niveaux, à travers des cérémonies et des outils spécifiques.

== Vidéo d’introduction ==
Une vidéo introductive sur l'agilité chez Vitam est disponible ici :
[https://exemple.com/video Lien vers la vidéo d'introduction]

== Le cadre ==
L’agilité chez Vitam repose sur différentes cérémonies permettant une coordination efficace et une amélioration continue. La méthodologie centrale est SCRUM avec des ajout spécifique emprunté à méthodologie d'agilité à l'échelle.

=== Au niveau des équipes ===
Les équipes agiles suivent plusieurs rituels pour organiser leur travail et garantir une bonne communication :

==== Le Sprint ====

Un sprint dure trois semaines et commence le jeudi.

==== Les daily ====
Les '''daily meetings''' (ou '''stand-up meetings''') sont des réunions quotidiennes permettant de synchroniser l'équipe et d'identifier les obstacles.

{| class="wikitable"
|+ Tableau des horaires
!
! Admin
! Multiteam
! Devops
|-
! Horaires
| 9h30
| 10h
| 10h30
|}

==== Le sprint planning ====
Le '''sprint planning''' est une réunion où l’équipe définit le contenu du prochain sprint en sélectionnant les tâches prioritaires du backlog. Elle a lieu le premier jour du sprint le jeudi.

{| class="wikitable"
|+ A quels moments
!
! Multiteam
! Devops
|-
! Moments
| Toute la journée
| Toute la matinée
|}

==== Le raffinage du backlog ====
Le '''raffinage du backlog''' est un processus continu où l’équipe ajuste, détaille et priorise les user stories et les tâches.
C'est tous les jeudis de 10h30 à 12h30 hors journées de sprint planning

==== Le Tech Design ====
Le '''Tech Design''' est une session où les développeurs discutent des choix techniques avant d’implémenter une fonctionnalité. Ces moments sont réservés garantissent la présence de la direction technique si besoin.

Tous les mardi de 14h à 15h et tous les vendredi de 10h30 à 11h30.

==== Rétro d'équipe ====
Une rétrospective de l'équipe visant à améliorer les processus et les interactions entre ses membres.

Une fois par mois pour l'équipe Admin
Tous les mercredi après-midi du dernier jour du sprint
** De 14h à 15h pour l'équipe DevOps
** De 15h à 17h pour l'équipe Multiteam

=== Au niveau du programme ===
À un niveau plus large, des cérémonies de coordination ont lieu :

==== Les Tres Amigos ====
Réunion réunissant les trois rôles clé (PO, Développeurs, Testeurs) pour aligner la compréhension des user stories. Elles rentrent dans l'activité de raffinage du backlog mais peut être lancés à tout moments pour les besoins du programme.
Il faut veiller à bien identifier le sujet de discussion et fixer un temps limite pour l'échange. Ne pas toujours y convier les même personnes.

==== Le Weekly ====
Une réunion hebdomadaire permettant d’échanger sur l’avancement global du programme.

Elle a lieu tous les lundi de 11h30 à 12h30.

==== SOS Mid-week ====
Un point intermédiaire pour identifier les blocages critiques et ajuster les priorités.

Elle a lieu tous les mercredis de 12h00 à 12h30

==== Rétro générale ====
Une rétrospective collective visant à améliorer les processus et les interactions entre équipes. Tout le programme y est convié.

Le dernier mercredi du dernier sprint de la release

==== Post Mortem ====
Une analyse après un incident majeur pour comprendre les causes et éviter qu'il ne se reproduise.

==== PI Planning ====
Le '''PI Planning''' (Program Increment Planning) est une réunion de planification à l’échelle du programme, servant à synchroniser les équipes sur les objectifs des prochains sprints.

La première semaine du premier sprint de la release y est consacré.

== L’utilisation de Tuleap ==
Tuleap est la plateforme utilisée par Vitam pour suivre le travail agile et gérer les artefacts du projet.

=== Les outils de suivi (trackers) ===
Tuleap propose des '''trackers''' permettant de suivre les différentes tâches et artefacts du projet.

=== Les Continuous Improvements ===
Les '''Continuous Improvements''' sont des actions d'amélioration continue identifiées lors des rétrospectives.

=== Les Tâches ===
Les tâches sont les unités de travail de base assignées aux membres de l'équipe.

=== Les User Stories ===
Les '''user stories''' décrivent les besoins fonctionnels du projet sous forme d’histoires utilisateur.

=== Les Epic ===
Les '''Epic''' regroupent plusieurs user stories liées à une même fonctionnalité de haut niveau.

=== Les DOMAINES ===
Les '''DOMAINES''' correspondent aux grandes catégories de travail organisées dans Tuleap.

=== Les Activités PIC ===
Les '''Activités PIC''' concernent la planification et la coordination des activités du projet.

=== Les Activités PROD ===
Les '''Activités PROD''' suivent les actions et interventions réalisées en environnement de production.

=== Les Bugs ===
Les '''Bugs''' sont les anomalies détectées et suivies dans Tuleap pour correction.

=== Les Demandes de support ===
Les '''demandes de support''' permettent de signaler des problèmes nécessitant une intervention ou une assistance.

= Le PI Planning VITAM =

Depuis la release 9.0 la vision est travaillée dans le cadre d'un PI Planning méthodologie issus de SAFE.

Une infographie ici vous permet de visualiser toutes les étapes.

== Les actions préalables ==

== La semaine de pré-planning ==

== Le PI Planning ==

=== Le Jour 1 ===

=== Le Jour 2 ===

----

''Cette page est un guide sur l'agilité appliquée chez Vitam. Pour toute mise à jour ou question, veuillez contacter l’équipe de gestion agile.''

AGILITÉ

2025-03-18T14:44:06Z

Vitam : /* Les cérémonies */

= L’Agilité chez Vitam =
L'agilité est une approche de gestion de projet et de développement logiciel qui met l'accent sur l'adaptabilité, la collaboration et l'amélioration continue. Chez '''Vitam''', l'agilité est mise en œuvre à différents niveaux, à travers des cérémonies et des outils spécifiques.

== Vidéo d’introduction ==
Une vidéo introductive sur l'agilité chez Vitam est disponible ici :
[https://exemple.com/video Lien vers la vidéo d'introduction]

== Le cadre ==
L’agilité chez Vitam repose sur différentes cérémonies permettant une coordination efficace et une amélioration continue. La méthodologie centrale est SCRUM avec des ajout spécifique emprunté à méthodologie d'agilité à l'échelle.

=== Au niveau des équipes ===
Les équipes agiles suivent plusieurs rituels pour organiser leur travail et garantir une bonne communication :

==== Le Sprint ====

Un sprint dure trois semaines et commence le jeudi.

==== Les daily ====
Les '''daily meetings''' (ou '''stand-up meetings''') sont des réunions quotidiennes permettant de synchroniser l'équipe et d'identifier les obstacles.

{| class="wikitable"
|+ Tableau des horaires
!
! Admin
! Multiteam
! Devops
|-
! Horaires
| 9h30
| 10h
| 10h30
|}

==== Le sprint planning ====
Le '''sprint planning''' est une réunion où l’équipe définit le contenu du prochain sprint en sélectionnant les tâches prioritaires du backlog. Elle a lieu le premier jour du sprint le jeudi.

{| class="wikitable"
|+ A quels moments
!
! Multiteam
! Devops
|-
! Moments
| Toute la journée
| Toute la matinée
|}

==== Le raffinage du backlog ====
Le '''raffinage du backlog''' est un processus continu où l’équipe ajuste, détaille et priorise les user stories et les tâches.
C'est tous les jeudis de 10h30 à 12h30 hors journées de sprint planning

==== Le Tech Design ====
Le '''Tech Design''' est une session où les développeurs discutent des choix techniques avant d’implémenter une fonctionnalité. Ces moments sont réservés garantissent la présence de la direction technique si besoin.

Tous les mardi de 14h à 15h et tous les vendredi de 10h30 à 11h30.

==== Rétro d'équipe ====
Une rétrospective de l'équipe visant à améliorer les processus et les interactions entre ses membres.

Une fois par mois pour l'équipe Admin
Tous les mercredi après-midi du dernier jour du sprint
** De 14h à 15h pour l'équipe DevOps
** De 15h à 17h pour l'équipe Multiteam

=== Au niveau du programme ===
À un niveau plus large, des cérémonies de coordination ont lieu :

==== Les Tres Amigos ====
Réunion réunissant les trois rôles clé (PO, Développeurs, Testeurs) pour aligner la compréhension des user stories. Elles rentrent dans l'activité de raffinage du backlog mais peut être lancés à tout moments pour les besoins du programme.
Il faut veiller à bien identifier le sujet de discussion et fixer un temps limite pour l'échange. Ne pas toujours y convier les même personnes.

==== Le Weekly ====
Une réunion hebdomadaire permettant d’échanger sur l’avancement global du programme.

Elle a lieu tous les lundi de 11h30 à 12h30.

==== SOS Mid-week ====
Un point intermédiaire pour identifier les blocages critiques et ajuster les priorités.

Elle a lieu tous les mercredis de 12h00 à 12h30

==== Rétro générale ====
Une rétrospective collective visant à améliorer les processus et les interactions entre équipes. Tout le programme y est convié.

Le dernier mercredi du dernier sprint de la release

==== Post Mortem ====
Une analyse après un incident majeur pour comprendre les causes et éviter qu'il ne se reproduise.

==== PI Planning ====
Le '''PI Planning''' (Program Increment Planning) est une réunion de planification à l’échelle du programme, servant à synchroniser les équipes sur les objectifs des prochains sprints.

La première semaine du premier sprint de la release y est consacré.

== L’utilisation de Tuleap ==
Tuleap est la plateforme utilisée par Vitam pour suivre le travail agile et gérer les artefacts du projet.

=== Les outils de suivi (trackers) ===
Tuleap propose des '''trackers''' permettant de suivre les différentes tâches et artefacts du projet.

=== Les Continuous Improvements ===
Les '''Continuous Improvements''' sont des actions d'amélioration continue identifiées lors des rétrospectives.

=== Les Tâches ===
Les tâches sont les unités de travail de base assignées aux membres de l'équipe.

=== Les User Stories ===
Les '''user stories''' décrivent les besoins fonctionnels du projet sous forme d’histoires utilisateur.

=== Les Epic ===
Les '''Epic''' regroupent plusieurs user stories liées à une même fonctionnalité de haut niveau.

=== Les DOMAINES ===
Les '''DOMAINES''' correspondent aux grandes catégories de travail organisées dans Tuleap.

=== Les Activités PIC ===
Les '''Activités PIC''' concernent la planification et la coordination des activités du projet.

=== Les Activités PROD ===
Les '''Activités PROD''' suivent les actions et interventions réalisées en environnement de production.

=== Les Bugs ===
Les '''Bugs''' sont les anomalies détectées et suivies dans Tuleap pour correction.

=== Les Demandes de support ===
Les '''demandes de support''' permettent de signaler des problèmes nécessitant une intervention ou une assistance.

----

''Cette page est un guide sur l'agilité appliquée chez Vitam. Pour toute mise à jour ou question, veuillez contacter l’équipe de gestion agile.''

AGILITÉ

2025-03-18T14:24:26Z

Vitam : /* Les daily */

AGILITÉ

2025-03-18T14:11:02Z

Vitam : L'exercice d el'agilité dans VITAM

Accueil

2024-03-21T14:06:05Z

Vitam : /* FAQs */ nouvelle section

Bienvenu sur le wiki du projet Vitam. Il a pour objectif principal de centraliser la base de connaissance du projet concernant le développement, le devops, et le support.

== [[MULTITEAM]] ==
== [[DEVOPS]] ==
== [[SUPPORT]] ==
== [[AGILITE]] ==

== FAQs ==

dsffqd