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.

Méthode Aglie et Scrum

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 15^e 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.