Une problématique à gérer : le changement

Les entreprises ont aujourd’hui une importante inertie qui les empêche d’intégrer rapidement les nouvelles technologies et/ou les nouveaux processus. Scub Foundation permet à nos équipes et à nos clients de produire plus rapidement de meilleurs logiciels et de réduire le « time to market », c’est à dire, le temps nécessaire à transformer une idée en solution logicielle.

Afin d’atteindre cette agilité, le développement logiciel doit répondre à deux critères :

  • Il doit être industrialisé pour gérer la complexité.
  • Il doit être incrémental pour gérer les incertitudes.

Pour le premier problème, Scub Foundation nous permet de réduire la complexité grâce à une standardisation du développement. Pour la gestion des incertitudes, nous avons choisi d’utiliser la méthodologie Scrum.

Pour faire simple, cette méthode s’appuie sur le découpage d’un projet en lots, nommés « sprints », ainsi que
l’auto-organisation de l’équipe de développement avec les règles suivantes :

  • Les sprints durent 3 ou 4 semaines.
  • Chaque sprint commence par une estimation suivie d’une planification opérationnelle.
  • Le sprint se termine par une démonstration au client.

Ceci nous permet un démarrage rapide, la possibilité d’adapter le projet au fur et à mesure en évitant un “effet tunnel”

La rédaction du cahier des charges

« Un petit dessin vaut mieux qu’un long discours » est la maxime qui nous guide dans la rédaction de nos cahiers des charges. Nous sommes donc de fervents partisans du maquettage d’écrans avec des outils comme Balsamiq.

Voici un exemple de maquettage réalisé lors de l’un de nos projets :

Exemple de maquette

L’avantage de cet outil est que l’on peut se mettre d’accord avec le client et ses utilisateurs sur ce qu’il veut car tout le monde peut comprendre ce que l’on fait. L’utilisateur est aussi plus impliqué car il obtiendra ce qu’il dessiné, il saisit donc toute l’importance de la démarche.

La rédaction du texte accompagnant se fait ensuite dans un Wiki ce qui permet au client et à nos équipes de travailler en temps réel sur les mêmes documents et ne plus avoir à s’échanger des documents par email.

Processus de développement

Processus de développement

Le schéma ci-dessus montre le processus d’exécution d’une prestation de service en présentant les rôles, les processus et les outils :

  • Les experts métiers réalisent des entretiens avec le client et rédigent un cahier des charges avec des maquettes d’écrans.
  • Le chef de projet va être responsable du projet et des relations avec le client. Il va participer aux estimations et au découpage en itérations.
  • L’ingénieur développeur va développer les itérations avec le socle technique.
  • L’ingénieur testeur mettra en place des tests (unitaires et fonctionnels). Il vérifiera que l’itération correspond bien à l’attente du client.
  • L’ingénieur intégrateur se chargera de la construction d’une version du projet (via l’intégration continue), de versionner les sources et de déployer la version sur un serveur.
  • Le support client va traiter et suivre les retours clients via l’outil Mantis.
  • Le directeur de projets supervise l’ensemble du processus et assure le respect de la qualité, du budget et des délais.



Processus de livraison

Processus de livraison

Avec la nouvelle version de Scub Foundation, l’intégration continue va automatiquement récupérer les sources d’un projet, le compiler, lancer les tests unitaires et faire un livrable (voire livrer).
Le schéma ci-dessus montre le processus de livraison d’un projet en présentant les rôles, les processus et les outils :

  • L’ingénieur intégrateur va se connecter au serveur SVN pour versionner les sources.
  • L’ingénieur intégrateur va ensuite paramétrer Jenkins en indiquant le POM concerné et les identifiants SVN.
  • Jenkins va récupérer les sources depuis SVN, compiler le projet, lancer les tests unitaires et créer un livrable.
  • L’ingénieur intégrateur va récupérer le livrable et le déployer chez le client. Pour certaines lignes (comme la pré production), Jenkins livrera lui même l’application sur le serveur et le relancera.
  • Le chef de projet va mettre à jour Mantis et prévenir le client.



Processus de support

Processus de support

Le schéma ci-dessus montre le processus de maintenance d’une application :

  • Le client entre les informations de son incident directement dans Mantis. Si le client rapporte le problème par téléphone ou par mail, le support client devra retranscrire les informations dans Mantis.
  • Le support client étudie la demande et, si elle est valide, il change l’état du ticket à “accepté”.
  • Le support client affecte le ticket à un ingénieur développeur / testeur qui se charge de la résolution.
  • Une fois le ticket corrigé, l’ingénieur testeur va changer l’état du ticket à “résolu”.
  • L’ingénieur intégrateur va se charger de versionner, constuire et déployer une version. Le chef de projet prévient le client.
  • Le client teste sur la version déployée si le ticket est effectivement bien corrigé. Si c’est le cas, le client doit changer l’état du ticket à “fermé”.