# points à traiter MT/CR

## agilité
### Constat

- Sirus/Orus : les spécifs sont claires, l'équipe stat est réactive pour recetter. On n'est pas très loin de l'agilité, il manque peut-être des points avec la MOA, l'AMOA et MT entre les comités de maintenance pour avoir une vision moyen terme.
D'autre part il y a un point d'attention sur le remplacement d'Ali : un cadre formel pourrait permettre de sécuriser les bonnes pratiques déjà en place.

- Origami/Ocapi/Harmonica
Pour les 3 applications, on patine pas mal qd il y a des maintenance métier à faire essentiellement à cause :
- du manque de disponibilité des équipes stat pour spécifier et recetter
- d'un manque de priorités à court et moyen terme qui font qu'on se disperse (en lien aussi avec le point précédent)
- et parfois on a l'impression que les équipes stat ne savent pas trop ce qu'elles veulent (ce qui ne les incite pas à faire des spécifs...)

Les opérations de production courantes (points d'attention lors des dates clé des campagnes mensuelles ou annuelles, rechargements de bases, livraisons en recette sur tel ou tel environnement) reposent beaucoup trop sur la mémoire des agents.
Il y a peu voire très peu de connaissance métier dans l'équipe de maintenance ce qui ne facilite pas les choses.

Origami : quand il y a des maintenances métier, l'équipe stat a la volonté de faire des spécifs mais elles ne sont pas forcément carrées (ex procédures pour valider les traitements de notre côté)

Ocapi : spécifs plutôt carrées mais gros gros manque de temps côté stat pour les faire. Pas ou peu de visibilité sur ce qui n'est pas du tout exploré, par exemple sur les changements de nomenclature, sur le rebasement ou sur l'intégration des données de l'agriculture. On sent un manque de temps pour tester ce que l'appli est en mesure de faire toute seule et ce qui relève de maintenances dans le code. On n'a pas assez d'infos pour faire des premières investigations.

Harmonica : pas de spécifs réellement utilisables. On est obligé d'essayer de deviner ce qu'il faut faire et on ne peut pas toujours. Il y a des choses à faire mais qui ne sont ni spécifiées ni planifiées. C'est assez décourageant.
Peu de réactivité pour les recettes côté Paris.

### Quelques outils agiles déjà en place
- pour toutes les applis on a des hebdos avec les administrateurs d'appli, ce qui est très bien, mais il reste de la marge de progression
- on a des projets Kanboard pour toutes les applis mais qui ne sont pas très suivis. Il y a parfois des tickets qui ont des années... écrits par des personnes parties depuis bien longtemps. Les tickets Kanboard sont considérés comme peu pratiques.
- on bascule progressivement vers des tickets Gitlab qui sont beaucoup plus lisibles
- bascule à 100% pour Sirus/Orus
- Harmonica : les nouveaux tickets sont directement crées sous Gitlab
- Ocapi et Origami : on va les mettres en place début février pour les nouvelles maintenances métier

- des estimations collectives dans l'équipe de dev, en jours pour Sirus/Orus et en taille de Tee Shirt pour les applications d'incices

### pourquoi aller vers plus d'agilité ?
- l'agilité engage les équipes stats et info. Côté maintenance info, on voit l'indisponibilité des stats comme une entrave à un fonctionnement fluide. On pense que si les équipes stats peuvent s'engager sur des dates pour faire des dpécifs et des recettes, on sera moins dispersés et on perdra moins de temps.
- Il n'y a pas de priorisation par la MOA entre les trois applications d'indices, à part deux fois par an au comité e maintenance, mais ce ne sotn pas des priorisations opérationnelles. Un point régulier avec MOA, AMOA et MT permettrait d'une part que tous ces acteurs aient une vision de l'avancement réel et d'autre part d'avoir une feuille de route bien répartie sur l'année pour les développeurs.
D'autre part, ces points réguliers mettraient en évidence la difficulté que les équipes stat ont à suivre la vie des applications et pourraient probablement aider à trouver des solutions, ce qui n'est pas le cas avec les comités de maintenance qui ne sont pas opérationnels en raison de leur fréquence (2 fois par an).
### les forces et les freins
- Force : l'équipe de dev est OK pour y aller, notamment pour avoir des feuilles de route plus précises, plus fréquentes que les comités de maintenance et partagées maintenance/métier. Elle espère remédier au dispersement observé actuellement sur les applications d'indices.
- Force : il y a une pratique agile installée dans certaines équipes du service et donc un savoir-faire
- Force : les équipes stat sont partantes pour passer à des tickets Gitlab, ce qui montre une ouverture au changement :smiley:
- Faiblesse : l'exercice d'estimation fait un peu peur aux mainteniciens. La notion d'estimations est vécue comme un engagement et rend frileux pour faire plus fin que des tailles de tee-shirt. La notion de points agile n'est pas du tout comprise. Cela dit c'est une notion qui s'est parfois mal installée dans les équipes du service...
- Faiblesse : pour le moment les équipes stat ne sont pas réellement sensibilisées à l'agilité. Il faut une impulsion de la MOA et une formation spécifique.

### quelques propositions
- faire des itérations et inter-itérations communes pour les applications Origami, Ocapi et Harmonica. En effet, chacune de ces applications a, en moyenne de l'année, une taille trop petite pour l'agilité ; c'est bien en particulier pour lisser les travaux dans le temps que les développeurs sont mutualisés entre les applications. De plus, cette mise en commun permettra de ne mobiliser la MOAD et l'AMOA qu'une fois et pas trois.
- pour ces trois applications, dont deux ont des campagnes mensuelles, caler les inter-itérations non pas sur 4 semaines mais sur les mois. Ainsi, on aura 12 inter-itérations par an. Celles-ci pourront se positionner à un moment "calme" des campagnes mensuelles Ocapi et Harmonica, laissant le temps aux équipes stat de les préparer (en particulier de recetter les développements de l'itération).
- proposer un coaching pour les équipes stats et info avec au moins les points suivants :
- les spécifs :
- avoir une feuille de route avec les échéances incontournables
- connaître son besoin métier ou technique et l'analyser pour le découper en sous tâches
- anticiper la validation de la recette (DOD)
- intérêt des revues de spec (macro specs et US)
- découverte de l'estimation :
- côté info, on ne peut pas estimer ce qui n'est pas spécifié
- côté stat et info, savoir estimer un travail pas encore fait par analogie
- déculpabilisation sur l'imprécision des estimations
- force des points agile
- vélocité
- pour chaque itération, avoir (cf BRPP et ELire) :
- un ticket de suivi de prod qui rappelle les échéances de la campagne et dans lequel on renseigne le suivi des incidents de prod, l'organisation des recettes et MEP
- un ticket de suivi des incidents (s'il y en a !) qui réclament des développements correctifs