Vous êtes sur la page 1sur 43

Maitre de stage :

Morgan Perrot
stage : Pierre
Chartagnat

Tuteur de

Gérer les
problèmes de
productivité
Rapport de stage
Antoine Guiral

2007/20
08
Sommaire

SOMMAIRE........................................................................................ ..3

REMERCIEMENTS................................................................................. 4

INTRODUCTION........................................................... ........................5

1.1 UNAPOLOGETIC SL.................................................................. ..............8


A.PRÉSENTATION............................................................................................................8

B. LES BESOINS D'UNAPOLOGETIC SL ...................................................................................8

1.2 NOS PROPOSITIONS................................................. ............................10


1.3 NOS RÉALISATIONS ............................................................. ................11
A. ENVIRONNEMENT DE TRAVAIL.........................................................................................11

B. LES STOCKS............................................................................................ ................11

C. LE CATALOGUE................................................................................ .........................13

D. LE SITE VITRINE................................................................................................ ........13

E. LE RESTE........................................................................................... ....................13

1.4 ANALYSE DU TRAVAIL EFFECTUÉ....................................................... ..........15


A.PLANNING PRÉVISIONNEL ET RÉEL.....................................................................................15

B.ANALYSE....................................................................................................... ..........16

C.CONCLUSION..................................................................................... .......................17

2.1 BIEN GÉRER LES RELATIONS AVEC LE CLIENT............................................ .........21


A.ÉVALUATION DES BESOINS...................................................................................... ........21

B.COMMUNICATION............................................................................................. ...........23

C.FLEXIBILITÉ, ADAPTATION : SCRUM................................................................................25

2.2 LE MANAGEMENT ET L'ORGANISATION.................................................... ........29


A.TRAVAILLER À PLUSIEURS............................................................................. ..................29

B.GÉRER LA MOTIVATION DE L'ÉQUIPE............................................................................. ......30

C.OPTIMISER LA PRODUCTIVITÉ....................................................................................... ....32

CONCLUSION................................................................................. ....35

GLOSSAIRE................................................ .......................................36

ANNEXES....................................................................... ...................38

ANNEXE 1 : MCD........................................................................... ..........1


ANNEXE 2 : CONVENTIONS DE NOMMAGE........................................................... ....2
ANNEXE 3 : COMPTE RENDU DE SPRINT OU « SCRUM PLANNING » DU 10/07.......................3
Remerciements

Avant tout développement sur cette expérience professionnelle, je me dois


de commencer ce rapport de stage par des remerciements, à ceux qui
m’ont beaucoup appris au cours de ce stage, et même à ceux qui ont eu la
gentillesse de faire de ce stage un moment très profitable.

Aussi, je remercie Matthieu Hernandez et Morgan Perrot, mes maîtres


de stage qui m’ont accompagnés tout au long de cette expérience
professionnelle avec beaucoup de patience et de pédagogie. Enfin, je les
remercie pour les conseils qu’ils ont pu me prodiguer au cours de ces trois
mois.

Je remercie également Fabrice Escure et la région Limousin pour leur


aide financière conséquente.

Odile Duvalet pour sa disponibilité et sa patience lors de mon


changement de stage.

Julien Lamy pour sa bonne humeur et le travail qu’il a effectué à mes


cotés.
Introduction

Du 2 juin au 2 septembre 2008, j’ai effectué un stage au sein de


l’entreprise Unapologetic SL (située à Barcelone, Espagne). Au cours de ce
stage, j’ai pu appliquer et étendre ma connaissance d'Internet.

Plus largement, ce stage a été l’opportunité pour moi de développer


une application web de A à Z. De la rédaction du cahier des charges
jusqu'à la réalisation, en passant par l'analyse et les conventions de
développement puisque je travailler avec un autre stagiaire de 3IL, Julien
LAMY.

Au-delà d’enrichir mes connaissances dans le développement web,


ce stage m’a permis de partager les premiers mois de la vie d'une
entreprise. Cela a été aussi l'occasion de rédiger un article pour le
magasine Linux+Magasine et de préparer mes certifications MySQL.

Unapologetic SL est une entreprise de distribution de vêtements de


sport de glisse (skate, BMX, roller, surf, snowboard, etc). Son premier
fournisseur est une marque chilienne dont elle a l'exclusivité en Europe.
Nous, avec Julien, avons rencontré ses créateurs et avons été force de
proposition afin de d'obtenir un stage. Nous leur avons proposé de réaliser
quatre objectifs. Le premier est un outil de gestion de leurs stocks ainsi
que ceux de leurs clients (les magasins). Le second est un site vitrine afin
de promouvoir leur image sur Internet. Le troisième est la mise en place
d'un blog afin de mettre en avant les sportifs sponsorisés par les marques
que distribue Unapologetic. Enfin, nous avons émis la possibilité de créer
une application FaceBook pour renforcer la présence de l'entreprise sur les
réseaux sociaux.

Au cours de ce stage, j'ai été confronté à deux problèmes, ou plutôt


à deux grandes nouveautés. La première fut la relation avec le client, ou le
commanditaire du projet. En effet les besoin pour une application évoluent
continuellement. La seconde fut de garder une motivation quasi-constante
sur un projet de quelques mois. Je suis bien conscient que ces deux
événements sont choses courantes dans le monde du travail. Cependant
elles restent inhabituelles pour un étudiant.

Afin de rapporter au mieux le déroulement de mon stage, je vais


commencer par présenter l'entreprise, son milieu et les missions que nous
devions réaliser en son sein. Cela nous permettra de mieux appréhender
la seconde partie dans laquelle nous verrons les éléments que nous avons
mis en place en termes de gestion de projet.
1. Unapologetic : ses besoins,
nos solutions

Dans cette première


partie je vais présenter
plus précisément mon
entreprise d'accueil,
Unapologetic SL. Cela
nous permettra de mieux
comprendre quels étaient
leurs besoins et de voir
comment nous y avons
répondu.

13
13
Unapologetic : ses besoins, nos solutions

1.1 Unapologetic SL
a.Présentation

Unapologetic SL est une entreprise de distribution de vêtements de


sport de glisse (skate, BMX, roller, surf, snowboard, etc). Pour le moment,
une marque, SUPPORT, lui a confié sa distribution exclusive pour l'Europe.
C'est ce qui a permis à MM. Hernandez et Perrot de se lancer dans
l'aventure.

Ils ont plusieurs objectifs à court, moyen et long terme. Dans un


premier temps il s'agit de conclure les premières ventes en Espagne afin
d'amorcer la pompe. C'est toujours une étape délicate puisque c'est le
premier contact entre les produits distribués et les vendeurs, ceux qui ont
un contact direct avec les utilisateurs finaux. Une fois la marque installé
en Espagne, ils élargiront leur champ d'action à l'Europe. De cette
manière, ils auront un réseau de revendeurs fourni et pourront distribuer
plusieurs marques.

Cependant le monde dans lequel ils évoluent (sport de glisse) est un


