Qu’est-ce qu’un développeur « Full Stack »? et qu’est-ce qu’un « MVP »? le cas de l’app « CoLuncher »

Hercule en "full stack developer"

Etude de cas

Il y a deux mois, Alain, un expatrié français, vétéran du logiciel qui vit depuis 15 ans dans la « vallée du silicium » près de Cupertino, m’a confié une mission globale et un défi : développer, designer et déployer à grande vitesse la première version de CoLuncher, une app mobile sous iOS pour trouver des déjeuners d’affaires autour de centres d’interêt communs. Il m’aura fallu à peu près 300 heures de travail (soit 900km à 3Km/heure ) sur une période d’une quarantaine de jours pour livrer ce projet.  Nous nous apprêtons à publier dans « l’app Store  » la première version de ce produit. Alain recherchait un développeur « Full Stack » et il m’a trouvé!

Qu’est-ce qu’un développeur « Full Stack » ?

Si l’on s’en réfère au grand poète-automate « Google Translate », un « Full Stack Developer » est  « un développeur de pile complète ».  Humm … Comme c’est étrange ! Concrètement, cela signifie que nous avons à faire à un programmeur, non seulement capable d’écrire du code, ce qui est déjà pas mal, mais aussi en mesure de créer, concevoir, piloter, superviser, toute la pile d’un projet mobile, de la conception à l’exploitation, en passant par le développement, le design,  l’expérience d’usage (UX), les processus et méthodes de production, le marketing, l’optimisation pour « l’app store », les campagnes de tests, l’assurance qualité, etc.

Trêve de bavardage! « CoLuncher », à quoi ça ressemble, qu’est-ce que c’est, et comment ça marche ?

(Fig.1) Avec l’application CoLuncher, vous allez rencontrer des personnes intéressantes, étendre votre réseau d’affaires et découvrir de nouveaux restaurants !  Pour ce faire, vous n’aurez qu’à tapauter et sélectionner vos centres d’interêt (Fig.2) et à accepter que l’application vous « géolocalise » (Fig.3). Rien de plus ! C’est simple, non ?

L’application vous proposera des déjeuners pour le jour ou le lendemain, en fonction de savants algorithmes,  de « pattern-matching-géo-compatibles » (Fig.4) .  S’il n’y a pas de déjeuners qui vous conviennent, ne soyez pas timide (Fig.5) et créez votre propre invitation à déjeuner (Fig.6),  ouverte à tous ceux et celles qui à proximité partagent vos centres d’intérêt.

Choisissez des restaurants ou cafés sympas et agréables  (Fig.7).  Des « coLunchers » ne tarderont pas à rejoindre votre déjeuner (Fig.8), et vous en serez notifié en temps réel.  Quand 3 personnes sont inscrites à un déjeuner, le déjeuner est confirmé (Fig.9) et ne peut plus être annulé. Une quatrième personne peut rejoindre le groupe avant le coup de sifflet fixé à midi. Les déjeuners qui ne sont pas confirmés à 11H30 sont annulés.

Mais au fait, comment avons-nous fait ? C’est ce que nous allons voir en faisant l’inventaire, un peu désordonné, des outils, des procédures et des composants que nous avons mis en oeuvre pour en arriver là.

Inventaire désordonné des outils, des procédures et des composants que nous avons mis en oeuvre pour en arriver là.

App cooker de coluncher
App cooker de CoLuncher
  1. Pour établir un bon niveau de communication entre les Vallées  Cévenoles et la « Silicon Valley »,  nous avons instauré une réunion translatlantique quotidienne de 45 minutes en moyenne, en fin d’après midi, tous les jours, via Skype pour le suivi d’avancement et pour discuter de détails techniques et de conception.
  2. Alain a réalisé à ma demande une maquette interactive « Hi-Fi » dans App Cooker, une excellente application pour iPad que je recommande inconditionnellement (capture d’écran ci-dessus). Il a défini le comportement général et de détails des « écrans principaux ». Ce prototype interactif nous a servi de spécification fonctionnelle et de première itération pour qualifier l’expérience d’usage.  Alain a mis à jour le « mock-up » deux ou trois fois pendant les premières semaines, et l’a envoyé à quelques connaissances via AppTaster pour « tâter » le terrain et avoir de premiers retours  d’utilisateurs.
  3. Très rapidement, nous avons eu une application fonctionnelle sous iOS, que nous avons transmise  à nos testeurs avec HockeyApp et TestFlight. Nous avons déployé quelques versions Alpha et Beta, et neuf versions « candidates » à la publication.
  4. J’ai développé l’application cliente pour iOS7 et 8 en développement natif avec le iOS SDK 8.1. en Objective C 2.0. Je n’ai pas opté pour le langage SWIFT qui ne me permet pas encore d’améliorer ma productivité.
  5. Pour automatiser la mise à jour des tierces ressources, j’ai eu recours à Cocoapods (un gestionnaire de dépendance).
  6. J’ai écrit quelques « tests unitaires » au cas où, mais l’on ne peut pas dire que nous ayons adopté une approche « guidée par les tests ».
  7. J’ai écrit la baie de « web-services » en PHP pur et sec, sans aucun « framework », en essayant de respecter au maximum l’orthodoxie des architectures « Restfull« . J’ai  édité le code dans Zend Studio, Nano et VI selon les situations.
  8. J’ai écrit des routines de push en PHP socket au-dessus du protocole TLS (Apple ne supporte plus SSL depuis quelques jours).
  9. Pour assurer la  persistence des données, j’ai choisi MongoDB, une base de donnée NOSQL orientée document, très efficace pour manipuler des grandes quantités et filtrer des données géolocalisées en temps réel. Outre la très bonne performance de l’engin et sa capacité à répartir la charge sur des machines multiples, MongoDB est une base sans schéma, ce qui réduit considérablement les temps de mise au point et reporte la modélisation principalement du côté des couches clientes consommatrices ( CF. l’article Why-schemaless ?)
  10. Nous avons déployé sous Linux, Debian, mon environnement de prédilection, sur une infrastructure virtualisée pour une meilleure « scalability ».
  11. Pour administrer la chose, nous utilisons Virtualmin, un panneau d’administration d’Hôtes virtuels.
  12. Comme serveur web,  nous utilisons Apache 2 (Nous aurions pu lui préférer NGINX).
  13. J’ai « dessiné » quelques ressources graphiques comme les croix et coches de validation colorées sous Illustrator. Et nous avons fixé la palette de couleurs dans Adobe Color .
  14. Nous gérons les sources et le « versionning »  avec l’incontournable et merveilleux GIT.
  15. Pour le suivi de production et la gestion des cas, nous  avons eu recours à Redmine (parfaitement intégré avec GIT).
  16. Pour pouvoir analyser et mesurer les installations et le comportement des utilisateurs, et améliorer à moyen terme l’application, nous avons modérément integré Google Analytics.
  17.  Pour gérer les retours utilisateurs et analyser les  « crashs »,  nous faisons usage d’HockeyApp.

