Projet ASE seconde année

Projet ASE seconde année Objectifs et démarche 2 mars 2012 • Johann Bourcier <johann.bourcier@irisa.fr> Benoit Combemale <benoit.combemale@irisa.fr> 1

Sommaire • Objectifs et organisation du projet • SCRUM : principes • SCRUM : mise en œuvre • Sujet • Résultat attendus • Démarrage

Objectifs et organisation du projet • Appréhender le développement de produit dans un contexte industriel • Objectif double : • Produire une application de qualité : • Utiliser les techniques de génie logiciel apprises en cours • Suivre une démarche rigoureuse : • Gestion du projet • Mettre en œuvre la méthode agile Scrum

Organisation générale • 1 équipe • L’équipe doit être autonome et doit chercher à fournir la meilleure solution au besoin exprimé par le client • Apprentissage autonome • Veuille techno. • La démarche choisie pour mener le projet est Scrum • Utilisation d’un système de gestion de développement collaboratif (Forge ISTIC, http://forge.istic.univ-rennes1.fr/): • gestionnaire de version (SVN), • gestionnaire de document, • liste de diffusion. • wiki, …

Démarche incrémentale • Pratique ancienne et courante : • Vise à découper un projet en livraisons successives • Permet de vérifier l'avancement • Et d'échelonner les paiements • N'est pas contradictoire avec un cycle en V • La solution est définie au commencement du projet • Seule sa réalisation est décomposée

Itératif • Contrairement à l'incrémental : • On démarre avec une vision produit et une première esquisse • On construit le produit au fur et à mesure des itérations • Le principe clef est d'utiliser la boucle de rétroaction • Apprendre en développant • Apprendre en UTILISANT le produit issue de l'itération précédente => Il n'est pas possible de spécifier à priori un bon produit • Elément nécessaire mais pas suffisant pour être agile Itératif Agile

Agile • L'agile intègre les principes du lean management • Amélioration continue • Respect des personnes • Remettre en cause chaque chose • Adopter le changement • Le focus est mis sur la réalisation de produit utilisable, sur la capacité à produire le plus de valeur pour le travail fourni • Le client est au cœur du processus • Le produit est construit par le dialogue avec le client : • Une équipe, pas un donneur d'ordre et des exécutants • En laissant l'équipe s'organiser • Choisir ses méthodes et ses outils

Construire un produit de façon agile (repris du blog de Martin Fowler) : • Pas agile : • Agile :

Les principes SCRUM (1/4) • Scrum est un processus Agile qui permet de produire la plus grande valeur métier dans la durée la plus courte. • Du logiciel qui fonctionne est produit à chaque itération appelée sprint (toutes les 2 à 4 semaines). • Le client définit les priorités. L'équipe s'organise pour déterminer la meilleure façon de produire les exigences les plus prioritaires. • A chaque fin de sprint, tout le monde peut voir fonctionner le produit courant et décider ce qui doit être fait dans le prochain sprint ou livrer le produit s'il est jugé satisfaisant par le client.

Principes SCRUM (2/4) : manifest agile Processus et outils Personnes et interactions > Logiciel qui fonctionne Documentation > Collaboration avec le client Négociation à partir d'un contrat > S'adapter au changement Suivre un plan >

Principes SCRUM (3/4) : le process

Rôles • Dir. Produit • ScrumMaster • Equipe Réunions • Planification du sprint • Revue du sprint • Rétrospective • Scrum quotidien Artefacts • Backlog de produit • Backlog de sprint • Burndown chart Principes SCRUM (4/4) : le cadre

Anticiper les évolutions • Scrum ne spécifie rien sur les méthodes d'ingénierie • Un développement piloté uniquement par les histoires utilisateurs ne permet pas de construire un système évolutif (risque avec XP) • Il est nécessaire de fixer le cadre des développements • Le modèle d'analyse : • Définit le langage commun avec le client, fixe les notions • Donne le modèle du problème et son éco système • Le modèle d'architecture décrit: • Le principe de la solution • L'organisation statique et dynamique du logiciel • Les règles respectées lors de la conception • Les technologies utilisées • Comment sont prises en compte les contraintes non fonctionnelles

Le sprint 0 • Un sprint à part, au démarrage du projet • Permet de définir les bases du produit • Le modèle d'analyse • Pour tous parler de la même chose • Le modèle d'architecture • Pour pouvoir travailler ensemble • Le cadre de production : choisir les outils, se mettre d'accord sur la façon de travailler : gestion de configuration, règles de codage, référence pour les tests • Permet de valider les points techniques durs • Vérifier le fonctionnement de composants non maîtrisés sur des exemples • Se concrétise par une première fonctionnalité, même partielle, qui démontre que l'ensemble de la construction tient. • Permet de faire une première estimation macroscopique du backlog produit

Les sprints suivants • Permettent l'obtention d'une version plus complète du produit • Le résultat obtenu est stable • Il est utilisable par le client • En implémentant de nouvelles histoires utilisateur • En fonction des priorités définies par le client • De façon à lever les incertitudes au plus tôt

Le cycle de vie d'un sprint : planification • Revue de planification de sprint • Objectif : • identifier les cas d'utilisation qui seront implémentés dans le sprint • Se mettre d'accord sur le contenu de la démo de fin de sprint • Eléments d'entrée : • Le product backlog, la liste des cas d'utilisation identifiés pour le produit • La capacité à produire de l'équipe pour le sprint • Eléments en sortie : • Le sprint backlog : les cas d'utilisation qui seront implémentés dans le sprint • La description de la façon dont sera démontré chaque cas d'utilisation • La définition des tâches nécessaires à la réalisation des histoires et leur estimation en heure.

Le cycle de vie d'un sprint : réunion quotidienne • Chaque jour, avant de commencer le travail • Objectif : • Recenser ce qui a été fait • Identifier les problèmes rencontrés, ce qui gène (impediment) • Définir ce qui sera fait dans la journée • Eléments d'entrée : • Le sprint backlog, • Un outil de suivi des tâches, de leur affectation et de leur reste à faire • Eléments en sortie : • Le sprint backlog remis à jour : reste à faire, commentaires et précision sur les tâches • La courbe de reste à faire du sprint (Burn Down chart).

Le cycle de vie d'un sprint : revue de sprint • Présentation des résultats du sprint • Objectif : • Valider l'avancement • Analyser le résultat • Définir les actions pour la suite • Eléments d'entrée : • Le produit issu du sprint • Eléments en sortie : • Le product backlog remis à jour avec de nouveaux items ou des changements de priorité

Le cycle de vie d'un sprint : rétrospective • Analyse du déroulement du sprint • Objectif : • Identifier les bonnes pratiques à poursuivre • Identifier ce qui marche mal et qu'il faut abandonner • Définir les améliorations à apporter • Eléments d'entrée : • L'histoire du sprint (impediments) • La courbe du sprint (Brundown chart) • Eléments en sortie : • Une ou deux résolutions pour le sprint suivant

Comment concevoir et se partager le travail • Travailler à partir de réunion de co-design • Pour choisir les principes de solution • Maintenir le modèle UML global à jour • Chacun enrichit au fur et à mesure des travaux • Consigner les raisons des choix techniques • Partager le travail par fonctionnalité plutôt que par domaine technique • Permet la propriété collective du code : chacun est responsable

Comment définir et estimer les tâches • Cherchez l'ordre de grandeur, pas la valeur exacte • Par exemple : 1, 2, 4, ... • Définissez un Critère de fin de tâche et tenez en compte au moment de l'estimation • Pensez aux tests et vérifiez qu'ils sont reproductibles • Définissez bien la référence pour éviter le « chez moi, ça marche » • Avoir une idée du design est nécessaire pour estimer • Eviter de calquer les tâches sur le modèle de design, choisissez plutôt quelque chose de testable

Références • http://www.12manage.com/methods_demingcycle.html • http://en.wikipedia.org/wiki/Spiral_model • www.mountaingoatsoftware.com/scrum • www.scrumalliance.org • www.controlchaos.com • http://danube.com/scrumworks/basic • http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

Lexique • User Story / Histoire utilisateur • Décrit une fonctionnalité à développer en se plaçant du point de vue de l'utilisateur • À rapprocher du cas d'utilisation • Backlog : ensemble d'histoires utilisateur • Un pour le produit, global et un pour chaque sprint • Sprint : itération de développement • Burn Down chart : courbe de reste à faire. • Une pour le produit et une pour chaque sprint

Contexte général MOBILECONF AddMobile Experience to yourConferences…

Contexte général • Application Android générique, destinée au participants à des (fédération de) conférences scientifiques • Exemple #1 : Les journées de conférences du Groupe De Recherche du Génie de la Programmation et du Logiciel, et la Conférence en IngénieriE du Logiciel (CIEL) • http://gpl2012.irisa.fr • Exemple #2 : 8th Educators' Symposium @ MODELS 2012: Software Modeling in Education • http://edusymp2012.irisa.fr

Contexte général (~ User Stories) • Exemple pour la fédération de conférence GDR GPL et CIEL 2012 : • Journées GDR GPL • Programme de la conférence (talk, keynote, lunch, break…) • avec gestion des favoris • avec localisation des salles de conférence • Conférence CIEL : • Programme de la conférence • avec gestion des favoris • avec localisation des salles de conférence • Affichage des news (RSS et Twitter) • Liste des participants (GPL et/ou CIEL) • Evènements sociaux • Visite de Rennes + diner de gala • Apéro BreizhJUG • (ouvert à tous) …. • Comités d’organisation, de programme et de présidents • Sponsors

Un exemple… • Inspirez vous de l’application ICSE sur iPhone • http://itunes.apple.com/fr/app/icse-2011/id435615522 • Ca ne doitêtrequ’une source d’inspiration ! Et toutn’est pas à retenir de cetteapplication !

Contraintes techniques • Plateforme Android • http://developer.android.com • Basic : http://developer.android.com/guide/basics/what-is-android.html • Map : http://developer.android.com/resources/tutorials/views/hello-mapview.html • L’application doit gérer l’internationalisation (EN/FR) • L’application doit facilement pouvoir être réutilisé pour plusieurs fédérations de conférences : • Voir mobileconf.xsd, gplciel2012.xml, et edusymp2012.xml. • L’application doit pouvoir être simulé sur l’environnement de développement Android, et exécuté sur un téléphone

Les résultats attendus • Un logiciel conforme aux attentes du client • Un document d'analyse • Un document d'architecture et de conception • Un dossier de gestion de projet (y compris estimation, planning, gestion et traçabilité des exigences…) • Un code clair et commenté • Un jeu de tests • Un manuel d’utilisation • Utilisez la forge de l’ISTIC : • Chaque sprint devra donner lieu à un tag particulier sur le SVN • L’ensemble des livrables devront être accessible sur les gestionnaire de documents et de fichiers

Document d'analyse • Objectifs : • S'assurer que tout le monde partage la même compréhension • Du domaine métier • Des critères de réussite du projet • De l'écosystème du projet • Définir les principes de la solution • Plan type : • Rappel du besoin et critères de succès • Modèle du domaine métier : modèle UML des notions manipulées, relations et explications • Description de l'écosystème : présentation des éléments avec lesquels le système va devoir s'intégrer, des contraintes à respecter • Principe de solution : description externe de la solution proposée ( le quoi, pas le comment)

Document d'architecture • Objectifs : • Définir les choix structurant pour les designs à venir • L'organisation générale du logiciel : statique et dynamique • Les règles de partage de responsabilité • Le choix des outils et librairies tierces • Décrire la prise en compte des contraintes identifiées en analyse • Plan type : • Principe de mise en œuvre de la solution (comment) • Règles d'architecture • Modèle statique : organisation des packages, descriptions des classes principales et de leurs responsabilités • Modèle dynamique : flux des événements, nominal et sur erreur, démarrage et arrêt • Explication de la prise en compte des contraintes d'analyse • Cadre de production : outils de dev, de configuration et de livraison.

Document de conception • Objectifs : • Définir les choix de conception de chaque sprint • Décrire la prise en compte des contraintesidentifiées en analyse • Plan type : • Principe de mise en œuvre de la solution (comment) • Règles d'architecture • Modèle statique : organisation des packages, descriptions des classes et de leurs responsabilités • Modèle dynamique : flux des événements, d’états • Explication de la prise en compte des contraintes d'analyse • Cadre de production : outils de dev, de configuration et de livraison.

Document de gestion de projet • Objectifs : • Définir l’organisation du projet • Décrire la prise en compte des besoins • Plan type : • Rappel des besoins et des éléments principaux de la solution • Estimation (planning, ressources) et description du déroulement du projet (démarche, jalons, outils, réunions) • Description des rôles et des responsabilités • Gestion du déroulement du projet (suivie du planning, comptes rendus de réunions…) • Description et gestion des exigences

Critères d'évaluation • Qualité du logiciel livré • L’application doit absolument être opérationnelle ! • Respects des exigences et contraintes générales • Qualité de la solution • Qualité de l’analyse et de la conception • Qualité de la gestion de projet • Qualité de la démonstration • Qualité des documents livrés • Respect des délais • Le respect des livrables n’est pas un critère d’évaluation mais de pénalisation !

1 Sprint0 2 3 Sprint3 Sprint2 Sprint1 4 5 Planning Ex: conf. Ex: social events, news Ex: comités, participants, sponsors Ex: accueil Réunion de lancement : le 02/03 Démo sprint 0, rétrospective, planification sprint 1 : le 09/03 Démo sprint 1, rétrospective, planification sprint 2 : le 30/03 Démo sprint 2, rétrospective, planification sprint 3 : le 27/04 Démo sprint 3, rétrospective : le 21/05 (de 17h à 18h)

Questions ?

Projet ASE seconde année