Etude du projet Agile
Utilisation de la méthodologie Agile pour coller à un projet évolutif
1. Définition du produit
	. Pourquoi ?
	. Quelles fonctionnalités/problèmes résolus (liste des écrans nécessaires au produit à développer) ?
	. Pour qui ?
2. Définition des échanges de flux de données avec les applications tierces
	Définir chaque flux et choisir les API nécessaire à l'alimentation de ces flux dans le produit à réaliser ainsi que les délais de mise à jour.
3. Définir la base de données à créer ou à utiliser
	. Quelles sont les données stockée et celles qui sont calculées nécessaires au produit ?
	. Quelles technologies utilisées pour ce stockage (fichiers ou base de données) et estimation du serveur et de l'espace de stockage nécessaire ?
4. Définir l'architecture applicative
	. En fonction des besoins 2 possibilités :
		- Choix de la technologie et trouver un prestataire qui la maîtrise.
		- Choix d'un prestataire et utilisation des technologies qu'il maîtrise.
	. Pour la partie mobile, prévoir les cas de déconnexion et planifier les mises à jour de données.
		- Etudier les données qui seront conservées sur un serveur.
		- Etudier les données qui seront conservées sur mobile, la technologie utilisée et la périodicité des mises à jour.
5. Définir les fonctionnalités du backoffice et son implémentation
	. Définir les interfaces graphiques (UX-UI design) et fonctionnalités nécessaires à la gestion de l'application via le backoffice
	. Définir les mises à jour de données sur le serveur (qui fait ces mises à jour, comment, périodicité).
6. Définition des users stories
	. Rapport entre fonction produit et fonctionnalités nécessaires.
7. Suivi des équipes de développement
	. Définir les dates de livraison des différentes fonctionnalités par ordre de priorité.
	. En moyenne 4 à 6 users stories/semaine (en fonction de la taille de l'équipe).
		- Pour tenir ce rythme il est nécessaire d'investir dans des outils de tests automatiques et d'intégration continue pour éviter les tests de régression manuels.
		- Chaque user stories a au moins un test d'acceptation automatique au niveau fonctionnel.
		- La majorité du code a des tests unitaires automatisés.
	. Eviter de surcharger le développement suite aux livraisons par un trop grand nombre de nouvelles demandes, permet d'éviter une surcharge de travail et mauvaise qualité de développement.
		- Pour cela il faut avoir une semaine d'avance sur la planification des users stories à réaliser.
	. Il faut donc bien gérer les sprints et tickets afin d'avoir un bon suivi du développement.
	. Il faut aussi gérer le backlog des nouvelles demandes à venir en les priorisant, en faisant le tri et en refusant notament celles qui sont inutiles.
	. Il faut définir pour cela la valeur et la taille des users stories (criticité, durée, optionnelles).
		- Pour définir l'importance des users stories, il faut communiquer avec les parties prenantes qui utiliseront ces fonctionnalités afin d'en estimer la valeur et avec les développeurs pour la taille/durée de leur développement.
		- Attention, essayer de tomber juste dès le début du projet n'est pas une bonne méthode car très difficile à estimer, cela se fera au fur et à mesure du développement et des livraisons.
	. Par contre, il faut aussi décomposer les users stories par tâches à réaliser des plus précises au plus floues, les plus floues devenant plus précises au fur et à mesure des développements.
	. Planifier un atelier d'affinage des users stories 1h/semaine suite au feedback des utilisateurs par rapport aux livraisons.
8. Validation des développements
	. Etablir un planning de test avant mise en production et après mise en production (tests rééls).
	. Valider les développements avant déploiement.
	. Prévoir une période de test sur un groupe d'utilisateur pour valider la partie fonctionnelle.
9. Déploiement de l'application
	. Définir les périodes de mise à jour les moins génantes pour les utilisateurs.
	. Bloquer l'accès aux fonctionnalités mises à jour.
	. Sauvegarde de régression.
	. Mettre à jour.
	. Libérer les fonctionnalités bloquées après avoir tester que tout fonctionne correctement, sinon retour arrière et correction des erreurs.
Attention :
. Une bonne gestion d'un projet est liée à une bonne documentation et des commentaires dans le code.
. En travaillant avec des sociétés de prestation, celles-ci en fournissent le moins possible pour conserver leur savoir-faire et conserver leur clientèle.
. Il vaut mieux réaliser le cahier des charges et la documentation en interne afin de rester maître du projet et ne pas risquer de perte d'informations avec le temps.