Rapport de Stage_1

2007/2008

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

Antoine Guiral

Maitre de stage : Morgan Perrot

Tuteur de stage : Pierre Chartagnat

Maitre de stage : Morgan Perrot

Tuteur de stage : Pierre Chartagnat

Sommaire

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

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

1. UNAPOLOGETIC : SES BESOINS, NOS SOLUTIONS ........................................................................ 6

1.1 UNAPOLOGETIC SL.........................................................................................................................7A.PRÉSENTATION........................................................................................................................................7B. LES BESOINS D'UNAPOLOGETIC SL.............................................................................................................71.2 NOS PROPOSITIONS........................................................................................................................81.3 NOS RÉALISATIONS.........................................................................................................................9A. ENVIRONNEMENT DE TRAVAIL.....................................................................................................................9B. LES STOCKS...........................................................................................................................................9C. LE CATALOGUE.....................................................................................................................................10D. LE SITE VITRINE.....................................................................................................................................10E. LE RESTE..............................................................................................................................................101.4 ANALYSE DU TRAVAIL EFFECTUÉ......................................................................................................11A. PLANNING PRÉVISIONNEL ET RÉEL.....................................................................................................11B. ANALYSE......................................................................................................................................12C. CONCLUSION................................................................................................................................12

2. GÉRER LES PROBLÈMES DE PRODUCTIVITÉ ................................................................................. 13

2.1 BIEN GÉRER LES RELATIONS AVEC LE CLIENT........................................................................................14A. ÉVALUATION DES BESOINS...............................................................................................................14B. COMMUNICATION.........................................................................................................................15C. FLEXIBILITÉ, ADAPTATION : SCRUM.................................................................................................162.2 LE MANAGEMENT ET L'ORGANISATION..............................................................................................19A. TRAVAILLER À PLUSIEURS................................................................................................................19B. GÉRER LA MOTIVATION DE L'ÉQUIPE.................................................................................................20C. OPTIMISER LA PRODUCTIVITÉ...........................................................................................................21

CONCLUSION ................................................................................................................................. 23

GLOSSAIRE

ANNEXES

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.

13

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.

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.

1. Unapologetic : ses besoins, nos solutions

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


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


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 ».

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


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 !

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


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


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 imposent souvent de revoir en profondeur le travail effectué. Les changements qui en

13


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


13

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)*.

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)*.

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

21

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


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


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.

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

21


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 :

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

21


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

21


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'organisationTravailler à 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 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

21


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.

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

21


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.

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


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


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.

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.

Annexe 1

Annexes

ANNEXE 1 : MCD 1

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

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=ajouterMagasino 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 articleExemple: commande article 33 pointure 9 trois fois et pointure 10 une fois.

Ajouter origine de la tailleExemple: 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étaireainsi 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=USDcf: http://en.wikipedia.org/wiki/ISO_4217

L’ajout fonctionne est confirmé

Ajouter fournisseur

champs nécessaires: "fournisseur" "website" "pays" adresse complètesuivie 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/équipementsuivie de "ajouter contact"

Amélioration : ces trois parties doivent être remplie pour valider. Bug : quand je clique sur "ajouter", rien ne se passe!!

http://en.wikipedia.org/wiki/ISO_4217

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 taillesé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"

Documents

Rapport de Stage_1