1

Projet ASE seconde annéeObjectifs et démarche2 mars 2012

Johann Bourcier <johann.bourcier@irisa.fr>Benoit Combemale <benoit.combemale@irisa.fr>

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, …

Sommaire

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

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 outilsPersonnes et interactions >

Suivre un planS'adapter au changement >

DocumentationLogiciel qui fonctionne >Négociation à partir

d'un contratCollaboration avec le

client >

Principes SCRUM (3/4) : le process

Principes SCRUM (4/4) : le cadre

• Dir. Produit• ScrumMaster• Equipe

Rôles

• Planification du sprint • Revue du sprint • Rétrospective• Scrum quotidien

Réunions

• Backlog de produit• Backlog de sprint • Burndown chart

Artefacts

Sommaire

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

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

Sommaire

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

Contexte généralMOBILECONF

Add Mobile Experience to your Conferences…

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 être qu’une source d’inspiration ! Et tout n’est pas à retenir de cette application !

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

Sommaire

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

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 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 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 !

Sommaire

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

Sprint3Sprint2Sprint1

Planning

1. Réunion de lancement : le 02/032. Démo sprint 0, rétrospective, planification sprint 1 : le

09/033. Démo sprint 1, rétrospective, planification sprint 2 : le

30/034. Démo sprint 2, rétrospective, planification sprint 3 : le

27/045. Démo sprint 3, rétrospective : le 21/05 (de 17h à 18h)

Sprint0

1 4 52 3

Ex: conf. Ex: comités, participants, sponsors

Ex: social events, newsEx:

accueil

Questions ?