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 :

back-end : EJB pour connexion login et base de données (Hibernate) utilisable pour le login.
 * prévu : front-end : fiche produit lorsqu'on clique sur un produit de la liste, panier.

back-end : mise en place des EJB. Pas encore de BD, actuellement en cours. Également en cours : conception de la charte graphique.
 * réalisé : front-end : fiche produit lorsqu'on clique sur un produit de la liste.

Produit de la liste cliquable, redirige vers une fiche produit dévelppée. Projet test simple qui montre l'accès RMI aux EJB.
 * Démo : bouton panier avec compteur cliquable, redirige vers une fiche panier.

mardi 27 novembre 2012

 * Rétrospective :

Mise en place base de données et lien avec le projet (JDBS). Première IHM implémentée.
 * prévu : page panier.

Base de donnée crées avec les tables nécessaires pour le site et des exemples. Problème de base de donnée.
 * réalisé : Mise en place d'un exemple simple pour les EJB.


 * Démo : Petite démo test pour les EJB dans le projet. Ajout page commentaire accessible pour chaque produit grace à un bouton sur la page du produit concerné. Permet de laisser un commentaire et une note si on est loggé ; sinon redirige vers la page de log, puis une fois loggé, revient à la page commentaire. Ajout barre de recherche. Ajout page panier affichant le contenu du panier avec un champ pour modifier les quantités.

mardi 11 décembre 2012

 * Rétrospective :


 * prévu : IHM terminée, ajout boutons suppr et modifier au panier. Connexion entre base de donnée et site JSP. Page commande, et page admin.


 * réalisé : Premier jet d'IHM, encore en développement, très peu intégrée au noyau fonctionnel. Intégration des EJB au site. Connexion à la base de donnée. Modification des quantités du panier. Fonction login/logout terminée (avec gestion des erreurs...). Première page pour passer commande : informations de livraison. Les informations du compte d'utilisateur sont accessibles et modifiables en cliquant sur le login. Page admin non réalisée, fonction de recherche encore non fonctionnelle.


 * Démo : permet l'inscription d'un utilisateur, la constitution d'un panier et donne accès à la première page permettant de renseigner les informations de livraison pour passer la commande.

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.