LA MÉTHODE DE DÉVELOPPEMENT MISHOP

L'évolution de miShop est permanente, nous délivrons une nouvelle version par mois à minima. Chaque nouvelle version profite à tous nos utilisateurs, c'est un des bénéfices du mode SaaS (logiciel utilisé en tant que service Web).

Présentation

Les évolutions sont fonctions de 3 éléments :

  • les besoins et demandes de nos clients
  • notre plan d'évolutions fonctionnelles
  • l'environnement (adaptation aux nouvelles règles de référencement Google, évolution de la sécurité des systèmes de paiement, etc...)

 

 

L'équipe de développement de miShop est composée de six personnes : Chef de projet, développeurs et infographiste.

 

Tous n'ont qu'une seule ambition : vous délivrer une application intuitive mais riche en fonctionnalités !

 

L'équipe développe selon la méthode de programmation orientée objet, avec Php et Javascript principalement, sur une base de données MySQL. La gestion de projet est assurée par REDMINE tandis que les versions sont gérées via GIT.

Le développement 'Agile'

Nous souhaitons vous offrir la meilleure adéquation entre miShop et votre besoin. Notre philosophie est d'être à l'écoute tout en étant force de proposition, en cherchant des solutions créatives pour répondre à vos enjeux métiers. 

Nous préférons nous reposer sur le potentiel d'un collectif plutôt que sur les directives et les décisions d'une seule personne. Nous préférons multiplier les échanges et les interactions pour limiter les incompréhensions qui entraînent des retards. Notre méthodologie dite 'Agile' nous permet d'opérer des changements de direction en cours de projet, à moindre frais plutôt que de continuer dans l'erreur. 

 

L'agilité est plus qu'une méthode pour notre équipe de développement miShop, c'est un état d'esprit.

Les environnements

Nous distinguons 3 environnements :

  1. les environnements de développement 
  2. l'environnement de validation
  3. l'environnement de production

Chaque développeur a son environnement de développement spécifique. Un référentiel de sources permet de partager les évolutions du code une fois les tests unitaires effectués. Les sources de l'environnement de validation évoluent automatiquement, en même temps que ceux du référentiel. Plus globalement, notre référentiel de source fait partie intégrante d'un logiciel de suivi de version : il s'agit de GIT. Nous sommes donc capables, lors d'une évolution, de revenir en arrière ou de maintenir plusieurs branches de développement permettant à plusieurs développeurs d'avancer sur des fonctionnalités différentes qui seront ensuite regroupées au sein du projet principal.

 

Nos clients ont accès à l'environnement de validation. Cela permet :

  1. de voir le projet avancer en évitant l'effet "tunnel"
  2. de valider les nouvelles fonctionnalités, les écrans et leur ergonomie
  3. de tester dans un environnement stabilisé

On évalue, on ajuste et on progresse

Ce cycle vous permet d’être au plus près des évolutions de miShop.

 

Vous disposez d'accès à notre plate-forme collaborative de suivi de projet, REDMINE, qui vous permet, sur un extranet dédié à votre projet, de déposer vos demandes :

  • pour des corrections de bugs (anomalie)
  • pour des cas non traités (évolution)
  • pour des modifications ergonomique (évolution)
  • pour de nouvelles fonctionnalités
  • voir pour de l'assistance

 

Chaque demande est suivie depuis sa création jusqu'à sa réalisation/résolution. Une personne lui est affectée tout au long de sa prise en charge et elle possède un statut qui évolue :

  • Nouveau : la demande vient d'être créée.  
    Si elle n'est pas assignée, c'est qu'elle n'a pas encore été analysée et donc prise en charge.
    Si elle est assignée à un développeur, c'est qu'elle a été acceptée et ajoutée à la feuille de route
  • En cours : la demande est en cours de développement. Elle est assignée à un développeur.
  • A tester : la demande a été développée, testée unitairement par le développeur et intégrée à l'environnement de validation.        
    Elle est d'abord assignée au chef de projet chargé de tester à son tour et de valider son bon fonctionnement. Si c'est  le cas, elle est ensuite affectée par le chef de projet au demandeur originel chargé de la valider avant mise en production. Si elle ne passe pas ces deux étapes, elle retourne en statut "En cours", affectée au développeur.
  • A intégrer : (optionnel) dans le cas de demandes faisant intervenir de l'intégration HTML (développement internet ou extranet), il peut être nécessaire que notre infographiste mette en forme les modifications. Cette phase se déroule entre la phase de test par le chef de projet et la phase de validation par le demandeur. Une fois l'intégration effectuée, la demande repasse en statut "A tester", affectée au chef de projet.
  • A mettre en production : la demande a été validée par le demandeur, elle est en attente d'intégration à l'environnement de production.
  • Résolu / Fermé : la demande est en production. On indique "résolu" dans le cas des anomalies et "fermé" dans les autres cas.
  • Rejeté : la demande n'a pas été prise en charge par l'équipe de développement pour diverses raisons (doublon, injustifiée, complexité...)