spring-board-bpds

Avant de conclure, je tiens à souligner que je n’ai pas dessiné l’icône de l’application – le fameux « Burger cravaté ». J’ai proposé des solutions alternatives toutes rejetées. L’icône me semble vilaine, peu compatible avec la promotion de l’activité physique, et  inutilement phallocratique. Mais je vous le demande, l’icône d’une application mobile a-t’elle une réelle importance ?  Pas tant que ça ! Elle doit surtout être facile à mémoriser, et c’est le cas.  Je profite de cette occasion pour vous écrire combien plus encore je déteste la mascotte et icône de Se Coucher Moins Bête. J’essaie d’ailleurs d’en venir à bout depuis des années, en vain : Philippe reste sourd à mes régulières et insistantes demandes. Alors au passage,  si vous êtes de mon avis, n’hésitez pas à le lui faire savoir.

Et oui ! Fabriquer une « app » n’est pas si simple que ça, et demande des compétences trans-disciplinaires. Confier son développement à quelqu’un à même d’intégrer toutes ces dimensions, c’est réduire le temps de mise au point, et délivrer plus rapidement des produits et services innovants. Ben justement, les premiers de série, les versions ø, c’est ma spécialité ! Je suis un développeur « Full Stack », voilà c’est dit, maintenant vous le savez !

PS :  une dernière petite chose, un « M.V.P. », au fait, qu’est-ce que c’est, hein ?

Un produit  limité fonctionnellement à son strict minimum, un ballon sonde, ou preuve du concept, pour vérifier si l’affaire intéresse les usagers : les anglo-saxons désignent cela par l’acronyme  « M.V.P »  ou « Minimal Viable Product ».  Le terme a été popularisé par Eric Ries, gourou du mouvement des « lean start up » qui prône l’art de l’échec, l’usage parcimonieux des ressources, et fait l’éloge de la vitesse et de la souplesse.

CoLuncher est un exemple de typique de « Minimal Viable Product », certifié conçu-dessiné-et-télé-programmé 100% en marchant.

4 réflexions au sujet de « Qu’est-ce qu’un développeur « Full Stack »? et qu’est-ce qu’un « MVP »? le cas de l’app « CoLuncher » »

  1. « …de la conception à l’exploitation, en passant par le développement, le design, l’expérience d’usage (UX), les processus et méthodes de production, le marketing, l’optimisation pour “l’app store”, les campagnes de tests, l’assurance qualité, etc. »

    Salut Benoît
    ce truc m’a fait réagir ! Ce serait faire peu de cas je trouve du design, du UX et du marketing qui sont des jobs à part entière que d’exiger du dev. qu’il s’en charge. En fait c’est surement un gage d’échec ! Disons qu’un bon développeur doit assurément être conscient de l’importance cruciale de ces étapes et intégrer ces exigences à sa reflexion.

  2. Il est hors de propos d’éliminer des talents ou de concentrer tous les métiers sur une seule tête. Ce serait impossible, et probablement pas souhaitable. Nous parlons fabriquer une tranche de produit minimale de qualité.

    Dilemme du fromage : « Dans quel sens doit-on couper la tranche? » Le tweet de Jussi Pasanen @jopas du 26 sept reproduit ici, illustre la nécessité d’opérer une coupe transversale.

    une tranche de produit

    Cf. l’image ci-dessous, extraite d’un article sur les M.V.P publié sur le blog des « singes véloces » (et attribuée aux équipes de Spotify).
    M.V.P construction progressive

    Je suis plasticien de formation, formé à l’image et au sens, développeur d’expérience, et je me sens qualifié pour fabriquer avec célérité des trottinettes honorables, pas des bagnoles, et surtout pas des tanks, d’ailleurs, pour être sincère, je préfère la marche à pied! CQFD

Les commentaires sont fermés.