monde complexe, régit par de nombreux codes et dans lequel les
différents sports ne cohabitent pas forcement. La promotion de ses
marques peut devenir un exercice périlleux. Il faut donc être très prudent
en termes d'image et de communication. Mais aussi dans la constitution
du catalogue que l'on propose. Le plus facile pour promouvoir ses marques
étant d'avoir un panel de sportif reconnu dans chacun des sports et de les
sponsoriser. On s'approche alors du marketing viral. Des vidéos et/ou
photos qui montrent des exploits des sportifs sponsorisés circulent sur
internet et exposent la marque. Marque que d'autre sportifs reprendront
continuant ainsi le cycle de promotion.

D'autre part, l'entreprise étant très récente (statuts déposés


quelques jour avant le début du stage), elle devait affirmer sa présence
sur internet et se doter d'outils lui permettant d'améliorer sa productivité.

b. Les besoins d'Unapologetic SL

Unapologetic avait deux besoins majeurs. Un premier qui concerne


l'image de l'entreprise et sa visibilité sur Internet. Et un second qui impact
la productivité de l'entreprise puisqu'il s'agit de la partie gestion des
stocks, des commandes, du carnet d'adresse, etc.

L'image d'une entreprise sur internet passe avant tout par son site
vitrine. Viens ensuite la présence de l'entreprise sur les différents réseaux
sociaux (facebook, myspace, dailymotion, youtube, vimeo,...). Le besoin
numéro 1 était donc d'asseoir la présence d'Unapologetic sur Internet.

D'autre part, Unapologetic allait devoir gérer des stocks. Avec tout
ce que cela implique pour une entreprise de distribution. Plusieurs

13
Unapologetic : ses besoins, nos solutions

fournisseurs pour plusieurs marques, qui seront revendues à et par


plusieurs magasins. Il faut ajouter à cela que chaque fournisseur/magasin
a au moins un contact. La gestion des stocks et des contacts est un point
critique pour l'entreprise. Les stocks doivent être connu afin d'anticiper les
approvisionnements (les produits sont souvent fabriqués en Chine) et ainsi
éviter de faire du tord à la marque et à l'entreprise. Quand aux contacts,
ils ont chacun leur langue/culture et il faut essayer de s'adapter au mieux
lors des échanges : utiliser la même langue (si possible), des références
communes (sportifs sponsorisés notamment), etc. Le second objectif était
tout trouvé : assurer une productivité optimale à l'entreprise grâce à un
outil sur mesure couvrant l'ensemble de leur besoin.

Nous avons alors dégagés quatre axes de travail.

13
Unapologetic : ses besoins, nos solutions

1.2 Nos Propositions


Un des avantages de ce stage est que nous avons du être force de
proposition et ainsi bien cibler les attentes de l'entreprise et d'y répondre.

En ce qui concerne la gestion des stocks de l'entreprise nous avons


pris le parti de créer une application de A à Z. Ceci pour plusieurs raisons.
D'un coté nous étions en stage, et nous avons jugé qu'il était plus
intéressant de tout faire plutôt que de choisir un CMS (Content
Management System) et d'y ajouter nos plugins. D'autre part, ce choix
nous assurait de répondre au plus près aux besoins d'Unapologetic.
L'application devait permettre de gérer les fournisseurs, marques,
collections, articles, magasins, contacts et commandes. De plus les
magasins auraient un accès à leurs statistiques. Un client FLEX*/AIR* avait
aussi été prévu afin de faire bénéficier les magasins d’une interface
conviviale pour accéder à leurs comptes et leurs stocks. Le but était aussi
de se familiariser avec cette technologie d’avenir.

Pour promouvoir l'image de l'entreprise nous avions misé sur un site


vitrine, indispensable, et un blog pour être dans le coup et assurer une
certaine interactivité entre leurs « teams » et leurs consommateurs. Nous
devions réaliser le découpage et l'intégration de la charte graphique.
L'autre partie du travail se résumait dans l'optimisation des sites autant en
termes de performance, que de référencement et d'accessibilité. Nous
devions coder entièrement le site vitrine tandis que le blog aurait été basé
sur le moteur de blog Wordpress.

Nous avons aussi proposé de créer un plugin FaceBook afin


