Ecom-sapins de noel 2012

Équipe
Qikai Gu

Xiao Lu

Noé-Jean Caramelli

Rôles : répartition des responsabilités

Chef de projet : Noé-Jean

Auteur : Noé-Jean

Concepteur d'interaction : Noé-Jean, Xiao

Développeur : Xiao

Expert en utilisabilité : Qikai

Graphiste : Qikai

Description du projet
Site web d'e-commerce pour la vente de sapins de Noël.

Choix de fonctionnement et justification
Nous avons choisi de prendre le chef de projet pour ScrumMaster.

Justification :  Il faut noter que l'on nous a demandé de nous organiser à la fois de façon traditionnelle et selon la méthode Scrum. Le rôle du ScrumMaster est "de la protéger des perturbations extérieures. Il est complètement transparent pour la communication entre l'équipe et les clients et n'a aucun pouvoir hiérarchique sur l'équipe. C'est en revanche un facilitateur pour les problèmes non techniques de l'équipe." (Wikipedia). Le chef de projet a aussi pour rôle de gérer les perturbations extérieures, et en principe il a aussi un rôle hiérarchique. C'est toujours le chef de projet qui doit envoyer les livrables demandés par l'équipe pédaggique (constat). Pour concilier au mieux les deux méthodes d'organisation que nous devons appliquer, nous avons choisi de prendre le chef de projet pour ScrumMaster et de gommer l'aspect hiérarchie. Chaque membre de l'équipe a des responsablilités et un pouvoir d'arbitrage déterminé (voir les rôles définis ci-dessus), mais aucun n'a plus de pouvoir qu'un autre.

Nous avons choisi une durée de sprint de 15 jours.

Justification :  Plusieurs critères nous orientent vers différents choix pour la durée du sprint. Nous avons affectés un coefficient à chacun d'eux puis avons fait la moyenne pondérée de durée de sprint :

(coef pour le critère*nb semaines/sprints)

(0.3*1) La courte durée du projet, de 2 mois (date de fin de la release fixée au 18 décembre 2012), nous insite à choisir des sprints d'1 semaine.

(0.3*3) La faible disponibilité de l'équipe de développement sur une semaine, compte tenu du cadre scolaire, nous oriente vers des sprints de 3 semaines.

(0.15*3) L'effectif réduit de l'équipe de développement, compte tenu du coût supplémentaire engendré par la préparation d'un produit partiel (démo+rétrospective), nous oriente vers des sprints de 3 semaines.

(0.1*3) La stabilité de l'architecture (sujette à modifications sur conseils dans un cadre pédagogique, méconnaissance des technologies utilisées) nous insite à choisir un sprint de 3 semaines.

(0.1*3) La durée maximum pour prendre en compte un changement (taille équipe, disponibilité, perturbations) nous oriente vsers des sprints de 3 semaines.

(0.05*1) Le maintient de la motivation de l'équipe nous oriente vers un sprint d'1 semaine.

(0) L'implication des clients et utilisateurs n'est pas comptabilisée.

Si l'équipe pédagogique (PO) est disponible physiquement une fois par semaine, les utilisateurs réellement ciblés sont inaccessibles !

Nous obtenons une durée de sprint de 2.3 semaines, arrondie à 2 semaines.

Rétrospectives
Pour les prévisions pour l'application de la méthode Agile, et par rapport aux informations qui nous ont été communiquées, nous retenons ces dates :

Ce sont les dates de fin de chaque sprint, toutes les 2 semaines

mardi 9 octobre 2012
Pas de développement

mardi 23 octobre 2012
Première 15e de développement


 * Rétrospective :


 * prévu : prototype de front-end, avec login et liste de produit (JSP) ; EJB basique pour login ; Mise en place d'un accès à une BD


 * réalisé : front end JSP OK, EJB ne fnctionnement pas, problèmes techniques ; donc, pas de temps pour la BD


 * Démo : démo fonctionnelle du front-end présentant le login/logout/inscription et une liste de deux produits.

[mardi 30 octobre 2012 : vacances]

mardi 13 novembre 2012

 * Rétrospective :


 * prévu :


 * réalisé :


 * Démo :

mardi 27 novembre 2012

 * Rétrospective :


 * prévu :


 * réalisé :


 * Démo :

mardi 11 décembre 2012

 * Rétrospective :


 * prévu :


 * réalisé :


 * Démo :

Nombre d'itérations : 4

Product backlog

fonctionnalités

N scprints backlog (bonnus : poker planning, estimation, complexité)

N sprints planning

N demo à la fin du sprint

N rétrospectives (thérapie de groupe, ce qui s'est bien/mal passé, ce qui peut être amélioré)

Dépôt SVN code
Ne contient que ce qui est nécessaire à l'application, le code.

Dépôt SVN documentation
Contient toute la documentation et les fichiers annexes.