Une demande est aussi caractérisée par son degré d'urgence qui correspond à la priorité avec laquelle elle va être traitée. Cette priorité peut être définie par le demandeur et révisée par le chef de projet avant attribution au développeur. Les différents niveaux de priorité sont : 

  1. suggestion : la demande pourra éventuellement être traitée si sa complexité le permet, à la fin du projet.
  2. bas : la demande devra être traitée en fin de projet.
  3. normal : la demande est traitée dans le cadre du déroulement normal du planning.
  4. haut : la demande doit être la prochaine prise en charge.
  5. urgent : la demande est bloquante pour l'avancement du projet ou pour au moins un utilisateur en production. Elle doit être prise en charge rapidement.
  6. immédiat : la demande est bloquante pour tout le projet ou tous les utilisateurs en production. Elle doit être traitée toute affaire cessante.

 

A noter que pour les demandes en priorité "immédiate" ou "urgente", il est possible que nous devions apporter la correction directement sur l'environnement de production. L'environnement de validation et le référentiel de source seront alors mis à jour, une fois la correction faite. Il est possible que nous ayons à faire de même pour des demandes que nous ne reproduisons que sur cet environnement de production. Il est important de comprendre qu'il nous est difficile de traiter une anomalie que nous ne savons pas reproduire.

 

REDMINE permet aussi de mettre à disposition des documents utiles :

  • maquettes
  • évolution de la structure de la BDD
  • suivi des mises en production (date - fonctionnalité)
  • ...

 

Grâce à GIT, vous avez aussi à votre disposition dans REDMINE le référentiel et le suivi des évolutions des sources.

Cet extranet continuera à nous servir de base d'échanges tout au long de la vie de l'application, même une fois celle-ci en production. De même que l’environnement de validation qui nous permet de mettre en œuvre de futures évolutions sans effets de bord sur votre site en production.

Ergonomie et infographie

En parallèle du développement de miShop, vous pouvez avoir des besoins spécifiques auxquels nous sommes capable de répondre en mode projet.

 

Une des premières étapes du projet consistera à réaliser une maquette des pages importantes. Une maquette est une représentation sous forme d’image : elle fixe les éléments graphiques et ergonomiques. Pour pouvoir vous proposer une première maquette, notre infographiste a besoin de connaître votre cible et vos objectifs mais aussi vos préférences. Pour cela, nous vous demanderons de nous fournir des références de sites pour lesquels vous trouver un intérêt : qualité graphique, ergonomie, disposition, le menu, une simple idée,… Ces références serviront à orienter le travail de notre équipe.

 

Il peut aussi être envisagé en premier lieu une version dite 'en fil de fer' (ou wireframing) qui consiste plus à schématiser les différents éléments à présenter sur les pages et éventuellement, à prévoir les enchaînements entre elles. Le maquettage se déroule comme le traitement d’une demande fonctionnelle : par des échanges entre notre infographiste (et non un développeur) et le donneur d’ordre jusqu’à validation par ce dernier.

 

L’étape suivante est le découpage et l’intégration HTML de la maquette pour valider l’ergonomie et le dynamisme; toujours avec ce cycle de présentation/validation/intégration des évolutions demandées. Pour chaque modèle de page du site (la première est évidemment la page d’accueil), nous reprenons ce cycle. Pour les pages simples, la phase de maquette Photoshop peut être omise.