d'apprendre à utiliser le FBML (FaceBook Meta Langage) et de relater les
événements des teams d'Unapologetic sur le réseau social le plus
populaire au niveau international (même si MySpace compte le plus grand
nombre d'utilisateur).

Nous pouvons clairement identifier quatre tâches :

• la gestion des stocks et son client AIR


• le site vitrine
• le blog
• l'application FaceBook.

C’est à partir de ses 4 tâches que nous avons défini notre sujet de
stage.

13
Unapologetic : ses besoins, nos solutions

1.3 Nos Réalisations


Parmi ses quatre objectifs majeurs, tous n'ont pas été réalisés tandis
que la réalisation du catalogue s'y est greffée. Nous verrons dans la partie
1.4 les raisons de cet échec.

a. Environnement de travail

Dès le départ, nous nous sommes fixés des conventions de


nommages et de codages afin de faciliter la lecture et la modification de
nos codes respectifs. Ensuite nous nous étions fixé comme objectif de faire
un code accessible, du moins avec un JavaScript non intrusif sur les
formulaires critiques. L'utilisation de l'application de gestion des stocks
directement chez un client ou un fournisseur avec un téléphone portable
était un défi accessible et qui nous ferait prendre de bonnes habitudes.

Nous développions avec Aptana Studio*. C'est un environnement de


travail basé sur Eclipse. Cela nous permettait d'avoir tout les outils
nécessaires à la gestion du code directement sous forme de plugins. Que
cela soit pour la gestion du ftp ou de SVN (subversion, remplaçant de
CVS). Nous utilisions Google code comme serveur SVN.

Ainsi nous avions un environnement de travail robuste et flexible.

b. Les stocks

L'outil de gestion des stocks était sans aucun doute le plus gros du
travail. Nous avions découpé la réalisation en plusieurs phases.

La première phase comportait la création des différents formulaires


de saisie. J'avais en charge tout ce qui avait attrait aux magasins,
contacts, fournisseurs, marques, collections, articles... Julien s'occupait
pour sa part de toute la gestion des commandes. La logique aurait été de
créer les tests en premier. Dans notre cas, les besoins n'étant pas
clairement définis au départ, le fait de commencer par les formulaires de
saisie nous permettait de valider au fur et à mesure notre schéma
relationnel (annexe 1). Pour exemple, après notre première discussion
nous avions établi un schéma de 6 tables. Le projet fini en comporte plus
de 20.

La seconde phase fût celle des affichages. Tout ce que nous


pouvions saisir, ou presque, devait être affichable. La plus grande difficulté
de cette partie réside dans l'ergonomie. Le nombre de clic pour arriver à
l'information désirée doit être minimal. Certains artefacts JavaScript
peuvent être utilisés pour afficher de nouvelles informations sans créer de
rechargement de pages. On tend alors vers une application dite « 2.0 ».

13
Unapologetic : ses besoins, nos solutions

La troisième phase était de permettre une utilisation multiutilisateur.


Cela incluait la gestion des droits et la création automatique de mot de
passe avec envoi à l'utilisateur. En effet, les magasins peuvent remplir
l'état de leurs stocks toutes les semaines et de cette manière, peuvent
avoir accès à leurs statistiques de ventes.

La dernière phase nous permis de tester, d'optimiser et de valider le


travail effectué.

13
Unapologetic : ses besoins, nos solutions

c. Le catalogue

Cet objectif n’était pas dans les objectifs initiaux. Pourtant il est
logique qu’il fasse parti de nos réalisations. En effet, lors de la réalisation
de l’application de gestion des stocks, le catalogue est entièrement saisi. Il
ne manquait, pour fournir un catalogue en ligne digne de ce nom, que les
photographies des articles, collections et marques.

Ayant déjà réalisé les formulaires, j’ai naturellement pris en charge


ces modifications pendant que Julien réalisait le catalogue en lui-même. Il
avait besoin d’image de plusieurs tailles. J’ai pris le parti de créer les
miniatures au moment de l’upload des images : l’espace sur le serveur est
moins une contrainte que la bande passante utilisée pour charger des
images lourdes, et encore moins qu’un site plus lent pour l’utilisateur. Php
et sa librairie gd2 permet de réaliser ce redimensionnement facilement.

d. Le site vitrine

Le site vitrine d’une entreprise est un point critique pour son image.
C’est pourquoi sa charte graphique et son ergonomie doit être réalisée par
des designers professionnels. Cette charte graphique devait nous être
fournie courant juillet. Cependant, et c’est le risque lorsque l’on sous-traite
des tâches, il y a eu des retards de livraison. A tel point qu’à la fin de notre
stage nous ne l’avions toujours pas. Difficile donc de travailler sur un site
dont nous ne connaissons pas le contenu, la charte graphique et tout ce
qui en découle : architecture, navigation, etc.

Pour ne pas rester passif devant cet événement, nous avons proposé
à nos maitres de stages de leur réaliser chacun une charte graphique
provisoire. L’objectif n’était pas de perdre un temps considérable mais de
se familiariser avec les outils de création graphique, la découpe d’un
design et son intégration. Il est aussi intéressant de se poser des questions
sur l’ergonomie du site que l’on veut réaliser. L’utilisateur est roi et doit
pouvoir atteindre les informations le plus rapidement possible. Bien sur
l’accessibilité et le référencement ne sont pas en reste et le site se devait
d’être optimiser en tout point.

e. Le reste
Les 3 autres objectifs n’ont pu être accomplis. Nous avons eu le
même problème pour le blog que pour le site vitrine. Pas de charte
graphique, pas de blog puisque hormis l’ajout de plugins ou la création du
thème il n’y guerre de travail à faire…à moins de recréer un moteur de
blog !

13
Unapologetic : ses besoins, nos solutions

L’application FaceBook et l’application AIR n’ont pas été réalisées


par manque de temps. C’est dommage car cela aurais pu être la partie la
plus intéressante techniquement parlant. Le fait d’apprendre de nouvelles
technologies constamment fait du métier d’informaticien ce qu’il est : un
métier passionnant et enrichissant.

13
Unapologetic : ses besoins, nos solutions

1.4 Analyse du travail effectué


Je vais d’abord vous présenter les plannings prévisionnels et réels,
avant d’analyser les écarts et d’en tirer des conclusions.

a. Planning prévisionnel et réel

13
Unapologetic : ses besoins, nos solutions

Rappel Tâche Début éstimé Durée éstimée (jour) Début réel Durée réelle (jour)
A Gestion des stocks 0 25 0 45
1 Analyse, MCD 0 5 0 5
2 Formulaires 5 8 6 14
3 Vues 13 8 20 10
4 Optimisations 21 2 30 2
5 Création des graphes de stocks 23 1 32 9
6 Multi-utilisateur 24 1 41 4
B Site Vitrine 25 5 45 10
7 Graphisme 25 1 45 6
8 Integration 26 1 51 1
9 Contenu 27 1 52 1
10 Optimisations 28 2 53 2
C Catalogue 30 5 55 15
11 Modifications formulaires 30 2 55 7
12 R&D 32 3 62 8
D Blog 35 15 0 77
E Application FaceBook 50 10 0 77
F Application Cliente Air 60 17 0 77

0 10 20 30 40 50 60 70 80 90

A
1
2
3
4
5
6
B
Gantt prévisionnel
7
8
9
10
C
11
12
D
E
F

0 10 20 30 40 50 60 70 80 90

A
1
2
3
4
5
6
B Gantt réel
7
8
9
10
C
11
12
D
E
F

b. Analyse

Le premier constat est que les différences entre prévisionnel et réel


sont importantes. Elles sont dues principalement à trois facteurs.

Le premier était l’évolution constante des besoins, problème récurrent


en informatique. En effet, à chaque réunion d’importants changements
étaient évoqués. Cela implique souvent des modifications du MCD* qui

13
Unapologetic : ses besoins, nos solutions

imposent souvent de revoir en profondeur le travail effectué. Les


changements qui en découlent sont rarement compliqués mais fastidieux.
Par exemple l’ajout d’un champ dans un formulaire a pour conséquence :

• modification du squelette du formulaire de saisie

• modification de la base de donné (et des requêtes)

• modification des contrôles coté client et coté serveur

• modification du formulaire de mise à jour de la même manière

• modifications des vues

La mise à jour des besoins par le client s’effectuait toutes les semaines
lors de nos réunions. Le projet, principalement l’application de gestion des
stocks, prenait ainsi un peu plus de retard toutes les semaines.
Heureusement nous arrivions à tenir le rythme et l’application
s’enrichissait à vue d’œil.

Le second était lié exclusivement au site vitrine et au blog.


Unapologetic avait sous-traité la réalisation de la charte graphique du site
vitrine et du blog. Malheureusement elle n’a jamais été livré (toujours pas
à l’heure où j’écris ces lignes). Cela m’a laissé du temps pour m’attarder
sur des fonctionnalités non essentielles et sur l’apprentissage de certaines
technologies mais m’a empêcher de réaliser un site vitrine digne de ce
nom. Afin de ne pas délaisser complètement cet objectif, j’ai proposé à
mon maitre de stage que nous réalisions chacun une charte graphique
temporaire. Cela leur laissait le choix et nous permettait de nous essayer
au métier de designer. Malgré le fait que je n’avais pas le contenu du site
j’ai proposé un design épuré doté de quelques fonctionnalités basiques en
termes de navigation.

La dernière cause de retard fût l’ajout du catalogue en ligne. Cet


ajout le contraint à revoir une partie des formulaires que j’avais conçut.
Certaines modifications avait lieu sur des parties réalisées en AJAX* et
m’obligeait à repenser l’ergonomie des formulaires afin de ne pas altéré la
navigation et le confort de l’utilisateur.

c. Conclusion

En conclusion, il ressort que les relations avec les commanditaires du


projet (maitres de stage, clients, etc…) sont primordiales. D’une part pour
mener le projet à bien mais aussi pour livrer un projet qui correspond aux
attentes du client (qui sont la plus part du temps différentes de celles
exprimées dans le cahier des charges initial!). Les retards de livraison
inhérents à ses changements ne sont rien comparés à un projet à
recommencer car plus d’actualité et inutilisable…Cependant ces
demandes de modifications/ajouts de fonctionnalités peuvent avoir un

13
Unapologetic : ses besoins, nos solutions

impact néfaste sur la motivation de l’équipe si ils sont mal gérés. C’est
pourquoi nous avons décidé de nous orienter vers les méthodes de
management dîtes agiles*. Et plus particulièrement vers la méthode
SCRUM*. De cette manière nous gardions une motivation intacte tout au
long du projet tout en optimisant nos temps de développement. Notre
productivité s’en trouver d’autant plus grande.

13
Unapologetic : ses besoins, nos solutions

13
2. Gérer les problèmes de productivité

Dans cette seconde


partie je vais présenter ce
que le stage m’a
principalement apporté :
la gestion des problèmes
de productivité. D’un
coté j’ai découvert les
relations client (les clients
étant nos maitres de stage
ici). De l’autre c’est la
première fois que je
travaillais en équipe.
J’expose ici ce que j’en
retire et ce que j’aimerais
réutiliser ou faire la
prochaine fois que je
serais confronté à cette
situation. Le fil
conducteur sera la
méthode SCRUM et
l’eXtreme Programming
(XP)*.

13
Gérer les problèmes de productivité

2.1 Bien gérer les relations avec le client


Les relations avec le ou les clients font parties intégrantes d’un
projet informatique. On pourrait penser que le client passe sa commande
puis attends d’être livré et qu’entre temps il ne joue aucun rôle. Nous
verrons qu’il doit être présent durant toute la phase de développement et
nous verrons comment le faire rentrer dans la partie. Une fois que nous
aurons vu quels rôles il devrait jouer nous regarderons un peu plus en
détail la méthode SCRUM, dérivée des méthodes agiles. Cela donnera un
cadre plus fondé et éprouvé à mes propos.

a. Évaluation des besoins

Nous admettrons dans cette partie qu’un membre de l’équipe sert de


lien entre l’équipe et le client pour toutes les questions directement liées à
la réalisation du projet. Avec le client il représentera l’équipe, avec
l’équipe il représentera le client. Cela vient de la méthode SCRUM. Je
reviendrais dessus plus en détail dans la partie 2.1.c.

La base d’un projet est une envie, une commande : un besoin. Ce


besoin peut être, et c’est souvent le cas, exprimé par quelqu’un de
totalement étranger au monde de l’informatique et plus précisément du
web dans notre cas. Afin de pallier à ces éventuels problèmes de
compréhension des normes ou langages on été créé. Elles permettent aux
deux partis de ce comprendre. UML* en est un exemple avec les « user
case ». Au fur et à mesure des discussions on réalise des schémas qui d’un
coté seront compréhensibles par le client (qui montrera alors plus
d’investissements et d’intéressements) et de l’autre exploitables par
l’équipe de développement.

Les discussions qui permettent de créer ces schémas et, plus


généralement le cahier des charges, doivent être réalisées avec la plus
grande attention. Un maximum de question doit être posé, et ce qui va
sans dire va mieux en le disant : même si quelque chose apparait évident
aux yeux du représentant de l’équipe il vaut mieux poser la question. Ce
qui peut lui paraitre évident avec sa vision de développeur ne le sera peut
être pas pour un client néophyte.

La première étape est passée. L’équipe peut maintenant se réunir et


analyser les données récoltées. La réalisation d’un MCD et d’un schéma
relationnel permettra d’avoir une première idée sur la faisabilité du projet.
De plus le projet commencera à prendre forme. On pourra commencer à
discerner le noyau, des fonctionnalités plus ou moins prioritaires. Ce sera
aussi l’occasion d’avoir une première approximation du temps nécessaire
à la réalisation du projet et donc du coût.

A ce moment là, il peut être opportun de voir le client pour plusieurs


raisons. La première est la validation du travail effectué par l’équipe :
MCD, architecture, navigation, éléments graphiques, etc…Nous sommes

21
Gérer les problèmes de productivité

d’accord, ce ne seront que des ébauches, schéma, croquis. Pas du travail


fini mais quelques choses qui permettront de vérifier si ce qu’a compris
l’équipe est en accord avec ce qu’a pensé le client.

Deux cas peuvent alors se présenter :

 Le client n’est pas d’accord ou souhaite modifier certaines


choses, soit parce qu’il y a eu des incompréhensions soit parce
qu’il veut changer certaine chose. Dans ce cas là on refait une
itération : prise d’information, analyse avec l’équipe puis
nouvelle réunion avec le client et enfin validation ou non.

 Le client valide le travail de l’équipe. Le développement du


projet peut commencer.

21
Gérer les problèmes de productivité

D’autre part il est important de voir avec le client quels sont les
modules/fonctionnalités/pages prioritaires afin de fixer une feuille de route
à l’application. De cette manière des versions pourront être livrées plus
rapidement et à une fréquence plus élevée. Le client aura alors une réelle
impression que le projet avance et en sera d’autant plus satisfait (c’est lui
qui paye au final !).

b. Communication

Une fois que le projet est lancé le client doit continuer à être présent
tout au long du développement. C’est une communication permanente qui
doit avoir lieu sans pour autant altéré la productivité de l’équipe.

Grossièrement on pourrait imaginer deux types de gestion des relations


avec le client :

 La première serait une évaluation des besoins et un cahier des


charges réalisés avec lui puis la livraison du produit final. Entre
temps l’équipe et le client non aucun contact et le
développement s’en tient a ce qui avait été exposé au début du
projet.

 La seconde débuterait de la même manière, avec une rédaction


du cahier des charges. Si possible de la manière dont nous avons
parlé dans le 2.1.a afin de partir sur de bonnes bases. Ensuite un
membre de l’entreprise (si possible car il servira de « traducteur
de besoin ») représentera le client durant toute la durée de
développement. Ainsi le projet évoluera en même temps que les
besoins du client.

On se rend compte, même si je le répète c’était une schématisation,


que dans le premier cas le projet à de grande chance d’être un échec. Et
plus le projet sera gros plus il a de chance de ne pas ou plus correspondre
aux besoins actuels du client. Dans le second cas par contre, le projet va
évoluer en même temps que les besoins du client. Les délais peuvent en
être rallongés mais le client les acceptera mieux puisqu’il sera un
« acteur » de ces changements.

En outre, le fait que le client soit « présent » au sein de l’équipe va


considérablement stabiliser le projet et diminuer les temps de livraison. A
chaque fois qu’un membre de l’équipe se posera une question lors de la
réalisation de tel ou tel module/fonctionnalité/élément graphique/etc, il
aura le plus souvent directement la réponse. Donc d’une part, il ira plus
vite mais en plus, de suite dans la bonne direction. Les gains en
productivité s’en ressentiront directement.

Je souhaiterais revenir sur un point : « un membre de l’équipe


représentera le client ». On vient de voir que la présence du client tout au
long du développement est importante. Cependant la présence directe de

21
Gérer les problèmes de productivité

ce dernier pourrait nuire à l’équipe. Cela rajouterait une pression négative


sur ses membres et leur rendement baisserait automatiquement. Pour
pallier à ça un membre de l’équipe aura comme rôle de représenter le
client. Il suivra l’évolution du produit au jour le jour et corrigera le tire le
cas l’échéant. Il sera en contact avec le client et s’assurera que les
décisions prises sont toujours les bonnes.

Maintenant que nous avons vu de manière « empirique » comment


nous pourrions optimiser le rendement de l’équipe en gérant différemment
les relations avec les clients, nous allons cadrer tout cela théoriquement
en s’appuyant sur la méthode SCRUM.

21
Gérer les problèmes de productivité

c. Flexibilité, adaptation : SCRUM

Tout d’abord SCRUM a été conçue pour la gestion de projets de


développement informatique. Elle est sensée en améliorer la productivité
en se basant sur six idées clés :

 Le client au cœur du projet

 Esprit d’équipe

 La communication est la clé

 Simplicité, Efficacité, et Qualité

 Flexibilité aux changements

 Avancement basé sur le concret.

A cela viennent s’ajouter quatre oppositions entre concepts proposés et


concepts « traditionnels » (source Wikipedia) :

 Individus et interactions vs. Processus et outils : ce sont les


individus qui font la valeur du travail accompli, ce sont donc eux que
l’on doit privilégier. Les processus qui définissent ce que doit faire
chaque personne brident le potentiel caché derrière chacun : faire
interagir les gens au maximum est bien plus prolifique et permet
d'améliorer grandement l'efficacité et la qualité du travail fourni, en
rassemblant des visions différentes d'un même problème.

 Logiciel qui fonctionne vs. Documentation exhaustive : les


processus lourds génèrent une documentation qui se veut exhaustive
avec tous ses inconvénients : ambiguïté du langage, coût de la
rédaction, coût du maintien en accord avec la réalité, etc. Ces
documents ne sont qu'une illusion d'avancement du projet. Dans les
méthodes Agiles, un seul critère permet de mesurer l'avancement d'un
projet : le logiciel qui fonctionne. La documentation n'est qu'un support
concret qui aide à produire le logiciel.

 Collaboration du client vs. Négociation de contrat : dans tout


projet, le but premier est de gagner de l’argent, autant pour le client
(rentabilisation) que pour le fournisseur (prestation). Si la négociation
protège plus ou moins des risques financiers, elle peut provoquer
l’échec des projets (délais non respectés, budgets insuffisants), et
engendrer d'interminables procès où tout le monde y perd. Il faut sortir
de la guerre client/fournisseur et penser en équipe qui veut atteindre
un but commun : réussir le projet.

21
Gérer les problèmes de productivité

 Réponse au changement vs. Suivi d'un plan prédéfini : Un plan


prédéfini a tendance à nous rendre autistes aux événements qui
surviennent pendant le projet. Il est en plus à l'origine des conflits
client/fournisseur classiques sur les délais de livraison. Pour le client,
pouvoir adapter les besoins en cours de projet est un atout
concurrentiel : il est réactif aux fluctuations des marchés et s'assure en
plus que le logiciel développé répond parfaitement à ses véritables
besoins. Les méthodes Agiles sont conçues pour s’adapter au
changement, en assurant un plan macroscopique précis et adaptatif.

On remarque que le dernier point nous permettra (puisque c’est prévu)


de faire face aux évolutions des besoins du client. Et c’est là que SCRUM
est particulièrement intéressant. SCRUM va nous permettre de passer de
la théorie à la pratique en expliquant les rôles de chacun et en livrant les
grandes lignes des cycles de développements. Bien sûr, elles sont
adaptables à toutes les structures (ce serait un comble !).

Il existe peu de rôles dans la méthodologie SCRUM. La hiérarchie est


supprimée car elle alourdie les processus et rigidifie la structure. Les
interactions entre les membres sont moins fortes, la créativité baisse, la
productivité aussi…

On voit sur ce schéma qu’il n’y a que trois rôles :

21
Gérer les problèmes de productivité

 Le directeur de produits (ou product owner) qui est chargé de


représenter le client au sein de l’équipe. C’est lui que j’évoquais au
début de la partie 2.1.a. Il est les yeux et la bouche du client. Pour
cette raison il doit se montrer le plus disponible possible pour
l’équipe afin de répondre aux moindres de leurs interrogations : c’est
lui qui prend les décisions concernant l’orientation du projet. Dans
notre cas, ce rôle était assuré par M. Perrot (malgré le fait qu’il soit
aussi le « client »).

 L’équipe est autogérée. Pas de hiérarchie, pas de poste : le chao. Il


s’est avéré que les équipes autogérées étaient celles qui étaient les
plus productives et les plus qualitatives. J’ose un parallèle avec le
rugby : au rugby on joue pour les autres parce que sinon les autres
ne joueront pas pour nous (et gare aux doigts qui trainent !). Ici
l’équipe, que dis-je, l’EQUIPE est solidaire et les membres codent les
uns pour les autres.

 Le Scrum master a un rôle particulier. C’est un peu la clef de voute


du système. Son but premier est de coacher le groupe afin qu’ils
suivent les directives de SCRUM. C’est donc lui entre autre qui
mènera les réunions (on verra tout à l’heure qu’il y en a plusieurs
types). Son autre but et de couper l’équipe des stimuli
perturbateurs. Non pas pour les couper du monde mais pour qu’ils
ne se dispersent pas. Par exemple il gérera l’administratif ou tout
autre tâche non-technique. Il est important de préciser que le Scrum
master n’est ni un chef de projet ni un intermédiaire avec le client –il
existe aujourd’hui des certifications Scrum master-.

Durant le stage nous n’avons pas pu mettre entièrement en place cette


façon de procéder. M. Hernandez aurais un rôle proche de celui de Scrum
master mais il était aussi client ce qui est uen contre indication. A coté de
cela l’équipe était autogérée et M. Perrot répondait très rapidement à
toutes nos questions d’ordres techniques.

En plus d’avoir essayé de suivre la répartition des rôles, nous avons


voulu nous rapprocher de SCRUM dans notre fonctionnement au quotidien.
D’après leurs recommandations, la vie d’un projet suit plusieurs cycles
bien précis : release/projet, sprint, et quotidien. Par exemple nous avions
cinq projets (voir GANTT 1.4.a page 10). Ces projets étaient décomposés
en plusieurs parties qui s’appelées « sprint ». Chaque sprint a un but et
contient une liste de fonctionnalité à réaliser : une liste d’items de backlog
de produit. Elle doit être discuté et approuver par tout les partis : product
owner, Scrum master et l’équipe lors du Scrum planning. L’équipe définie
le nombre d’items de backlog de produit réalisable concernant les
fonctionnalités prioritaire données par le product owner. Si un sprint est

21
Gérer les problèmes de productivité

accepté, on le décompose en une liste d’items de backlog de sprint.


Autrement dit : une liste de tâches élémentaires. Une fois la liste d’items
de backlog de sprint réalisée le sprint commence. On rencontre alors un
autre type d’itération : le Scrum ou daily Scrum. C’est une réunion
quotidienne d’une quinzaine de minutes chapotée par le Scrum master.
Chaque membre de l’équipe dit ce qu’il à fait la veille, ce qu’il va faire
aujourd’hui et quelles sont les difficultés qu’il rencontre. Cela permet de se
fixer des objectifs quotidiennement et de ne pas rester enfermé dans ses
problèmes. Une fois que la fin du sprint arrive il y a une revue de sprint.
C’est une présentation des fonctionnalités réalisées. Le product owner les
valide ou non et l’équipe repart sur un nouveau sprint.

Cette illustration permet de mieux saisir les cycles qui rythment la vie d’un
projet.

Pour nos projets nous avions choisi des sprints d’une semaine. Pour
mes tâches, le premier sprint servait à valider les interfaces graphiques et
l’ergonomie tandis que la seconde validait entièrement le formulaire et les
traitements associés.

Les réunions quotidiennes s’effectuaient le matin lors de notre arrivée


dans les locaux de l’entreprise. La réunion en elle-même est intéressante
car elle permet d’avoir de réels objectifs tout les jours et de s’y tenir.
D’autre part, les discussions post réunion qui concernent les problèmes
rencontré sont très enrichissantes et permettent de progresser plus
rapidement.

Après quelques mois de pratique, plus ou moins assidus, il s’avère que


ma proposition d’utiliser SCRUM fût convaincante. J’ai vraiment pris
conscience que cette méthode est réellement flexible et adaptée aux
changements et à l’évolution des besoins du client. De plus, cela permet à
l’entreprise et au client d’être satisfait puisque les deux travaillent dans le

21
Gérer les problèmes de productivité

même sens : la réussite du projet. L’équipe travail dans un environnement


satisfaisant et el client à un produit qui colle au plus près de ses attentes.

Nous avions donc trouvé une méthode flexible qui nous permettait de
mener à bien nos projets. Il ne nous resté plus qu’à mettre en place notre
cadre de travail et nos méthodes de travail.

2.2 Le management et l'organisation


Travailler à plusieurs comportes des avantages : synergie, résolution
de problème, désenclavement personnel, etc… Mais cela apporte
quelques changements d’habitudes : convention de nommages,
versionning, dispersion, etc…Je vais donc exposer quels outils j’ai proposé
de mettre en place.

a. Travailler à plusieurs

Le fait de travailler à plusieurs implique inévitablement que des bouts


de code de chaque développeurs vont venir s’assembler. Certain seront
modifiés par un autre membre de l’équipe, d’autres seront supprimés, etc
mais d’aucune manière cela doit faire régresser l’application.

Pour gérer ce problème on peut utiliser un gestionnaire de version. J’ai


donc proposé d’utiliser SubVersioN (SVN) qui est le successeur du célèbre
CVS (Concurrent Versions System). Coté client nous utilisions un plugin
pour Aptana (notre éditeur qui est un dérivé d’eclipse). Et nous avons opté
pour Google Code comme serveur SVN en ligne. Google Code permet,
outre le fait de gérer les versions, d’accéder au code en ligne à tout
moment, de disposer d’un wiki, et d’un gestionnaire de tickets (utile pour
suivre les bugs). La seule « contrainte » lorsque l’on travail avec SVN est
qu’il faut commiter (rendre disponible son code sur le serveur) le plus
souvent possible afin d’éviter les conflits lorsque deux membres travaillent
sur le même fichier.

L’autre point essentiel lorsque l’on travail à plusieurs est la


communication. Elle doit se mettre en place naturellement. Que cela soit
pour indiquer qu’un commit sur un fichier commun a été effectué ou pour
résoudre un problème. On aurait trop tendance à vouloir résoudre ses
problèmes ou bugs tout seul. Mais les pertes de temps se multiplient et la
motivation en prend un coup lorsque les problèmes s’enchaînent. Le fait
d’en parler permet non seulement d’aller plus vite mais surtout d’avoir
constamment un point de vue extérieur sur son code. Les membres de
l’équipe se transmettent alors leurs connaissances soit en donnant des
pistes pour la résolution d’un problème, soit en exposant une autre
manière de faire plus simple ou plus directe. Inévitablement le niveau
général de l’équipe s’homogénéise et tend vers le haut.

Les outils de versionning mis en place et les intérêts d’une bonne


communication bien compris, il faut se mettre d’accord sur des

21
Gérer les problèmes de productivité

conventions de nommage. En effet partager son code et en parler ne suffit


pas quand on travaille à plusieurs. Il faut aussi que le code soit
compréhensible et modifiable par toute l’équipe. Dans notre cas, les
conventions de nommages (annexe 2) concernaient les noms de variables,
les noms de fonctions, les noms de tables et champs mysql et
l’indentation. C’est un exercice difficile au début mais il faut être rigoureux
si l’on veut que le code écrit soit maintenable.

Enfin, il est important de respecter les autres membres de l’équipe.


Chaque individu a ses propres moyens de concentration et son propre
rythme de travail. Il faut en prendre compte afin de ne pas les perturber à
outrance et faire chuter la productivité d’un ou plusieurs membres de
l’équipe. L’autre effet que cela pourrait avoir serait de mettre une
mauvaise ambiance dans l’équipe et de la démotiver.

Et la motivation de l’équipe est un paramètre important dans la


réussite d’un projet ! Nous allons voir dans la prochaine partie comment
gérer au mieux la motivation d’une équipe.

b. Gérer la motivation de l'équipe

La motivation de l’équipe est un des facteurs prépondérants dans la


réussite d’un projet. Plusieurs facteurs sont à prendre en compte pour
s’assurer que l’équipe vit bien et soit motivée.

L’idéal est de garder une motivation intacte sur un projet…or c’est


mission quasi impossible.

C’est inhérent à un projet, au début la motivation est au top, excitation


dûe à l’arrivée d’un nouveau projet, avec des problématiques différentes,
etc… puis peu à peu la fatigue se fait sentir et la motivation baisse (un
peu comme indiqué sur le graphique ci dessous), avec à la fin, hâte de
releaser le projet et pouvoir (enfin!) passer à autre chose.

21
Gérer les problèmes de productivité

Pour pallier à ce problème, nous avons la méthode SCRUM décrite en


2.1.c. Pour un même projet, les cycles de motivation se régénèrent avec
les releases ou projets (courbes bleues), les sprints (courbes vertes) et en
zoomant un peu ils sont même régénérés quotidiennement avec les daily
Scrum (pas de courbes pour des raisons de lisibilité). On tendrait alors à
avoir une courbe de motivation qui contiendrait non pas un pic de
motivation mais plusieurs très régulièrement :

Mais la motivation dépend aussi de l’environnement dans lequel


l’équipe évolue. Du bon matériel, des bonnes chaises, une bonne
ambiance sont d’autres facteurs qui induisent sur la motivation. Dans
notre cas, nous avions plusieurs projets sur une courte période. De plus
nos sprints duraient une semaine ce qui a maintenu notre motivation au
maximum durant toute notre stage.

D’autre part il faut concentrer toutes les énergies dans le même sens :
réussir le projet. La communication joue alors tout son rôle dans la
résolution des conflits, le plus tôt possible, afin de ne pas disperser
l’équipe. Les conflits sont clairement anti-productifs. Des « clans » peuvent
apparaître, le projet ne devient plus LE centre d’intérêt, le travail devient
une corvée...bref la motivation est à zéro.

En résumé, pour une motivation optimale :

 Pics de motivation réguliers (SCRUM par exemple)

 Environnement de travail épanouissant (Google est un bon


exemple)

 Eviter ou résoudre au plus tôt les conflits.

Cependant, avoir une équipe motivé ne suffit pas, encore faut il qu’elle
soit productive.

21
Gérer les problèmes de productivité

c. Optimiser la productivité

Pour optimiser notre productivité nous pouvons appuyer sur plusieurs


leviers. Le premier est une bonne organisation, un autre est basé sur une
méthodologie qui consiste à pousser à l’extrême certain concept de
management. Cette méthode s’appelle l’eXtreme Programming ou XP.

Une bonne organisation repose surtout dans le fait de limiter les temps
de « déconcentration/re-concentration ». Il est clair que sur une journée de
8h il est impossible d’avoir sa productivité à 100% sur les 8h. Il faut donc
s’organiser et se planifier des plages horaires pour effectuer les tâches
que l’ont fait habituellement. Ensuite il faut arriver à se discipliner pour ne
pas aller voir ses mails ou ses flux RSS toutes les 10 min. Une partie de la
journée sera consacrée au travail (on évitera les plages horaires où l’on
est peu disposé à travailler, après le repas par exemple…), une autre sera
réservée à la gestion des mails, une autre à la veille technologique, etc…
Ainsi lorsque l’on est concentré on le reste plus longtemps et on évite de
perdre du temps à se replonger dans la tâche en cour.

Pour la productivité aussi l’environnement de travail est important. Une


bonne chaise pour éviter des fatigues musculaire dues à une mauvaise
posture. Une machine fiable et performante est un outil de travail
indispensable pour ne pas perdre une heure par jour en ralentissement,
bugs, plantage, et autres problème en tout genre. Un deuxième écran
peut dans certain cas augmenter radicalement la productivité.

Enfin, il y a l’eXtreme Programming. Cette méthode (souvent couplée


avec SCRUM) consiste à pousser à l’extrême certain principe. Ces
principes ne sont pas nouveaux : ils existent dans l'industrie du logiciel
depuis des dizaines d'années et dans les méthodes de management
depuis encore plus longtemps.

21
Gérer les problèmes de productivité

L'originalité de la méthode est de les pousser à l'extrême :

 puisque la revue de code est une bonne pratique, elle sera faite en
permanence (par un binôme) ;

 puisque les tests sont utiles, ils seront faits systématiquement avant
chaque implémentation ;

 puisque la conception est importante, elle sera faite tout au long du


projet (refactoring) ;

 puisque la simplicité permet d'avancer plus vite, nous choisirons


toujours la solution la plus simple ;

 puisque la compréhension est importante, nous définirons et ferons


évoluer ensemble des métaphores ;

 puisque l'intégration des modifications est cruciale, nous l'effectuerons


plusieurs fois par jour ;

 puisque les besoins évoluent vite, nous ferons des cycles de


développement très rapides pour nous adapter au changement.

Nous avons essayé de nous reposer sur ces principes en fonction de


notre environnement. Par exemple nous ne pouvions pas travailler en
binôme vu nos contraintes de temps. De plus la réalisation des tests avant
le développement de l’application n’a pas été respectée. Avec un peu de
recul, je ne sais pas si ceux-ci nous auraient réellement apporté quelque
chose et j’ai envi lors du prochain projet auquel je participerai de
commencer par là.

J’ajouterai que pour améliorer la communication dans l’équipe il est


intéressant de mettre en place un outil de gestion de projet. Le plus connu
et reconnu à ce jour se nomme BaseCamp. Malheureusement il est
payant. Nous avons donc cherché une autre solution. Notre choix s’est
porté sur Zoho Project. Cela nous permettait de consigner nos compte
rendu de début et fin de sprints (annexe 3), de gérer nos deadlines, nos
rapports de bugs etc…

21
Gérer les problèmes de productivité

21
Conclusion

A travers ce rapport nous avons pu voir quelques moyens que j’ai


tenté de mettre en place pendant le stage et qui permettent d’optimiser
les temps de développement d’une application (web dans notre cas).
Parmi ces moyens deux me semblent important : la méthode SCRUM et
l’eXtreme Programming. Les deux ont été conçues pour s’adapter à
l’évolution des besoins et limiter les coûts de ces évolutions. SCRUM
propose une organisation dite « agile » pour gérer les relations avec le
client et les cycles de productions tandis que XP est plus lié au
développement en lui-même et permet de booster la productivité d’une
équipe.

J’avais déjà entendu parler de ces méthodes avant mon stage chez
Unapologetic S.L.. Cependant cela ma permis d’avoir un test en condition
presque réelle (presque parce que nous n’étions que deux développeurs).
Les retombées en termes de satisfaction, de propreté du code, de
productivité, de motivation d’ambiance au sein de l’équipe (étendue) sont
incroyables. Cette expérience m’a donc conforté dans mes choix et il est
clair que l’utilisation de ces méthodes de développement et de
management sera des critères important lors de mes futures recherches
d’emploi.

D’autres part, nous avons vu que certain objectifs n’avaient pas été
atteins. Nous avons proposé à MM. HERNANDEZ et PERROT de continuer à
travailler au développement de leurs outils. Ce genre de développement
est toujours une expérience enrichissante qu’il ne faut pas laisser passer.

Le site de gestion des stocks est d’ores et déjà utilisé par l’entreprise
ainsi que le catalogue qui a été envoyé à tous les clients potentiels. Le site
vitrine est toujours en construction à l’heure où j’écris ces lignes.
Glossaire

 Agile (méthode) : Les méthodes Agiles permettent de concevoir des


logiciels en impliquant au maximum le demandeur (client), ce qui
permet une grande réactivité à ses demandes. Les méthodes agiles se
veulent plus pragmatiques que les méthodes traditionnelles. Elles
visent la satisfaction réelle du besoin du client, et non d'un contrat
établi préalablement.

 AIR : Adobe Integrated Runtime (AIR) est un projet de lecteur universel


RIA de la société Adobe Systems, basé sur le framework Flex, qui
unifiera notamment les moteurs de visualisation des formats PDF
(Acrobat) et SWF (Flash).

 AJAX : AJAX est un acronyme signifiant Asynchronous JavaScript and


XML (« XML et Javascript asynchrones »), et désignant une solution
informatique libre pour le développement d'applications Web. Ce
concept est très lié au concept de web2.0 et d’application cliente
riches.

 Aptana : Aptana est un environnement de développement intégré


orienté web, multiplateformes et open-source. Il facilite l'écriture du
code en fournissant des aides à la saisie pour le JavaScript, l'HTML, les
CSS et PHP.

 eXtreme Programmin (XP) : L'Extreme Programming (XP) est une


méthode agile de gestion de projet informatique adaptée aux équipes
réduites avec des besoins changeants. Elle pousse à l'extrême des
principes simples.

 Flex : Flex est une solution de développement créée par Macromedia


en 2004 puis reprise par Adobe en 2006, permettant de créer et de
déployer des applications Internet riches (RIA) multi plates-formes.

 MCD : Le MCD (Model Conceptuel des Données) est un des


diagrammes de la méthode Merise. C’est à partir de lui que seront
créées les tables d’une base de données.

 SCRUM : Scrum est une méthode agile pour la gestion de projets. Elle
a été conçue pour améliorer grandement la productivité dans les
équipes auparavant paralysées par des méthodologies plus lourdes.
Gérer les problèmes de productivité

 UML : UML (en anglais Unified Modeling Language, « langage de


modélisation unifié ») est un langage graphique de modélisation des
données et des traitements.

21
Annexe 1

Annexes

SOMMAIRE........................................................................................ ..3

REMERCIEMENTS................................................................................. 4

INTRODUCTION........................................................... ........................5

1.1 UNAPOLOGETIC SL.................................................................. ..............8


1.2 NOS PROPOSITIONS................................................. ............................10
1.3 NOS RÉALISATIONS ............................................................. ................11
1.4 ANALYSE DU TRAVAIL EFFECTUÉ....................................................... ..........15
2.1 BIEN GÉRER LES RELATIONS AVEC LE CLIENT............................................ .........21
2.2 LE MANAGEMENT ET L'ORGANISATION.................................................... ........29

CONCLUSION................................................................................. ....35

GLOSSAIRE................................................ .......................................36

ANNEXES....................................................................... ...................38

ANNEXE 1 : MCD........................................................................... ..........1


ANNEXE 2 : CONVENTIONS DE NOMMAGE........................................................... ....2
ANNEXE 3 : COMPTE RENDU DE SPRINT OU « SCRUM PLANNING » DU 10/07.......................3
Annexe 1

Annexe 1 : MCD

3
Annexe 2

Annexe 2 : conventions de nommage

 noms de fonctions, variables, objets, etc explicites :


nomDeDomaine au lieu de ndd

 utilisation des conventions de nommages CamelLowerCase :


nomDeDomaine au lieu de nom_de_domaine

 commentaire du prototype pour chaque fonction

 le site doit être utilisable sans javascript (tel mobile) quelques


exceptions à discuter

 fichier d'accès à la base de données dans ./config/bdd.php

 fichiers de styles dans ./styles/

 fichiers javascript dans ./scripts/

 fichiers de fonctions php dans ./includes/

 utilisations d'un fichier vue.php dans lequel seront les entêtes et


pieds de pages de nos squelettes xhtml. il contiendra par exemple
les fonction headerXhtml(), menu(), footerXhtml()

 utilisation d'un fichier traitement dans lequel seront effectués tous


les traitements. Ils seront ordonnés avec des switchs selon le
paramètre action passé dans les formulaires.

o action=ajouterMagasin

o action=supprimerArticle

 ...

3
Annexe 3

Annexe 3 : compte rendu de sprint ou « scrum planning »


du 10/07

Ajouter un article

 Taille : possibilité de mettre un rang de taille

Exemple: je rajoute un paire de chaussures, je les ai en taille 8-9-..12. Cela serait bien de pouvoir
entrer de la taille 8 - 12 ("-" = "à").

 Lors de la commande possibilité de choisir la pointure exacte par article


Exemple: commande article 33 pointure 9 trois fois et pointure 10 une fois.

 Ajouter origine de la taille


Exemple: 8 US ou UK
Bug : lors de l entrée de l article quand on ajoute une nouvelle marque et une nouvelle
collection, message d'erreur: "Veuillez vérifier le ou les champs suivant : collection"
quand on choisit une marque qui existe déjà et qu’on rajoute une nouvelle collection ca
marche.

Vérification: nom de la marque ajouté n’existe pas déjà dans la base!

L’ajout fonctionne.

A réfléchir : si je rajoute un article dans une nouvelle collection 08 et que après je m aperçois qu’il
existait déjà la collection 2008. Est-ce que je peux modifier les propriétés de l’article et le passer dans
la collection 2008?

Ajouter un magasin
Bug : Quand j ajoute un magasin et son contact. Le "submit query" n’agit pas quand je clique
dessus.

Bug : Quand je clique sur le premier "ajouter" aucun message!??


Amélioration : Quand on ajoute un magasin, rendre obligatoire de l’associer à un contact existant
ou nouveau.

3
Annexe 3

Ajouter contact
Amélioration : Remplacer "aim" par "gtalk"
A réfléchir : Est-ce que c’est possible d’ajouter automatiquement une adresse gmail dans le carré
"gtalk"?!

Ordre de la liste du formulaire:


-choix: Fournisseur / Distributeur
-menu déroulant avec la liste des fournisseurs ou distributeur
-Nom
-Prénom ...

Amélioration : Ajouter nationalité! Dans chaque magasin/distributeur, le personnel est varié et


chacun a sa culture!! Bon de la connaitre!!
Amélioration : Pour le champ poste mettre un menu déroulant avec les postes fixe:
Directeur/RP/Transport/Designer/Commercial/Secrétaire
ainsi quand on veut créer des mailing list on peut faire un tri par profession.
Amélioration : Ajouter une case à cocher "contact principal"
Amélioration : Ajouter case "fax"
Bug : J’ai ajouté un magasin. Quand j ai cliqué sur les boutons "submit query" et "ajouter" aucune
réaction. Je vais ensuite dans ajouter contact pour ajouter un second contact au magasin que je
pensais avoir ajouté. Mais je ne le trouve pas dans la liste de magasin existant. Il existe déjà un
magasin dans la liste "Magasin 1". Je le choisis et clique sur ajouter et toujours pas de réaction!??

Ajouter devise
Amélioration : Ajouter case "ISO 4217 Code"
Exemple: Dollar US ISO 4217 Code=USD
cf: http://en.wikipedia.org/wiki/ISO_4217

L’ajout fonctionne est confirmé

Ajouter fournisseur
champs nécessaires:
"fournisseur"
"website"
"pays"
adresse complète
suivie d’une nouvelle partie :
Puisque qu’on peut avoir plusieurs marques par fournisseur, il faut une table "marque" relié
à celle des fournisseurs et des contacts!!
Possibilité d’ajouter une marque:
champ: "nom de la marque"
"fournisseur" menu déroulant des fournisseurs existant lien direct vers le "contact
principal" de ce fournisseur
"type de produit" =chaussure/habit/équipement
suivie de "ajouter contact"

Amélioration : ces trois parties doivent être remplie pour valider.


Bug : quand je clique sur "ajouter", rien ne se passe!!
3
Annexe 3

Commande reçue:
L’ajout de la devise a bien marché.

Lors de l’ajout des articles dans "Description" j'ai fait des retours à la ligne.

Amélioration : Ajouter <br/> à la fin de ligne.


Maintenant on peut mettre un rang de taille
sélection marque menu déroulant de la taille voulue. Quand on valide la ligne, ajouter une
nouvelle ligne avec le même article.
Amélioration : Si le prix inscrit égale à 0 demander confirmation!

Enregistrement commande fonctionne!

Commande à valider:
L’enregistrement a fonctionné mais n’apparait pas dans "commandes en cours".

Commande validées:
Pas testable

Commande fournisseur:
Le calendrier pour la date fonctionne.
Pas testable

Faire un état des stocks:


Pas testable

L’ordre des éléments du menu gauche:


"Accueil"

"Ajouter un fournisseur"
"Ajouter une marque"
"Ajouter un magasin"
"Ajouter un contact"
"Ajouter un article"

"Nouvelle Commande magasin"


"Commandes magasin en attente"
"Commandes magasin émises"

"Nouvelle Commande fournisseur"


"Commandes fournisseur en attente"
"Commandes fournisseur reçues"

"Faire un états des stocks d'un magasin"

"Ajouter une devise"