Organisation des projets de développement d'application

La définition du besoin

Un projet débute par la découverte du métier du donneur d'ordre par nos équipes : nous avons besoin de savoir ce que vous faites et comment vous travaillez.
L'acquisition de la connaissance métier continuera tout au long du projet.
Il faut définir ce qui a de la valeur pour vous afin de concentrer notre effort sur l'essentiel

En début de projet, nous vous proposons une réunion de lancement qui va permettre de présenter comment va se dérouler le projet. Elle permettra de :

Présenter les équipes,
Rappeler l'objectif,
Définir les priorités des fonctionnalités ou écrans à livrer,
Définir des jalons,
Définir le planning,
Coordonner les équipes.

Les priorités peuvent évoluées au fil du projet, et vous pourrez aussi réviser votre besoin. Le planning sera révisé en conséquence : nous adapterons le plan en tenant compte des objectifs afin de livrer le meilleur produit final.

Les différentes plates-formes utilisées lors du développement du projet

Nous distinguons 3 environnements :

Les environnements de développement
L'environnement de validation
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 du GDS pour les développements Windev et de GIT pour les autres développements, Php notamment. Nous sommes donc capables, lors d'un projet, 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.

Vous avez accès à l'environnement de validation. Cela permet :

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

Un quatrième environnement dit d'intégration peut aussi être envisagé entre les environnements de validation et de production. Il aura des données très proches de celles de production (J-1 par exemple) et une version des sources égale ou très proche du référentiel (v-1 maximum). Il vous permet de faire de nouveaux tests dans un cadre plus proche encore de celui de production.

La vie du projet

Un planning prévisionnel est réalisé dès le lancement du projet. Il définit les priorités des fonctionnalités à réaliser et l'ordre dans lequel elles vont être développées. Ensuite l'équipe de développement met au point des solutions et commence rapidement à livrer des composantes.
Dès que possible, nous livrons des éléments fonctionnels qui sont intégrées à l'environnement de validation et dont vous êtes informés. Vous pouvez les tester et nous faire part de vos remarques.

On teste, on ajuste et on progresse.

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 :

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

2. En cours : la demande est en cours de développement. Elle est assignée à un développeur.

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

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

5. A mettre en production : la demande a été validée par le demandeur, elle est en attente d'intégration à l'environnement de production.

6. Résolu / Fermé : la demande est en production. On indique "résolu" dans le cas des anomalies et "fermé" dans les autres cas

7. Rejeté : la demande n'a pas été prise en charge par l'équipe de développement pour diverses raisons (doublon, injustifiée, complexité...)

REDMINE

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

REDMINE permet aussi de mettre à disposition des documents utiles :

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

Dans le cadre d'un projet où GIT est utilisé, 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.

Les demandes prioritaires

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.

Recette

Même si chaque fonctionnalité est validée tout au long du développement, lorsque celui-ci touche à sa fin, quand la mise en production finale approche, une réunion de recette est prévue permettant de vérifier que chaque fonctionnalité a bien été développée conformément aux attentes initiales. Les écarts seront justifiés.

Une fois cette étape réalisée et l'ensemble de la prestation réglée, vous devenez le propriétaire du produit et des sources.

Infogérance de l'application

Le support logiciel débute au 2ème mois après la mise en production et est souscrit pour une durée d'au moins un an.
Dans le cas contraire, la période de garantie d'un mois à partir de la mise en production est aussi appliquée mais ensuite les interventions sur le projet seront facturables.

Nous contacter